Why Enterprise AI Adoption Is Failing

The short version

• Enterprise AI is failing at the deployment layer, not at the model layer. MIT's NANDA initiative found 95% of generative AI pilots delivered no measurable P&L impactP&L impactA measurable effect on the profit and loss account: more revenue, lower cost, or both.The AI profit and loss view. RAND found more than 80% of AI projects fail, twice the failure rate of IT projects that do not involve AI. In both cases the reason given is the same: the systems were not built for the work they were dropped into.

Sources: MIT NANDA, The GenAI Divide (2025), as reported by Fortune (opens in a new tab) · RAND, RR-A2680-1 (2024) (opens in a new tab)

• The failure is concentrated in five places, and none of them is a technical capability limit: data debt, unit economics that break between the pilot and production, systems that are not fitted to the workflow they serve, governance added after the fact, and a delivery model that rebuilds everything from scratch for every client. RAND names a separate cause, applying AI to problems beyond current capability, and ranks it last among its five.

• The single most concrete failure mode is economic. A pilot that runs comfortably for ten users on pay-as-you-go pricing becomes a serious monthly line item at ten thousand, because inferenceInferenceThe work a model does each time it answers a question. It is the part of AI you pay for every day, as opposed to the one-off cost of building the model.Tokens and inference cost grows faster than usage, while pilots are priced on free credits and clean, light traffic. The model bill is also only part of the cost: data engineering, maintenance, evaluation, governance, integration and people make up the rest, and a pilot is designed not to reveal them. Report 03 sets out the arithmetic.

• Data is the substrate problem, and everything downstream derives from it. Most enterprise data is unstructured, scattered across legacy ERPs, departmental databases, shared drives and email, with no single way in, no shared definitions, no record of where it came from and no consistent access control. Measured on real enterprise data rather than demonstrations, the gap is stark: question-answering accuracy on a raw enterprise schema was 16.7%, and 54.2% when the same questions were grounded in a governed knowledge graph. Naive single-step retrievalRetrieval (RAG)Retrieval-augmented generation: the system searches your documents for relevant passages and gives them to the model before it answers.Grounded answers scores around 0.40 against 0.73 when the right documents are supplied outright, and the canonical failure taxonomy puts most of the seven failure points before the model is involved at all.

Sources: IDC forecast that 80% of data will be unstructured, via Solutions Review (opens in a new tab) · Sequeda et al., knowledge graphs and enterprise question answering (2023) (opens in a new tab) · Krishna et al., FRAMES (2024) (opens in a new tab) · Barnett et al., Seven Failure Points When Engineering a RAG System (2024) (opens in a new tab)

• The causal chain is short and it is worth stating plainly: systems built without the specific workflow in mind, plus data debt, produce no lasting assets, so every project re-solves data, evaluation, governance and cost from scratch, so pilots succeed small, subsidised, on clean data and low volume, and stall at scale. The stall is then recorded as an AI failure when it was a fit failure.

What the evidence shows

1. Problem framing and fit outrank technology as causes. RAND's interviews identify five root causes: problems that are misunderstood or poorly communicated, inadequate data, gaps in infrastructure and integration, premature focus on advanced technique, and, last, applying AI beyond what it can currently do. Four of the five are about how AI fits into the organisation around it. Only one is a technical limit.

Source: RAND, The Root Causes of Failure for Artificial Intelligence Projects (2024) (opens in a new tab)

2. AI added on top of an inefficient process inherits every inefficiency underneath it. Most organisations already run their work through layers of hand-offs, re-keying, approvals and workarounds that grew up over years. An AI system placed on top of those layers does not remove them; it adds one more, along with the job of checking what the AI produced. McKinsey's data shows the organisations that see financial impact are the ones that rework the process itself, removing the redundant layers, rather than automating around them.

Source: McKinsey, The State of AI (2025) (opens in a new tab)

3. The market has begun telling AI programmes apart. Investors and credit analysts have started distinguishing between companies that adopt AI and companies that can show what it returns. A programme now has to be able to show its benefit, not only its activity.

