AI adoption is a management problem, not a model problem

By now everyone has a number for how often AI fails. RAND put it at more than 80 percent of AI projects, roughly twice the failure rate of IT projects that do not involve AI (RAND, 2024). MIT’s 2025 study of enterprise generative AI found that 95 percent of pilots delivered no measurable return, and only about 5 percent ever reached production (MIT, via Forbes, 2025). Gartner expects close to a third of generative AI projects to be dropped after the proof of concept (Gartner, 2024).

The usual explanation is that the technology was not ready, or the data was messy. Sometimes that is true. But if you read what these studies actually say about the failures, they keep pointing somewhere less comfortable. Not at the model. At the organisation around it.

What the failure numbers actually say

RAND interviewed 65 data scientists and engineers about projects that went wrong. The first root cause they name is not technical. It is that leaders and the technical team never agreed on the problem the project was meant to solve, so success was never clearly defined and accountability never landed. MIT describes the same thing from the other side: the pilots that failed were the ones that did not fit how people actually work day to day.

BCG has put a number on it. In what they call the 10-20-70 rule, about 10 percent of the value of an AI effort comes from the algorithm, 20 percent from the data and technology, and 70 percent from people and process, meaning the workflows you redesign, the roles you rewrite, and the training you actually do (BCG). Their blunt version is that the model you pick is almost beside the point.

This is not only consultancies and think tanks. A 2024 peer-reviewed review in PLOS ONE of what actually blocks AI inside hospitals found the same shape: the primary barriers were organisational and human, leadership gaps, weak change management, conflicting performance targets, and too little training, rather than the algorithm. Its plainest sentence reads almost like a warning label: the more a system forces a workflow to change, the harder it is to adopt (Nair et al., 2024).

Read together, study after study, with different methods and different authors, lands in the same place. The thing that decides whether AI works inside an organisation is mostly not the AI.

To be clear, I am not saying the model never matters. Sometimes it genuinely is the problem, and I have shipped enough of these to have guessed wrong about which was which more than once. But when you line the failures up, the model is rarely the thing standing over the body.

The management gap

I call the space where these projects die the management gap. It is the distance between the team that bought or built the system and the people who have to run it every day, and it is where ownership quietly fails to land.

It looks like this. A pilot works in a demo. Procurement signs. Then the system meets the caseworker who does not trust its output, the clinician who has no spare minute to check it, and the process that was never redesigned around it. None of that is a modelling problem, so none of it is fixed by a better model. It is an ownership problem, and ownership gets decided before you buy, not after.

The gap is easy to miss because everyone in the room is doing their job well. The vendor demoed honestly. The data team shipped a model that scores well. The executive approved a real budget. What no one did was decide who owns the workflow after go-live. That single omission is the failure, sitting there quietly, waiting for launch.

Why high-stakes industries feel it worst

In a consumer app you can ship, watch what happens, and patch. In healthcare, public services, or law you cannot. The cost of being wrong is a patient, a benefits decision, a legal exposure. So the people expected to use the system are right to be careful, and “we will fix it in production” is not a sentence they are allowed to say.

That does two things to the management gap. It widens it, because the distance between a data team and a clinical or casework floor is large to begin with. And it makes it unforgiving, because in regulated work what you actually operate is the floor, the worst case the system produces on an ordinary day, and the floor is where the whole risk lives.

What owning the workflow actually means

Ownership is a word that dies in a slide unless you make it concrete. In practice it means four specific things, and none of them are about the model.

First, redesign the work before you buy the tool. An AI dropped into an unchanged process does not remove a step, it adds one: now someone has to read the output and decide whether to trust it, on top of the job they already had. If the process does not change, you have not adopted AI, you have added overhead. Most of the 70 percent BCG talks about is this decision, what the humans stop doing, what they start doing, and where the AI actually sits in the flow.

Second, name one person with the authority to change that process. Not a committee, not the vendor, not a data team two floors away. Someone close enough to the work to notice when the AI is wrong, and senior enough to change how the work is done in response. If the only people who understand the system cannot change the process, and the only people who can change the process do not understand the system, the gap is structural, and no amount of model tuning will close it.

