The numbers are worse than most people assume. RAND Corporation analysed more than 2,400 enterprise AI initiatives and found that roughly 80% fail to deliver their intended business value — about twice the failure rate of ordinary IT projects. MIT's Project NANDA went further, reporting that 95% of generative-AI deployments produced no measurable P&L impact.
Meanwhile 88% of AI pilots never reach production at all, and the average organisation scraps 46% of its proof-of-concepts before they ship. Enterprises spent an estimated $684 billion on AI in 2025. More than $547 billion of it produced nothing measurable.
What makes this interesting is not the size of the failure. It is how consistent the failure mode is. Across both studies the same causes recur: unclear definitions of success, weak data foundations, poor integration into real workflows, and technology chosen before the problem was understood.
The demo is the easy part
Modern foundation models make impressive demos almost trivial. You can wire a retrieval pipeline over your documentation in an afternoon and show something that looks like magic. That demo creates budget, and budget creates a project.
Then the project meets reality. The documents are inconsistent. Half the useful knowledge lives in Slack threads and nobody's sure which version of the policy is current. The model answers confidently and wrongly on exactly the edge cases that matter, and nobody can say how often, because nothing was ever measured.
A demo proves a thing is possible. It tells you almost nothing about whether it is reliable.
The gap between those two states is where most AI budgets die. It is not a modelling gap. It is an engineering and measurement gap.
Failure one: no definition of correct
Ask a team what accuracy their AI feature needs and you will often get a shrug or a number chosen because it sounded reassuring. Without a definition of correct behaviour, there is no way to know whether a change improved things, and no way to catch a regression before a customer does.
This is the single strongest predictor we see. Teams that build an evaluation set before they build the feature ship. Teams that plan to add evaluation later mostly do not. The industry has started to notice — 60% of new RAG deployments in 2026 include systematic evaluation from day one, up from under 30% in early 2025.
An evaluation set does not need to be elaborate. A hundred real questions with agreed-correct answers, assembled by someone who understands the domain, will tell you more than any benchmark score.
Failure two: the data was never ready
Gartner predicts organisations will abandon 60% of AI projects through 2026 due to inadequate data, and only 37% of organisations report confidence in their data practices. Poor data quality already costs the average organisation around $12.9 million a year before any AI is involved.
AI does not tolerate what reporting tolerates. A dashboard with a 3% error rate is usually fine. A model trained on that data learns the errors and reproduces them at scale, confidently, in a system people are told to trust.
This is why we start engagements with a data audit rather than an architecture proposal. Sometimes the honest finding is that the use case cannot be supported yet, and the useful work for the next quarter is fixing the pipeline underneath it.
Failure three: nobody changed how they work
A prediction that arrives in a dashboard nobody opens changes nothing. A risk score in a system the underwriting team does not use is a number, not a decision.
The question worth asking early is: who acts on this output, in which tool, and what do they do differently? If nobody can answer, the project is a research exercise with a product budget. That is not a criticism of research — it is a criticism of the framing that got it funded.
Failure four: it shipped and then decayed
Models degrade. Input distributions shift, upstream schemas change, user behaviour moves. Without monitoring on feature distributions and prediction quality, the first signal is usually a business metric moving in the wrong direction months later.
Anything you deploy needs a plan for how you will know it stopped working. That plan is not optional infrastructure — it is the difference between a system and an experiment.
What the successful ones do differently
The pattern among projects that do reach production is unglamorous. They start from a decision rather than a technology. They establish a baseline — often a simple heuristic — and require the sophisticated approach to beat it. They build an evaluation set early. They ship something narrow into a real workflow and expand from there.
None of that requires a research team. It requires treating AI as an engineering discipline with measurement obligations, rather than as a capability that arrives fully formed with the model.
The organisations getting value from AI are not the ones with the best models. They are the ones who decided in advance how they would know it was working.
If your AI work is stuck between demo and production, the bottleneck is worth diagnosing precisely. In our experience it is almost never the model.