4. Retrieval failures are information architecture failures. The canonical taxonomy of retrieval failures names seven distinct failure points, and most of them sit before the model: content that is missing from the corpus, documents that never make the retrieved set, structure destroyed in parsing, and the wrong passages surviving consolidation. On questions requiring more than one hop, naive single-step retrieval reaches around 0.40 accuracy against 0.73 when the correct documents are handed over outright, which locates the deficit in the retrieval stage rather than in the model. The causes are foundational rather than algorithmic: stale or conflicting sources, parsers that destroy table and section structure, arbitrary chunking that separates a heading from its content, and access control that lets restricted content reach a model.

Sources: Barnett et al., Seven Failure Points When Engineering a RAG System (2024) (opens in a new tab) · Krishna et al., FRAMES (2024) (opens in a new tab)

5. A good AI system knows when to hand over to a person. One that does not, fails. A randomised field experiment in Alibaba's Taobao customer service found that an agentic AI system made chats faster but lowered customer ratings on the chats it handled. Handing over to a person protected quality when the problem was technical, and helped far less once a customer was already upset. The lesson is that the hand-over is the product: a system designed to recognise the difficult case and pass it to a person early holds quality, and a system that keeps trying on its own does not. Klarna is the best-known public example. Its assistant was reported in 2024 as doing the work of 700 agents; in 2025 its chief executive said cost had weighed too heavily in the design, quality had suffered, and the company began hiring people back into customer service.

Sources: Agentic AI and Human-in-the-Loop Interventions: Field Experimental Evidence from Alibaba's Customer Service Operations (2026) (opens in a new tab) · Fortune on Klarna's return to human support (2025) (opens in a new tab)

6. Prompt injection is the leading identified security risk, and may never be fully fixed. The NCSCNCSCThe UK National Cyber Security Centre, the government's technical authority on cyber security. It publishes guidance for organisations on new risks, including AI.ncsc.gov.uk (opens in a new tab) has published the position directly: because a language model has no built-in separation between instructions and data, prompt injectionPrompt injectionHiding instructions inside text an AI system reads, such as an email or a web page, so the system follows them instead of the user. It is the most widely reported security risk for AI assistants.OWASP on prompt injection (opens in a new tab) may never be closed off the way SQL injection was. Separately, IBM found that 97% of organisations breached through AI said they lacked proper AI access controls, and that shadow AIShadow AIStaff using AI tools the organisation has not approved, often through personal accounts, so company data leaves without anyone knowing.Why an AI inventory comes first added roughly $670,000 to the average breach cost.

Sources: NCSC, Prompt injection is not SQL injection (2025) (opens in a new tab) · IBM, Cost of a Data Breach Report 2025 (opens in a new tab)

1. What the research houses found

1.1 The six studies

Source: each study is linked from its name in the table above.

Frontier model capability, over the same period, raced ahead. The binding constraint moved from what the models can do to whether a system is built around the organisation that uses it.

1.2 The pilot-to-production cost cliff

The most concrete technical failure is economic, and it has a shape.

Inference cost does not scale linearly. Frontier models are billed per tokenTokensThe small pieces of text, roughly three quarters of a word each, that AI providers count and charge for.Tokens and inference, and the price for generated output is several times the price for input. Pilots run on free credits, clean data and low, predictable traffic. Production runs on list prices, messy data and bursty traffic. The result compounds rather than adds: follow-up questions reload the whole conversation, malformed output gets retried, and agents branch into sub-tasks. Report 03 works through the numbers.

Because the solution was not tailored to the use case, a set of follow-on problems appears. Output has to be verified by hand; results vary from one run to the next, so ordinary quality checks stop working; connections to several systems at once break when any one of them changes; and success was never defined at the start, so nobody can say whether it worked. Staff end up spending their time on these tasks rather than on the output the system was meant to produce.

