Change management in AI projects: Why pilots don’t scale

Almost every company is using AI. Almost none has changed how the work gets done.

The adoption numbers look like a success story. McKinsey’s 2025 State of AI survey found that 88% of organizations regularly use AI in at least one business function. Then you look at the second number: only 7% report having scaled it across the enterprise, and nearly two-thirds haven’t started scaling at all.

MIT’s NANDA initiative put a sharper edge on it. Their 2025 study of 300 public deployments, 52 organizational interviews and over 150 executive surveys concluded that roughly 95% of generative AI pilots produced no measurable P&L impact. The authors were explicit about the cause: not model quality, not regulation, but what they called a learning gap: the inability of organizations to integrate these systems into their workflows, structures and cultures.
Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Again: none of these are model problems.

Years ago we wrote a short piece about Robotic Process Automation in digital operations. Our conclusion then was that RPA was primarily a change management challenge for the entire organization, rather than a technological one. The technology has since changed beyond recognition but The conclusion hasn’t. If anything, it has become more true, because the surface area of what we are now automating is much larger – and so is the disruption it causes to the people doing the work.
What follows is not a maturity model. It’s what a decade of running these programs has left us with: first inside large organizations, where we owned the automation and change agenda, now as the method Lorenz brings into every engagement. It’s the set of things we keep seeing decide whether an AI automation program becomes an operating capability or an expensive pilot.

1. You are not adding a tool. You are rebuilding the work.

The fastest way to produce a disappointing pilot is to bolt AI onto a process that already exists and measure what happens. The gains are marginal by construction, because the process was designed around human constraints: handoffs, batching, waiting for approval, someone re-typing a value from one system into another. Automating the re-typing saves the re-typing. It doesn’t change the shape of the work.
The question from those projects is the same one we ask now: do we need AI automation, or do we need a better process? More often than not the answer is embarrassingly obvious once you map the flow end to end.
There’s a related truth that nobody enjoys saying out loud. Most operations are held together by a handful of people who are black belts at getting things done. They know how to navigate between systems, how to handle the recurring issue that only triggers under specific conditions, how to manipulate a file when something upstream breaks. That knowledge looks like instinct. It’s actually undocumented process – and AI systems can’t inherit it by osmosis.

This is where leadership stops being a formality. Redesigning a workflow means deliberately destabilizing something that currently works good enough, in exchange for an outcome that is better but not yet proven. That is a genuinely uncomfortable decision, with short-term risk that is measurable and upside that isn’t yet. Without explicit air cover from the top, every team will rationally default to protecting what works today. Sponsorship here doesn’t mean a kickoff email. It means someone senior visibly owning the decision to touch a functioning process.

2. Be realistic.

The single biggest blocker we encounter is the hype.

The ambient narrative says you can automate your company in a month with three hundred agents that handle everything. Nobody entirely believes it, but it sets the benchmark anyway. So when the first deployment saves a team six hours a week instead of restructuring a department, it doesn’t land as a win. It lands as evidence that you did it wrong. The damage of hype isn’t disappointment: it’s the feeling of inadequacy it manufactures inside organizations that are actually making progress.

So we prefer to be blunt early:

• This takes longer than the pitch decks suggest. Not because the models are weak, but because the work of mapping, standardizing, integrating and validating is real work with a real calendar.
• Start from a short, prioritized list. Expected outcome versus effort, ruthlessly. A few processes where value is clear, feasibility is high, and the investment needed is manageable.
• Expect hard blockers, and name them before they surprise you. Legacy systems without usable APIs, data scattered across tools nobody owns, permission models that predate the cloud, exception handling that lives in someone’s head. Gartner makes the same point: integrating agents into legacy systems is technically complex, often disrupting workflows and requiring costly modifications.

The value of these programs is not a big bang. It’s a compounding series of well-chosen, well-built increments. That framing is not a way of lowering expectations: it’s the only framing under which the expectations survive contact with month three.

3. Start narrow. Appetite grows with eating.

Pick one area, or one coherent set of processes, and prove it there. We sometimes call this an internal pilot, to distinguish it from the vendor sense of the word: the goal isn’t to test whether the technology works, it’s to produce defensible evidence inside your own organization.

Two reasons this matters more than it sounds.

The first is evidence: Nothing moves a skeptical department like a neighboring department that stopped complaining about a task. Internal proof travels in a way that external case studies never do.

