Most AI pilots fail. You have seen the number: a 2025 MIT report found that roughly 95 percent of enterprise generative AI pilots delivered no measurable return. It got quoted everywhere, including by people selling the fix.
That figure is real. It is also narrower and shakier than almost anyone repeating it admits, so the next section takes it apart properly rather than waving it around. What survives the scrutiny is the part that matters anyway: pilots die in the gap between a demo that impresses a room and a system that survives a Tuesday in production, and the reason is almost never the model.
We have watched this happen from the inside for years, and we have been hired to rescue enough stalled pilots to see the pattern clearly. The companies that ship are not the ones with the best data scientists. They are the ones that treated the boring parts as the actual project.
What the 95 percent number actually means
The source is MIT’s State of AI in Business 2025. The headline finding is that the vast majority of corporate generative AI initiatives produced no measurable profit-and-loss impact, and that the researchers traced the failure to implementation approach rather than to model quality or regulation.
Before you repeat that number in a board deck, know what is underneath it.
| What people hear | What the report actually did |
|---|---|
| ”MIT studied enterprise AI and found 95% fails” | The finding rests on 52 interviews, plus an analysis of 300-plus public initiatives that the report does not fully explain |
| A rigorous, peer-reviewed result | Not peer reviewed. The report describes its own findings as “directionally accurate based on individual interviews rather than official company reporting" |
| "95% of AI projects don’t work” | Success required deployment beyond pilot with measurable KPIs, and ROI measured six months post-pilot |
| Any business benefit counts | The definition excludes efficiency gains, cost reduction, churn reduction, lead-conversion improvement and pipeline velocity |
That last row is the one worth sitting with. Under that definition, a system that cut a team’s manual handling by 80 percent but had not yet shown up as a P&L line within six months would be counted as a failure. Several projects we have shipped would have been scored that way at the six-month mark and were plainly not failures. The most-cited critique of the study makes exactly this point.
So we are not going to tell you 95 percent of AI projects fail. We do not know that, and neither does anyone quoting the figure at you.
Here is what survives the scrutiny, and it is enough. Nobody on either side of the argument claims the failures cluster at model quality. The critics dispute the rate, not the cause. Every serious estimate, and our own experience rescuing stalled pilots, puts the failure at the same place: the gap between a working demo and a system integrated into how the business actually runs.
That distinction is the whole reason this article exists, because it points at the fix. If the models were the problem, the answer would be to wait for better models. Since the problem is implementation, the answer is available now, and it is mostly engineering discipline rather than AI wizardry.
The three ways pilots go to purgatory
Across the stalled projects we have seen and inherited, the failure almost always traces to one of three problems. They are not exotic. That is exactly why they get skipped.
The first is the demo-to-production gap. A proof of concept is built to impress, so it runs on a clean slice of data in a controlled setting. Production is the opposite: the messiest 30 percent of real inputs, the edge cases, the malformed records, the customer who pastes a screenshot instead of a file. A demo that handles the easy 70 percent looks 95 percent done and is actually about 40 percent done. The remaining work is unglamorous and it is where projects quietly stall.
The second is tool sprawl. A team wires together a Zapier flow, a GPT call, three browser extensions, and a custom script. Each piece works alone. None of them talk to each other reliably, nobody can debug the whole chain, and the first time an API changes, it breaks with no clear owner. The pilot was never a system. It was a pile of parts held together by one enthusiastic person’s attention.
The third is no one to hand it to. Even when a pilot works, it often lives inside one champion’s head or one contractor’s laptop. When that person moves on, the thing rots. There is no documentation, no runbook, no training, so the organization cannot maintain what it cannot understand. This is the quiet killer, because the pilot technically succeeded and still delivered nothing a year later.
Why smart teams keep hitting the same wall
None of this is a knowledge problem. Most teams that stall know, in the abstract, that integration and data are hard. They hit the wall anyway, for structural reasons.
Pilots are usually funded and staffed to prove a point, not to run in production. The budget covers the demo. The people are borrowed part-time from other work. The success metric is “does it work in the demo,” which is answered long before the system is actually usable. So the project hits its stated goal and stops, having built the 40 percent that was fun and skipped the 60 percent that was hard.
There is also an incentive gap. The part of an AI project that impresses stakeholders is the model output. The part that determines whether it ships is the integration, the error handling, the monitoring, the data cleanup. Those never demo well. A team optimizing for the next steering-committee meeting will keep polishing the visible part and keep deferring the invisible part that actually matters.
What the few that ship do differently
The projects that make it to production and stay there share a handful of habits. We build every engagement around them because we learned the hard way that skipping any one of them is how you end up in purgatory.
They solve integration and data first, not last. The unglamorous plumbing gets built early, while there is still budget and attention, instead of being discovered as a nasty surprise near the deadline. On our logistics document project, the whole reason the client needed us was the messy 30 percent that off-the-shelf vendors could not handle. We built for that case first, the backlog cleared in week one, and eighteen months later the client told us it was still running. Durability is the only real proof a pilot escaped purgatory.
They scope around a real workflow with a real owner. Not “explore AI for support” but “cut the time our team spends prepping mortgage files.” A concrete workflow has a concrete finish line and a person whose job gets better when it works. That person keeps the project honest.
They measure a business outcome, not model accuracy. Accuracy is an input. The output that matters is hours saved, deals won, headcount freed. When a fintech client ran a two-week strategy sprint with us, the deliverable was not a model score. It was a decision: roughly $250,000 of misdirected AI spend to stop, and a $400,000 backlog worth building. That is a number a board can act on.
They plan the hand-off before they start. Documentation, a runbook, and training are part of the scope from day one, not an upsell at the end. The engagement is done when the client’s team can run the system without the vendor, which is the only definition of done that survives the vendor leaving.
A pilot that actually shipped
Here is what shipping looks like in practice, so “the 5 percent” is not just an abstraction.
A Canadian mortgage brokerage had the classic setup for purgatory: a doc-heavy workflow, a manual process eating eight or more hours per loan file, and previous automation attempts that never stuck. Instead of a flashy demo, we scoped a specific workflow (intake and document prep) with a specific owner (the head of operations) and a specific target (hours back per file).
We built the integration into their loan origination system first, handled the ugly reality of documents arriving as email attachments and phone photos, and put PII anonymization in the pipeline because it was a compliance requirement, not an afterthought. File prep dropped from about eight hours to roughly 25 minutes. Files disqualified in underwriting fell from 22 percent to 9 percent. Then we handed it over with documentation and a training session, so it kept running without us.
The engagement ran eight weeks against a $48,000 cap and came in at $44,200. None of that is a model breakthrough. All of it is the discipline that stalled pilots skip. The full numbers are here.
How to rescue a pilot that has already stalled
Plenty of companies come to us not at the start but in the middle, with a pilot that has been almost done for months. The good news is that a stalled pilot is often more rescuable than it looks, because the concept is usually proven and only the engineering was skipped.
The first step is to stop extending it and make a decision. A pilot that has been re-scoped twice is not going to escape purgatory on a third try with the same approach. Name the real workflow it should serve and the owner whose job it should improve. If neither exists, the honest answer may be to kill it, and killing a bad pilot cleanly is a win, not a failure.
If it is worth saving, the rescue is almost always the same shape: go back and do the work that got deferred. Build the integration into the real systems. Handle the messy inputs the demo avoided. Add the validation and error handling that a demo never needs. Then write the documentation and train the team so it survives without whoever built it. This is unglamorous and it is exactly the 60 percent that was skipped the first time, which is why the pilot stalled.
One caution: a rescue is only cheaper than a rebuild when the underlying approach was sound. If the pilot was wired together from mismatched tools with no clear architecture, it is sometimes faster to rebuild the workflow properly than to keep patching the pile of parts. An honest partner will tell you which situation you are in rather than billing you to prop up something that should be replaced.
Signs your pilot is heading for purgatory
If you have a pilot in flight, these are the early warnings that it will stall. Any two of them together is worth a hard conversation now, while it is still cheap to fix.
| Warning sign | What it actually means | What to do this week |
|---|---|---|
| The demo only ever runs on the same clean sample data | Nobody has tested the messy 30 percent, so the hard work is unscoped | Run it on 20 of your worst real inputs and watch |
| Nobody can name who owns the system after launch | It will be orphaned on day one | Name an owner whose job improves when it works |
| The success metric is a model score | Nobody has agreed what business outcome this is for | Replace it with hours, cost or conversion, with a baseline |
| Integration is described as “phase two” | The most expensive part is unfunded and undated | Move it into phase one or accept this is a demo |
| No line item for documentation or training | The hand-off will not happen | Put it in the scope in writing |
| It depends on one person not on the maintenance team | Bus factor of one | Pair someone from the team that will run it |
| Timeline extended twice, still “90 percent done” | The deferred 60 percent is now due | Stop and decide, do not extend again |
That last one is the signature of purgatory: perpetually almost finished, because the remaining work is the hard 60 percent that was deferred from the start. Any two of these together is worth a hard conversation now, while it is still cheap.
How to structure a pilot that reaches production
The fix is not to skip pilots. It is to run them as the first phase of a production system rather than a science project. A few structural choices make the difference.
Phase-gate it. Start with a small, cheap scoping phase, then a prototype with a real slice of production data, then the production build. Put a stop point at each boundary so you can kill a bad idea early and cheaply, and only spend the big money once the risky questions are answered.
Fund it to ship, not to demo. Budget for the integration, the error handling, the monitoring, and the hand-off up front. If those are not in the plan, you are funding a demo and calling it a pilot.
Pick one workflow that matters. Depth beats breadth. One workflow taken all the way to production teaches you more, and returns more, than five explorations that all stop at the demo.
Make hand-off a deliverable. Write down that the project is complete when your team can run it alone. That single sentence in the scope reorganizes how the whole thing gets built.
Frequently asked questions
What percentage of AI pilots actually fail? The honest answer is that nobody knows precisely. The most-quoted figure, 95 percent, comes from MIT’s State of AI in Business 2025 and rests on 52 interviews with a narrow six-month P&L definition of success that excludes efficiency and cost savings. The direction is well supported; the precision is not. What is not disputed is where the failures happen: at the pilot-to-production boundary, not at the model.
Is generative AI overhyped, then? The technology is real and the returns are real when a project ships. What is overhyped is the idea that buying a model or running a demo is the hard part. The hard part is the integration, data, and operational fit, which is ordinary software engineering discipline applied to a new tool.
How long should an AI pilot take? A focused prototype on real data usually takes two to three weeks. If a pilot has run for months with no production date, it is not a pilot anymore, it is purgatory, and it needs a decision rather than another extension.
Can a stalled pilot be rescued? Often, yes. Most stalled pilots proved the concept and then skipped the engineering. Rescuing one usually means rebuilding around the real workflow, doing the integration and data work that was deferred, and adding the hand-off that was never planned.
If you have a pilot in flight, run it against the seven warning signs above this week. Two or more, and the conversation you need to have is about scope and ownership, not about the model.
If you are earlier than that and want to know whether you are set up to ship anything at all, the company AI readiness checklist scores the five conditions that decide it, and the three purgatory failure modes above map straight onto three of them. If you already know the workflow and want it built to reach production, that is what our AI strategy work scopes.
Last updated