ADKAR Meets AI: Applying Change Management Discipline to AI Adoption

Prosci's ADKAR model was never built with AI in mind, which is exactly why it holds up so well against it. AI adoption is a change like any other, arguably a harder one, because it touches both how people do their jobs and how much they trust the tool doing part of the job for them.

Where AI adoption breaks the ADKAR chain

• Awareness: staff hear about "the AI project" through rumor before any official communication, and the narrative that forms first is rarely the one you want.
• Desire: without a clear answer to "what does this mean for my role," desire defaults to fear, not curiosity.
• Knowledge: training built for software adoption (click here, then here) under-prepares people for tools whose output varies and requires judgment.
• Ability: knowing how to use the tool isn't the same as having the confidence to act on its output in a live customer or patient interaction.
• Reinforcement: AI tools evolve after launch in ways traditional software doesn't; reinforcement has to be ongoing, not a 30-day check-in.

The practical fix is to build the change plan from ADKAR outward, not bolt it onto a technical project plan after the architecture is decided. Awareness and Desire need to be addressed before the tool is selected, not after it's built, because by the time staff see the finished product, the narrative about what it means for them has often already hardened.

In my engagements, the organizations that adopt AI well treat Ability and Reinforcement as ongoing line items in the operating model, not milestones that close out when the project does. That's a PMO and operations decision as much as a change management one.