Preparing People for AI: The Change Management That Decides Whether It Works

A company launches an AI assistant. The vendor demonstrates it, leadership announces it and the project is marked complete. Three months later, staff keep their old spreadsheet, copy outputs into private chats and ask a trusted colleague to do the checking. The software is installed. The new way of working is not.

AI projects rarely fail because a screen cannot open. They fail because people do not trust the result, do not understand the decision behind the rollout, or see the tool as a threat to their place in the organisation. They route around it quietly.

This is a leadership problem before it is a training problem. The OECD’s work on AI and skills connects training with workplace outcomes, while its guidance also calls for social dialogue, transparency and shared responsibility. The International Labour Organization’s 2025 update makes a related point: because human input remains necessary across many tasks, most jobs are more likely to be transformed than simply removed. That does not make the transition painless. It makes role design and communication decisive.

Start with the truth people are trying to discover

When staff hear “AI transformation”, they often want answers to practical questions:

• Will my role still exist?
• Will this tool monitor my speed or score my judgement?
• Who is blamed when the output is wrong?
• Will I be expected to learn it after hours?
• What happens to the time the tool is supposed to save?

Do not answer these with slogans. Say what is known, what is being tested and what has not been decided. If the organisation expects a role to change, name the tasks that will change. If the tool will not make employment decisions, write that rule down. If the business case assumes fewer hours, explain how that assumption will be reviewed.

People can work with uncertainty when leaders do not disguise it. Trust falls faster when a promise of “support” later becomes an unannounced performance target.

Map work at task level, not job-title level

A job title hides too much. A finance officer may reconcile transactions, explain exceptions, answer suppliers, prepare a board pack and carry context from one month to the next. AI may assist with one part and weaken another.

The NIST AI Risk Management Framework calls for clear roles, training, leadership responsibility, worker diversity and defined human oversight. Use that as a practical checklist for the work map. A person is not “in the loop” if nobody knows what they are expected to review or whether they are allowed to stop the process.

Involve the people who carry the exceptions

Senior leaders see the business case. The people doing the work see the exceptions that make the process real. Include both views before the pilot starts.

Hold a short listening session with the people whose work will be touched. Ask:

• Which part of the current process wastes time?
• Which exception would make an automated suggestion unsafe?
• What information is missing from the system?
• What would make the new process slower or harder?
• What would a useful first version do by the end of the pilot?

Pay attention to the answer that makes the project less exciting. A team may say that an AI summary is less useful than a shorter form, or that the data must be corrected before automation. That is not a failure of enthusiasm. It may be the most valuable design input the rollout receives.

Redesign roles so time saved has a destination

“The tool will save time” is incomplete. Time saved from what, and redirected to what?

If AI reduces manual document sorting, give the team a clear next responsibility: investigate exceptions, contact customers earlier, improve records, coach colleagues or prepare a better management review. If leaders cannot name the destination, staff may reasonably suspect that the real purpose is silent headcount reduction.

Protect the work that gives a role its dignity. A customer-service colleague may spend less time copying order details and more time resolving the case that needs patience. A project manager may spend less time formatting a report and more time discussing the risk the report reveals. A finance manager may spend less time assembling a schedule and more time asking whether the business can fund its next commitment.

These are choices about operating design. They cannot be delegated to a vendor’s product tour.

Build trust through small, visible wins

Early wins should be useful enough to matter and bounded enough to inspect. Do not begin with the workflow that controls pay, credit, clinical decisions or dismissal. Start with a task where the cost of an error is understood and a human can check the output.

Do not confuse usage with adoption. A person can click a tool because a manager requires it while still avoiding the output in the real process. Track whether the work is completed correctly, whether people know when to challenge the result, and whether the fallback process remains usable.

Give managers a script and a responsibility

Change communication fails when only the chief executive has the message. Line managers answer the daily questions, see the workaround and decide whether a mistake is reported. Prepare them before the wider announcement.

Every manager should be able to explain:

• the problem the project is trying to solve;
• the task the tool supports and the tasks it does not control;
• the human approval and escalation point;
• the training time and support channel;
• the measures used to decide whether the pilot continues;
• the route for a confidential concern about role impact, data or fairness.

Managers should also be allowed to say, “I do not know yet.” That answer is safer than inventing certainty and later losing trust.

A six-week people-first rollout

1. Week 1, listen: map the affected tasks, fears, exceptions, language needs, accessibility needs and current workarounds.
2. Week 2, explain: publish the purpose, boundaries, data rules, decision rights, support plan and what remains undecided.
3. Week 3, design: let users and process owners shape the pilot, fallback route and success measures.
4. Week 4, practise: give people a safe environment to test the tool, correct errors and learn when not to use it.
5. Week 5, run: operate the bounded workflow with a named human owner. Record adoption, errors, exceptions, time, quality and staff feedback.
6. Week 6, decide: keep, change, narrow or stop the pilot. Publish what was learned and what happens next.

The 2026 OECD and ILO compendium on human-centred AI at work places worker preparation, transparency, human oversight and the ability to seek redress inside the adoption question. That is the right level of ambition for a small business as well as a large institution: the process should give people a voice before the decision is locked in.

When resistance is the correct response

Some resistance is a communication gap. Some is a warning. A team may be resisting because the tool produces errors, removes necessary context, assumes a language or connectivity pattern that does not fit the work, or creates a new risk without a clear owner.

Do not label every objection “fear of change”. Ask what evidence would resolve it. If the concern is valid, change the workflow or stop the pilot. The goal is not to make people appear enthusiastic. The goal is to build a process that deserves to be used.

AI adoption becomes durable when leaders treat people as participants in the redesign, not as an obstacle between a purchase and a launch. Communicate plainly, make role changes visible, give staff time to learn and keep a human accountable for the consequences. If you need help preparing an AI rollout that people can actually use, contact Peter.