The failure is rarely the model. It's the data access, the integration surface, and a success criterion nobody agreed on. A look at the patterns behind stalled AI programmes.
There is a well-worn statistic in circulation that most enterprise AI projects never reach production. The number moves depending on who is citing it and what they are selling, so it is worth being sceptical of the precise figure. What is not in dispute, for anyone who has worked inside these programmes, is the direction: a large share of enterprise AI work produces a compelling demonstration and no operational change.
What is more useful than the statistic is the pattern. Across the programmes we have been brought in to rescue or restart, the causes cluster tightly — and almost none of them are about model quality.
The pilot runs on data that production will never provide
This is the single most common failure. A pilot is built against an extract — a CSV someone pulled, cleaned by hand, with the awkward records quietly dropped. It performs well, because the data is unrepresentatively clean.
Production data is not like this. It arrives continuously, with missing fields, inconsistent formats, duplicate entities and edge cases that nobody documented because everyone who works with the system has internalised them. The model that scored well on the extract performs materially worse on the real distribution, and the team's first instinct is to blame the model.
The organisations that get past this treat data access as the first engineering problem, not an input assumption. If reaching production data requires six weeks of pipeline work, that is the honest project timeline — and it is better to know it at the start than to discover it after the steering committee has seen the demo.
Nobody agreed what success meant
Ask three stakeholders what a pilot needs to demonstrate and you will frequently get three answers: that the technology works, that it saves a specific amount of time, and that it is safe to deploy. These are different bars, and a pilot designed for the first will not satisfy the third.
The absence of an agreed threshold is what turns pilots into permanent pilots. Without a number defined in advance, there is always a reason to run one more iteration, and no moment at which the thing is finished.
Define the bar before building: which process, measured how, improved by how much, at what error rate, judged by whom. If that cannot be agreed, the disagreement is the actual project risk — and it is better surfaced in week one than in month nine.
The integration surface was never scoped
An AI system that produces an output a human then re-keys into another system has automated the thinking and left the work. The value is in the integration, and integration is where the effort actually goes: authentication, rate limits, error handling, idempotency, and the permissions model of every system being touched.
This is unglamorous work and it is routinely underestimated, particularly by teams whose experience is in modelling rather than systems engineering. In our experience the integration and operational surface is usually the majority of the build.
Governance arrived after the architecture
In regulated environments, a pilot that cannot demonstrate who accessed what, what the model saw, and why it produced a given output will not pass review — regardless of how well it performs.
Retrofitting this is expensive. Access control in particular has to be enforced at the retrieval layer: if a system can retrieve any document and is merely instructed not to reveal certain ones, it has no meaningful access control at all. That is an architectural decision made early, not a policy applied late.
What the successful programmes do differently
They start narrow. One process, one clearly bounded scope, one measurable outcome. This is less exciting than a platform strategy and considerably more likely to produce something that runs.
They resource the unglamorous majority — data pipelines, integration, evaluation harnesses, monitoring — rather than concentrating effort on model selection, which is usually the most tractable part of the problem.
They set an evaluation bar in advance and hold to it, including being willing to stop. A programme that concludes in month three that a use case is not viable has produced a genuinely useful result at low cost.
And they build for the operational reality from the start: what happens when the model is unavailable, when costs spike, when quality drifts, when a user reports a wrong answer. These questions have answers in production systems and are usually unasked in pilots.
The uncomfortable conclusion
Most stalled AI programmes are stalled data and engineering programmes wearing a more fashionable label. The organisations that have a governed data platform, clean integration surfaces and disciplined delivery practice find AI adoption comparatively straightforward. The ones that do not find that AI exposes every weakness in their data estate at once.
That is not an argument for delaying AI work until the foundations are perfect — that day does not arrive. It is an argument for being honest about which problem you are actually solving in the first phase, and for resourcing it accordingly.
