Change management in the age of AI: 5 mistakes to avoid

In almost every AI transformation that fails, the technology worked. The model produced what it was meant to produce, the interface was usable, the infrastructure held. What failed was adoption. And adoption never fails by accident: it fails along remarkably repeatable patterns, which can be named and, for the most part, avoided.

The first mistake is announcing AI before answering the question everyone is actually asking. That question is not "how does it work?" nor "what are the expected gains?". It is: "what does this mean for my job?". Until it is answered, every corporate message about performance and competitiveness is heard as a euphemism. People are not resisting the tool; they are resisting uncertainty about their own future. Organisations that address this head-on — saying what will change, what will not, and what has not yet been decided — earn a level of buy-in that no amount of abstract enthusiasm can match.

The second mistake is confusing training with support. A two-hour session on operating a conversational assistant has never changed a professional practice. What changes it is going back to real work: picking up a live case with the tool, seeing where it helps and where it gets things wrong, adjusting how you prompt it. Skill transfer happens in the work itself, not in the training room. Organisations that budget for initial training but nothing for the following six weeks have funded an expense, not a transformation.

The third mistake concerns the choice of first users. The reflex is to hand the pilot to the most enthusiastic teams, usually the most comfortable with technology. It is comfortable and it produces good usage figures. It is also misleading: those teams would have adopted the tool unaided, and their success proves nothing about the rest of the organisation. The useful pilot is the one that deliberately includes sceptical or less confident users, because their obstacles are what will determine whether the rollout scales. A pilot that surfaces no difficulty has taught you nothing.

The fourth mistake is silence about failure. When a use case does not deliver, the temptation is to close it quietly and communicate about the next one. But inside an organisation, nothing travels faster than a project that disappeared without explanation. By the third silent shutdown, nobody believes the announcements any more. Transformations that last are the ones that document what they stopped as carefully as what they achieved: here is what we tried, here is why it did not work, here is what we learned. That transparency costs little and buys credibility nothing else provides.

The fifth mistake, and the most structural, is leaving the transformation without an owner. AI often arrives through the technology function, with a sponsor in the executive team and users in the business. Between the three, nobody formally owns adoption. The outcome is predictable: IT considers it delivered, the executive team waits for results, the business waits to be told what to do. And the project stalls without anyone being accountable for it.

Here is a composite scenario, rebuilt from several engagements rather than drawn from one. A services group rolls out a writing assistant to several hundred employees. After three months the indicators look good: high login rates, positive satisfaction survey results. But a closer look at usage tells a different story. A minority of users account for most of the queries; the majority open the tool once a week, produce a short piece of text and return to their habits. Nobody lied in the survey: employees genuinely find the tool pleasant. It has simply not entered anyone's actual workflow. The fix is not technological but a matter of work design: identify three specific moments in the working day where the assistant replaces an existing task, and support those three moments.

That dimension shapes how we work at KAIROS Impulse. An AI transformation is not a tool rollout with a communications plan attached: it is a redefinition of how work is organised. So we rarely start with the tool. We start by mapping the professional gestures involved, identifying who loses something in the change — because someone always does — and sequencing accordingly. The question of timing returns insistently here: launching a change programme during a reorganisation, a peak workload period or just after redundancies means stacking two movements that cancel each other out.

The common objection is that this work slows the rollout. True in the short term, false thereafter. A tool deployed fast but used by fifteen per cent of its intended audience costs more than a slower rollout reaching sixty per cent, because the licence is paid for everyone and a second attempt with an already disappointed population is far harder than the first. Abandoned transformations are not easily restarted.

Finally, a word on measurement. Login rate is the most available indicator and the least informative. What matters is frequency of use on the targeted tasks, the share of users still active beyond the first month, and above all the time genuinely freed up — verified with the teams, not estimated in a spreadsheet. A transformation that cannot answer "what are people doing differently today?" has not yet begun.