You can build the most accurate, well-governed AI system in the world. If people don’t use it — or use it wrong — it doesn’t matter. Change management for AI projects goes beyond traditional IT adoption because AI changes not just the tools people use, but how they think about their work.

Traditional change management focuses on process changes and new interfaces. AI change management must address deeper questions: Can I trust this system? Will it take my job? What happens when it’s wrong? How do I know when to override it? The PM who answers these questions well will achieve genuine adoption. The PM who skips them will deliver a system that collects dust or, worse, gets used badly.

Why AI Change Management Is Different

The Trust Problem

People have mental models for how software works. They expect deterministic behaviour: same input, same output. AI breaks this expectation. The same question might get different answers. Confidence scores seem arbitrary. Explanations may be incomplete.

Building trust in AI requires more than user training. It requires helping people develop new mental models for working with probabilistic systems — understanding not just what the system does, but how to calibrate when to rely on it and when to question it.

The Expertise Threat

Many AI systems are deployed in domains where human expertise matters. Loan officers, radiologists, recruiters, customer service agents — these roles involve judgment built over years of experience. Introducing AI can feel like a challenge to that expertise, even when it isn’t intended as one.

Effective change management acknowledges this dynamic and positions AI as augmentation, not replacement — while being honest about how roles will evolve. Experts who are involved in designing and testing AI systems develop ownership rather than resistance.

The Accountability Ambiguity

When a human makes a decision, accountability is clear. When AI makes a recommendation that a human approves, accountability gets murky. People may not know how much scrutiny to apply, when to override, or what happens if things go wrong. This ambiguity breeds both over-reliance and avoidance.

Change management must clarify roles, responsibilities, and decision rights before deployment — not after an incident makes the gap visible.

The Explanation Gap

People want to understand why AI makes recommendations. But AI explanations are often technical, incomplete, or unsatisfying. Users may not trust what they don’t understand — or they may over-trust because they assume the system knows something they don’t.

Training must help users interpret AI outputs appropriately and recognise when to question them. This is calibration, not just orientation — and it takes deliberate practice with realistic scenarios, not a one-hour onboarding session.

Regulatory Requirements

AI literacy isn’t just good practice — it’s increasingly required by the frameworks that govern AI deployment.

EU AI Act

The EU AI Act explicitly requires AI literacy. Organisations must ensure that staff involved in operating or using AI systems have sufficient understanding of AI capabilities, limitations, and risks. For high-risk systems, deployers must ensure users can interpret outputs and understand when human oversight is appropriate.

Providers of high-risk AI systems must supply instructions for use to deployers, covering system capabilities, limitations, and appropriate use. These instructions form the basis of user training — not its entirety, but its compliance floor.

Other Frameworks

The NIST AI RMF emphasises human factors throughout the AI lifecycle, including training for operators and practitioners. The GOVERN function requires that AI roles and responsibilities are documented and that personnel have the skills to perform them. UNESCO’s AI ethics recommendations call for public awareness and literacy programmes. COBIT’s AI governance guidance emphasises that effective human oversight requires people who are trained to exercise it.

The Change Management Framework

Standard change management frameworks apply to AI, but need adaptation. The ADKAR model provides a useful structure: Awareness, Desire, Knowledge, Ability, Reinforcement. Each stage requires AI-specific thinking.

Awareness

People need to understand why AI is being introduced, what the system does and doesn’t do, how their work will change, and what’s expected of them. For AI projects, add: how the system makes decisions, what its limitations are, when human judgment should override, and how to report problems.

Awareness is not the same as announcement. A single all-hands email does not create awareness. Sustained communication across multiple channels, before deployment and during it, does.

Desire

People need motivation to engage with the change. For AI, the barriers to desire are often higher than for conventional software. Address fear of job loss honestly — where roles will change, say so and explain what the path forward looks like. Acknowledge the frustration of working with imperfect systems. Recognise that established practitioners have real reasons to be skeptical of tools that claim to replicate their expertise.

Knowledge

People need to know how to work with AI effectively: how to use the system mechanically, how to interpret outputs with appropriate judgment, when to trust and when to question (calibration), and how to override and escalate when needed. Knowledge transfer is not complete when training ends — it is complete when people can apply it independently in real situations.

Ability

