Last year a founder told me his company "did AI." They ran a pilot, everyone got a chatbot, there were workshops. When I asked what it changed in the business, he thought about it and said the team liked it. That was the whole answer.
He is not unusual. A widely-cited MIT report this year found that around 95% of enterprise generative-AI pilots delivered no measurable impact on profit or loss. Ninety-five percent. No return you could point to.
The number gets passed around as proof that AI is overhyped, or that everyone else is doing it wrong. I read it as something narrower. It's a precise description of a common mistake, and the 5% who avoid it are usually not smarter or better funded. They build the thing in a different place.
The 95% buy activity
Walk into most AI rollouts and the pattern shows up within a minute.
The AI is in the shop window. It's the chatbot on the site, the assistant everyone was told to open, the demo that got applause. It's visible, which feels like progress, and that's exactly why it rarely moves a number.
The dashboard tracks the wrong things. Prompts run. Tokens used. Seats active. All up and to the right, none of them an hour or a euro you could bank.
Nobody owns it. The pilot belonged to everybody, so it belonged to no one, and when it half-worked there was no single person whose job was to make it fully work.
The rules came late. What the AI must never do on its own got written after the first thing went wrong, if it got written at all.
This is activity. It looks like an AI project and it produces almost nothing, because it was built to be seen instead of built to run.
The 5% build infrastructure
The ones that pay off tend to share a shape, and it's a boring one.
The AI is in the plumbing. It sits behind a process that already mattered and quietly takes the repetitive part off a person. Nobody outside the team can tell it's there, and that's the point.
It drafts, and a human sends. Anything that leaves the building goes out as a draft someone approves. The team keeps a hand on the dial, which is the thing that lets them trust it and hand it more over time.
It has red zones from day one. The tasks the AI is not allowed to touch unsupervised are written down before it runs. The guardrails a cautious manager wants turn out to be the same constraints that keep the output good.
It's measured against one real number. Revenue, or an hour saved you can turn into money. If a use can't be tied to a number, it doesn't ship.
And it starts where the week and the revenue actually leak, which is usually the boring, repeated, expensive work rather than the impressive demo.
None of that is clever. It's pointed at a different target.
A quick, honest check
You can usually tell which one you're building with a few questions:
- Could you name the hour or the euro this changed, or only the activity around it?
- If it broke tomorrow, would a customer or the P&L notice, or only the team?
- Who owns it, by name?
- What is it not allowed to do without a human, and did you decide that before or after it went live?
- Is it in the plumbing or in the shop window?
If most of your answers land on the activity side, you built the visible version of AI. That's the version the 95% built, and it's fixable.
Where to start
Stop starting with the tool. Start with the leak. Find the task that eats hours no one should spend, or the revenue that slips at a step you can name. Put a small, governed, drafts-never-sends piece of AI against that one spot, measure the one number, and only then do the next.
If you want a structured way to find your own leaks, I put the self-check I use into a free sheet in the resources here. It scores two things: how much AI could actually help you, and how ready you are to deploy it well. The distance between those two is usually the plan.
The 5% aren't doing something you can't. They started with the leak instead of the launch.