August 5, 2026
August 5, 2026
Ninety-five percent of AI pilots never reach production
A number from a conference stage this summer, and the part nobody quotes with it. The technology is almost never what failed.
A number from a conference stage this summer, and the part nobody quotes with it. The technology is almost never what failed.
Vasuman Moza spends his working life inside large companies, rebuilding how their departments operate. Speaking at the AI Engineer conference this summer, he put a number to something most owners already suspect.
His number was ninety-five percent. That is the share of generative AI pilots that never reach production, from an MIT review he cited on stage. He put a second figure beside it: eighty-seven percent produce no measurable return.
Numbers like that get quoted constantly. The diagnosis underneath them almost never does.
The technology is rarely what failed
His explanation was blunt. AI is being slapped on top of broken processes. The pilot works in the demo because the demo follows the happy path. Then it meets a real week and falls over, because a real week is mostly exceptions.
He made a sharper point about where companies go looking for the truth. Documentation, he said, covers “the golden path and maybe an edge case or two, but this is still fundamentally not the reality.”
Then he described what the reality sounds like when you go and ask. Sarah in accounts payable handles the work one way. When something goes wrong she sends it to Chris, and Chris takes four days to reconcile a purchase order against an invoice.
None of that is written down anywhere. All of it is the job.
What we do about it
Before we recommend anything, we go and learn how the work actually happens, from the people doing it. The org chart describes one process. We go looking for the one that survives contact with a bad Tuesday.
The problem a business hires us for is usually a symptom of one nobody has named yet.
Automating before that work is done buys you the same mess at higher speed. A business that automates a broken process has bought a faster broken process. A business handed a binder nobody follows has bought paper. The two together are what moves the needle.
The part that decides whether it survives
His third point is the one most likely to get skipped, and it is about people rather than technology. A redesigned process has to be different enough to return something real, and familiar enough that the team can still run it.
Take an eleven step workflow, replace it with one step, and adoption collapses. Change nothing meaningful and you have bought a demo. The work is deciding which four steps run on their own, which two keep a person in the loop, and which one stays entirely with a human because the risk is too high.
That is a judgement call about the work itself, and no tool will make it for you. A tool cannot tell you which work should exist.
Which is why we start there.
Vasuman Moza spends his working life inside large companies, rebuilding how their departments operate. Speaking at the AI Engineer conference this summer, he put a number to something most owners already suspect.
His number was ninety-five percent. That is the share of generative AI pilots that never reach production, from an MIT review he cited on stage. He put a second figure beside it: eighty-seven percent produce no measurable return.
Numbers like that get quoted constantly. The diagnosis underneath them almost never does.
The technology is rarely what failed
His explanation was blunt. AI is being slapped on top of broken processes. The pilot works in the demo because the demo follows the happy path. Then it meets a real week and falls over, because a real week is mostly exceptions.
He made a sharper point about where companies go looking for the truth. Documentation, he said, covers “the golden path and maybe an edge case or two, but this is still fundamentally not the reality.”
Then he described what the reality sounds like when you go and ask. Sarah in accounts payable handles the work one way. When something goes wrong she sends it to Chris, and Chris takes four days to reconcile a purchase order against an invoice.
None of that is written down anywhere. All of it is the job.
What we do about it
Before we recommend anything, we go and learn how the work actually happens, from the people doing it. The org chart describes one process. We go looking for the one that survives contact with a bad Tuesday.
The problem a business hires us for is usually a symptom of one nobody has named yet.
Automating before that work is done buys you the same mess at higher speed. A business that automates a broken process has bought a faster broken process. A business handed a binder nobody follows has bought paper. The two together are what moves the needle.
The part that decides whether it survives
His third point is the one most likely to get skipped, and it is about people rather than technology. A redesigned process has to be different enough to return something real, and familiar enough that the team can still run it.
Take an eleven step workflow, replace it with one step, and adoption collapses. Change nothing meaningful and you have bought a demo. The work is deciding which four steps run on their own, which two keep a person in the loop, and which one stays entirely with a human because the risk is too high.
That is a judgement call about the work itself, and no tool will make it for you. A tool cannot tell you which work should exist.
Which is why we start there.
