The pattern is consistent enough to be boring. A team builds something impressive in three weeks, demonstrates it to an approving room, and then spends nine months not shipping it. Nobody is incompetent and nothing dramatic goes wrong. The thing simply never arrives.
What the evidence says, stated carefully
The widely quoted figure is that 95% of enterprise AI pilots fail. The underlying MIT research said something more specific and more useful: around 95% of enterprise generative AI pilots showed no measurable impact on profit and loss.
That is a different claim. A pilot can work perfectly, be genuinely liked by the people using it, and still not move a number anyone tracks. Most stalled pilots are in that category rather than the broken one, which is why “the model isn’t good enough” is almost never the real diagnosis.
Treat every percentage in this area, including that one, as an argument rather than a measurement. The figure has been restated as “95% of AI projects fail” so often that the original meaning is mostly gone. What survives scrutiny is the direction: a large majority of pilots do not become systems that change how a business operates, and the reasons are consistently downstream of the model.
One finding from the same body of work is worth more attention than the headline. Internally built systems stalled at roughly twice the rate of vendor-supplied ones, and the gap was attributed to the compounding difficulty of connecting to real systems of record, ticketing platforms and knowledge bases. That is not an argument for buying. It is a warning about which part of the project is actually hard.
Why demos are easy and systems are not
Where the work actually sits
Ask a stalled project what remains and the answer is never “a better model”. It is a list like this one.
The six things that are actually missing
No operational owner
The pilot was sponsored by innovation, transformation or a CTO’s discretionary budget. Production needs someone whose day job includes this thing working, with a budget line and a place in an on-call rota.
Name that person before the pilot starts, and have them agree in advance what would make them adopt it. If nobody will take it, that is the answer and you have saved nine months.
No change to anybody’s workflow
The output appears in a dashboard nobody opens, or an email nobody acts on. A prediction that does not enter a decision is a hobby, however accurate.
Describe the moment the output is consumed: which screen, which person, at which point in their existing work, and what they do differently. If that sentence cannot be written, the project has no destination.
No way to tell whether a change helped
Someone edits the prompt and everyone shrugs. Without an evaluation set, every subsequent change is a guess and confidence quietly drains out of the project.
Build the evaluation harness during the pilot, from the failures the pilot produces. Retrofitting one later means starting without the examples that would have populated it. We cover the mechanics in testing software that answers differently every time.
No permissions model
The pilot ran on an export, or with an account that could read everything. Production has to answer who is asking, and the retrieval layer has to respect it.
Use real entitlements in the pilot, even on a small slice of data. Discovering at security review that the index ignores permissions is the single most common late blocker, and we describe why in building an AI feature on your own data without leaking it.
No cost model at real volume
Fifty demo queries cost nothing. Fifty thousand a month is a budget conversation, and an agent loop multiplies it further.
Log tokens in, tokens out, model and attempt count from day one, then extrapolate. The arithmetic is in what it costs to run an LLM feature in production, and it is usually less frightening than people fear once it is actually calculated.
No behaviour when it goes wrong
The demo never saw a timeout, a malformed response, a refusal, an empty retrieval or a document in the wrong language. Production sees all of them in week one.
Decide what the user sees in each failure case and make it a requirement. “It says something odd occasionally” is the reason adoption dies quietly.
Run the pilot backwards
The reframe that changes outcomes: a pilot’s job is not to show the technology works. It is to find the reasons it would not ship, while they are still cheap to find.
Under that framing the pilot looks different. You deliberately use ugly real inputs rather than clean ones. You put it in front of the person who would actually use it, not their director. You run it with real permissions on a small slice. You count the failures and write them down, because that list is the deliverable.
A pilot that surfaces eleven concrete blockers is a success. A pilot that produces a flawless demonstration has told you nothing you did not already believe, and it has cost the same.
This also changes who should see it. An impressive demo shown to executives generates enthusiasm and a mandate, which sounds good and is frequently the thing that kills the project, because the mandate arrives before anyone has found out what would break. A rough version shown to the team who would use it generates objections, which are information.
Define the metric before you start
The MIT finding was about profit and loss impact, and that is the uncomfortable centre of this. Most pilots never had a number attached, so there was nothing to measure and nothing to defend when budgets tightened.
The metric does not have to be revenue. Cases closed per person per day, time to first response, percentage of invoices matched without a human, hours of manual reconciliation. It does have to be something already measured today, so that a before exists. A metric invented at the end of the pilot, for the pilot, persuades nobody.
A production readiness list
- A named owner who accepts it into their operation, with budget and on-call.
- A metric with a baseline that was being measured before any of this started.
- An evaluation set built from real failures, running on every change.
- Real entitlements enforced at retrieval, not filtered afterwards.
- A cost projection at expected volume, including retries and any agent loops.
- Defined failure behaviour for timeout, refusal, empty result and malformed output.
- A workflow change described as a sentence about a specific person’s day.
- A rollback that takes minutes, because the first month will need it.
Eight items. Most stalled projects are missing five or six of them, and have been for months, because none of them are the kind of problem that announces itself.
Related: data readiness covers what has to be true before the pilot, where AI actually pays off covers picking the use case, and AI agents for internal operations covers the class of work that tends to survive this list.
Our AI and machine learning team runs pilots designed to surface blockers rather than to impress, which makes for less enjoyable demos and considerably more things reaching production. If you have something stuck between working and shipped, tell us where it stalled.
Common questions
Why do most AI pilots never reach production?
Rarely because of model quality. The common blockers are that nobody in operations owns the result, no existing workflow consumes the output, there is no evaluation set so nobody can tell whether a change helped, the retrieval layer ignores permissions, the cost at real volume was never modelled, and failure behaviour was never defined because the demo never failed. Each one is invisible in a demonstration and each one takes weeks to fix afterwards.
Is it true that 95% of AI projects fail?
Not as usually stated. MIT research in 2025 found that around 95% of enterprise generative AI pilots produced no measurable profit and loss impact, which is a different claim from technical failure. A pilot can work well, be liked by its users, and still not move a number anyone tracks. The figure has been restated so often that the original meaning has largely been lost, so treat it as a direction rather than a measurement.
Should we build an AI feature in-house or buy one?
MIT’s research found internally built systems stalling at roughly twice the rate of vendor-led ones, with the gap attributed to the difficulty of connecting to real systems of record rather than to model quality. That is not an argument for always buying. It is a warning about where the work is. Build where the process is genuinely your advantage, and be honest that the integration and operations layers are most of the effort either way.
What should an AI pilot actually deliver?
A list of the specific reasons it would not ship, found cheaply. That means using real and ugly inputs rather than curated ones, running with genuine permissions on a slice of data, putting it in front of the person who would use it rather than their director, and counting failures rather than hiding them. A pilot producing a flawless demonstration has told you nothing you did not already believe.
Sources
- MIT research published in 2025 on enterprise generative AI adoption reported that approximately 95% of enterprise generative AI pilots produced no measurable profit and loss impact, and that internally built systems stalled at roughly twice the rate of vendor-led deployments, attributing the gap to the difficulty of integrating with systems of record, ticketing platforms and knowledge bases rather than to model capability. The figure is widely restated as a failure rate, which is not what it measured.
- Gartner’s related finding that organisations will abandon 60% of AI projects unsupported by AI-ready data through 2026 is covered with its survey detail in data readiness for machine learning.
- Proportions in the second chart are illustrative. The ordering, and the observation that the model is the smallest block, reflect what we see on stalled projects rather than a published measurement.
Written September 2026.
