What Done Looks Like

Most AI projects that "fail" produced a working model. What they never produced was a capability — something the organisation can rely on next quarter without the original team.

The gap between a model and a capability

A model is a file. A capability is everything around it:

Data reaching it automatically, in the right shape, every day.
Somewhere it runs reliably, fast enough for whoever is waiting.
Its output arriving where a decision is made, inside the tool people already use.
Somebody trusting it enough to act on it.
Somebody noticing when it degrades, and a route to fix it.
A defined path for the cases it cannot handle.

Only the first two are engineering. The rest are organisational, which is why they are frequently nobody's job.

A definition of done

Before declaring an AI project finished, all of these should be true:

It runs without manual intervention. If a person exports a spreadsheet weekly and runs a script, it is a recurring chore, not a system.
Its output reaches the point of decision. In the CRM, the ticket queue, the dashboard people already have open — not in an emailed PDF.
Its performance is being measured in production, against the criterion agreed at the start.
Uncertain cases have a defined route. Usually to a human, via a confidence threshold.
Someone owns it, by name, with time allocated.
The people affected know how it works well enough to trust it and to challenge it.
You know what it is worth, measured against the baseline.

Point 7 is the one that gets skipped. Many organisations cannot say what their deployed models are worth, which makes the next funding conversation a matter of faith.

Measure against a baseline

A number without a comparison means nothing. "The model is 91% accurate" is not a result. The result is 91% against something:

What do humans currently achieve? If triagers route correctly 94% of the time, a 91% model is a downgrade.
What does the obvious simple rule achieve? If "always route to the biggest queue" gets 68%, then 91% is a real gain.
What did we do before? If nothing was being predicted at all, the comparison is to the cost of not knowing.

Insist on the baseline being measured at the start, alongside the acceptance criterion. Measuring it afterwards is much harder and suspiciously easy to do favourably.

Roll out so that being wrong is survivable

Every model is wrong sometimes. A good rollout assumes it and limits the blast radius.

📅 Timeline

Shadow modeThe model runs on real data and its predictions are recorded, but nothing acts on them. You compare against what humans actually did. No risk, real evidence.

Human in the loopThe model suggests; a person decides. Every correction becomes training data.

Confidence-gated automationThe model acts alone when confident, routes uncertain cases to a person. Most durable production designs live here.

Full automationOnly where errors are cheap, detectable and reversible.

Most systems should stop at the third stage permanently. Full automation is not the goal — it is one option, appropriate when the cost of an error is low and someone will notice it.

Shadow mode in particular is undersold. It costs almost nothing, carries no risk, and answers the question everyone is arguing about: how good is this really, on live data, compared with what we do now?

An insurer builds a model flagging claims for manual review. Technically excellent: it catches substantially more problem claims than the previous rules, with fewer false alarms.

Six months after launch, the assessors are ignoring it. Not refusing — the flags simply do not change what they do. Adoption is near zero and nobody escalated it, because the model is "live" and the project is "delivered".

What went wrong is not in the model.

The assessors were never involved in defining what a problem claim was. The flag arrived as a coloured icon with no explanation, and their first few encounters were with the model's worst errors, which is what a new user notices. They had no way to disagree with it — no feedback button, no route to say "this was wrong and here is why". And nobody had told them what happens if they follow a flag and it turns out wrong: is that on them?

The fixes are unglamorous and cheap. Show the top reasons a claim was flagged, even approximately. Give people a way to disagree, and demonstrably act on it. Involve the assessors in setting the threshold, so they own the trade-off. State clearly who is accountable when the model is wrong. And publish how it performs, honestly, including the mistakes.

A model that people do not trust delivers exactly zero value, regardless of its accuracy. Trust is not a soft nice-to-have around the edges of an AI project. It is part of the deliverable, it has to be designed, and it is usually the difference between a system that changes how work is done and one that quietly becomes wallpaper.

❓ Knowledge Check

A model runs live, is 91% accurate, and its predictions appear in a weekly emailed report. Human triagers currently achieve 94% on the same task. What is the honest assessment?

📚 Flashcards1 / 6

Term

Model versus capability

Click to flip

Definition

A model is a file. A capability is data arriving automatically, somewhere reliable to run, output reaching the point of decision, someone trusting it, someone noticing degradation, and a route for cases it cannot handle.

Click to flip back

💡Key Takeaway

Done means a capability, not a model: running unattended, reaching the point of decision, measured in production against a baseline established at the start, with uncertain cases routed to people and someone owning it by name. Roll out through shadow mode and human-in-the-loop before automating anything, and treat trust as part of the deliverable — because a system nobody believes is worth precisely nothing.