The Change Management Problem Nobody Mentions When Deploying AI at a Bank

The usage metrics came back at 23%. The model was performing well — the validation results were solid, the integration was clean, the system was available. The operations team had built a workaround in a spreadsheet during the testing period and never stopped using it. Leadership concluded the model wasn't working. The model was working fine. The change management plan was the slide that got skipped.

This pattern appears in the list of reasons AI programs stall at financial institutions, but it deserves a longer treatment because it is both common and almost entirely avoidable. The 23% utilization outcome is not random. It is the predictable result of a specific set of decisions made — or not made — early in the program.

The decisions that produce it are not technical. They are organizational. And the institutions that avoid this outcome are not the ones with the best models. They are the ones that treated the people who would use the system as partners in building it, rather than recipients of it.

Why AI change management is different

Every technology deployment involves change management. AI deployments have three specific characteristics that make the change management challenge harder than it is for most other systems.

Users are being asked to trust a system they cannot inspect. When a bank replaces its core system or upgrades its CRM, the new system does things the user can see and verify. If it produces the wrong output, the user knows it's wrong. An AI system produces outputs that are often plausible regardless of whether they are correct — the recommendation looks reasonable, the summary sounds right, the flag seems justified. Users who have been burned by a confident-sounding wrong answer become skeptical of the system in ways that are entirely rational. That skepticism is harder to overcome than resistance to a new interface.

The system is asking people to change how they exercise judgment. Most AI deployments in financial services do not replace a manual process with an automated one. They change how a human makes a decision — by surfacing information, flagging risks, recommending actions. This requires the user to develop a working model of when to trust the system and when to override it. That is not a trivial cognitive adjustment, and it cannot be accomplished through a two-hour training session. It develops through experience, through feedback, and through a culture that makes overriding the system acceptable rather than marking the user as uncooperative.

The operational team's resistance is often well-founded. The people who will use the system day-to-day often know things about the operational reality that the project team does not. They know about the edge cases. They know about the exceptions that the model will never have seen. They know about the downstream workflow implications of a wrong recommendation. When they push back on the system, they are frequently not being obstructionist — they are providing signal that the system is not ready, or that the workflow design is wrong, or that the training data does not reflect their actual operating environment. Treating that resistance as a change management problem to be managed, rather than as information to be incorporated, produces exactly the outcome above.

The mistake: treating the operational owner as a stakeholder

The standard project management approach to stakeholders is to identify them, assess their interest and influence, communicate with them appropriately, and manage their concerns. This approach treats the operational team as a constituency to be informed and kept on side — not as a party whose input shapes the product.

For most technology projects, this is adequate. The operational team is adopting a system that was designed by people who understand their needs well enough. For an AI deployment, it is not adequate, because the AI system is directly affecting how those people exercise judgment, and the design decisions that determine whether it works for them cannot be made without their active involvement.

The operational owner needs to be in the design conversation from the beginning — not just informed of decisions, but making them. Which outputs does the system surface, and in what format? At what point in the workflow does the recommendation appear? What does the user see when they disagree with the system? How is feedback captured? What happens when the user is right and the model is wrong? These are not UX questions to be answered by a designer. They are workflow questions that only the operational team can answer, because they are the only ones who understand the operational context deeply enough.

Institutions that bring the operational owner in as a design partner — not as a UAT participant, not as a training attendee, but as a co-designer of how the system will be used — produce fundamentally different outcomes than institutions that hand over a completed system and ask the operational team to adapt to it.

The three investments that change the outcome

Workflow co-design before build, not after. The standard sequence is: build the system, design the UX, train the users, deploy, measure adoption. The sequence that produces high adoption is: understand the current workflow in detail, design the AI-assisted workflow with the operational team, build the system to fit the designed workflow, train users on a system they helped design.

The practical implication is that the operational team needs to be involved before the system is built — ideally before the vendor is selected, because the workflow requirements should inform the vendor evaluation. At minimum, before the integration is designed. Retrofitting a workflow into a system that was built without it produces an awkward fit that operational teams recognize immediately and work around.

Workflow co-design does not require months of workshops. It requires two or three structured sessions with the right operational people, focused on specific questions: walk me through how you make this decision today, what information do you use, where do you get it, where does the output go, what are the exceptions that break the standard process. That understanding shapes everything downstream.

Feedback loops that give users a voice in improving the system. One of the most effective change management investments is also one of the most technically straightforward: building a mechanism for users to flag when the system is wrong. Not just a general feedback channel — a specific, low-friction way to say "this recommendation was incorrect" or "this flag was a false positive" and have that signal go somewhere that produces a response.

This does two things. First, it captures information the model needs — the edge cases and exceptions that the training data didn't include, the operational realities that weren't reflected in the validation dataset. Second, and more important for adoption, it signals to the user that their judgment matters. A system that incorporates user corrections improves over time in ways the user can observe. A system that ignores user corrections treats the user as an output consumer rather than a participant. People adopt systems that treat them as participants.

The feedback loop also creates the organizational cover for override. When users know that their overrides are captured and reviewed, overriding the system feels less like defying the technology and more like doing the job correctly. That shift in framing is significant.

Training that explains the model's logic, not just its interface. Standard software training covers what the system does and how to use it. For AI systems, users also need to understand something about why the system produces the outputs it does — not at a technical level, but at the level of the operational logic. What signals is the model looking at? What kinds of cases is it best at? Where are its known limitations? What should trigger a manual review?

This training does not require a machine learning curriculum. It requires honest communication about the system's design — including its limitations. Institutions that oversell the system's capabilities in training create a credibility gap when users encounter the limitations in practice. Institutions that train honestly on both capabilities and limitations create users who trust the system appropriately rather than either over-relying on it or dismissing it entirely.

The training should also cover what to do when the user disagrees with the system. Many AI deployments leave this undefined, and the result is that users either suppress their disagreement (and their judgment) or override without capturing the feedback. Neither is the right outcome. Defining a clear protocol — here is how you flag a disagreement, here is what happens when you do — makes the system more functional and makes users more confident.

When to call it a model problem versus a change management problem

Low adoption after AI deployment is almost always diagnosed as a model problem — the model isn't accurate enough, the interface isn't intuitive enough, the integration isn't clean enough. These diagnoses are sometimes correct. More often, the model is performing adequately and the adoption problem is organizational.

The diagnostic question is: are users who do use the system getting value from it? If the answer is yes — if the users who engage with the system find it useful, if the output quality is adequate when people actually look at it — then the adoption problem is not a model problem. It is a change management problem, and the interventions are organizational, not technical.

The spreadsheet workaround is the clearest signal. When an operational team has built a manual process to do what the AI system was supposed to do, they are not rejecting the use case — they are rejecting this particular implementation of it, or this particular way it was introduced. Understanding which one it is determines what to do about it.

A technically functional AI system with 23% adoption is not a success. It is a change management failure that looks like a technology success. The institutions that avoid it are the ones that treat adoption as a design requirement from the beginning — not a metric to be improved after deployment.

If your institution has deployed an AI system and the usage numbers are disappointing, the first question is not what is wrong with the model. It is what the operational team was told, when they were told it, and whether they had any say in how the system was designed. The answer to that question will usually explain the utilization number better than any technical audit.