Mitigation exists, small tuned models, routingRoutingSending each request to the cheapest model that can handle it well, and saving the expensive models for the hard cases.Fine-tuning and routing, distillationDistillationTraining a small, cheap model to copy the behaviour of a large one on a specific task.Fine-tuning and routing and caching, and it is real. Distillation is the clearest published case: DistilBERT reduced model size by 40% while retaining approximately 97% of language understanding and running 60% faster. Sending routine traffic to a small tuned model and escalating only the edge cases lowers the inference bill by a large multiple. But every one of those techniques requires an evaluation harness, curated data, routing infrastructure and continuous retraining.

Sources: Sanh et al., DistilBERT (2019) (opens in a new tab) · Belcak et al., NVIDIA, Small Language Models are the Future of Agentic AI (2025) (opens in a new tab)

1.3 Data readiness, the deepest cause

Every research house converges on data as the substrate problem. S&P Global's enterprise survey puts cost, data privacy and security at the head of the obstacle list, and the share of companies abandoning most AI initiatives before production rose from 17% to 42% in a year. IBM found 50% of chief executives reporting disconnected technology and 72% identifying proprietary data as the key to unlocking value.

Sources: S&P Global, Voice of the Enterprise, via CIO Dive (opens in a new tab) · IBM CEO Study 2025 (opens in a new tab)

The structural problem is that enterprise data lives in silos, legacy ERPs, departmental databases, and vast quantities of locally held unstructured files. There is typically no single access layer, no shared definitions, no lineageLineageA record of where a piece of data came from and every step that changed it on the way to an answer.OpenLineage (opens in a new tab) and no consistent access control. Aggregating and securing that data is the single largest cost in any AI programme, and the one most often estimated at a fraction of its real size.

Retrieval failures make this concrete. Grounding the same question set in a governed representation of the data, rather than pointing a model at the raw schema, took enterprise question-answering accuracy from 16.7% to 54.2% in a controlled benchmark. That is why the data layer has to be built once, properly, as a reusable component, not re-solved by hand for every use case.

Source: Sequeda et al., knowledge graphs and enterprise question answering (2023) (opens in a new tab)

1.4 Agentic deployment is behaviour modelling, not prompting

Drawing on more than fifty agentic builds, McKinsey's QuantumBlack team states that onboarding an agent is more like hiring a new employee than deploying software. Agents should be given clear job descriptions, onboarded, and given continual feedback. Organisations that focus on the agent rather than the workflow produce impressive-looking agents that do not improve the workflow at all. The starting point has to be mapping the process and finding where the pain actually is.

Source: McKinsey, One year of agentic AI: Six lessons from the people doing the work (2025) (opens in a new tab)

The real step change comes from combining tacit knowledge with agents. The judgement experienced people carry in their heads, how they handle the unusual case, which customer needs a call rather than an email, is most of what makes them valuable. Captured carefully and given to an agent, that knowledge lets the system handle the exceptions as well as the routine, at a scale no team could reach by hand. That combination, not the model on its own, is where the real change in how work gets done comes from.

Timing of human intervention determines the outcome. The Taobao field experiment is the most useful evidence here: handing over to a person worked when it happened early and when the problem was technical, and helped much less once a customer was upset. The design implication is that human-in-the-loopHuman in the loopA design where a person reviews, approves or takes over from the AI at defined points.Human in the loop is not a safety net at the end of the process; it is a trigger placed before the failure, and calibrating that trigger is design work.

Source: Agentic AI and Human-in-the-Loop Interventions: Field Experimental Evidence from Alibaba's Customer Service Operations (2026) (opens in a new tab)

1.5 Governance, security and jurisdiction

As AI moves from pilot to everyday use, a number of regulations apply to it, and most current systems were not built with them in mind.

The EU AI Act (opens in a new tab) entered into force in August 2024. It asks organisations to manage risk on an ongoing basis, look after the quality of the data the system uses, keep logs that cannot be quietly changed, be open about when AI is in use, allow human oversight, and keep the system secure. Each of these takes careful planning, which is why it is easier to design for them from the start than to add them later. Our EU AI Act explainer sets out what applies and when.

