Last year MIT published a number that should have ended a thousand board meetings early: 95% of generative AI pilots deliver no measurable return. Not "underwhelming returns." Nothing. Zero impact on the P&L.
RAND had already said something similar. Over 80% of AI projects fail, roughly double the failure rate of ordinary IT projects. And in 2025, 42% of companies abandoned most of their AI initiatives, up from 17% the year before. Half of all proofs of concept never made it to production.
We build AI systems for a living. So you'd expect us to tell you those companies just picked the wrong vendor.
We're not going to do that. The wrong vendor is rarely the problem. The wrong question is.
The question nobody asks before starting
Almost every failed AI project we've seen (and we get called in to look at a few after they've died) started the same way. Someone senior saw a demo, got excited, and asked: "How do we use AI in our business?"
That question has no good answer. It's like asking "how do we use electricity in our business?" You don't use electricity. You use the things it powers.
The businesses that make AI work start from the opposite end. They pick one process that's already bleeding. Missed calls, leads going cold in a spreadsheet, the kitchen over-ordering stock every single week. Then they ask: "What would it take to fix this?" Sometimes the answer involves AI. Sometimes it's just better plumbing. Either way, the project has a finish line, and you know when you've crossed it.
MIT's researchers found the same pattern from the data side. The pilots that failed had unclear success metrics, weak sponsorship, and no connection to a real workflow.
The failures weren't technical. The models worked fine. The organisations around them didn't.
— On where pilots actually die
Why the pilot itself is the trap
Here's the part that took us longest to accept: the pilot format is often the reason for the failure.
A pilot, by design, sits outside your real operations. It runs on sample data, gets used by volunteers, and nobody's job depends on it. So it produces a polished demo and no habit. Then someone asks "should we roll this out?" and the honest answer is that you never actually tested the thing that matters — whether it survives contact with your Tuesday afternoon.
When we built a demand forecasting system for a fresh-food operator, we didn't run it as a side experiment. It went into the same database the kitchens already used. The forecast showed up where the ordering decision was made, not in a separate dashboard nobody opens. If it had been wrong, everyone would have known by Friday. That pressure is uncomfortable, and it's exactly what makes a system real.
One database. One workflow. No parallel universe where the AI lives.
The build-it-yourself tax
The MIT study had another finding that didn't get enough attention: projects done with specialised external partners succeeded about twice as often as internal builds — roughly 67% versus 33%.
That's not because outside developers are smarter. It's because an internal team building its first AI system pays tuition on every mistake: wrong architecture, wrong data pipeline, six months on a chatbot nobody asked for. A team that has shipped twenty of these has already paid that tuition on someone else's budget. Preferably not yours.
One honest caveat, because there should always be one: an external partner fails too if you hand them the vague version of the question. "Build us an AI strategy" fails at any price. "Our front desk misses 30% of calls after 6pm, fix that" succeeds almost every time. It usually costs less than the strategy deck would have, too.
What the 5% actually do
Strip away the case studies and it comes down to habits, not genius:
- Start with a bleeding process, not a technology. The project exists because a specific number is wrong, not because a demo was impressive.
- Define "working" before writing code. In money or hours saved, agreed by the people who own the number.
- Live inside the real workflow from day one. Real data, real database, used by people whose jobs depend on the output.
- Treat launch as the starting point. The systems that survive keep learning from feedback instead of being frozen at v1.
None of this is glamorous. There's no keynote in it. But 2026 is turning into the year the AI conversation gets boring in the best possible way — less "what's possible," more "what's profitable."
If you're sitting on a stalled AI initiative right now, don't ask whether the technology is ready. It is. Ask whether anyone in the room can finish this sentence: "This project succeeds if ___ number goes from ___ to ___ by ___."
If nobody can, you don't have an AI problem. You have a clarity problem, and no model at any price fixes that.
