The statistics on AI project failure are striking. Depending on which research you read, somewhere between 70% and 85% of enterprise AI initiatives fail to reach production or fail to deliver their intended value once deployed. After years of working in transformation and operational excellence — and having recently completed formal training in data and AI engineering at Aalto University — I have a clearer view than ever of why this happens. And it is rarely what the post-mortems say.
The technical teams usually did their job. The model was built. The data was processed. The algorithm performed reasonably well in testing. The failure happened elsewhere — in the decisions made before anyone wrote a line of code, and in the gap between deployment and adoption that nobody planned for.
The Three Failure Patterns That Matter Most
The CRISP-DM framework — the most widely used structured approach for data science and AI projects — identifies the most common causes of failure with uncomfortable precision.
Management misunderstands the problem. The initiative starts with a business objective that is vague, shifting, or misaligned with what the data can actually answer. An executive sponsors an AI project to “improve customer satisfaction.” Nobody agrees on what that means, how it will be measured, or what decisions the model’s output will drive. Six months later, the team has built something technically functional that answers a question nobody asked. This is not a data science failure. It is a requirements failure — the kind of failure that change managers and business analysts are specifically trained to prevent.
The wrong data, or no data at all. Organisations frequently discover mid-project that the data they assumed existed does not, the data that does exist is too inconsistent to use, or there is no established process for collecting what the model actually needs. This is often framed as a data engineering problem. But underneath it is an organisational problem: nobody owns the data, nobody has defined what “good quality” means for this domain, and nobody has a process for maintaining it. Those are governance and process design questions — not infrastructure questions.
Technology applied to problems too complex for AI. Some initiatives fail because the chosen approach — a machine learning model, an AI agent, a predictive algorithm — is simply the wrong tool for the problem being solved. The expectation that AI will resolve an ambiguous human judgement call, or automate a process that depends on context no model can capture, sets the initiative up to disappoint. A change manager asking the right questions at the business case stage — “what decisions will this model make, and what happens when it gets them wrong?” — can catch this before the budget is committed.
The Cases Nobody Talks About in the Business Case
Two high-profile AI failures illustrate what happens when governance and change management are skipped entirely.
Amazon deployed a hiring algorithm trained on a decade of CVs submitted by successful hires. The model learned to replicate historical hiring patterns — including historical gender bias. Women’s CVs were systematically scored lower because the training data reflected an industry that had historically hired fewer women. The model was eventually discontinued, but not before it had been used in real hiring decisions. This was not a technical failure. The algorithm did exactly what it was trained to do. The failure was in how the initiative was designed, who reviewed it, and what safeguards were put in place before deployment.
A widely cited healthcare study found that an algorithm used across US hospitals to allocate care management resources was systematically underprioritising Black patients — not because race was a variable in the model, but because the proxy variable used (historical healthcare expenditure) encoded existing inequalities. The algorithm predicted who would need care based on who had historically received care, which was not the same group. Again: technically functional, organisationally harmful, and entirely predictable if the right questions had been asked before deployment.
Both cases share a common thread. They were designed, built, and deployed without adequate stakeholder diversity, without governance checkpoints, and without a structured process for asking “who could be harmed by a flawed output from this model?” That is a change management gap, not an engineering gap.
What Change Managers Need to Do Before the Build Starts
The CRISP-DM framework makes a business understanding phase mandatory before any data work begins. In practice, this phase is where change managers should be most active — because the questions it requires are exactly the questions that change and transformation disciplines are built to answer.
What problem are we actually solving, and for whom? Who are the stakeholders with a legitimate interest in the outcome? What does success look like, and how will we measure it in a way that everyone agrees on? What happens to people whose work changes because of this initiative? What happens if the model produces a wrong output? Who will own this after go-live?
These are not technical questions. They are organisational questions, and they determine whether the technical work that follows will land or fail.
The Agentic AI Problem Is Already Here
One emerging pattern deserves particular attention: the deployment of AI agents — systems that do not just provide recommendations but take actions autonomously. Booking systems, procurement workflows, support ticket routing, customer-facing interactions. Organisations are deploying these at speed, often without designing the governance structures they require.
The risk is what some researchers call “sleepwalking into agentic AI.” The system runs. Decisions are made. Actions are taken. And nobody has defined where the human in the loop is, what happens when the agent encounters an edge case, or who is responsible when something goes wrong. Unlike a flawed report that a human still interprets before acting, an autonomous agent does not wait for review.
This is not a problem for IT to solve alone. Defining the oversight structure, designing the escalation path, training the people who need to intervene, and building the governance process around an AI agent is exactly the kind of work that change and transformation managers do in every other operational context. The tools are new. The discipline required is not.
The Through Line
AI and ML projects fail because organisations treat them as technology projects and manage them accordingly. The people, process, and governance work gets either skipped or left until after deployment — by which point it is too late to prevent the most common failure modes.
Change managers who understand CRISP-DM, who know what questions to ask at the business understanding phase, and who can design governance frameworks for AI deployment are not peripheral to these initiatives. They are the difference between an AI project that gets launched and one that actually works.
The technology is not the bottleneck. It never was.