Three choices separate the companies making money with AI from the 95 percent stuck in pilots. None of the three is about better models.
A director told me last month that his AI pilot delivered nothing after six months and 40,000 euros. Not because the model didn't work, but because nobody could explain what the company gained from it.
This is not an isolated case. This is the 95 percent MIT counted last year.
In August 2025, MIT's NANDA initiative published a report with a figure that has since come up at every AI conference: 95 percent of corporate AI pilots deliver no measurable return. Five percent do. I wrote about this earlier in why saved time is not ROI, and promised then that I would dig deeper into that five percent. This is that follow-up.
Because the interesting thing about that MIT research isn't the failure rate. We already knew that. The interesting thing is that the researchers could pinpoint exactly where the winners differ. Three choices. And none of the three is about a better language model, a smarter prompt, or more compute. It's about organisational decisions you can make on Monday.
The 95 percent doesn't fail on technology
First, a word about that report, because you need to know what's under the hood before you trust the conclusions. MIT NANDA's State of AI in Business research (opens in new window) is not a large-scale quantitative study. It rests on 52 structured interviews, 153 surveys among senior leaders, and an analysis of more than 300 publicly disclosed AI initiatives, collected between January and June 2025. That's a serious sample, but not a law of nature. I mention this explicitly because the 95 percent figure has since taken on a life of its own, and people cite it as if it were a physical constant.
The core of MIT's analysis is what the researchers call the learning gap. Most companies buy or build an AI tool, place it next to existing work, and expect the return to follow automatically. It doesn't. The problem is almost never that the model is too dumb. Ninety percent of employees already use ChatGPT or Claude privately and find them brilliant. The problem lies in translating "handy tool" into "a change on the profit and loss account." Five percent of organisations make that translation. The rest don't.
The temptation is to think that five percent simply has more money, better data scientists, or more expensive models. That's exactly wrong. The winners make three sober choices that have nothing to do with technology. I'll walk through them one by one, and note each time what it means for your organisation.
Choice 1: buy more often than you build
This is the choice I struggle with most, which makes it the most interesting one for me. I build things myself. Over the past while I've put together more working tools than I ever thought possible, without a development team, just with Cursor and Claude Code. Vibe coding works. And yet my advice to most companies is: don't build, buy.
MIT's numbers are uncomfortably clear here. Companies that bought their AI solution from a specialised vendor achieved a successful rollout roughly two-thirds of the time. In-house builds succeeded about half as often. Twice the success rate, simply by buying instead of building. Fortune (opens in new window) summarised the research and put this difference front and centre, rightly so.
Why is that? A specialised vendor has solved one problem a hundred times. Your internal team solves it for the first time, on half the budget, alongside their regular work, and with the added task of maintaining it once the first version is live. That maintenance is where most in-house builds die. Building is fun and moves fast these days. Keeping something alive is dull and takes years.
I notice this with my own tools. The things I put together in an afternoon work immediately. But the handful I genuinely keep running cost me an hour every week: an API that changes, an integration that breaks, an edge case I hadn't foreseen. For myself, I accept that, because I enjoy it. For an organisation, that's exactly the wrong model. You don't want the continuity of a business process to depend on whether that one builder still has the time and motivation next month.
There's another reason to start with buying, one that's often forgotten: it gives you time immediately. A purchased tool runs this week, not in six months. That also makes buying the smartest validation tool you have. You deploy it, you measure what happens, and within a few weeks you know whether the problem is big enough to invest in seriously. Is the tool used a lot? Does it deliver a demonstrable saving? Only then does the question of whether to build it yourself in the long run become interesting. Buying isn't an end point, it's the cheapest way to test the business case for building before you put a team on it.
That way, building becomes a deliberate next step, not a starting point. You only build yourself once the numbers justify it, and once you have a real edge in data or process that you don't want to hand to a vendor. I made that argument earlier in everyone can build, but not everyone has something to say (opens in new window). The question is no longer whether you can build it. The question is whether you have data worth building on.
Now for an honest nuance in the numbers themselves. The MIT researchers themselves note that the causality isn't watertight: companies that buy externally are often also the companies that already have their procurement process in order. Buying is therefore partly a symptom of maturity, not only a cause of success.
What this means on Monday: look at your current or planned AI project and ask whether a vendor already exists that has solved this exact problem for ten other companies. Does one exist? Then buy it first, win time immediately, and let the tool prove your business case. Building in-house only becomes relevant after that, and only where your data or process gives you a genuine edge.
Follow me on LinkedIn
Choice 2: the return sits in the back office, not the visible front end
The second choice runs directly against where the money is going now. According to the MIT research, more than half of all AI budgets go to sales and marketing. The customer-facing chatbot, the smart recommendation, the AI that makes your website feel more personal. Understandable, because it's visible, it looks good in a press release, and management can show it to customers.
Only the biggest return is rarely found there. It's in the back office. In repetitive, structured processes that nobody ever mentions at a drinks reception. The MIT report gives concrete examples: companies that applied AI to document processing and customer-service handling saved between 2 and 10 million dollars a year on outsourced services. Thirty percent lower costs for external content and creative agencies. A million dollars a year saved on outsourced risk management. Those are not soft time-saving claims. Those are line items that disappear from the cost budget.
And here I need to correct a misconception I held myself for a long time. The back office isn't just a cost item you make cheaper. It's often precisely where the greatest customer value sits. I've become convinced that in the insurance market, where I spend a lot of my time, you win more for the customer at the back end than with that flashy quote module on the homepage.
Take filing a claim. Traditionally, the customer has to fill in a long form, retype data that's already sitting in a document somewhere, and just hope they don't forget anything. Build an intake flow around that where AI reads the uploaded documents, recognises the photos and the invoice, and fills in the right fields automatically, and something changes on both sides at once. The claims handler receives a clean, categorised notification instead of half a form. And the customer barely has to type anything in by hand. That's not a cost saving you hide in a spreadsheet. That's a noticeably better experience at the exact moment it matters most to the customer: when something has gone wrong.
That's exactly why the back office is so underrated. People assume it's about cost, when it's just as much about customer experience. The processes there are repetitive, structured, and easy to measure, precisely the qualities a loose customer conversation lacks. And if you do it well, it cuts both ways: a lower cost per case and a customer who has to do less.
What this means on Monday: make a list of the processes where your customer spends the most time typing, waiting, or repeating themselves. Not the chatbot on the homepage, but the application, the notification, the change request. That's usually where the biggest saving and the biggest jump in customer value sit at the same time. Start there.
Choice 3: rebuild the process, don't just paste a layer on top
The third choice is the hardest to actually carry out, which is why most projects die here. The winners don't lay AI over their existing work as a thin layer. They redesign the process around it.
This is the heart of the learning gap from the MIT report. Most organisations take an existing process, insert an AI step somewhere in the middle, and leave the rest exactly as it was. The result is a tool that helps occasionally but isn't truly responsible for anything. Nobody trusts it fully, so everything gets double-checked, and the time saving that looked good on paper evaporates in practice. The model didn't do anything wrong. The process around it was never adapted.
Compare it to the early years of the office computer. Companies put a PC next to the typewriter and left the work otherwise unchanged. The real productivity gain only came once they redesigned the entire process around what the computer could do. With AI, we're at exactly that point now. The tool is standing next to the typewriter. Whoever dares to remove the typewriter, wins.
Redesigning means asking uncomfortable questions. If AI produces the first version of every claims assessment, what does the claims handler still do, and where does their responsibility start? If a model categorises customer questions, is it allowed to answer them itself, or only pre-sort them? Those aren't technical questions. They're organisational, and sometimes legal, questions, and that's exactly why they get left unanswered. It's easier to buy a tool than to change a job description. But without that second step, you're left with a pilot.
This is where governance comes into play, and that's no coincidence. Whoever redesigns the process also has to establish who is responsible for what when the AI drops the ball. That makes redesign slow and uncomfortable. It's also exactly why the five percent that does it gains such a large lead. Most people give up at the first difficult question.
What this means on Monday: map the process you want to improve with AI from start to finish, and at every step ask what can be removed, not just what AI can add. If the answer is "nothing goes away, AI just gets added on top," you're building a pilot that's going to fail.
Three choices, one common thread
Put the three choices side by side and you see they aren't independent of each other. Buy first, because that wins you time and lets you cheaply test whether building later is worth it. Choose the back office, because that's where the measurable saving and the biggest jump in customer value sit at once. And rebuild the process, because otherwise even the best tool delivers nothing. It's the same underlying attitude, three times over: treat AI as a business decision, not a technology project.
That's the uncomfortable answer to the question posed by the director I opened with. His 40,000 euros weren't lost to a bad model. They were lost because the project was set up from day one as a technical experiment instead of a change in how the company works. He didn't buy, he had something built. He chose the visible front end. And he changed no process at all. Three wrong turns in a row, and a 95 percent chance of failure is actually generous.
The good news is that all three choices are free. They cost no extra compute and no new model. They cost only the willingness to treat AI as something the board is responsible for, rather than something you throw over the fence to IT. That conversation doesn't start with the tool. It starts with the question of what exactly you want to earn, and which of these three turns you've missed so far.
Sources
* The original MIT NANDA research with the three success factors and the learning gap: State of AI in Business 2025 (opens in new window) * Fortune's summary of the report, including the buy-versus-build ratio: fortune.com (opens in new window) * My earlier blog on why saved time is not a return: saved-time-is-not-roi * On data as the real reason to build yourself: everyone can build, but not everyone has something to say (opens in new window)