The foundation: engage.re
AI and Data 30 July 2026 10 min read

Why Do AI Projects Fail? The Cause Most Reports Miss.

Most AI projects do not deliver the value their business case promised. Two serious studies name the causes, and neither one blames the model. RAND finds that the root causes are organisational. The National Audit Office finds that legacy systems and data sharing limit what UK government can do. A third study measures the specific defect that both describe, and that defect survives after you fix the others.

Connect with us about your data foundation · · Replies within 24 hours

84%
of RAND's industry interviewees named leadership issues as the main cause
70%
of government respondents were piloting or planning AI use cases
12%
of UK AI users report higher revenue so far

Why do AI projects fail?

They fail for organisational reasons far more often than technical ones. RAND studied this directly and published The Root Causes of Failure for Artificial Intelligence Projects, and it names five root causes.

  1. The wrong problem. Teams misunderstand or miscommunicate what needs solving, so models optimise the wrong measure or fit no workflow.
  2. Missing data. The organisation lacks the data needed to train an effective model.
  3. Technology before the user. The team chases the newest tool instead of a real problem.
  4. Inadequate infrastructure. The organisation cannot manage its data or deploy a finished model.
  5. A problem too hard for AI. Some tasks sit beyond what the technology can do.

One figure from that work matters more than the list. Within RAND's sample, 84% of industry interviewees named leadership-driven issues as the primary cause of failure. The failure therefore sits above the engineering rather than inside it.

What does the UK public sector report?

The National Audit Office examined the use of artificial intelligence in government. It found 70% of respondents piloting or planning AI use cases, with adoption not yet widespread.

It named two obstacles: legacy systems, and data access and sharing. It also warned that value for money is at risk when no department owns the AI strategy.

Those obstacles match the RAND list. Cause two is missing data and cause four is inadequate infrastructure. The NAO describes both in a UK public-sector setting, and it adds a third condition. The data exists, and it cannot move between systems.

Neither report blames the models. Both describe one situation. An organisation cannot get its own data into a usable state, under a clear owner, in time to be useful. The AI is the part that works.

Why does a data problem look like an AI problem?

The failure appears at the end of the project. A team spends months on procurement, data access and integration, and the model arrives last. It then produces a wrong answer and takes the blame for everything upstream.

The Office for National Statistics shows the gap in outcomes. Its 2023 to 2026 series puts UK SME adoption at 54% in 2026, up from 35% the year before, with only 12% of those users reporting higher revenue. Adoption is therefore not the constraint.

The cause that survives

Remove the causes that effort can fix. Suppose your leaders engage with the work, you choose the problem well, the data exists, and the technology can do the task. One defect still remains, and researchers have measured it.

Your database stores the structure of your data, and it does not store the meaning, so a model must invent the business rules that nobody recorded.

A 2026 benchmark tested that directly. Three frontier models answered 99 business questions on a public dataset, twice each, and the second run added a short document describing the measures and the conventions.

Model Schema only Schema and meaning Change
Claude Opus 4.750.5%67.7%+17.2 points
Claude Sonnet 4.646.5%68.7%+22.2 points
GPT-5.445.5%68.7%+23.2 points

With the document present, the three models became statistically indistinguishable from each other. Without it, they also became indistinguishable.

The conclusion in the researchers' words. "the most consequential architectural decision is not which frontier model to use but whether the system is grounded in authoritative business semantics at all." From Semantic Layers for Reliable LLM-Powered Data Analytics, 2026.

We give the full evidence in why AI gets your own business data wrong.

Is readiness a technology purchase?

A recent paper argues that it is not, and its title says so. Why AI Readiness Is an Organizational Learning Problem, Not a Technology Purchase.

That framing matches the RAND finding about leadership, and it explains why buying a platform rarely fixes the problem on its own. A platform can hold a discipline, and it cannot supply the decision to adopt one.

The useful question therefore changes. Not which tool to buy, but which of these failures your architecture makes impossible.

Which failures can architecture remove?

Root cause Removable by architecture? Reason
The wrong problemNoA human decision. Only better scoping fixes it.
Missing dataPartlyArchitecture cannot create data, and it can stop a silo trapping it.
Technology before the userNoA cultural failure.
Inadequate infrastructureYesThis is the definition of an architectural problem.
Too hard for AINoA limit of the technology.
Meaning not recordedYesA declared vocabulary makes the omission impossible.

Two of six is an honest answer, and it still separates a project that can succeed from one that cannot.

What ESRE Media offers

