A CTO forwards you the same slide everyone has seen: 85% of enterprise AI projects fail. The number is real, the reaction is usually wrong. Teams read it as a reason to be cautious about which model they pick, when the model is almost never where the failure starts. The failures that actually sink enterprise AI projects happen before a single line of training code runs, or in the long gap between a working demo and a system anyone trusts in production. They are organisational and structural failures wearing technical clothes. And almost every one of them is attributable — someone approved a scope without auditing the data, someone defined success as “deploy AI” rather than as a measurable business outcome, someone sponsored an experiment and called it a project. This is worth being precise about, because the headline failure rate gets quoted as if it were a law of nature. It is not. It is the aggregate result of repeated, nameable decisions. Where the 85–95% Failure Numbers Actually Come From The most-cited figures are not one study. Gartner has repeatedly estimated that a large majority of AI projects never reach production or never deliver intended value (published-survey; Gartner analyst estimates, varying by year and definition). The MIT figure that circulated through 2025 — the headline that something like 95% of enterprise generative AI pilots showed no measurable P&L impact — comes from MIT’s GenAI Divide report (published-survey; MIT, 2025), and it is narrower than the way it gets repeated. Read carefully, the MIT report concludes something more useful than “AI doesn’t work.” It found that the divide is between organisations that embedded AI into a specific workflow with owned outcomes and those that ran pilots disconnected from any process they were willing to change. The failure was rarely the model’s capability. It was the absence of a workflow the model was allowed to alter and a metric someone was accountable for moving. So what is the right number for a serious team to internalise? None of the headline percentages, used as a target. The honest framing is directional: most enterprise AI initiatives that begin without a data audit, a feasibility check, and a measurable milestone fail to reach durable production — a directional industry pattern, not an operational benchmark for any one organisation. The point of the number is not to predict your fate. It is to make you ask which of the root causes below your project has already walked into. The Four Root Causes That Are Rarely Named When we trace stalled enterprise AI projects back to their origin, the same four causes recur. None of them is “we chose the wrong architecture.” (Observed across our consulting engagements; the pattern is consistent, the proportions are not a benchmarked rate.) Data-Quality Blindness The project starts with a model, not with a data audit. A team selects an approach, sometimes even a vendor, before anyone has established whether the data that the model will depend on is complete, labelled, current, and legally usable. The model then surfaces the data problem — late, expensively, and after commitments have been made. The fix is sequencing: a data audit precedes model selection, not the other way around. Infeasible Scope The project is scoped to require capabilities the current state of AI does not reliably deliver. This is not pessimism; it is the difference between an engineering task and a research bet. A request to “automatically resolve any customer issue end to end” is a research question dressed as a deliverable. Distinguishing the two early is a discipline in itself — we wrote about how to tell whether an AI problem is an engineering task or a research question precisely because so many projects commit to a timeline that only an engineering task could honour. No Success Criteria There are no measurable milestones, so failure is discovered retroactively. If success is defined as “deploy AI,” the project can run for a year, deploy something, and still have failed on every metric that mattered — except no one wrote those metrics down, so the failure is arguable rather than visible. A project without a number it is trying to move cannot tell you it is in trouble until the budget is gone. Organisational Misalignment The AI initiative is treated as an IT project rather than as a business-risk decision. It gets a technical sponsor instead of an accountable business owner, it is measured on delivery rather than outcome, and the part of the organisation whose workflow would have to change is never asked to change it. The MIT divide is largely this cause in aggregate. The Failure Cause Table A compact map of the four root causes, who is accountable, and the prevention that removes each one. Root cause Where it originates Looks technical, is actually Prevention Data-quality blindness Model chosen before data examined Organisational sequencing Data audit before model selection Infeasible scope Capability assumed, not assessed Scoping/feasibility Feasibility assessment before commitment No success criteria “Deploy AI” treated as the goal Project management Measurable milestone at every phase Organisational misalignment AI run as IT, not business risk Sponsorship Accountable business owner + a metric they own The common thread: each cause is a decision someone made, not an accident that befell the team. That is the uncomfortable part, and also the hopeful one — decisions can be made differently. Why Do Enterprise AI Projects Survive POC but Die Between POC and Production? This is the failure pattern that surprises teams most, because the proof of concept worked. A POC is allowed to assume clean inputs, generous latency, a forgiving evaluation set, and a human in the loop. Production tolerates none of those by default. The handoff gaps that most often kill a surviving POC are mundane and predictable: no monitoring for input distribution shift, no defined owner for model behaviour after deployment, no rollback path, no agreement on what acceptable accuracy means under real traffic, and data pipelines that existed as a notebook rather than as a maintained service. A POC proves that the idea can work under favourable conditions. Production demands that it keeps working under unfavourable ones. The two are different engineering problems, and conflating them is why so many demos never become systems. We treat the POC-to-production boundary as a first-class risk — it is the subject of what an AI proof of concept should actually prove before an organisation commits real budget to scaling it. How This Differs From GenAI-Specific Failure General enterprise AI failure and generative-AI failure overlap but are not the same. The four root causes above apply to a defect-detection vision system as much as to a chatbot. Generative AI adds its own failure modes — hallucination under load, prompt brittleness, evaluation that resists automation, cost that scales with usage in ways classical models do not. Those are covered separately in why generative AI projects fail and the GenAI-specific failure patterns. If your project is generative, read both: the organisational causes here will sink you first, and the GenAI-specific ones will sink you second. What a Sober AI Project Looks Like An organisation that has watched its peers fail does a few things differently, and none of them is exotic. It audits the data before choosing the model. It runs a feasibility assessment that is honest about which parts of the request are engineering and which are research, and it scopes only the engineering. It assigns an accountable business owner, not a technical sponsor, and gives that owner a metric. It defines measurable milestones at every phase, with explicit pivot points where the project is allowed to change direction or stop without anyone losing face. And it sets expectations about failure at the start, in writing — which is the quiet structural advantage almost no one talks about. That last point matters more than it sounds. A buyer who has documented the expected risk, the pivot points, and the success criteria at engagement start can defend the project to the board regardless of the technical outcome, because the decision was made well even if the result was uncertain. Honesty about failure rates, set up front, is not a liability. It is what makes the project defensible. Establishing readiness on these terms is the work of assessing enterprise AI readiness before starting a project, and it is where our R&D engagements with outcome ownership tend to begin. FAQ Why do most enterprise AI projects fail, and which root causes are not the ones publicly discussed? Most enterprise AI projects fail on organisational and structural causes, not on model choice: data-quality blindness, infeasible scope, absent success criteria, and treating an AI initiative as an IT project rather than a business-risk decision. The publicly discussed cause is usually “the technology wasn’t ready,” but each real failure is attributable to a decision — someone approved a scope without a data audit, or defined success as “deploy AI” rather than a measurable outcome. Where do MIT and Gartner’s reported failure rates (85–95%) actually come from, and what is the right number for a serious team to internalise? The figures come from separate published estimates — Gartner analyst estimates across multiple years and MIT’s 2025 GenAI Divide report — and they use different definitions of “failure.” No headline percentage is a useful target. The right thing to internalise is directional: projects that begin without a data audit, a feasibility check, and a measurable milestone tend not to reach durable production, so the number’s job is to prompt those checks, not to predict your fate. Which failures are organisational versus technical? The four dominant root causes — data sequencing, scope feasibility, success criteria, and sponsorship — are organisational, even though they surface as technical problems. Genuinely technical failures (architecture, infrastructure) exist but are rarely the origin; they tend to be the late symptom of an earlier organisational decision. Why do enterprise AI projects survive POC but die between POC and production? A POC is allowed favourable conditions — clean inputs, generous latency, a human in the loop — that production removes. The gaps that kill a surviving POC are usually monitoring for distribution shift, an owner for post-deployment behaviour, a rollback path, an agreed accuracy threshold under real traffic, and data pipelines maintained as services rather than notebooks. A POC proves the idea can work; production demands it keeps working. What does a sober AI project look like in an organisation that has watched its peers fail? It audits data before selecting a model, runs an honest feasibility assessment and scopes only the engineering, assigns an accountable business owner with a metric, sets measurable milestones with explicit pivot points, and documents expected risk in writing at the start. The documentation is the quiet advantage: it lets the buyer defend the project to the board regardless of outcome, because the decision was made well. How is general enterprise AI failure different from the GenAI-specific failure patterns? The four organisational root causes apply to any AI project, generative or not. Generative AI adds failure modes of its own — hallucination under load, prompt brittleness, evaluation that resists automation, and usage-scaling cost — which are covered separately. Generative projects face the organisational causes first and the GenAI-specific ones second. What does the 2025 MIT GenAI Divide report actually conclude about enterprise AI ROI, and how should a serious team read its headline failure figure? The report’s substantive finding is that the divide runs between organisations that embedded AI into a specific, owned workflow and those that ran disconnected pilots — not between good and bad models. The headline figure about pilots showing no measurable P&L impact should be read as a verdict on workflow integration and accountability, not on model capability. A serious team reads it as a mandate to tie any AI effort to a workflow it is willing to change and a metric someone owns. When an AI project survives only as a POC, what concrete handoff or production-readiness gaps most often kill it before it reaches production? The recurring gaps are no monitoring for input distribution shift, no defined owner for model behaviour after deployment, no rollback path, no agreement on acceptable accuracy under real traffic, and data pipelines that exist as notebooks rather than maintained services. Each is a production concern a POC is permitted to ignore, which is exactly why the demo passing does not predict the system surviving. The four root causes are not a checklist you pass once; they are decisions that recur at every phase, and the project fails the first time one of them is left unattended. An AI Project Risk Assessment names these risks upfront, defines the pivot points where the project is allowed to change course, and produces a defensible decision document — so that when the next slide quotes the failure rate, your project is the exception you can explain rather than the statistic you became.