People need opportunity to practice. Hands-on training with realistic scenarios, a safe environment to make mistakes, feedback on human–AI collaboration, and time to develop new habits. Ability builds through experience, not just instruction. Plan for a proficiency curve and budget for the support that covers it.

Reinforcement

People need ongoing support after go-live: performance support and job aids accessible in the flow of work, feedback on system and user performance, recognition for appropriate use including appropriate skepticism, and continuous improvement based on user input. Reinforcement is what sustains adoption past the first few weeks.

Training for AI Users

What to Cover

AI-Specific Training Elements

Standard system training covers mechanics. AI training must go further.

•       Calibration exercises: Help users develop appropriate trust by working through examples where AI is right, where it’s wrong, and how to tell the difference. Calibration is a skill that degrades without practice.

•       Edge case exposure: Show users realistic edge cases where the system may struggle, so they know what to watch for in production. Users who have seen failure modes are more likely to catch them.

•       Override practice: Give users explicit experience overriding the system in appropriate situations, so they are not reluctant to do so when it matters. Override should be normalised, not treated as a sign of system failure.

•       Explanation interpretation: Train users to understand what AI explanations do and don’t tell them, and to recognise when explanations are insufficient to support a decision.

Who Needs Training

Communication Planning

Key Messages by Phase

Addressing Common Concerns

Communication Channels

Use multiple channels to reach different audiences and reinforce key messages.

•       Town halls and team meetings for awareness and Q&A — effective for creating shared understanding but not for depth

•       Written guides and FAQs for reference — accessible in the flow of work when users encounter specific situations

•       Training sessions for skill building — the only channel that develops ability, not just knowledge

•       Champions and super-users for peer support — the most effective channel for sustained adoption

•       Feedback channels for ongoing input — essential for reinforcement and continuous improvement

Managing Resistance

Resistance to AI adoption is normal and often rational. Address it constructively rather than trying to eliminate it.

Sources of Resistance

Resistance Management Strategies

•       Involve users early: Include end users in design and testing. Their input improves the system and builds ownership. People resist what is done to them; they support what they helped build.

•       Acknowledge valid concerns: Some resistance reflects real problems. Listen for feedback that identifies genuine issues with the system or the implementation plan. Not all resistance is irrational.

•       Provide choice where possible: Let users opt in gradually, choose how they receive AI input, or customise interfaces. Agency reduces resistance.

•       Celebrate appropriate skepticism: Users who question AI outputs are doing their job. Reinforce that override and escalation are expected and valued, not signs of system failure or user error.

•       Address automation bias explicitly: Help users avoid both over-trust and under-trust. Rubber-stamping AI recommendations without review is as problematic as ignoring the system entirely. Both patterns need to be addressed in training and reinforcement.

Organisational Impacts

AI changes more than individual jobs — it can reshape roles, teams, and organisational structures. PMs need to surface these impacts early, not discover them after deployment.

Job Redesign

Some tasks will be automated. Others will be augmented. New tasks will emerge. Plan for each type of impact across affected roles.

New Roles

AI may require new capabilities that don’t exist in the current workforce. Plan for:

•       AI system operators and monitors with the ability to interpret system performance metrics

•       Human oversight personnel with defined authority and accountability for AI-assisted decisions

•       AI incident responders who can identify, escalate, and manage AI system failures

•       User support specialists with both technical and operational AI expertise

Workforce Planning

Be honest about workforce impacts. UNESCO’s AI ethics recommendations emphasise fair transition for affected employees, including upskilling, reskilling, and safety net programmes for those who cannot be retrained. Addressing these questions in project planning is not just ethical — it directly affects adoption. People who believe their organisation has thought through the human impacts are more likely to engage with AI systems than those who feel blindsided.

•       Which roles are affected, and how significantly?

•       What retraining is needed, and is it realistic within the project timeline?

•       Are there redeployment opportunities for displaced roles?

•       What is the timeline, and have those affected been told honestly?

Post-Deployment Support

Change management doesn’t end at go-live. The period immediately after deployment is when the gap between training and reality becomes visible — and when inadequate support causes the adoption curve to stall.

Hypercare Period

Immediately after deployment, provide intensive support calibrated to user volume and system criticality.

•       Extended help desk coverage during peak hours, with AI-specific expertise available

•       On-the-ground support in high-volume areas — someone physically present is more effective than a ticket queue