Third, measure the floor, not the average. Most dashboards report average accuracy, which is the number that looks best and matters least. What the operator lives with is the worst case on a normal day. Decide, before launch, what floor you can accept, who watches it, and what happens when it is breached. A system with a 92 percent average and an ugly, unwatched tail is not a 92 percent system to the person holding the bad 8 percent.

Fourth, fund the part that is not software. The uncomfortable implication of the 10-20-70 rule is that most of the budget and most of the calendar should go to things that do not look like AI: training, process change, and the slow work of getting people to trust and actually use the thing. Organisations tend to do the opposite. They spend on the 30 percent that is easy to buy and starve the 70 percent that decides the outcome.

In the EU, this is now the law

Until recently, closing the management gap was good practice you could quietly skip. In the EU you no longer can. The AI Act phases in over several years, and the core obligations for standalone high-risk systems, the ones used in areas like health, essential services, employment, and law enforcement, apply from 2 December 2027.

Article 14 requires that high-risk AI systems be built so a human can effectively oversee them in use (EU AI Act, Article 14). Article 26 puts the operational duty on the organisation that deploys the system: it must assign that oversight to a named person, or people, who have the competence, training, authority, and resources to actually carry it out (EU AI Act, Article 26).

Read those words again with the management gap in mind. Competence, training, authority, resources, assigned to a named human who is close to the work. That is not a compliance formality bolted onto a technical system. It is a legal description of the exact thing that, done or skipped, decides whether the project works at all. The Act has effectively turned “who owns this workflow” into a question you must be able to answer on paper. A lot of organisations are about to discover that they cannot, and that the honest answer was never really about the AI.

How to tell if the gap is already open

You do not need a study to find the gap in your own project. You need one question, asked early: who owns this workflow the day after go-live?

If the answer is the vendor, or “the AI team,” the gap is already open. The vendor leaves. The AI team builds systems; it does not run your operation. The workflow has to be owned by someone on the floor who can change how the work is done and who answers for it when the output is wrong. If you cannot name that person before you sign, you are buying a pilot, not a system.

A few follow-ups tend to surface it fast:

• Who is allowed to overrule the AI, and what happens to their day when they do?
• Whose job actually changes, and have they been told, trained, and given the time?
• When the system is wrong on a normal Tuesday, who notices, and who fixes it?

Take an illustrative case. A hospital buys a tool that flags patients at risk of deterioration, and in the demo it catches cases early and looks impressive. Now run the questions. Who overrules it? The nurses, except their shift has no slack to check every flag, so they end up either trusting it blindly or tuning it out, the alert fatigue those same healthcare studies keep documenting. Whose job changed? Nobody told the nurses their triage now starts from an AI list, and nobody trained them on what the score does and does not mean. Who fixes it when it is wrong at three in the morning? Unclear: the vendor owns “the model,” IT owns “the system,” and the false alarm that woke a ward goes nowhere. The model here might be excellent. The adoption fails anyway, and it fails in the gap.

None of those are AI questions. They are management questions, and the fact that they feel out of scope for an “AI project” is exactly the problem.

What I have seen

None of this is theoretical for me. I build and ship AI in exactly these settings, chronic disease care, social services, and legal and compliance work, and the pattern has held every time I have watched it up close. The efforts that struggled were almost never the ones with the weaker model. They were the ones where, on the day the system went live, no single person close to the work actually owned the workflow it was meant to change, and the handoff from the people who built it to the people who had to use it belonged to no one.

What to do about it

Before the next AI project, spend the first meeting on ownership, not on the model. Name the person on the floor who will own the workflow and carry the consequences. Redesign the work before you buy the tool. Decide what floor you can live with and who watches it. And put the budget where the value is, the 70 percent that is people and process, not only the part that is easy to purchase.

The organisations in MIT’s 5 percent did not have better models than everyone else. They had someone who owned the change. That was the whole difference, and it was never a technical one.

---

Sources

• RAND Corporation, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed (2024).
• MIT Project NANDA, The GenAI Divide: State of AI in Business (2025), as reported by Forbes.
• Gartner, Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025 (2024).
• Nair, M. et al., A comprehensive overview of barriers and strategies for AI implementation in healthcare: Mixed-method design, PLOS ONE (2024).
• Boston Consulting Group, the 10-20-70 approach to AI value.
• Regulation (EU) 2024/1689 (the EU AI Act), Articles 14 and 26.