Almost every enterprise AI project we see has already had a successful pilot. That is not the hard part. The hard part is the eighteen months afterwards, when the thing that worked in a demo is still not doing any real work.
This is the normal outcome, not the exception
The numbers are worse than most teams assume. MIT’s Project NANDA found that roughly 95% of generative AI pilots deliver no measurable return on the profit-and-loss statement. Gartner puts the figure for AI agents specifically at 89% of pilots failing to reach production. S&P Global found the average organisation scraps 46% of its proofs of concept before production.
The corollary is more interesting than the failure rate. Gartner reports that the agent pilots which do survive return 171%. The gap between the two outcomes is not model quality, everyone is using much the same models. It is what surrounds them.
It is rarely the model that fails
Everyone has access to much the same models, and they are mostly good enough. What differs between the projects that ship and the ones that do not is everything built around them.
Nobody can explain a decision to the person who has to sign it off. The data the system needs sits behind a boundary it is not allowed to cross. The team it was built for has quietly gone back to the spreadsheet. None of those are model problems. All of them are engineering and governance problems, which is better news than it sounds: they are the kind you can design for.
Nobody can audit the decision
A model that produces a good answer and cannot say why is not usable in a regulated process. It does not matter how often it is right. When a client, an auditor or a regulator asks how a conclusion was reached, "the model said so" ends the conversation and usually ends the project.
This is not solved by adding an explanation after the fact. A system that generates a plausible-sounding justification for an answer it already gave is worse than no explanation, because it invites confidence it has not earned. The output has to be traceable to the records it came from, by construction.
Nobody measured whether it works
Trust is downstream of measurement. Teams say a system is "difficult to trust" when what they mean is that its behaviour is unpredictable and nobody has quantified how unpredictable.
This is measurable and mostly unmeasured. A 2025 MIT Sloan study found that 61% of enterprise AI projects were approved on projected returns that were never measured after launch. The business case was made once, at the start, and never checked.
A recent project of ours makes the point better than an argument can. We scored four models against seven real cases from the work itself.
Judged on the headline score alone, the best-looking model passed none of the seven. Measuring a second dimension picked a different model, which passed all seven.
Nothing about the models changed between those two sentences. The only thing that changed was what we chose to measure, and it was the difference between shipping nothing and shipping the whole thing.
If you cannot say where a system fails, you cannot honestly say it works.
The data is not allowed to move
This is the single largest barrier, and by some distance. Deloitte found data privacy and security cited by 71% of enterprises as the obstacle to wider deployment, ahead of accuracy at 58% and cost at 44%. Roughly 60% of AI leaders name cross-border data restrictions specifically, and NTT DATA research puts privacy and sovereignty at the centre of where enterprise AI is stalling.
Plenty of capable systems die at the compliance review for exactly this reason. Client confidentiality, the Data Privacy Act, sector rules, or simply a policy that customer records do not leave the building, and the architecture assumed everything would be sent to somebody else’s cloud.
This is worth establishing in week one rather than month six. If the data cannot leave, that is a design constraint, not an objection to be argued with. A well-tuned smaller model running on hardware you control is frequently a better answer than a frontier model you are not permitted to send anything to.
The costs arrive later than the pilot suggested
Pilot economics mislead. MIT Sloan data puts cost overruns for retrieval-augmented generation projects at 380% above pilot projections once they run at production scale, with a median of fourteen months from approval to shutdown. A pilot runs on a handful of documents and a few dozen queries a day; production runs on the whole archive, every day, with retries.
Per-token pricing scales with usage rather than with value delivered, which is a poor shape for a system whose usage you want to grow. It is one of the reasons we keep returning to smaller models: the economics stay legible as volume rises.
The people were never brought along
The failure mode that gets discussed least is the one we see most. A capable system is delivered to a team that was given the tool and not the training, and within a month they have routed around it.
This is a rational response, not resistance. Someone who cannot tell a good answer from a confidently wrong one is right not to rely on it. Spotting a hallucination, writing a prompt that constrains rather than invites invention, knowing which tasks a model is unsuited to, these are learned skills. Nobody acquires them by being sent a link.
The surveys bear this out: alongside privacy, respondents consistently cite skills shortages, unrealistic expectations and employee resistance among the leading barriers. Those are three descriptions of the same gap.
What actually helps
None of this requires a different model. It requires deciding, before anything is built, how you will know whether it works.
- Define the cases the system must handle, and score against them, so "it works" becomes a number rather than an impression.
- Build so that outputs trace to their sources, rather than bolting on an explanation afterwards.
- Establish the data constraint in week one and design within it, instead of discovering it at the compliance review.
- Model the production cost, not the pilot cost, before committing to an architecture.
- Train the people who will use it while you build it, not after go-live.
None of that is glamorous. It is the difference between a pilot and a system.