Sources: Regulation (EU) 2024/1689, the AI Act (opens in a new tab) · European Commission summary (opens in a new tab)

Data residencyData residencyWhere data is physically stored and processed, and which country's laws therefore apply to it.Data protection and AI is a related consideration. A cloud region operated by a provider headquartered in another country may remain subject to that country's legal requests, wherever the data is physically stored; Microsoft France confirmed this position to the French Senate in June 2025. National data protection laws, and sector rules in banking and healthcare that require certain data to be stored in-country, add further requirements that differ from one jurisdiction to the next.

Source: SDxCentral on Microsoft France's testimony to the French Senate (2025) (opens in a new tab)

On security, prompt injection is ranked first among risks to language-model applications by OWASPOWASPThe Open Worldwide Application Security Project, a non-profit that publishes widely used security guidance. Its Top 10 for language-model applications lists the most serious risks to AI systems.OWASP Top 10 for LLM applications (opens in a new tab), and both OWASP and the UK's National Cyber Security Centre indicate it may never be fully solved. Documented exploits have included EchoLeak, a zero-click flaw that allowed data to be extracted from Microsoft 365 Copilot through a single crafted email; Microsoft fixed it in 2025. Shadow AI adds to the exposure: one 2025 study found that most workplace use of generative AI tools happens through personal, unmanaged accounts.

Sources: OWASP Top 10 for LLM Applications (opens in a new tab) · The Hacker News on EchoLeak, CVE-2025-32711 (opens in a new tab) · TechRepublic on LayerX's 2025 enterprise AI data report (opens in a new tab)

In short, these rules ask you to show who used an AI system, what it did and why. A quick pilot is rarely built to answer those questions, and that is often what stops it going live.

1.6 The delivery model itself is part of the failure

When an AI system completes in minutes what a consultant billed hours for, the hourly model means billing less for a better outcome. It discourages exactly the behaviour the firms need to adopt. Reporting indicates the large firms are moving, with a growing share of fees tied to outcomes rather than time.

The evidence of delivery-led underperformance sits inside the failure statistics themselves. A large share of the stalled pilots were bespoke projects: each one hand-built rather than repeatable, so nothing carries over and every client pays again to re-solve the same data, evaluation, governance and cost problems.

The exception proves the rule. The firms that work in this space successfully lead with a product and a model of how the business actually works, and embed engineers to configure it rather than rebuild it. Model capability was never the bottleneck. Deployment that fits the organisation is.

2. Causes and symptoms

Separating fundamental causes from derivative symptoms matters, because most remediation programmes attack the symptoms.

Fundamental cause 1, Data debt. Decades of siloed, ungoverned, unstructured data with no single access layer and no shared definitions. Everything downstream, retrieval failure, hallucination, integration brittleness, derives from this. It is fundamental because no amount of model capability compensates for it.

Fundamental cause 2, Delivery economics that do not carry over. AI delivered as one-off, billable-hours projects, so nothing is reusable, incentives reward effort rather than outcomes, and unit economics are never designed for scale. It is fundamental because it decides whether learning builds up across deployments or disappears at the end of each one.

Fundamental cause 3, Systems not fitted to the workflow, and no capture of tacit knowledge. Agents placed on top of existing processes rather than the process being reworked and the expertise written down. McKinsey's data puts this first among the correlates of financial impact.

Derivative symptoms, each caused by the above: cost explosion at scale (from having no routing or small-model architecture); evaluation and trust gaps (from having no test harness); governance and security failures (from adding them on rather than building them in); talent gaps (from every project being bespoke); procurement mismatch (from the billable-hours model).

Systems not built for the specific workflow + data debt → no lasting assets → every project re-solves data, evaluation, governance and cost from scratch → pilots succeed small, on subsidised pricing, clean data and low volume → they stall at scale on cost, messy data, missing governance and missing trust → abandonment.

3. How we deliver because of it

