For twenty years, digital transformation had a quiet ally: time. An ERP took eighteen months to implement, a CRM six, a customer portal a year. While the technology dragged on, people got used to it. There were meetings, training sessions, pilots, beta versions. Adoption happened along the way, almost without anyone managing it.
AI has removed that ally. A team can have an assistant summarising emails, an agent triaging support requests or a model extracting data from invoices within a week — sometimes within an afternoon. What used to be the bottleneck (building) has become fast. What used to be invisible (people changing the way they work) has become the bottleneck.
That is why change management — the discipline that for decades was a chapter at the end of the project plan — has become the project itself. This article explains what changed, which forms of resistance are specific to AI, where projects usually die, and what works when you want the change to stick.
What changed: technology is no longer the critical path
In a classic technology project, the schedule was dominated by construction. Change management had months to happen in parallel and, by the time the system went live, people had heard about it twenty times.
With AI, the order has flipped. The model already exists, the integration takes days, and the organisation receives a new capability before it has had time to discuss what it means. The result is a ready-to-use tool in a company that has not yet decided who uses it, for what, within which limits and with what responsibility.
BCG sums this up in a rule worth pinning to the wall: only about 10% of the value of an AI transformation comes from the algorithm itself, another 20% comes from data and technology, and the remaining 70% comes from redesigning the work, culture, governance and human-AI collaboration. If 70% of the value sits with people and processes, then 70% of the effort has to sit there too — and it rarely does.
The three forms of resistance that are specific to AI
Resistance to change is nothing new. But AI brings three forms that did not exist with earlier technology, and that the classic methods were not expecting to meet.
Fear of replacement. When a company rolled out a CRM, nobody thought the CRM would take their job. With AI it is the first question everyone asks, even if they don't say it. And it is a legitimate question: the tool does part of the work the person used to do. A change plan that does not answer this honestly — what changes in each role, what stops being done, what starts being done — is asking for quiet sabotage.
Distrust of the output. Earlier systems were deterministic: if the number was wrong, it was a bug. Generative AI gets things wrong plausibly, confidently, and sometimes you don't notice. Anyone who has seen a model invent a reference or swap a value is right to be wary. The resistance here is not emotional, it is epistemic: "how do I know when this is right?" Without a practical answer — where the check happens, who does it, what happens when it fails — people either do the work twice or stop using the tool.
Loss of status. In many teams, a person's value lies in knowing the old process: the shortcuts in the system, where the exceptions live, being the only one who understands that spreadsheet. When AI absorbs part of that knowledge, that person loses influence. And it is often the very person the project depends on most.
None of these is solved by a training session on prompts.
The classic mistake: the pilot that worked and nobody uses
The pattern repeats in companies of every size. A small team builds a pilot — an assistant, an automation, an agent. Technically it works: the demo goes well, management is enthusiastic, the roll-out to the rest of the organisation is approved.
Six months later, usage is marginal. Not because the tool is bad, but because:
- it was designed by people who know technology, not by the people who do the work every day;
- it handles the average case and fails on the exceptions, which are precisely what keeps people busy;
- it has no owner after the pilot: nobody answers for it, nobody tunes it;
- what was measured was the deployment (it's installed), not adoption (it's being used, and the outcome changed).
The 2024 DORA report on engineering teams gives a warning that applies far beyond software: AI adoption increased individual productivity, flow and satisfaction, but worsened the stability and throughput of deliveries. In other words, every person felt faster and the system as a whole got worse. It is the portrait of a change made at the individual level without redesigning the process around it.
What works: start with the process, not the tool
The classic methods still hold. Prosci's ADKAR model — awareness, desire, knowledge, ability, reinforcement — describes well the stages each person goes through. Kotter's eight steps — create urgency, build a coalition, form a vision, communicate, remove barriers, generate short-term wins, sustain, institutionalise — remain a good map for the organisation. What changes with AI is the pace at which they have to happen and where the weight goes. In practice, what we have seen work:
Start with the process. Before choosing the tool, map the real process — not the one in the manual, the one that actually happens. Where the request comes in, who decides, where the exceptions sit, how long each step takes, where information gets lost. AI comes in afterwards, at a specific point, with a measurable goal. An assistant "to help the team" has no success criterion; an assistant that cuts customer response time from 48 hours to 4 does.
Design with the people who do the work. The people who run the process know the exceptions that will make the pilot fail. Involving them in the design is not a courtesy, it is the only way the tool works in week two. And it addresses part of the status resistance: whoever helps design the new process does not lose influence, they gain it.
Small, visible deliveries, every week. A six-month AI project with one big delivery at the end is a bet against people. Weekly deliveries — one step automated, one report that now produces itself, one queue that no longer exists — give people proof that the change serves them, and give management proof that the investment is producing. Kotter's "short-term wins", in cycles of days instead of quarters.
Measure adoption, not installation. How many people used it this week. How many requests went through the new process instead of the old one. How much time changed. How many exceptions had to go the manual route. If these metrics don't exist, the project is being managed by the gut feeling of its sponsor.
Clear rules on who decides. At every point where AI enters, write down in black and white: what the tool does on its own, what it proposes and a person approves, what it never does. This answers the distrust of the output (there is a check, and everyone knows where) and the fear of replacement (the person's role is defined, not whatever is left over).
The role of leadership: use it before you mandate it
There is a simple test for whether an AI transformation will stick: does management use the tool? Not for a demo — in their own work, every day.
A leadership that asks the organisation to adopt AI while continuing to work as before is communicating, unintentionally, that this is for other people. The opposite — a director who summarises meetings with an assistant, who asks the tool for the first draft of a document and says so — legitimises the change more than any communication plan.
Microsoft's 2026 Work Trend Index puts it directly: as AI and agents take on execution, what remains and grows is the capacity to decide, and the question is whether organisations are built to capture that. It is a question for leadership, not for the IT department.
Three concrete things that belong to management and nobody else:
- Say what happens to jobs. If the answer is "nobody leaves, the work changes", say so, in writing, early. If the answer is different, say that too — uncertainty is worse than either.
- Decide what AI may and may not do with customer data, with decisions that affect people, with money. These rules cannot be delegated.
- Accept that the first version will need tuning and give it time and budget, instead of treating the first error as proof that "AI doesn't work".
Training that isn't training
Most corporate AI training is a generic two-hour course on how to write prompts. It achieves little: people leave knowing how to ask ChatGPT for a recipe and still don't know how any of it applies to the invoice in front of them.
What works looks more like on-the-job learning:
- The company's own cases. Short sessions with the team's real documents, emails and processes. "This is the request that came in yesterday; let's do it with the tool."
- Peers, not instructors. The team member who already uses the tool well teaches the person next to them. It is more credible and it answers the questions an outside instructor doesn't even know exist.
- A place to ask. A channel where someone asks "can this be done with AI?" and gets an answer within hours. Most adoption opportunities die because the person didn't know it was possible.
- Protected time. Half an hour a week to experiment, not stolen from the workload. Without it, adoption is reserved for whoever already had slack.
Training like this is ADKAR's "knowledge" and "ability" done properly, and it is what turns an installed tool into a used one.
Warning signs
A short checklist for a project already under way. Two or more signs is reason to stop and fix before continuing.
- The tool was chosen before the process was mapped.
- The people who do the work did not take part in the design.
- The success metric is "in production" or "number of licences".
- Nobody can say what the AI decides on its own and what goes through a person.
- Management does not use the tool.
- Training was a generic course, once.
- The pilot has no owner after launch.
- There is no date set to review what is working and what isn't.
- People are doing the work "the old way" in parallel, just in case.
How we approach this at Scalor
Our job is to decide what the operation needs to change and stay until it is working, with deliveries every week. In an AI transformation, that means we start with the process map and the people who run it, not with the tool; that every week there is something new in production the team can see; and that we measure adoption and outcomes, not installation. When the technology is the easy part, the value lies in doing the hard part with method. That is how we work in process optimisation and AI training; to start on your own, the AI adoption guide sums up the steps.
Frequently asked questions
Is change management different for AI, or the same as ever? The principles are the same — awareness, involvement, ability, reinforcement. What changes is the pace (the technology no longer buys you time) and three new forms of resistance: fear of replacement, distrust of non-deterministic outputs, and loss of status for whoever mastered the old process.
Where should an SME with no change-management department start? With a single process, mapped with the people who run it, with an outcome metric defined before the tool is chosen. One person responsible, weekly deliveries and a review booked for the end of the first month.
How do you respond to the fear of losing one's job? With a written answer, early, from management, about what changes in each person's role. Uncertainty is worse than any concrete answer and feeds quiet resistance.
How long until adoption sticks? In a small team, with a well-chosen process and weekly deliveries, the first signs of real adoption appear in two to four weeks. What takes months is rescuing a pilot that started without involving people.
Which metrics should we use? Weekly usage (who used it, how often), the share of requests going through the new process, cycle time before and after, the number of exceptions routed to the manual path, and the business outcome that justified the project.
Sources
Writes about applied AI, operations, GEO/SEO and how to turn companies into machines that keep running even when no one is watching.