Why Generative AI Projects Fail

01The scale of the problem

Between 2023 and 2026, generative AI moved from board curiosity to budget line in nearly every large organisation. Copilots for service teams, drafting assistants for legal, chat over the policy library: the pilots arrived in waves, the demos were impressive, and the vendor decks promised production was a formality. Then, in organisation after organisation, very little happened.

The clearest measurement of how little comes from MIT Project NANDA’s 2025 study, The GenAI Divide: State of AI in Business 2025, whose most widely reported finding was that roughly 95% of enterprise generative AI pilots produced no measurable P&L impact. The figure travelled fast because it rang true. Executives did not need a research consortium to tell them their portfolios had gone quiet; the study confirmed everyone else’s looked the same.

It is worth being precise about what fail means here, because almost none of these projects ended in a public incident. Failure took three quieter forms. The first is no production impact: the pilot ran, but never changed a process, a cycle time or a cost line that anyone could point to. The second is quiet retirement: the pilot was wound down without announcement when the sponsor moved on or the renewal came due. The third is the indefinite pilot: still officially in evaluation many quarters after it started, kept alive because cancelling it would require an explanation. All three are failure. Only the third still has a budget line.

This article is about why. Not the comfortable explanation that blames immature technology, but the observable one: the same eight failure modes, recurring across sectors and vendor stacks, almost all institutional rather than technical. It closes with what the minority that reached production have in common.

02It is almost never the model

When a pilot stalls, the instinct is to question the technology. It is almost always misplaced: the capability was proven in the demo. The model did summarise the policy accurately. It did draft the letter, answer the product question, extract the clause. Whatever killed the project, it was not an inability to do the task, because the task was done in front of the audience that approved the funding.

What separates a demo from production is everything around the model. A demo needs a model, a curated slice of data and a screen. A production system needs live access to the systems that hold customer, financial or operational records; a named authority to approve that access; data whose meaning is consistent enough to act on; policy enforced on every interaction; an audit trail a regulator would accept; an owner who answers for the system’s behaviour; and unit economics that survive the whole workforce using it. Not one item on that list is a property of the model.

These are the unresolved questions, and they are institutional. Who approves a copilot reading the claims system? What evidence does risk need before an output can touch a customer? Which definition of revenue does the model use when three systems disagree? None of these has a technical answer, and in the failed 95%, nobody had assembled the organisational answers before the build began.

Waiting for the next model release is therefore the most common and least effective response to a stalled programme. An organisation that could not answer the institutional questions for last year’s model cannot answer them for this year’s either, and the pilot built on the new model will stall in the same place at higher cost.

03The eight failure modes

Talk to enough teams that have been through the cycle and the stories converge on eight failure modes. They are not mutually exclusive; most stalled programmes exhibit at least three. Each one, on its own, is sufficient to keep a working pilot out of production.

1. Built on a curated extract

The pilot ran on a hand-picked dataset: cleaned, deduplicated and labelled by the team that built the demo. The results were excellent, because the hardest problem had been quietly solved by hand before the model saw the data. Production means reading the real estate, live, with its duplicates, conflicts and gaps intact, and nobody scoped that work because the extract concealed its existence. When the gap surfaces, the honest estimate for making live data consumable dwarfs the original budget. The sponsor is being asked to fund the project twice, and most decline.

2. The data’s meaning is inconsistent across systems

The same customer exists under five identifiers. Revenue is defined three different ways in three systems. Every acquisition brought a schema with its own conventions, and nobody reconciled them. A model consuming this estate produces confident answers that contradict the numbers finance publishes, and the first time an executive catches the contradiction, trust in the system dies. It rarely recovers. The model was not hallucinating; it faithfully reflected an estate that disagrees with itself, and until that disagreement is resolved somewhere, every AI system built on the estate inherits it.

3. Governance arrives after the build, and kills it

The build ran ahead of approval, on the theory that a working system is easier to defend than a proposal. Then privacy, security and legal arrived, months in, with the elementary questions: what data does it see, where do outputs go, who approved this access? The team could not answer from the architecture, because the architecture was never designed to answer. Retrofitting governance onto a finished system costs more than the build did, and reviewers know it. The project dies in review, and the reviewers are blamed, when the actual failure was inviting them last.

4. No evidence for risk to sign off

Risk functions do not sign off on assurances; they sign off on evidence. The pilot produced a slide reporting that accuracy was strong and users were happy. Risk needed a record: which sources contributed to an output, under whose authority the data was accessed, how sensitive fields were controlled, what happens when the system is wrong. The pilot’s architecture could not produce that record, because nobody designed for it, so the sign-off never arrives and the pilot idles indefinitely. An indefinite pilot is a failure with better optics.