We built our delivery model in response to this diagnosis, and the response is structural rather than clever.

Gate on economics before anyone builds. A standard assessment of how ready the data is, candidate use cases scored on how specific the domain is and how deeply they sit in the workflow, and a hard unit-economics model projecting the cost from ten users to ten thousand before the build. The gate exists to stop the projects that were never going to work, and stopping them early is the cheapest intervention available.

Build the data foundation once, as a product. Certified connectors, an automated normalisation pipeline, a semantic layerSemantic layerA shared map that translates raw database tables and columns into business terms like customer, order and revenue, so people and AI ask questions the same way.Systems of record, access control enforced at question time, lineage and freshness monitoring. Because retrieval accuracy on governed data is so much higher than on ungoverned data, this is the single highest-leverage investment available, and building it once means its cost is shared rather than paid again by every client.

Build the evaluation harness before the model work. Real prompts and real workflows, re-run continuously, measuring how often tasks are completed correctly, how often the model invents things and how often guardrails trigger. Without this, variable output and hallucination are unmanageable at scale, and no routing decision can be made responsibly.

Design the cost architecture once, in the platform. Routing to small tuned models for routine traffic with escalation for genuine edge cases, distillation for well-defined high-volume tasks, response and semantic caching, and ordinary code wherever judgement is not actually required. This is the standard answer to the cost cliff.

Map the process before the agent. Then capture the tacit knowledge and the exception paths, and treat the agent as an onboarded worker with a job description, continual feedback and a defined hand-over to a person. Design for the difficult case, not the average: that is the Klarna lesson.

Build governance in, not on. Access control at retrieval time, tamper-evident logging, model documentation and impact assessments, set by jurisdiction rather than rebuilt for each one.

Instrument from the first day. Token consumption, cost per transaction, latency at percentiles, drift and guardrail hits. The question the instrumentation must always be able to answer: at what user count do we begin losing money per transaction?

What we haven't solved

Standardisation has a tail. The argument that failure modes are common across enterprises is strongly supported by the evidence, but some organisations have genuinely unusual estates or regulatory positions where a configuration becomes a de facto rebuild. The discipline is to recognise that case honestly rather than pretend it does not exist.

Outcome-based pricing is unsolved industry-wide. No firm has standardised what an outcome is worth, who decides whether a target was hit, or how to attribute financial impact to AI. "Roles avoided" is often a modelled estimate rather than a realised saving. Baselines and attribution remain the hardest commercial problem in this market.

Prompt injection may never be fully fixed. Governance reduces the damage; it does not eliminate it. Any honest design assumes compromise and contains it.

Tacit knowledge resists capture. Some expert judgement genuinely cannot be written down. Human-in-the-loop is a mitigation, not a solution, and over-automation reintroduces exactly the failure it was meant to avoid.

The economics are a moving target. Inference prices have fallen sharply while agentic consumption has risen faster. Today's routing calculation may change. The cost architecture has to be treated as a living system with an owner, not a project with an end date.

How far to trust these figures

• Several data points come from surveyed firms' own descriptions rather than audited disclosures. Treat them as reported, not settled.
• Vendor and practitioner sources have a commercial interest in emphasising failure and their own remedies. Where a figure comes from a vendor, it is labelled as vendor research next to the link.
• Forward-looking figures, Gartner's 2027 cancellation forecast among them, are predictions rather than realised outcomes, and are labelled as such wherever they appear.
• We have a commercial interest in this diagnosis, since our services follow from it. The counter is that the primary evidence is public, independent and linked throughout.

What this means for you

Every study above describes the average organisation. Yours is not average: it has its own systems, its own data, its own workflows and its own rules. The question that matters is not why AI fails in general, but which of these five failure points sits in your organisation today, and which of your use cases would clear the economics gate in section 3.

That is a question the research cannot answer for you, and it is the one we answer in our two-week diagnostic. You get a written assessment of your own data, your own use cases and your own cost curve, including a plain recommendation not to build where the numbers do not work. Tell us what you are working on.