The second is arithmetic: Attention is the scarce resource in these programs, not budget. Spread across five functions at once, you get five half-built things, none of which is good enough to point at, and a growing sense that the whole effort is diffuse. Laser focus isn’t a philosophy here: it’s what keeps the program alive long enough to have a reference case.
Then something useful happens. Once one team visibly wins, the conversation inverts: instead of pushing adoption, you start rationing it. Requests arrive. Budget arguments get shorter. That inversion – from push to pull – is the real milestone, and you can’t get there by starting everywhere.

Time-box the first wave, instrument it from day one, and be honest that its job is to produce a decision: scale, or stop.

4. Find your champions

Every change management playbook says this, and it’s still underrated in practice.

The lesson we keep returning to is that vertical communication is far less effective than horizontal communication. A directive from leadership establishes permission. It does not establish belief. Belief moves sideways, between peers who do the same job.
So identify your early adopters and make them partners rather than mascots. They are the ones who know which exceptions actually occur, which edge cases break things, why the process behaves differently at month-end. They also give you honest failure reports, which are worth more than enthusiastic ones.
One practical note: being a champion is real work on top of a real job. If you want it to last beyond the first month, protect their time and make the contribution visible. Otherwise you’ve quietly asked your best people to do you a favor indefinitely.

5. Governance: answer “what’s in it for me?”, then measure both halves

Every person touched by an AI automation program is running the same private calculation, whether or not they say it aloud. Operations lead, project manager, IT specialist, business manager: each needs an answer to what’s in it for me? that is specific, realistic and transparent.
Ambiguity gets filled in with the worst available interpretation. If people don’t know what happens to the capacity they free up, they will assume the answer is unpleasant, and they will optimize accordingly: by staying slow, or by keeping the workaround they alone understand.

Two things make this concrete.

A) Explicit expectations, including the negative space

What the system will do, what it will not do, what still requires a human, and what happens when it’s wrong. Overselling capability early is the most expensive kind of shortcut.

B) Feedback that runs on two tracks

The quantitative one is familiar: cycle time, volume, error and rework rates, cost per unit of work. The qualitative one is the one that gets dropped, and it’s the one that tells you whether adoption is real: does this actually make the job better, what broke last week, what are people silently working around. A process can show a green KPI and still be quietly abandoned.

6. Trust is a data conversation, and it’s not optional

Be transparent about data. Where it goes, which systems process it, whether it’s retained, who can see the outputs, what is deliberately excluded from the pipeline. Say it early, say it in plain language, and say it again when the architecture changes.
This is often treated as a compliance box. It’s an adoption lever. The MIT study documented what it called a shadow AI economy: while only around 40% of companies had official LLM subscriptions, roughly 90% of surveyed employees reported using personal AI tools for work tasks. People will find a way to use these systems. The only question is whether that happens on a path you designed and can see, or one you can’t.

7. The finish line is when the change team is no longer needed

Here’s the pattern we didn’t expect the first time we saw it.

One AI automation program we ran started as something like a task force: a small group hunting tactical and strategic opportunities across the organization and, frankly, evangelizing. That was the right structure for the beginning. Then, gradually, the way of working the program had been pushing stopped belonging to the program. Mapping a process before touching it, asking whether a step needed to exist at all, spotting an AI automation candidate in a weekly routine – those habits diffused. People started doing it without us. Some ran ahead on their own.
That’s the actual endpoint of change management in AI transformation. Not a dashboard, not a percentage of processes automated. The moment the capability detaches from the team that introduced it and becomes part of how the organization thinks.

The human half of the work

Operations remain a near-perfect fit for AI automation. They are also deeply rooted in people, in tailored processes and in tangled technology stacks. Introducing AI into them is not a speed-and-quality upgrade: it transforms the operations themselves, and every transformation is a change management problem wearing a technical costume.
The organizations crossing from pilot to capability aren’t the ones with the best models. They’re the ones that took the human half of the work as seriously as the technical half.

How we work on this at Lorenz

One more number from the MIT study, and it’s the one we find most interesting: deployments built with an external partner succeeded roughly twice as often as internal builds. Not because outside teams are smarter, but because they arrive with a method, no history to defend, and no political stake in which process stays untouched.
That’s the position we occupy. Everything above was learned the slow way: running these programs from inside large organizations, mapping processes, choosing what to automate, and doing the harder work of getting people to actually use what we built. Lorenz is where that experience now lives: the same method, applied as the partner companies bring in when they want the capability to stick rather than the pilot to look good.

In practice that means we start from the workflow, not the tool: we map how the work actually happens, prioritize by outcome against effort, build on a narrow scope where the evidence will be undeniable, and stay through the adoption phase, which is the part most projects skip.
If your AI automation program is somewhere between “interesting pilot” and “nobody’s changed anything,” that’s usually a solvable problem. Let’s talk.