Traditional Change Management Breaks When You Apply It to AI

Every major bank I've worked at had a change management playbook. Usually some version of Prosci's ADKAR model or Kotter's 8-step process. These frameworks work fine when you're migrating from one loan origination system to another. They fall apart completely when the thing you're rolling out changes every 90 days, the use cases multiply faster than you can document them, and your employees discover new applications you never planned for. That's AI. And if you're running your AI adoption through the same change management machine you used for your last ERP migration, you're already behind.

Why Traditional Change Management Assumes the Wrong Things

ADKAR stands for Awareness, Desire, Knowledge, Ability, Reinforcement. It's a linear model. You move people through stages, from not knowing about the change to being competent with it. Kotter's model is similar. Create urgency, build a coalition, communicate the vision, remove obstacles. Both frameworks assume something that's true for most IT projects: there's a defined end state. You're moving from System A to System B. The change is finite.

AI doesn't work that way. When we rolled out an internal AI assistant to 400 operations staff at one bank, we had a defined use case: summarizing customer complaint narratives for faster routing. That was the 'change' we managed. Within six weeks, those same employees had found 11 additional use cases we never scoped. They were drafting response letters, pulling regulatory citation references, and building comparison tables across product lines. The tool hadn't changed. The people changed how they used it.

Traditional change management would call that scope creep. In reality, it was the entire point. AI tools are general purpose. Their value compounds when people experiment. But if your change management process is built around a fixed training curriculum and a go-live date, you're teaching people to use a hammer when you handed them a Swiss Army knife.

I've seen this disconnect at three different institutions. The change management team builds a training deck for Use Case 1. They measure adoption by login rates and task completion for Use Case 1. Meanwhile, 30% of the user base is already on Use Case 4, which nobody trained them for, and another 20% stopped using the tool entirely because Use Case 1 didn't match their actual workflow. The adoption numbers look fine on paper. The reality on the ground is chaos.

The Continuous Adoption Loop: A Framework That Fits AI

What works instead is something I call the Continuous Adoption Loop. It has four phases, but unlike ADKAR, they don't end. You cycle through them every 60 to 90 days as capabilities evolve and your people find new ways to use them.

Phase 1 is Seed. You pick 2 to 3 specific use cases for a specific team. Not the whole organization. Not even a whole department. One team, clear problems, measurable outcomes. At one bank, we started with a 12-person commercial lending team that spent 6 hours per analyst per week pulling data for credit memos. The AI tool cut that to 90 minutes. That's the kind of concrete win that creates pull, not push.

Phase 2 is Observe. This is where most change management programs have a blind spot. For 30 days after deployment, you watch what people actually do with the tool. Not what you trained them to do. What they actually do. We embedded a product manager with the lending team and discovered that 4 of the 12 analysts had started using the tool to draft sections of the credit memo itself, not just pull data. That was never in scope. It was also 3x more valuable than the original use case.

Phase 3 is Absorb. You take what you learned in the Observe phase and fold it back into your training, your use case library, and your governance framework. The credit memo drafting became an official supported use case with guardrails, quality checks, and a review process. This happened 45 days after initial deployment. In a traditional change management timeline, we'd still be in the 'Reinforcement' phase of the original use case.

Phase 4 is Expand. Now you take everything from the first three phases and move to the next team. But you're not starting from scratch. You're bringing a tested use case library, real adoption data, and proof points from peers. The second team adopted 40% faster than the first. The third team was 55% faster. By the fifth team, we had an internal community of 30+ power users who handled most of the peer training themselves.

The Three Mistakes That Kill AI Change Programs

Mistake number one: treating AI training like software training. Software training teaches you where to click. AI training needs to teach you how to think about the tool. When I say 'think about the tool,' I mean understanding what it's good at, what it's bad at, and how to evaluate its output. At one institution, we replaced a 4-hour classroom training with a 45-minute session that covered three things: what the tool does well, what it gets wrong, and how to check its work. Adoption scores went up 28% compared to the previous cohort that got the full training.

Mistake number two: measuring adoption by usage, not by outcome. Login counts and session duration tell you nothing useful. We tracked three outcome metrics instead. Time saved per task, measured by self-reported surveys every two weeks. Error rates on AI-assisted work versus manual work. And the number of new use cases discovered per team per month. That third metric is the one most organizations miss entirely. If your teams aren't finding new uses for the tool, they're not actually adopting it. They're just complying with the rollout.

Mistake number three: ignoring the middle managers. I've written about how the middle manager role is changing, but in the context of change management, this is where programs live or die. At one bank, we had a VP of operations who told her team, 'Use the AI tool for the compliance summaries, but I still want to see your manual version too, just in case.' That single sentence killed adoption on her team for three months. People did double the work, resented the tool, and usage cratered. We didn't fix it with more training. We fixed it by sitting down with that VP for 30 minutes, showing her the accuracy data, and getting her to drop the parallel process. One conversation. Three months of lost adoption recovered in two weeks.

The pattern across all three mistakes is the same. Organizations over-invest in the rollout event and under-invest in what happens after. AI change management is 20% launch and 80% iteration.

Building the Change Team AI Actually Needs

Traditional change management teams are staffed with communications specialists and trainers. Those skills matter, but they're not enough for AI. The change team for an AI program needs three roles that don't exist in most change management frameworks.

First, you need a Use Case Scout. This person's job is to sit with teams post-deployment and identify emergent use cases. Not to train. Not to troubleshoot. Just to watch, ask questions, and document what people are actually doing. At one bank, we pulled a business analyst from the operations team and gave her this role full time for 90 days. She identified 23 use cases across 5 teams that nobody had planned for. Seven of those became officially supported use cases within 6 months.

Second, you need a Friction Hunter. This person tracks where people abandon the tool and why. Not through surveys. Through observation and short conversations. We found that 60% of abandonment at one institution happened at the same point: when the AI output needed to be reformatted to match an internal template. The tool was fine. The last-mile formatting was the problem. We built 5 output templates into the system and abandonment dropped by half in two weeks.

Third, you need an Executive Translator. This person converts adoption data into language that leadership cares about. Not 'we had 500 logins this week.' Instead: 'The commercial lending team completed credit memos 4 hours faster per analyst this week, freeing 48 analyst-hours that were redirected to pipeline development.' That's the kind of update that keeps executive sponsorship alive past the first quarter.

You don't need to hire three new people. Reassign existing staff for 60 to 90 days per wave of the Continuous Adoption Loop. The investment is small. The difference in adoption outcomes is massive. I've seen teams with these three roles hit 70% meaningful adoption in 90 days. Teams without them average 35% at the same milestone.

Actionable Takeaway