The number everyone quotes is 95%. MIT's NANDA initiative found that 95% of enterprise generative AI pilots deliver no measurable business impact. Other measurements land in the same range: RAND puts AI project failure above 80%, roughly double the rate of conventional IT projects, and 42% of companies abandoned most of their AI initiatives in 2025 — up from 17% the year before.
The usual explanation is that organisations lack an AI strategy, or that change management was neglected, or that expectations were unrealistic.
I spend my time measuring what large companies actually run, and I think that explanation is mostly wrong. The pilots don't fail because of strategy. They fail at the seam between the pilot and everything else — and that seam is an engineering problem, which means it can be diagnosed before you start rather than discovered after you've spent the budget.
The pilot succeeds. That's the problem.
Here is the pattern, and once you've seen it a few times you can predict the outcome in the first meeting.
A team gets access to a model. They pick a use case with clean, available data — often an export someone prepared by hand. They build something in six weeks. It works. The demo is genuinely impressive, because modern models are genuinely impressive.
Then the pilot has to become a system. And at that point it needs:
- a live connection to the source data, not a hand-prepared export
- an identity model, so the agent sees what the user is allowed to see and nothing more
- a way to know when it was wrong, and a path for a human to correct it
- versioning, because the prompt will change and the model underneath will change without asking permission
- an owner, a budget line, and someone on call at 3am
None of these are AI problems. All of them are platform problems. And in most large organisations, the platform that would answer them doesn't exist yet — which is why the pilot stops, quietly, without anyone declaring failure.
The pilot didn't fail. It succeeded at proving the model works, and then ran into the fact that the model was never the hard part.
What "AI-ready data" actually means
The phrase gets used loosely enough to be meaningless. In practice it means four specific things, and you can check them in an afternoon.
Can the system reach the data while it's running? Not "is the data available" — can a service, authenticated as a specific user, query it at request time within an acceptable latency? An awful lot of enterprise data is available for reporting and unreachable for anything live.
Does someone own each field? When two systems disagree about a customer's address, which one wins? If nobody can answer that in a sentence, an agent won't be able to either, and it will confidently pick one.
Are permissions expressible? Retrieval-augmented generation retrieves. If your access rules live in the application layer rather than the data layer — and in most large organisations they do — then the retrieval step will happily surface documents the user was never meant to see. This is the single most common reason a working pilot never gets security sign-off.
Is there a feedback path? When the output is wrong, is there a mechanism to capture that, or does the correction happen in someone's head and disappear?
Four questions. If the answer to any of them is no, the pilot will demo well and stop there. Not because the AI is inadequate — because the plumbing isn't finished.
Two companies, same problem, opposite starting points
Two examples from a panel of large European companies I track weekly. Both are public, both are recent, and together they show that this problem is independent of how advanced you are.
A major European insurer ranked first in its sector's AI index in 2026, with more than 900 AI use cases deployed globally. Its internal experimentation platform has allowed employees to create over 30,000 agents. By any external measure, this is the most AI-advanced insurer in the world.
The same company is still switching off its mainframe. Its CTO describes application consolidation and legacy shutdown as the precondition for cloud migration.
Read those two facts together. Thirty thousand agents created by employees in a lab is a spectacular signal of appetite — and a governance problem nobody has solved yet. Which of those agents can reach customer data? What happens when the underlying model is deprecated? Who turns off the twenty-nine thousand that nobody uses? These questions get harder, not easier, when the platform underneath is mid-migration.
A major European bank is moving its IT estate to a public cloud. In parallel it has kept its FX trading platform on hybrid infrastructure because that suits its constraints better, and it is migrating its databases to a cloud-in-your-own-datacentre product for regulatory reasons. More than twenty business-critical applications are being re-architected by an external integrator.
Every one of those decisions is defensible on its own. Together they describe an organisation that will operate three parallel environments for several years. And every new AI use case has to cross all three to reach its data.
Different companies, opposite ends of the maturity scale, same underlying issue: the AI layer moved faster than the foundation it sits on.
That's a better problem than the one people usually diagnose. It isn't "they talk about AI without doing it." They're doing plenty. The budget is approved, the sponsor exists, the appetite is real. What's missing is specific, technical, and solvable.
The diagnostic that takes an afternoon
Before approving the next pilot, run this. It is deliberately unglamorous.
1. Name the system of record for every field the use case touches. Not the system the data was exported from — the one that wins in a conflict. If this takes more than an hour, you've found your first problem.
2. Trace one request end to end, on paper. User asks a question, system authenticates them, retrieves N documents, calls a model, returns an answer. Write down every hop and who owns it. Count the hops that cross an organisational boundary. That number predicts your timeline better than any estimate.
3. Ask what happens when it's wrong. Not "how accurate is it" — what is the mechanism when a specific answer is wrong on a specific Tuesday. If the answer is "the user will notice", you don't have a production system, you have a demo with users attached.
4. Ask who pays for inference. Cost per request times projected volume. Many pilots are economically fine at pilot volume and absurd at production volume. Better to find that out now.
5. Ask what happens when the model changes. It will, and you won't control the timing. Is there an evaluation set that would catch a regression? If not, you'll find out from a customer.
Five questions, half a day. They won't tell you whether the use case is valuable. They will tell you whether it can exist — which is a different question, and the one that gets skipped.
The uncomfortable implication
If this analysis is right, then the largest piece of AI work over the next two years isn't AI work.
There's a concrete deadline attached to this, at least for the very large number of companies running SAP. SAP's AI roadmap is explicitly staged, and the first stage isn't AI at all — it's "clean core." Before the platform layer, before the AI foundation, before any agent: a clean core. In practice that means unwinding years of custom ABAP development, stopping modification of the standard, moving extensions to a separate layer, and exposing data cleanly. And 2026 is being positioned as the last year in which adopting SAP's AI can remain optional experimentation.
That is refactoring, data migration, and technical debt repayment. The word "AI" will be in the budget line. The work will be plumbing.
There's independent evidence this is already happening. Accenture reported $11.5bn in cumulative advanced AI bookings through Q1 FY2026, and noted that half of those projects bundle data modernisation. The largest AI consultancy in the world is telling you, in its own earnings commentary, that half of what it sells under an AI label is data infrastructure work.
That's not a criticism. It's a confirmation. The market has already discovered where the work is — it just hasn't renamed it yet.
What to do differently on the next one
Not "do a data project first." Nobody funds an eighteen-month data programme with no visible outcome, and they're right not to.
Instead: pick the pilot for what it forces you to build.
Most organisations pick the use case with the highest projected ROI, discover it needs infrastructure that doesn't exist, and stall. The alternative is to choose a use case that is modest in value but forces you to build one piece of durable platform — a real-time connection to a system of record, a permission-aware retrieval layer, an evaluation harness.
The first pilot returns less. The third one ships in a fraction of the time, because the seam is already sewn.
The companies in the 5% aren't the ones with better models. Everyone has access to the same models. They're the ones who treated the first pilot as infrastructure work with a demo attached, rather than a demo with infrastructure to be sorted out later.
The gap between a pilot budget and a production budget is where most of this money disappears. We break the ranges down in What AI and Data Consulting Actually Costs.
Sources: MIT NANDA, "The GenAI Divide: State of AI in Business 2025"; RAND Corporation on AI project failure rates; Accenture Q1 FY2026 results; company disclosures and career-portal data collected 2026-07-26 as part of an ongoing weekly review of 54 large European and Middle Eastern companies.
Fares runs QartMina Labs, an independent backend and AI engineering practice. He tracks the technology posture of 54 large companies across France, Germany and the Middle East.