Ninety-five percent of enterprise AI pilots return nothing to the P&L. That number, from MIT's Project NANDA, has been passed around boardrooms for the better part of a year now, usually as evidence that the technology is overhyped, or that the models aren't ready, or that the whole category needs another eighteen months to mature.
Every one of those explanations is wrong. The pilots did not fail because the models underperformed. In most cases the models did exactly what they were asked to do. The pilots failed because of decisions made before a single line of code ran, decisions about how the work was scoped, measured, owned, and funded. The failure is more often in the charter, than in the technology.
This is not a semantic distinction. If you believe the model failed, you wait for a better model. You sit out another release cycle, watch a competitor, and tell your board you are being disciplined. If you understand the charter failed, you fix something you actually control, and you fix it now. The difference between those two beliefs is the difference between the companies that will compound an advantage over the next three years and the companies that will spend that time running pilots and scaling none of them.
The number underneath the number
Start with what the MIT researchers actually found, because the headline statistic obscures the more useful one. When they looked at why pilots delivered no measurable return, the recurring cause was not model accuracy. It was that most pilots launched with no predefined definition of success. There was no metric agreed in advance, no threshold that would let anyone in the room say the thing worked.
Chew on that for a bit. A pilot with no success criterion cannot succeed. Not because the technology is weak, but because success was never made measurable. You can run that pilot flawlessly, hit every technical benchmark, deploy a model that does precisely what the vendor promised, and still have no way to declare a win. The scoreboard was never built. So the project drifts, sponsorship fades, and it gets quietly folded into the pile of things that "didn't pan out."
The corroborating data is not kind. S&P Global found that 42% of companies abandoned most of their AI initiatives in 2025. IBM's own CEO study put the share of initiatives delivering the expected return at 25%, with 56% of chief executives reporting no significant financial benefit at all. These are not numbers you get from a technology that doesn't work. These are numbers you get from an execution model that was never designed to capture whether it worked.
The eighty percent you didn't budget for
Here is the part that should change how you allocate capital. Roughly 80% of the work required to move an AI capability from pilot to production has nothing to do with the model. Companies fund the 20% that gets the demo and assume the rest will sort itself out. It doesn't, and it is worth naming exactly what the rest is, because each piece is a line item someone chose not to fund.
Start with the plumbing, because it is real and it is large. Data engineering to feed the model reliably, and workflow integration to connect its output to the systems your people actually use. This alone is more work than most pilots budget for. But it is the easy part of the 80% to understand, which is why it gets the most attention within the part that gets too little.
The harder part is governance, and governance is not one thing. It is at least three. Model governance is versioning, drift monitoring, access control, audit trails, and the non-human identity that every autonomous agent now creates and that your existing identity systems were never built to manage. Process governance is the question of who is allowed to change a workflow the AI now touches, what the approval gates are, and how exceptions get escalated to a human. Data governance is lineage, quality, and permissioning, knowing what the model was trained on and what it is allowed to see. A pilot can ignore all three. A production system that ignores any of them becomes the security and compliance incident that ends the program.
And then the part that is closest to the actual work and furthest from anyone's budget: operational transformation. A model that performs a task is not the same as an operation that has absorbed it. The job has to be redesigned around the new capability. The operators have to be retrained, and more than retrained, they have to trust the output enough to act on it. The metrics people are measured against have to change, because if you drop an AI tool into a workflow while paying people on the old scorecard, they will route around it. And the compliance function has to be brought in early enough that it does not exercise its veto late, after the build, when reversing course is most expensive.
There is a deeper reason this is so hard, and it goes to what a large operation actually is. Most of how a big business runs lives in tacit, tribal knowledge, in the heads of operators who have run the system for years and in a thousand small judgments that were never written down. That knowledge is exactly what is hardest to hand to a model, because the model can only work with what has been made explicit, and the most valuable operating knowledge almost never is. Changing these processes carries a real cost, and leaders know it, which is why they are right to be careful with systems that work.
But this shift does not ask for care. Good operators know how to take a working system, improve it at the margin, and run it a little better. What AI actually calls for is something else entirely: to reinvent the operation from scratch, at scale, while it is running. When you have earnings to make, thousands of employees, and millions of customers on the line, that is a daunting thing to attempt. The technology is the easy part. The hard part is the courage to pull the tacit knowledge out of your best operators and then ask those same operators, the ones who know how to run the current system, to design its replacement.
I have made a version of the value argument before, that the model layer is becoming a commodity anyone can rent while the returns concentrate in the operating model no one can rent. I won't relitigate it here. What the pilot data adds is sharper: even the part everyone fixates on, the model itself, is only a fifth of the actual job.
The five ways a pilot is chartered to fail
When a pilot dies, the postmortem blames the technology, because the technology is the visible thing. Trace the failure back to its origin, though, and you almost always find one of five decisions, each made on a whiteboard, by people, before the model was ever involved. The first is the deepest, and the other four are often just its symptoms.
1. No recognition that the real task is operational reinvention
Most pilots are chartered as technology trials when the actual work is redesigning an operation, and that mismatch shows up in three places. First, the charter reflects no real understanding of the operational reinvention the capability will require, so it scopes a tool where it should be scoping a redesign. Second, even where the understanding exists, the commitment to fund that reinvention does not, because funding a model is a line item and funding an operational overhaul is a fight. Third, no one has identified the specific skills the reinvention demands, which are rarely the skills that ran the pilot. The technical talent that proves a model works is not the operating, change-management, and process-design talent that rebuilds the workflow around it. Charter a pilot without naming the reinvention, the money, and the skills, and you have chartered a demo that was never going to become an operation.
2. No predefined business success metric
If you cannot state, in advance and in a number, what this pilot must move, you have funded a science experiment, not a pilot. "See what AI can do for customer service" cannot fail because it cannot succeed. "Reduce average handle time on tier-one tickets by 20% without a drop in CSAT" can do both, which is exactly why it is worth running.
3. No business owner accountable for the P&L line
Pilots get handed to an innovation team or a center of excellence that does not own the outcome the pilot is meant to improve. So when the pilot works but requires operational change to capture value, no one's numbers depend on making that change happen. The pilot becomes an orphan, and orphans do not scale.
4. No path into a real workflow
A model that gives a good answer in a sandbox and a model embedded in the steps a real employee takes on a real day are separated by an enormous amount of integration work. If that path was not designed before launch, the pilot has nowhere to go even when it succeeds. It sits as a demo, admired and unused.
5. Fading executive sponsorship
Pilots launch with visible enthusiasm and lose their air cover the moment the next priority arrives. The changes required to capture value, always hard and political, stall once the champion moves on. The technology did not fail. The will to change the operation around it evaporated.
Not one of these is a technology problem. Every one is a chartering decision, which means every one is preventable, cheaply, if you fix it before you start rather than diagnose it after you stall.
What separates the five percent that do this well
Picture two companies with identical access to the same models, because that is the actual situation. Everyone can rent the frontier. The difference between them is not what they bought.
The first ran twelve pilots last year. Each had a champion, a demo, and a slide. None had a success metric written down before it started, none had an owner whose P&L depended on it, and none had the integration path designed in advance. Eleven are now quietly dead and the twelfth is a permanent pilot, admired in the quarterly review and used by no one. The board has concluded that AI is not ready.
The second ran three. Each started with a number it had to move and a named executive who owned that number and commitment to operational transformation. Each had its measurement built before the model was chosen and its workflow path designed before the pilot launched. Two are in production and compounding. The board has concluded that AI works, and is funding the next three.
The models were the same. The scaffolding was not. And that scaffolding is not something you can rent, download, or buy in a release cycle. It is operational work, done in advance, by people who understood that the pilot was never the point.
What the fix actually requires
If the failure is that pilots get chartered as technology when the work is operational reinvention, the fix is not a better model. It is resourcing the reinvention, and that comes down to two things most companies get wrong.
Get the operational transformation skills, not more model talent. The scarce capability is not people who can make a model perform. That talent is now abundant and rentable. The scarce capability is operators who can take a working model and redesign a live operation around it, at scale, without breaking the business that is currently running on it. Those are process-design, change-management, and operating skills, and they are the ones almost never staffed onto a pilot. If your AI effort is staffed entirely with technical talent, you have resourced the 20% and left the 80% to volunteers.
Govern the transformation as seriously as you govern the model. Model governance gets the attention now, versioning, drift, access, audit. It matters. But transformation governance matters as much and gets none: who owns the redesign of a process the AI now touches, how a change to that process gets approved, how you carry the operators through it, and how you decide when a workflow is reinvented rather than merely automated. A company with airtight model governance and no transformation governance will produce a well-monitored model sitting next to an operation that never changed. That is what most of the 95% look like.
And then prove it and compound it. Instrument the outcome the charter named so you can show the number moved, then feed each deployment's performance back into the next one. A production capability is the first version of a compounding asset, not a finished project. The companies pulling ahead treat it that way. The ones falling behind ship once, declare victory or defeat, and move on.
What you do Monday
This is not an argument for patience. It is an argument for a different set of first moves, available to you this week.
Kill every pilot in your portfolio that does not have a written success metric and a named business owner accountable for the P&L line it is meant to move. Not pause. Kill. A pilot without those two things consumes budget and attention while manufacturing a false lesson about whether AI works. It is worse than doing nothing, because it teaches your organization the wrong conclusion.
Then fund the eighty percent. When you scope the next capability, put the majority of the budget where the majority of the work actually is, in governance, integration, and the operational change required to absorb it, not in model selection. Charter it backward from the outcome it must move. Build the measurement before you choose the model. Design the workflow path before you run the pilot. And be honest with yourself about the real task, which is not installing a tool but reinventing an operation, and finding the courage to ask your best operators to help you do it.
The 95% number is not a verdict on the technology. It is a mirror. It shows you how your organization charters, funds, and measures its most important new capability, and for most companies the reflection is unflattering. The good news in that is simple. A technology problem you have to wait out. A chartering problem you can fix on Monday.