Why most enterprise AI pilots never reach production.

Over the last two years we have either built or inherited eleven enterprise AI pilots. Four are running in production today. Seven stopped. Going back through them, not one stopped because the model was not accurate enough.

How we sorted them

A pilot counted as "reached production" if it was still processing real work six months after handover, without an engineer from our side in the loop. That is a deliberately harsh bar. It rules out the demo that impresses a steering committee and is never mentioned again, and it rules out the system that technically runs but needs a weekly manual intervention nobody wants to own.

For each of the seven that stopped, we wrote down the last real blocker — the thing that was true on the day work paused. Then we grouped them. The grouping is not clean science; it is eleven cases, and the sample is ours, so it carries our biases about which projects we take on in the first place. But the pattern was consistent enough to change how we scope work.

The decision nobody makes

The single most common blocker was not technical. It was that no one had ever written down which decisions the system was allowed to make by itself, which it had to escalate, and who was accountable when it was wrong.

This sounds like a governance formality. In practice it is the load-bearing design decision, because it determines the required accuracy, the interface, the logging, the fallback path and the retraining cadence. A classifier that files a document is a different system from a classifier that suggests a filing to a human — same model, entirely different architecture around it.

Pilots that skip this question don't fail loudly. They produce a model, demonstrate it, and then wait — because deploying it means someone has to sign for its mistakes, and nobody was asked to volunteer for that during scoping.

"We could not deploy it because we could not agree who gets the call when it rejects a legitimate claim." — operations director, financial services pilot, month five

Data access is a political problem wearing a technical costume

Two of the seven stopped on access. In both cases the data existed, was of adequate quality, and could technically be moved. What did not exist was a person with the authority to approve moving it, who was also willing to.

We now treat data access as a milestone with a name and a date attached, resolved before any modelling begins. If nobody can produce a real extract in the first two weeks, that tells you more about the project's chance of shipping than any accuracy number will.

Write the stopping rule first

The four that shipped had something the others didn't: a written condition, agreed up front, under which the pilot would be abandoned. Counterintuitively, defining how to quit is what let them continue. It converted an open-ended research budget into a decision with a date, and it gave the sponsor something specific to defend internally.

A stopping rule is one sentence: if, by week ten, the model cannot match the current manual process on last year's data, we stop and write up why. It has to be measurable, dated, and signed by the person paying.

What we changed

Four things, all of which happen before we write model code:

None of this is sophisticated. It is a week of unglamorous conversation that prevents six months of well-engineered work with nowhere to go. If you are three months into a pilot and cannot answer the ownership question in a sentence, that is the thing to fix this week — not the model.