Why AI Projects Fail at Change Management, Not Technology

The model worked. Nobody used it.

A few years into my digital transformation work, I watched a perfectly functional recommendation engine get quietly switched off six months after launch. The algorithm was solid. The integration was clean. But the team whose job it was supposed to improve had never been involved in defining the problem, had received thirty minutes of training delivered via a PDF, and had a manager who privately believed the tool was there to replace them. Adoption was effectively zero.

That experience shaped how I think about AI projects more than any technical challenge has. The failure mode was not the technology. It was everything around the technology: governance, communication, change management, and the basic human question of why should I trust this?

Now that I am building CVChatly and advising on AI product strategy, I see the same pattern repeating at speed. Teams ship an LLM-powered feature, declare it done, and then wonder why usage numbers are flat. The answer is almost always the same: the project treated the model as the product, when the model is just one component of a much harder organisational change.

What change management actually means in an AI context

Change management gets dismissed as corporate soft skills. In practice it is the discipline of making sure that a new system, process, or tool actually gets used as intended, by real people, under real working conditions. In classical IT projects — SAP rollouts, ERP migrations, large-scale digital transformations — it typically accounts for fifteen to twenty percent of the total programme budget, and experienced programme managers treat it as a delivery risk, not a nice-to-have.

AI projects compress timelines dramatically. An MVP that would have taken eighteen months in 2018 now takes four. But the human side of adoption does not compress at the same rate. People still need to understand what the system does, why it makes the decisions it makes, and what happens when it is wrong. If anything, AI raises the stakes on these questions because the outputs are probabilistic, occasionally surprising, and harder to audit than a traditional rule-based system.

There are three specific failure points I see most often:

• Scope agreed with the wrong people. The business sponsor signs off, but the people who will actually use the tool were never consulted. You build something technically correct that solves the wrong version of the problem.
• No governance for model outputs. Who decides when an AI recommendation is wrong? Who has authority to override it? Who is accountable when it causes a bad outcome? If nobody has answered these questions before go-live, you will answer them in a crisis.
• Training treated as a checkbox. A single session, a how-to video, a Confluence page. Then silence. Effective adoption requires repeated exposure, real examples, and a feedback loop so users can report problems and see that someone is listening.

The governance layer most product teams skip

When I was running programmes at Puig across fifteen countries, governance was the infrastructure that kept everything moving: decision rights, escalation paths, change request processes, steering committees with actual authority. It was sometimes slow and occasionally frustrating. But it meant that when something went wrong — and something always went wrong — there was a clear process for resolving it without the whole programme grinding to a halt.

AI product teams, especially in startups, tend to skip this layer entirely. Move fast, ship, iterate. That works well for features with low stakes and easy reversibility. It works poorly for AI systems that are making consequential decisions — screening job candidates, flagging transactions, summarising medical notes, routing customer complaints.

For CVChatly, even at early stage, I have had to think carefully about governance questions that a typical product team might defer. Who reviews the CV analysis when a user disputes the output? What is the process for identifying and correcting systematic bias in recommendations? How do we handle a situation where an LLM agent produces a response that is factually wrong in a way that could affect someone's job search? These are not hypothetical edge cases. They are the questions your users will ask you within weeks of launch, and your answers need to exist before the questions arrive.

GDPR adds another layer. Under European data protection law, individuals have the right to meaningful information about automated decision-making that significantly affects them. That is not just a legal compliance checkbox. It is a governance requirement that forces you to document how your system works, what data it uses, and what a human review process looks like. Building that documentation after the fact is significantly harder than designing for it from the start.

What I do differently now

After two decades of seeing this pattern from both the consulting side and the founder side, I have settled on a few practices that I apply consistently.

First, I map the humans before I design the system. Before writing a line of code or drafting a prompt, I want to understand who will use the output, what their current workflow looks like, what they distrust about automation, and what would make them trust it. This is not user research as a formality. It is the information that determines whether the project succeeds.

Second, I define the override process on day one. Every AI-assisted decision in my systems has a documented path for a human to review, correct, or reject it. Not because I expect the model to be wrong most of the time, but because users need to know that path exists before they will trust the system enough to use it at all. Trust is built on the knowledge that errors are recoverable, not on the promise that errors will not happen.

Third, I treat the first ninety days after launch as a change management programme, not a maintenance period. That means scheduled check-ins with users, a clear channel for reporting problems, visible evidence that feedback is being acted on, and metrics that measure actual usage and task completion, not just sessions and page views. Vanity metrics hide adoption failures until it is too late to recover.

Fourth, I document governance decisions as I make them, not retrospectively. When I decide how CVChatly handles a contested AI output, I write it down at the time. This creates an audit trail, forces me to think the decision through properly, and means I am not reconstructing reasoning from memory when someone asks about it later.

The practical takeaway

If you are leading an AI project right now, ask yourself one question: if the model performs exactly as designed from day one, what would have to be true about your organisation for people to actually use it and trust it?

That question will surface your real risks faster than any technical review. The model is the easy part. The change is the hard part. AI does not change that equation — it just makes the cost of ignoring it higher, because the speed of deployment means you can be six months into a failed rollout before you realise what happened.

Build the governance layer. Do the change management work. Involve the people who will live with the system before you build it. These are not new lessons. They are the oldest lessons in enterprise technology, and they are more relevant now than they have ever been.