Why most AI pilots never reach production, and why that stopped being a technology problem.
Most AI pilots never reach production. The number that gets quoted is 88 percent. MIT's 2025 study of enterprise AI put the share that delivered no measurable return at 95 percent. Pick whichever figure you trust. The story underneath them is the same, and after this year I don't think it's a technology problem anymore.
A pilot is easy. You scope it small. You hand-pick the data. You put your best two people on it, and you give them the air to focus. It works. It demos beautifully. Someone senior sees it, and the room gets excited. That is exactly the trap, because almost none of what made the pilot work is present in the place you are trying to take it next. Name what the pilot is for
Before you take it anywhere, though, ask the question most teams skip, because skipping it is the quiet root of a lot of this. What is the pilot actually for? A few answers are honest. Maybe it's to understand the technology, to find out whether the model can do the thing at all. Maybe it's to understand the business, whether a workflow really changes when you put this in front of it. Maybe it's a learning tool, a way to see what it would take to run this for real, so the next build is scoped with eyes open. Those are all good reasons to run a pilot, and they share one feature. What you're producing is knowledge, not the tool.
Then there's the answer nobody says out loud. Sometimes the intent is just to get the thing out the door and into daily use. If that's the goal, be honest about it, because then it isn't a pilot. It's a production build wearing a pilot's clothes so it can skip the standards a production build has to meet. That's the most expensive misnaming in this work. You cut the corners of a pilot, you take on the dependence of a product, and you find out which corners mattered at the worst possible time.
So decide first, out loud, before anyone writes code. If the pilot's job is to teach you something, then the lesson is the deliverable, and "it never reached production" isn't a failure. It's a pilot that did its job. If the pilot's job is to become the real thing, then it was never a pilot, and it needed the foundations from day one. Most of the graveyard sits in the space between, where a learning exercise quietly gets promoted into a dependency nobody built for.
Production is a different country
Production is messy data. It is edge cases nobody thought to mention. It is people who never asked for the tool and have a job to do without it. It is a primary key that exists in one system, is missing from the second, and is named three different ways across the third and fourth. The pilot never had to survive any of that, because you protected it from all of it. That was the point of a pilot. It is also why the jump is so much larger than it looks from the demo.
The pilots that died this year mostly did not fail at the model. The model was fine. They failed at the handoff, the moment the clean demo had to become a thing real operations depend on every morning. That handoff is where the work actually lives, and it is the work most pilots skip, because skipping it is what let the pilot move fast in the first place.
What the survivors do differently
The teams whose pilots reach production do the unglamorous work first. They fix the data foundations before they build anything clever on top of them. They treat governance as the starting line, not the audit that happens after something breaks. It's slower at the front. It's the only thing that's faster by the end.
That order is the whole game, and it is the order almost everyone gets wrong. The exciting work, the model, the agent, the interface, is the part that demos. The foundational work, the naming, the keys, the lineage, the ownership, the question of who trusts this number and why, is the part that does not demo at all. So it gets deferred. It gets deferred straight into the gap between a pilot that works and a system that runs, and that gap is where most of the 88 percent quietly disappear.
Concretely, the boring work is this. It is deciding what a customer is, once, so that four systems stop disagreeing about it. It is reconciling the key that three teams each maintain in their own shape. It is recording where every number came from, so that when something breaks overnight you can see what ran and what did not without spelunking through logs at seven in the morning. It is deciding who owns the pipeline once the people who built it have moved on. None of that ships to a demo. All of it decides whether the demo ever becomes something the business can lean on.
Why this is a ways-of-working problem, not a tooling one
You can buy any model you like. You can buy the platform, the notebooks, the orchestration, the governance suite. What you cannot buy is the decision to do the foundational work before the visible work, and the discipline to hold that order when someone senior wants to see the exciting part sooner. That is not a technology choice. It is a way of working, and it is a cultural one, because it asks a team to spend its early weeks on things that will not show up in a status update.
This is the part I find most teams already half-know. Ask the engineers who have lived through a stalled pilot what went wrong, and they rarely say the model was weak. They say the data was not ready. They say nobody agreed on definitions. They say it worked on the sample and fell over on the real thing. They knew. The system around them just was not built to let the boring work go first.
What twenty years of buying taught me
I spent twenty years on the buyer side before we started Domino. I sat in the seat where the pilots either became real or became a line item someone had to explain later. The lesson arrived over and over, in different industries and different decades, and it never changed. The boring work is the work. The teams that respected that shipped. The teams that chased the demo built a graveyard of things that worked once, in a room, on a Tuesday.
That is why we build the way we do. We put the foundations in first, we make governance the starting line, and we make the plumbing *earn its keep* before we put anything shiny on top of it. Not because it is virtuous. Because it is the only version of this work that reaches production and stays there after we leave.
A diagnostic, if you need one
If you have a pilot that demos beautifully and will not move into production, here is the test worth running. Do not start by asking what is wrong with the model. Start underneath it. Is there one definition of your core entities, or four? Can you trace where each number came from? Does anyone actually own the pipeline once it is live? Would the tool survive contact with the data you did not hand-pick, and the people who did not ask for it?
If the honest answers are shaky, the bottleneck is not the AI. It is everything underneath it. That is uncomfortable, because the underneath is slower and less impressive than the model. It is also fixable, and it is fixable in a way you keep, which is the only kind of fix worth paying for.
Stop calling them pilots
One concession first. The people who say endless piloting is its own disease are right. A company running its tenth pilot to avoid a decision isn't learning, it's hiding, and no amount of naming the intent fixes a team that pilots because committing is scary. Too much piloting is a real failure, and it looks like progress, which is what makes it dangerous.
But watch what happens when a pilot actually works. You run a small, honest exercise. You learn something real. That knowledge turns an idea into a product your organization can use and trust, and the product holds up in production. You didn't just ship a tool. You found a way of working, and that is worth more than the tool, because you can do it again.
So maybe the word is the problem. "Pilot" sounds like a thing off to the side, a test with a trap door, separate from the real work. Drop it. Build the learning into how you deliver instead. Ideation, then learning, then applying what you learned, then delivery. Not four projects with a pilot bolted on the front. One workflow, with a small, deliberate knowledge-building step at the start of it, scoped to a question worth answering, feeding straight into the build.
That is the version we try to run, and it's the bar we hold ourselves to. The early exercise isn't a pilot we hope survives. It's the first move in the delivery, there to make everything after it cheaper, faster, and more certain, and to leave your team knowing how the thing was built. Done that way, "did the pilot reach production" stops being the question, because nothing was ever standing between the idea and the thing you keep. If that's the workflow you want and can't yet run, that's the conversation we like.