•       Rapid response protocol for issues that affect large numbers of users or high-stakes decisions

•       Frequent check-ins with users and supervisors to surface problems before they become patterns

Ongoing Support

After hypercare, maintain the infrastructure that sustains adoption.

•       User feedback channels that are actively monitored and acted on — not just available

•       Regular performance reviews covering both system performance and user adoption patterns

•       Refresher training as needed, particularly when system behaviour changes

•       Documentation updates as the system evolves and new edge cases are discovered

Continuous Improvement

Use post-deployment data to improve both the system and the change approach for future deployments.

•       Track user issues and complaints for patterns that indicate training gaps or system problems

•       Monitor override and escalation patterns — both high and low rates signal something worth investigating

•       Identify training gaps from support ticket analysis and supervisor feedback

•       Feed insights back to the development team; change management data is product data

PM Responsibilities by Phase

During Planning

•       Include change management in scope and budget — as a first-class deliverable, not a line item added at the end

•       Identify all stakeholders affected by the change and map their concerns, influence, and readiness

•       Plan communication and training activities with owners, timelines, and success criteria

•       Define adoption metrics alongside technical acceptance criteria

During Development

•       Involve end users in design and testing — their input improves the system and builds the ownership that drives adoption

•       Develop training materials in parallel with the system, not after it is built

•       Prepare communication content for each phase of the deployment

•       Identify and prepare change champions who can support peer adoption

During Deployment

•       Execute the communication plan — actively, not as a broadcast exercise

•       Deliver training to all required audiences before go-live, with completion tracked

•       Provide hypercare support and monitor adoption in real time

•       Track and triage issues with the same urgency applied to technical defects

Post-Deployment

•       Transition from hypercare to steady-state support with a defined handoff

•       Track adoption metrics against the thresholds defined at project initiation

•       Gather and act on user feedback — visible action on feedback sustains engagement

•       Document lessons learned for the next AI deployment

Measuring Change Success

Track adoption, not just deployment. A system that has been deployed but not adopted has not delivered its intended value.

Right-Sizing for Your Situation

Change management depth should match the scope and impact of the AI deployment. A chatbot for internal knowledge search needs substantially less change infrastructure than an AI system that makes recommendations affecting customer outcomes. AIPMO’s implementation playbooks provide practical guidance calibrated to your stage.

Become a member →

Framework References

•       EU AI Act (Official Journal, 12 July 2024) — Article 4 (AI literacy obligations for providers and deployers); Article 13 (transparency and provision of information to deployers and users); Article 14 (human oversight measures); Article 26 (obligations of deployers of high-risk AI systems, including instructions for use and user training); Recital 20 (AI literacy scope and intent)

•       NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) — GOVERN 1.1 (policies and organisational structures for AI risk governance); GOVERN 6.1 (personnel skills and competencies for AI risk management); MANAGE 2.2 (human oversight roles and responsibilities); MANAGE 4.1 (monitoring effectiveness of risk response)

•       NIST AI RMF Playbook — GOVERN 6.1 suggested actions (training, competency assessment, and skills gap identification for AI practitioners); MANAGE 2.2 suggested actions (human review procedures and override mechanisms)

•       UNESCO Recommendation on the Ethics of Artificial Intelligence (2021) — Section 5.3 (data stewardship and AI literacy); Section 5.9 (just transition and fair treatment for workers affected by AI automation, including upskilling, reskilling, and safety nets)

•       ISACA COBIT AI Governance — APO02 (managed strategy, including workforce capability planning for AI); BAI08 (managed knowledge for AI system operation); DSS05 (managed security services including oversight personnel responsibilities)

•       Singapore IMDA Model AI Governance Framework v2.0 — Section 4 (human involvement in AI-augmented decision-making; override authority; training requirements for AI operators)

•       AIGP Body of Knowledge v1.0.0 — Domain IV (organisational AI governance, including training obligations and accountability frameworks); Domain V (human oversight requirements and their operational implementation)

•       PMI Guide to Leading and Managing AI Projects (CPMAI 2025) — Phase I (stakeholder impact assessment including change readiness); Phase IV (deployment planning including training and communication); Phase VI (post-deployment monitoring including adoption metrics)

This article is part of AIPMO’s PM Practice series. See also: Human Oversight in AI Systems | Stakeholder Engagement for AI Projects | The AI Project Charter