We build your system on engage.re, and four of its properties bear directly on the failures above.

  • Your meaning is declared before your data exists. Your application registers every record type, field and relationship before it writes anything, and the platform refuses a write outside that declaration. Nobody can omit the meaning.
  • No silo can trap your data. Every application uses one shared dictionary, and identifiers are deterministic, so two of your systems mean the same concept without synchronisation. The NAO's data-sharing obstacle does not arise.
  • One identity model and one gate. Identity is a key, so your people, your applications and your agents all prove identity the same way. One authorisation decision covers every crossing, and every access is a recorded event.
  • Your system does not become legacy. The platform holds everything in five database tables, and those five never change. A new record type adds a dictionary entry instead of a table.

Sense Future built engage.re, and it has run in production since December 2025.

How to tell which failure you had

Ask four questions of your last project, and each answer points at a different cause.

  • Where did the months go? Months spent on data access point at infrastructure, and months spent on scoping point at the problem definition.
  • Did the model produce wrong answers, or no answers? Wrong answers with no error point at missing meaning, and no answers point at missing data.
  • Can you explain a single output? Where nobody can trace a number back to its records, you hold no audit path, and that is architecture.
  • Who owned it? Where the answer needs a discussion, RAND's leadership finding applies to you.

What the failure costs

The cost lands in three places, and only the first appears in a post-mortem.

The direct spend covers procurement, licences, integration work and staff time. You know that figure, and of the three it stays the smallest.

The opportunity cost is larger. A team spent twelve months on a pilot that produced nothing, and those months did not go into the service. No invoice records that cost.

The confidence cost lasts longest. A failed pilot teaches an organisation that AI does not work for its problem, and the next proposal then meets a board that has already decided. Where the data could not move between systems, the organisation has learned the wrong lesson from a real event.

The same pattern at two sizes

A council runs an AI pilot in adult social care, and the pilot needs data from housing, revenues and the care record. Each source sits behind a different supplier, a different permission model and a different definition of a person. Twelve months later the pilot reports that the data was not available, and nobody records that as an architecture failure.

A care home group runs the same pilot across a records system, a rota tool and a family portal. Three systems instead of thirty, and the same three obstacles. The manager concludes that AI does not work for care, and the obstacle was the estate.

The care home software and school software pages set out the sector detail. Our guides to CQC digital records and charity data management describe the same problem inside a single sector.

What we do not claim

  • Architecture does not fix most AI failures. Two of the six causes above are structural, and the other four are human.
  • Published failure rates vary between roughly 80% and 95%, and the definitions differ. We prefer the RAND and NAO findings, because both name causes rather than rates.
  • A platform cannot supply leadership. RAND found 84% of interviewees pointing at leadership, and no product changes that.

What to do next

  1. Read your last AI post-mortem again, and count the months spent on data access against the months spent on the model.
  2. Name the owner. The NAO warns about value for money where nobody owns the strategy.
  3. Ask which failure your architecture makes impossible. Where the answer is none, your next project fails the same way.
  4. Record what your data means before the next pilot.
  5. Then decide where that meaning lives: in a document that a person maintains, or in a declaration that your server enforces.

Common questions

Why do most AI projects fail?

For organisational reasons more often than technical ones. RAND names five root causes: the wrong problem, missing data, technology chosen before the user, inadequate infrastructure, and a task too hard for AI. Within its sample, 84% of industry interviewees named leadership-driven issues as the primary cause, so the failure sits above the engineering rather than inside it.

What stops the UK public sector using AI?

The National Audit Office names two obstacles: legacy systems, and data access and sharing. It found 70% of respondents piloting or planning AI use cases, with adoption not yet widespread. It also warned that value for money is at risk where no department owns the AI strategy.

Is the model or the data the bigger problem?

The data. A 2026 benchmark ran three frontier models over the same questions, with and without a description of what the data means. Accuracy rose 17 to 23 points with the description, and the three models then became statistically indistinguishable from each other. The description accounted for nearly all the variance.

Can better architecture prevent AI project failure?

It prevents two of the six causes. It removes inadequate infrastructure, and it makes undeclared meaning impossible. It cannot fix the wrong problem, a culture that chases tools, or a task beyond the technology. That answer is partial, and it still separates a project that can succeed from one that cannot.

What should we fix before an AI pilot?

Record what your data means, and name an owner. A team that has recorded its conventions can choose a model on cost and speed, and a team that has not cannot recover the gap with a larger model.

What does ESRE Media build?

We build your system on engage.re. Your meaning is declared before your data exists, no silo can trap your data, one identity model and one gate cover your whole estate, and your system does not become the legacy the NAO describes.

Connect with us about your data foundation · · Replies within 24 hours

Sources and further reading