Skip to content
All writing

Why most AI projects never reach production

MIT found 95% of enterprise AI pilots returned nothing measurable. Having built five that did reach production, here are the five reasons the rest stall, and what to check before you start.

In 2025, MIT’s NANDA initiative published The State of AI in Business. The finding that travelled furthest was that roughly 95% of enterprise generative AI pilots delivered zero measurable return to the profit and loss statement.

The number gets quoted badly. It does not mean the models do not work. It does not mean the technology is a bubble. It measures something narrower and more useful: of the organisations that ran a pilot, almost none could point to money saved or earned as a result.

That is a delivery problem, not a technology problem. We have built five AI systems that reached production and stayed there, and the reasons the others stall are consistent enough to list.

1. The demo ran on clean data

Every pilot begins with a curated sample. Someone picks fifty representative documents, the model handles them well, and the room is impressed.

Production data is not that. It is scanned at an angle, half-completed, entered by fourteen different people over nine years with no shared convention. It contains the same entity spelled four ways. It has fields that were repurposed in 2019 and never renamed.

When we built a record matching system for a state ambulance service, the difficulty was never the matching logic. It was that two systems recorded the same patient arrival with different timestamps, different name formats and different levels of completeness, and any rule strict enough to avoid false matches missed a third of the real ones.

The system now handles 12,000 records a day, matching 97% of them and declining the rest rather than guessing. Getting from a demo that worked on clean records to one that survived real ones was most of the work.

Ask before you start: has anyone run this on a genuinely messy sample, chosen by someone who did not build it?

2. Nobody costed the unglamorous eighty percent

The model is a small part of an AI system. The rest is authentication, permissions, audit logging, error handling, retries, monitoring, deployment, and a way for a human to correct a wrong answer.

Pilots skip all of it, which is why they finish so quickly and why the estimate to productionise comes back four times higher than expected. The pilot was not a smaller version of the real system. It was a different thing that happened to share a demo.

This is where most budgets die. Not because the number is unaffordable, but because it arrives after the enthusiasm has been spent, and it looks like a failure of the original estimate rather than the predictable cost of the parts the pilot never included.

Ask before you start: what does this cost with permissions, audit and error handling included, and who is quoting that number?

3. Nobody can check the answer

An AI system that produces plausible output nobody can verify will not be adopted in any work where being wrong has a consequence. Staff try it, catch it being confidently wrong once, and stop trusting it. Adoption never recovers.

The fix is not a better model. It is making the answer checkable. When we built an assistant over an organisation’s internal document estate, the feature that drove adoption was not the quality of the answers. It was that every answer carried a citation that jumped to and highlighted the exact passage it came from. Staff could confirm it in two seconds.

That changes the question from do you trust the AI to do you trust this document, which is a question people already know how to answer.

Ask before you start: when the system gives an answer, how does the person receiving it check whether it is right?

4. It never touched the system of record

A pilot that produces a spreadsheet is a demonstration. A system that writes into the platform your organisation actually runs on is a tool.

The gap between the two is integration work: credentials, rate limits, data formats that were never documented, a vendor whose API does not do the one thing you need, and a change process that requires sign-off from a team that has never heard of your project.

This is unglamorous and it is where timelines slip. It is also the entire difference between something people use and something people were shown once.

Ask before you start: which existing system does this write to, and has anyone confirmed it can be written to?

5. There was no owner after the pilot

Pilots are run by whoever was enthusiastic. Production systems need someone who answers when it breaks at 6pm on a Friday, who notices when accuracy drifts, who updates it when the underlying rules change.

If that person was never named, the system degrades quietly. Model costs creep, a source document format changes, accuracy falls, and by the time anyone notices, trust is gone and the system is quietly abandoned. It rarely gets switched off. It just stops being used.

Ask before you start: who owns this in six months, and is that in their workload or on top of it?

What production actually requires

None of this is exotic. The systems that survive share a short list of properties:

  • Grounded output. The system answers from your material, and can show which part of it.
  • A human checkpoint anywhere the consequence of being wrong is expensive.
  • An audit trail that records what happened and cannot be edited afterwards. In one compliance platform we built, completion records are cryptographically hashed and the database physically refuses to update or delete them. That is not a feature anyone asked for. It is the reason the records are worth anything at an audit.
  • Permissions that match the organisation, so the system cannot show one team another team’s material.
  • A named owner with time allocated.

Notice how little of that is about the model.

The honest version

Speed is possible. We built a clinical document system that took a transcription team from twenty-two people to one, and delivered it in two days. We built the ambulance matching system in three weeks.

Both were fast because the problem was narrow, the data was available, the target system could be written to, and someone owned the outcome. When those four things are true, AI projects move quickly. When they are not, no amount of budget or model quality compensates.

The 95% figure is not evidence that AI does not work. It is evidence that most organisations ran an experiment rather than starting a project, and then were surprised that an experiment produced no return.

If you are considering one, the five questions above will tell you more about whether it will reach production than any vendor demonstration will.

Recognise any of this?

We have built five AI systems that reached production. Twenty minutes will tell you whether yours can.

Book a call