AI on a Process Nobody Defined
Most AI pilots do not fail because the model is wrong. They fail because nobody can say what a correct answer looks like, so the output cannot be evaluated and the pilot cannot be trusted into production.
The demo went well. It usually does. Someone points a capable model at a real business problem, it produces plausible output on a handful of examples, and the room agrees this is going to save an enormous amount of time.
Then it stalls. Not dramatically. It just never quite reaches production, and after a few months it is quietly described as a learning exercise.
The post-mortem usually blames the model, the data, or the vendor. It is rarely any of those. The far more common cause is that the pilot was built on top of a process that had never been written down, so there was no definition of correct, and therefore no way to prove the thing was safe to rely on.
That is broken work, and putting AI on top of it does not fix it. It makes it faster and harder to see.
The missing artifact
Every production system that makes decisions needs something that most stalled pilots never had: a statement of what it is supposed to get right.
Not a vibe. Not "it should be helpful." A specification, at the level of "given this input, this output is correct, this one is acceptable, and this one is a failure that must escalate."
If that artifact exists, evaluation is straightforward. You build a set of representative cases, including the awkward ones, and you measure. The result is a number you can put in front of a risk committee.
If it does not exist, you are left assessing output by reading it and forming an impression. That works for ten examples and collapses at a thousand. It also means nobody can ever sign off, because signing off requires a threshold, and there is no threshold without a definition.
Demos are judged by whether the output looks good. Production is judged by whether the failures are tolerable. You cannot characterise failures you have not defined, which is why so many pilots work beautifully and then cannot get through review. Nothing is wrong with them. Nothing can be proven right about them either.
Where the definition went
The uncomfortable finding in most of these projects is that the process was never defined for humans either.
The work was being done, and done competently, by people applying judgment they had learned rather than been taught. Ask three experienced people how they handle a particular case and you get three defensible answers. That variation was invisible while humans did it, because each person was internally consistent and nobody compared notes.
The moment you try to automate it, the variation becomes the blocker. You cannot encode a rule that three people state differently. So the AI project stops and becomes, accidentally, the first serious attempt anyone has made to write the process down.
This is not a failure of the AI project. It is the AI project discovering the actual problem. The mistake is treating that discovery as a delay rather than as the deliverable.
If an AI pilot stalls because nobody can agree what the right answer is, the pilot has not failed. It has found the operating problem: a process running on undocumented judgment. Fixing that is worth more than the automation was.
The model is not the system
A model produces text. A system produces an outcome someone is accountable for. The distance between those two is where production lives, and it is made of parts that have nothing to do with the model.
Authoritative context. What the system is allowed to treat as true, and where that comes from. If two internal sources disagree about a fact, a model will confidently pick one. That is not a model flaw. It is an unresolved system-of-record question surfacing.
Defined inputs and outputs. Structured, so downstream systems can act on them and so failures are detectable rather than merely unattractive.
A stated boundary. What the system may do, what it must not do, and where a human decides. Written down before launch, not discovered after an incident.
Deterministic validation where it exists. Plenty of correctness is checkable by rule. Checking it by rule is cheaper and more reliable than hoping the model got it right.
An evaluation set with the hard cases in it. Including adversarial and edge cases, because the average case was never the risk.
An escalation path. What happens when the system is unsure, and who receives it. A system with no route for "I do not know" will guess.
Instrumentation. Quality, cost, latency, and exception rate, visible over time. Without this you cannot tell degradation from a bad week.
None of that is exotic. All of it assumes a defined process underneath, which is exactly what was missing.
The order that works
Pick a task narrow enough to be specified. Not "handle support." One decision, with a stated input and a stated output. Broad scopes are attractive and unevaluable.
Write the rules down with the people who actually apply them. Sit with them through real cases and ask why after every decision. Expect disagreement. The disagreement is the finding.
Sort what you get. Deterministic rules should be code, not prompts. Genuine judgment should stay with a human, with a stated basis. Rules that turn out to be workarounds for a broken input should be fixed upstream instead of encoded.
Only then decide whether the remainder needs a model at all. A meaningful share of automation candidates turn out to be deterministic once written down. Language in the input is not the same as ambiguity in the decision, and it is a bad reason on its own to reach for a probabilistic system.
Build the evaluation before the feature. If you cannot write the acceptance cases, you are not ready, and building anyway just defers the discovery.
Deploy into real work with the boundary and escalation in place, and measure against the original operating problem rather than against whether the tool works.
The expensive version of getting this wrong
The worst outcome is not the stalled pilot. A stalled pilot costs money and some credibility, and the organisation moves on.
The worse outcome is the pilot that succeeds at automating a process nobody agreed on. Now the undefined process runs at volume, applies consistently for the first time, and is much harder to change, because it is embedded in a system somebody paid for and staked their reputation on. The variation that used to be visible as three people disagreeing is now invisible as one system being confidently wrong in a consistent direction.
Speed applied to an undefined process is not an improvement. It is a commitment.
For the AI work currently in flight: could you write down, today, the acceptance criteria for what it is supposed to get right, including the cases where it should refuse and escalate? If not, that is the next piece of work, and it is worth doing whether or not the AI ships.
This is not an argument against AI
Worth saying directly, because it is easy to read this as caution dressed up as rigour.
AI is genuinely useful, including for work that used to require a person, and the organisations that deploy it well will pull ahead of the ones that do not. The argument here is not that it should wait.
It is that the thing that determines whether it works is almost never the model. It is whether the operation underneath it has a definition, an owner, a source of truth, and a stated boundary. Companies that have those deploy AI quickly and safely. Companies that do not run pilots for two years and wonder why nothing reaches production.
The work of defining the operation is not a prerequisite you can skip by choosing a better vendor. It is the work.