5. Pilot economics that do not survive scale

The pilot served a small group of enthusiasts on subsidised credits, and nobody watched the meter. Production means the whole workforce, every working hour, with context windows stuffed full of retrieved documents and every query routed to a premium model. Costs invisible at pilot size become a line item finance questions at scale, and the value side of the ledger, never measured during the pilot, has no answer ready. Worse, each new use case rebuilt its own retrieval, connectors and plumbing, so the costs compound instead of amortising.

6. A wrapper, not a workflow

The pilot shipped as a chat window beside the work rather than inside it. The assistant answers questions about claims, but the decision still happens in another system, and the handler copies between the two. Usage spikes in week one, sags by month two and settles at the handful of people who like new tools. There is no measurable impact because the decision the AI was meant to improve never touched it. Integration into the moment where the decision happens is the difference between a tool and a demonstration.

7. An ownership vacuum between IT, data and the business

IT considers it a data problem. The data team considers the use case the business’s to own. The business considers anything running on servers to be IT’s. The pilot survived the vacuum inside an innovation team with its own budget, but innovation teams rotate and dissolve, and production systems need owners for years, not quarters. When the pilot team moves on, nobody answers for the model’s behaviour, its access rights or the process changes it requires, and unowned systems get switched off. If no one can name the production owner today, the retirement date is already set.

8. Model-first procurement that hard-wires a vendor before the data is ready

Procurement began with the model: a vendor chosen, an enterprise agreement signed, consumption commitments made, then a search for use cases worthy of the spend. This is backwards. The binding constraint was never model capability but the readiness of the data underneath, and the agreement hard-wired a vendor before anyone knew what that data could support. Every use case must now justify the committed platform rather than the reverse, and when the estate work starts, the contracted model may be the wrong shape or price for what emerges. Model-agnosticism would have preserved the options; model-first procurement spent them in advance.

Notice what is absent from the list: model quality, prompt design, context length, the things programme reviews discuss. The failure modes live in access, meaning, governance, evidence, economics, integration, ownership and sequencing. That is not an accident of this analysis. It is the finding.

04The pattern underneath

Read the eight again and strike out the surface details. A curated extract and inconsistent meaning are data foundation problems. Late governance, missing evidence, per-project plumbing, the ownership vacuum: each is a different symptom of the same condition. Nearly every failure mode reduces to a single root: AI consuming fragmented, ungoverned data with no coordinating layer between the estate and the tools.

Because that layer is missing, every project must fight the same institutional battles alone. Each pilot separately negotiates access, discovers that the estate disagrees with itself, improvises answers for risk, builds its own plumbing and hunts for an owner. The organisation runs a dozen expeditions and builds no road; the tenth pilot starts as far from production as the first. The 95% is not a verdict on the technology. It is the arithmetic of expeditions.

05What the successful minority do differently

The minority of projects that reached production were not run by smarter teams, and they did not have better models. The differences are in sequence and posture, and they are consistent enough to list.

Foundation before use cases

Successful programmes treat the data foundation as the first deliverable, not a discovery made in month six. Before a use case is promised, the meaning of the relevant data is resolved across systems, access rules are encoded, and the path from source to output is one that risk can inspect. The foundation is scoped to the data the first workflows need, not the estate in its entirety. This is slower to the first demo and dramatically faster to the first production system; the second inherits everything the first established.

One bounded, visible first workflow

The failed pattern is a dozen simultaneous pilots, each shallow. The successful pattern is one workflow with bounded scope, a named owner and value an executive can see without a briefing note: a reconciliation, a triage queue, a reporting pack. Bounded scope keeps the governance surface small enough to clear properly. Visibility means that when it works, the organisation notices, and the next use case arrives with sponsorship rather than scepticism.

Risk and compliance in the room from week one

This inverts failure mode three. Risk, privacy and security shape the controls at design time, when accommodating them costs little, instead of auditing a finished system they had no hand in. The function that most often ends AI projects becomes a co-author of this one, and the sign-off that stalls other pilots indefinitely is largely pre-agreed before the build finishes.

Infrastructure over programme

Stalled organisations staff a programme per project, and every programme refights the same battles. Successful ones build or buy the shared layer once, as infrastructure. This is the case for an enterprise AI control plane: infrastructure that connects directly to the systems of record, materialises a governed, unified semantic layer, resolved once and stored, then enforces policy on each interaction and produces audit evidence continuously. Once that layer exists, a use case is configuration on top of infrastructure rather than an expedition.

Measure production impact, not demo applause

The successful minority define success as a measurable change in how the business operates: a cycle time, an error rate, a cost line, a decision made faster or better. Usage counts and user delight are explicitly not the metric. The discipline sounds obvious and is rare, because impact measurement forces the integration work of failure mode six. A programme that must show production impact builds into the workflow from the start, because there is nowhere else the impact can come from.

