When your AI pilot stalls, the conversation usually goes the same way. Someone says the data wasn’t ready. The team nods. Leadership accepts it. The pilot gets shelved — or more likely it enters a kind of organisational limbo where it isn’t quite dead but it isn’t going anywhere either.
The statistics on enterprise AI failure are consistent. McKinsey finds only 6% of organisations qualify as AI high performers, despite 88% having adopted AI in at least one function. BCG found 74% of companies have yet to show any tangible value from their AI efforts. The headline failure statistics tell a consistent story: bad data doesn’t explain those numbers.
BCG’s research found that only 20% of AI success hinges on data and technology combined. The other 70% comes down to people, processes, and organisational design. Most teams are focused on the 10–20% of the problem that looks familiar — the model, the architecture, the pipeline — while the real 70% goes completely unaddressed.
This article unpacks why the “bad data” narrative is really pointing to an organisational problem most companies haven’t yet named.
Why Is “Bad Data” a Symptom and Not the Root Cause of AI Failure?
Gartner cites poor data quality as a factor in 85% of AI project failures. That statistic is real. The causal story built around it usually isn’t.
Data problems in most failed pilots trace back to leadership decisions that were avoided. Cleansing data pipelines was never funded. Permissions fragmentation was never resolved. Data governance was never properly resourced. Bain’s research found pilots often succeed precisely because they’re built on offline, non-production datasets that someone manually cleaned. When you try to scale across the enterprise, those underlying data issues resurface — because nobody made the call to fix them.
Daniel Clydesdale-Cotter at RT Insights put it plainly: “When AI stalls, the blame lands on regulation, the models, or ‘our data isn’t ready.’ Safe targets, all of them. Nobody gets fired for bad data. But these explanations let everyone off the hook for the actual problem.”
IDC explicitly framed it as a question of “organisational readiness in terms of data, processes and IT infrastructure” — not data quality per se. Organisational readiness is a different order of problem from data quality. It requires leadership commitments, not engineering solutions.
When someone says “our data wasn’t ready,” what they’re usually describing is a series of avoided leadership decisions.
What Is the BCG 10-20-70 Principle and Why Does It Reframe Everything?
BCG’s 10-20-70 Principle comes from their “Widening AI Value Gap” research (Build for the Future, 2025). The finding: optimal AI investment weighting is 10% on algorithms, 20% on data and technology infrastructure, and 70% on people, processes, and cultural transformation.
That’s counter-intuitive if you’re focused on technical execution. The part of the problem that looks most familiar accounts for less than a third of what actually determines success.
Here’s a concrete example. A 150-person FinTech company invests 80% of its AI budget on model development and 20% on workflow integration. The model works. The adoption doesn’t. Customer support staff don’t trust the outputs. Managers haven’t changed their workflows to act on AI recommendations. Nobody was assigned to own the business result. The 70% was never funded. The pilot succeeds as a demo and then stalls.
AI future-built companies achieve five times the revenue increases and three times the cost reductions that everyone else gets from AI. Those future-built companies — the 5% generating transformative value — have learned to invest in the 70%. The 60% generating minimal value keep over-investing in the 10%.
The gap between future-built companies and AI pilot purgatory is widening because one side has figured this out and the other hasn’t. For the full statistical picture of how this pattern plays out across enterprises, the comprehensive AI pilot purgatory resource covers it.
What Is Outcome Ownership and Why Does Its Absence Keep Pilots in Purgatory?
Outcome ownership means a business leader — not a data scientist, not an AI engineer — is explicitly accountable for the business result of an AI initiative.
Most AI projects don’t have one. The structural gap is straightforward: a data scientist is assigned to the experiment, but no business leader is assigned to own the result. When the experiment ends, there’s no named owner to fund, defend, or operationalise the move to production. The project remains technically alive and organisationally orphaned.
RT Insights puts it plainly: “Getting to production means someone has to own the outcome.” When it stays in the hands of specialists, it stays in pilot purgatory.
The distinction matters in practice. If the success metric is “model accuracy of 92%”, the AI team owns that. If it’s “reduce contract review cycles from two weeks to two days”, that requires a business owner — someone whose performance depends on the outcome, not just the output.
Without that named owner, the organisational machinery for moving to production simply doesn’t exist. This is an organisational design question, not a personnel one — and it’s exactly what how to structure AI outcome ownership is about.
Why Do Leaders Approve AI Pilots They Know Are Underfunded?
IDC Group VP Ashish Nadkarni described the dynamic directly: “These POCs are highly underfunded or not funded at all. Most of the time the POC happens not because of a strong business case. It’s trickle-down economics to me.”
Approving an underfunded pilot is lower-risk than either refusing to participate in the AI wave or requesting a realistic budget that might get knocked back. The pilot becomes a hedge — visible AI activity without organisational commitment.
RT Insights calls this leadership avoidance. The decisions that would actually fix AI failure — funding data governance, restructuring workflows, assigning business ownership, committing to change management — are all politically difficult. It’s structurally easier to approve an underfunded pilot than to have those conversations.
The result: pilots succeed as demos and stall when the organisational transformation required for production is never funded. Until outcome ownership is structurally assigned, those incentives will keep producing purgatory.
AI Centre of Excellence vs. Distributed Ownership: Which Model Ships More AI?
There are two dominant approaches for organising AI in a mid-market company. A centralised AI Centre of Excellence (CoE) provides governance, tooling, and expertise across business units. Distributed ownership embeds AI capability directly into business units, with central platform support.
The CoE model has real advantages: centralised expertise, consistent governance, reduced duplication, easier compliance oversight. The failure mode is structural. Business units submit requests. The CoE builds and deploys. But because the business unit didn’t build it, they don’t own it. Outcome ownership never transfers. The CoE owns the system in production permanently, and accountability stays with the AI team rather than the business function.
The federated model, where business units own their AI outcomes with platform support from the centre, resolves this directly. The team lead accountable for the business function is also accountable for the AI system serving it.
For a 50–500 person company, the practical answer is a federated model: central platform infrastructure (MLOps, data governance, model registry) and distributed business outcome ownership. The condition that determines whether any model works is where outcome ownership lives. The CTO pilot triage framework for evaluating existing structures starts with exactly that question.
What Do the 6% of AI High Performers Do Differently on the Organisational Dimension?
McKinsey’s State of AI 2025: 88% of organisations report AI use in at least one business function, but only 39% report any impact on enterprise-level EBIT. The distinguishing factor between organisations that ship and those that don’t isn’t technology. It’s organisation.
Three traits consistently separate AI high performers from the rest. First: clear outcome ownership. A named business leader is accountable for the business result of every AI initiative. Second: cross-functional accountability. Engineering and business teams share ownership of the outcome metric throughout the pilot and into production. Third: funded change management. The 70% of BCG’s framework — workflow redesign, training, adoption management — is budgeted and staffed, not treated as an afterthought after deployment.
McKinsey found high performers are three times more likely to strongly agree that senior leaders demonstrate ownership of and commitment to their AI initiatives. That’s not about leadership cheerleading. It’s about structural accountability.
The difference between the 6% and the 94% is not about having better data scientists. The high performers have built organisational structures that allow technical capability to translate into production outcomes. The leverage point isn’t in the codebase. It’s in the governance model. And defining production readiness criteria before you start begins with organisational design, not model selection.
FAQ
What percentage of enterprise AI projects fail and why?
IDC/Lenovo’s CIO Playbook 2025 found 88% of AI POCs fail to reach widescale deployment. MIT research found 95% of enterprise generative AI pilots fail to deliver measurable financial returns. S&P Global found 42% of companies scrapped most of their AI initiatives in 2025. BCG’s 10-20-70 Principle identifies the root cause: 70% of AI success depends on people, process, and cultural transformation — the majority of failures are organisational, not technical.
What is the BCG 10-20-70 Principle in simple terms?
10% of AI success depends on the algorithm or model. 20% depends on data and technology. 70% depends on people, process, and cultural transformation. BCG identifies the inversion of this ratio — over-investing in the technical 30% while under-investing in the human 70% — as the primary reason 60% of companies are generating minimal value from AI investments despite substantial spend.
What does “organisational readiness for AI” actually mean?
IDC’s framing: “The high number of AI POCs but low conversion to production indicates the low level of organisational readiness in terms of data, processes and IT infrastructure.” Agility at Scale breaks it into three deltas — technical (infrastructure), governance (oversight and accountability), and operations (MLOps, monitoring, incident response). All three need to be in place before you can call something production-ready.
What is “pilot fatigue” and how do you recognise it?
Pilot fatigue sets in when an organisation has invested real resources in AI pilots that haven’t shipped. The symptoms: sponsors losing confidence, AI teams disengaging, a growing list of “completed” pilots with no production deployments, and growing budget resistance to new AI proposals. Beam AI’s analysis found 42% of enterprises deployed AI without seeing any ROI, with an additional 29% reporting only modest gains.
How is the AI Centre of Excellence model different from distributed AI ownership?
In a CoE model, a central AI or data science team governs and delivers all AI use cases across business units. The failure mode: outcome ownership stays with the AI team, not the business function.
In a distributed model, business units own their AI initiatives with central platform support. The advantage: outcome ownership is embedded in the business function accountable for the result. The risk is governance fragmentation if the central platform is too thin.
What does “outcome ownership” mean for an AI project?
A specific, named business leader is accountable for the business result — measured in business terms, not technical terms. “Reduce contract review cycles by 60%” is a business outcome. “Model accuracy of 92%” is a technical output. RT Insights defines it as assigning the business leader who carries accountability for production results, not just the technical team building the system.
Why do organisations blame data problems for AI failure even when the real cause is organisational?
“Bad data” is a socially safe explanation. It’s technical, impersonal, and implies a fixable problem rather than a leadership or governance failure. Bain’s research reinforces this: data problems persist not because data engineering is impossible but because “ownership is often unclear, defaulting to system administrators or data platform teams; without business-aligned ownership, governance lacks direction.”
What is the difference between an AI proof of concept and production deployment?
A proof of concept is a time-boxed experiment in a controlled environment — typically on clean or synthetic data — designed to validate technical feasibility. A production deployment operates at scale with real users, real data, and real business consequences. Agility at Scale frames the distance between them as three deltas — technical, governance, and operations — that a pilot rarely addresses.
How does executive sponsorship affect AI project outcomes?
McKinsey found AI high performers are three times more likely than peers to have senior leaders who demonstrate ownership of and commitment to their AI initiatives. Board-level pressure to “do AI” is not the same as genuine executive sponsorship. Pressure without follow-through — funding change management, restructuring workflows, assigning outcome ownership — produces underfunded pilots that are structurally set up to stall.
Why does only 6% of organisations qualify as AI high performers despite 88% adoption?
Widespread adoption doesn’t produce widespread scaling. Most organisations are still in experimentation or piloting phases and haven’t built the structures to scale. The three structural differentiators: redesigned workflows, committed leadership with demonstrated ownership, and funded investment across all the elements required for production — not just the technical ones.
What should you do first if AI projects keep stalling in purgatory?
RT Insights recommends starting with measurable business outcomes — “reduce customer service response time by 40 percent” rather than “implement AI.” If you can’t articulate the cost of the non-AI alternative, the problem hasn’t been defined clearly enough. Then run the 10-20-70 audit: estimate your actual allocation across algorithms, data and technology, and people and process. Where the split is inverted, start by reallocating — not by improving the technology.
For a comprehensive overview of why enterprise AI projects fail — covering the full scope of failure statistics, root causes, and the CTO decision framework — see the complete guide to the enterprise AI pilot purgatory problem.
