# Why your AI pilots are still pilots > Source: > Published: 2026-11-09 18:09:22+00:00 McKinsey surveyed 1,719 companies this spring. Eighty-eight percent of them use AI somewhere in the business. Thirty-seven percent can point to any effect on EBIT at all. Six percent get what McKinsey calls significant impact, meaning at least five percent of EBIT. Six percent was also the number last year. *Nearly everyone uses AI. Six percent get significant EBIT impact from it, and that share did not move between 2025 and 2026. McKinsey, State of AI 2026.* I’ve spent most of the past year inside PE-backed companies trying to get AI out of pilot and into the P&L, and that flat line is exactly what it feels like from the inside. Every portfolio company I’ve walked into has run a pilot. Almost none has one in production that the CFO would put their name next to. And the pilots don’t fail in any way you’d notice. Nobody kills them. They just sit there, and somewhere around month eighteen the board quietly stops asking. The explanation I hear most is that the technology isn’t ready yet. I used to half-believe this. I don’t anymore, and the data doesn’t either. The companies in the six percent aren’t running better models than everyone else; they have the same vendors and the same API keys. What’s different is that three-quarters of them rebuilt the workflow around the AI, against a quarter of everyone else. They’re twice as likely to have a senior leader who visibly owns it, and twice as likely to have a real way of measuring what it did. *The high performers didn’t buy different technology. They changed how the work is done, and they measured it.* So it isn’t what they bought. It’s five things they did, or didn’t do. I’ve started keeping a mental list, and I haven’t yet seen a stuck pilot that wasn’t stuck on at least one of them. **The pilot-to-production gap is an operating problem wearing a technology costume.** ## 1. Nobody owns a number Here’s what I see most often in the mid-market. AI is in the value creation plan as a theme. There’s a slide. And day to day, it lives with IT, or with whoever got most excited about it at the offsite. That person is usually good, which is part of the problem. They build something that works in a demo, show it around, collect compliments, and then get busy with the job they’re actually paid for. The pilot runs on their enthusiasm, and enthusiasm loses to a quarter-end every time. Nobody funds it, nobody cancels it. It just stops coming up in meetings. Bain’s September report on AI in private equity puts this first on its list of why portfolio companies stall: AI handed to a technology or innovation team with no executive owner. Their CEO survey this year found about 80 percent of chief executives unhappy with how fast their AI programs are moving, and only 18 percent getting most of what they set out to get. The 18 percent run AI off the CEO’s agenda. Everyone else runs it off the CIO’s. *Four in five CEOs are unhappy with the pace. Bain CEO Survey 2026.* I don’t think anyone makes this mistake stupidly. AI is a technology, so it went to the technology people, the way ERP went to the technology people, and that worked out fine. It doesn’t work here, because the value isn’t in the system. It’s in changing how the work gets done, and the technology people don’t own the work. **What has to change: AI becomes an EBITDA lever someone owns, not a capability someone builds.** One executive, one number for this year, and enough budget authority to move money toward it. The companies at the high end have a board that looks at a trend line against that number. At the low end, the board watches a demo. ## 2. The baseline was never measured Second pattern. The company ran a workshop. The workshop produced thirty use cases. Five got piloted. And nobody, at any point, measured what those five processes cost before the pilots started: not in hours, not in dollars, not in error rate. So even when one works, you can’t prove it. “The team says it’s faster” isn’t a number finance will put in a budget. And in a sponsor-backed company, a result you can’t show the board didn’t happen. Bain calls this the first barrier in portfolio companies: too many use cases spread too thin, producing productivity gains that never make it to the P&L. Their other finding, that there’s “little correlation between AI spend and value” across portfolio companies, is what you’d expect if that’s true. The money went to the interesting use cases rather than the ones sitting behind the biggest levers in the plan, and because nobody measured the starting point, nobody can say what it bought. One example in their report has stayed with me. A hospitality portfolio company took thirty candidate processes down to four that were tied to revenue, before they built anything. That narrowing was the actual work. Everything after it was just execution. “Start broad, learn fast” sounds like the responsible thing to do. What it produces is a portfolio of experiments, each too small to matter, none of them measured, and all of them expensive when you add them up. **What has to change: start from the value creation plan, not the use-case list.** Pick the three or four workflows behind the biggest levers. Measure what each one costs today. Let the baseline decide the order. McKinsey’s high performers are twice as likely to have a defined process for measuring AI impact, and I’d bet that’s cause more than effect. Measuring is what turns “what should we build” from a technical question into a financial one. ## 3. The data can’t be reached Third pattern, and the one that makes me wince, because everything upstream can be right and it still happens. The pilot is still a demo because someone exports a spreadsheet by hand every Monday morning, and the AI’s output lives in a chat window that somebody copies out of. That’s a demo, however good it looks. If the output doesn’t land in the system where the work actually happens, the CRM, the ERP, the ticketing queue, then a human is still carrying it across a gap by hand. And the gap is where the time goes. It’s also where the errors go. There are two ways to get this wrong, and they’re opposites. The first is “fix the data first,” which is the responsible-sounding answer and which produces an eighteen-month data platform program during which nothing ships and the sponsor who was excited in month one is gone by month twelve. The second is assuming the model will cope with whatever you give it. It will, in the demo. It won’t in production, when the edge cases show up. MIT looked at 300 enterprise deployments last year and found the failures weren’t about model quality. They came from tools that didn’t plug into the workflow and didn’t learn from it, from what the authors called a learning gap in the organization rather than the technology. Tools that were bought or partnered for and integrated deeply worked about two-thirds of the time. Internal builds that weren’t integrated, about a third. **What has to change: treat data readiness as a property of a use case, not of the whole enterprise.** Make the data for one workflow reachable and documented. Get one integration working end to end, so the output lands where the work is. Then make that integration boring enough that the next use case reuses it instead of starting over. The second use case should take half the time of the first. If it doesn’t, you don’t have a pattern yet, you have two projects. ## 4. The pilot was judged on a demo This is the one that matters most. I’ll come back to why. At the low end, the pilot was judged on the demo, or on the fact that the people who tried it liked it. At the high end, before anyone built anything, there was a written test: a hundred or so real cases, the right answers, and a pass mark the business owner had agreed to. Think about what the person who has to sign off on production is being asked to do. Put an AI system in front of customers, auditors or the board, on the evidence that it looked right in a demo. They won’t, and they shouldn’t. So a pilot without a test can’t get signed off no matter how good it is, because there’s nothing a responsible person can point to and say yes. The pilot isn’t stuck because it failed. It’s stuck because nobody can show it didn’t. And I understand how it happens, because the demos really are convincing. The models are good enough now that the first ten examples almost always look right. The trouble is the eleventh, and the hundred-and-eleventh, and you only find those by going looking for them on purpose. MIT’s headline number was that 95 percent of enterprise generative AI pilots show no measurable P&L impact. They don’t blame the models. They blame the learning gap: the organization never built a way to know whether the thing works on the cases that matter, so it never trusted it enough to let it do real work. Software engineering solved this decades ago. It’s called a test suite. Most companies deploying AI have never written one. **What has to change: treat AI output like any other process with a defect rate, and write the acceptance test before you build.** Fifty to a few hundred real cases with the right answer attached, and a threshold the owner signed. That turns “do we trust it” into a number, and a number is something a sponsor can approve. It’s also the cheapest fix on this list. A business analyst and someone who knows the process can write the first version in a week. ## 5. There is no cadence Last one. AI at the company is a series of projects rather than a way of working. Each initiative starts from zero. Each one depends on one capable person, the local hero, doing it on the side. There’s no regular review, so every initiative runs until everyone forgets about it. You can survive that with one pilot. With five it’s fatal. The two usual fixes both miss. “Hire a head of AI and stand up a center of excellence” puts the capability somewhere other than where the work is done. “Roll out the tools and let people find the value” puts the capability nowhere in particular, and then counts licenses. FTI surveyed 200 PE fund and operating leaders this year and found talent the top constraint on scaling AI, cited by 35 percent. I’d read that carefully. MIT’s data points the other way: the deployments that worked were the ones that empowered line managers, not a central lab. The talent that matters is the operator who owns the workflow, not the specialist who owns the model. **What has to change: a product owner, an engineer and a domain lead on every initiative, and a monthly review with the authority to kill the weak ones and move the money to the strong ones.** BCG’s survey this autumn found the share of companies getting real value from AI jumped from 5 percent to nearly half in a year, and the leaders among them are growing EBITDA 2.8 times faster than the laggards. What they have in common isn’t who they hired. It’s that they run AI as an enterprise program, with retraining built in (seven in ten of them), and the people doing the work are the ones running the change. *The five dimensions. Most companies sit somewhere in the middle on each; the interesting question is which one is lowest.* ## The five are not equal If I could fix only one of these at most of the companies I see, it would be the fourth. The other four slow AI down. The fourth stops it. A company with no executive owner can still ship something useful if the right person is stubborn enough. A company with no baseline can still get value; it just can’t prove it. A company with bad plumbing can carry output across the gap by hand for a surprisingly long time. But a company with no test can’t get anything into production at all, because nobody accountable will sign off on a system whose only evidence is that it looked right, and they’re correct not to. It’s also the fastest of the five to fix, which is the part people don’t expect. The other four take a quarter or two of organizational change. A written evaluation set takes a business analyst and a domain lead about a week, and it changes the conversation with the sponsor from “do we trust it” to “it passes.” Once that artifact exists, the other four gaps start closing on their own, because now there’s finally something to own, something to measure against, and something worth wiring in. How to write that test well, what goes in it, how many cases you need, who decides the pass mark, what to do when the model passes the test and still fails in production: that’s a whole separate article. For now the only question is whether one exists. ## Where you sit If you’d like to see where your company sits on these five, I turned them into a scorecard. Fifteen questions, about four minutes. It tells you which of the five is your bottleneck, why it’s probably there, and what I’d do first in your seat. It’s the first half hour of the assessment I get paid for, and it’s free, at [flatironconsulting.ai](https://flatironconsulting.ai). *Figures: McKinsey, The State of AI 2026 (1,719 respondents, fielded May–June 2026); BCG, AI at Scale 2026 (1,330 senior leaders, September 2026); Bain, Getting Past the AI Value Paradox in Private Equity (September 2026) and Bain CEO Survey 2026 (n=100); MIT NANDA, The GenAI Divide: State of AI in Business (2025; ~150 interviews, 350-person survey, 300 deployments analyzed); FTI Consulting, 2026 Private Equity AI Radar (200 fund and operating leaders, May 2026). The MIT success-rate figures depend on how the authors defined measurable impact, which the public summary does not spell out; treat them as directional.*