06A pre-mortem checklist

Before funding the next generative AI initiative, run the pre-mortem: assume it is a year from now and the project has quietly stalled, then ask which of these questions went unanswered. Each maps to a failure mode above, and each is cheaper to answer before the build.

• What live systems must this read in production, and who approves that access? If the approver is a hope rather than a name, the demo-production gap is already open.
• Do our systems agree on what this data means? If the same customer or metric is defined differently across systems, the disagreement will surface in the model’s answers.
• What evidence will risk need to sign off, and does the architecture produce it by default? Evidence assembled by hand afterwards is failure mode four on a delay.
• Who owns this when the pilot team moves on? A name and a budget line, not a committee.
• Where in the workflow does the output land? If the answer is a separate window, it is a wrapper, and adoption will decay with the novelty.
• What does each interaction cost at production volume, and who has modelled it? The meter nobody watched during the pilot becomes the argument that ends it.
• What does the second use case inherit from the first? If the answer is nothing, you are funding expeditions, not building capability.

A programme that can answer all seven is not guaranteed to succeed. One that cannot answer several is close to guaranteed to join the 95%, and the pre-mortem has said so while the funding decision is still open.

07Agents raise the cost of failure

Everything above treats failure as expensive but contained: budget spent, credibility dented, nothing broken. That containment is a property of chat. An assistant that answers questions can only be wrong in front of a person, who can question it and decline to act. Agentic AI removes that buffer. An agent reconciles the accounts, adjusts the record, sends the notice. It acts.

Autonomous action against inconsistent, ungoverned data multiplies every failure mode in this analysis. The curated extract becomes an agent acting confidently on live data it misreads. Inconsistent meaning becomes an agent reconciling figures that were never the same figure. The missing audit trail becomes a regulator asking how an automated action was authorised, with no record to answer from. And scale, the property that makes agents attractive, removes the containment: a stalled chat pilot wasted budget, but a failed agent acts wrongly at scale, repeating its mistake at machine speed until something outside it notices.

Risk functions understand this, which is why the evidentiary bar for agents is rising, and why no serious risk officer will sign off on autonomous action against data whose meaning, access rules and audit trail are undefined. Organisations that built the foundation can put agents on it and answer the hard questions. Those that did not will watch their agent ambitions stall exactly where their chat pilots did, with far more at stake in the attempt.

08If your pilots have stalled

A stalled portfolio is not a reason to stop; it is a map of what the organisation has not yet built. The recovery sequence is short, and none of it involves procuring a better model.

First, audit the stalled portfolio honestly. Classify every pilot into three groups: retire (no owner, no path), park (real value, blocked on the foundation) and rebuild (bounded scope, real value, a workflow that matters). The audit is uncomfortable, because it converts indefinite pilots into acknowledged failures. It is still cheaper than carrying them, and the parked group becomes the pipeline that funds what follows.

Second, pick one. From the rebuild group, choose the use case with the most bounded scope and the most visible value, and a workflow owner willing to put their name on it. Resist the instinct to restart several at once; the point of the first is to build the road, not to maximise coverage.

Third, build the governed path for that one use case. Connect the live systems it needs, and resolve the meaning of the data it touches so its answers agree with the numbers the organisation already trusts. Encode access from your existing identity model, and let audit evidence accrue by default from the first query. This is the working core of data governance for AI, applied to one workflow instead of the whole estate, which is what makes it achievable inside a funding cycle.

Fourth, let every later use case inherit that foundation. The second project should begin where the first finished: same semantic layer, same policy machinery, same evidence pipeline, a new workflow on top. Each use case makes the next cheaper, governance strengthens with use, and the portfolio stops being a collection of expeditions and becomes a capability.

The failure rate, in the end, is not a verdict on generative AI. It is a verdict on sequence: models procured before data was understood, builds finished before governance began, pilots funded before anyone named an owner. The stalled majority and the production minority used the same models. The difference was everything underneath them.

09Frequently asked questions

10Sources and further reading

• MIT Project NANDA, The GenAI Divide: State of AI in Business 2025, the study behind the widely reported finding that roughly 95% of enterprise generative AI pilots showed no measurable P&L impact.
• European Union, Regulation (EU) 2024/1689 (the EU Artificial Intelligence Act), the clearest statement of the direction on evidence obligations for AI systems.
• US National Institute of Standards and Technology, AI Risk Management Framework.
• DataReadyAI, Enterprise AI Control Plane: Definition, Architecture and Buyer’s Guide.
• DataReadyAI, Data Governance for AI.