Getting staff buy-in for an AI pilot: a change-management checklist
Getting staff buy-in for an AI pilot is usually treated as a soft problem to manage after the tool is live, not a risk to plan for before it launches. That ordering is backwards, and the data on resistance is moving in the wrong direction to ignore it. KPMG’s Q2 2026 AI pulse survey found employee resistance to AI agents jumped to 20%, up from just 5% the quarter before - with trust and ethics concerns now the leading driver, ahead of job security. A pilot with a sound business case can still fail if the people meant to use it quietly route around it, and that outcome is preventable with the same discipline you’d apply to the pilot’s success metrics.
Why resistance is rising, not falling
Gallup’s February 2026 survey of over 23,000 US employees found that while half now use AI at work in some form, only 13% use it daily - and the gap between access and actual use is where most pilots quietly stall. The same survey found 18% of workers think it’s likely AI will eliminate their job within five years, up from 15% in 2025. That concern doesn’t move in a straight line with how advanced the tool is; it moves with how the rollout is communicated. Gallup also found employees whose managers actively and visibly support AI use are nearly twice as likely to use it frequently - which means the biggest variable in adoption isn’t the software, it’s whether the people above the pilot visibly back it.
For a COO, that reframes the task. Staff buy-in for an AI pilot isn’t a communications exercise you run once at kickoff. It’s an input to the pilot’s success criteria, measured the same way you’d measure the task metric the pilot was meant to move.
The checklist to run before the pilot starts
Run these before anyone touches the tool, not after adoption numbers come in flat:
- Name who the pilot affects, by role, not by department. “Operations” isn’t specific enough to tell you who loses a task, who gains one, or whose daily workflow changes. List the actual roles and what changes for each one.
- Involve two or three people from that group before the pilot is scoped, not after it’s built. A pilot designed without input from the people using it arrives as something done to them, and that’s the fastest way to manufacture the resistance you’re trying to avoid.
- Write down what happens to the task the AI takes over - not in vague reassurance language, but specifically: does this role gain time for other work, does headcount change, is this reviewed again at a fixed date. Silence on this question gets filled in by the worst-case assumption, every time.
- Name a champion inside the team, not just a project sponsor above it. KPMG’s data shows trust, not capability, is now the leading resistance driver - and trust in a new tool moves faster through a peer who uses it well than through a memo from leadership.
- Set one adoption metric alongside the performance metric - percentage of the target group actively using the tool by week four, for example - and review it with the same rigour as the pilot’s efficiency or cost numbers.
Answer the trust question directly, in plain language
Because trust and ethics concerns now outrank job security as the top driver of resistance, a generic “AI will make your job easier” message doesn’t land. Staff want three things answered specifically, early, and without jargon:
- What does the tool actually see? Which systems, which data, whose information.
- What decision, if any, does it make on its own - and what stays with a person.
- What happens if it gets something wrong? Who catches it, and what’s the process for flagging an error.
These are the same governance questions a board or an auditor would ask of the pilot - answering them for staff isn’t a separate communication track, it’s reusing the governance work you should already be doing.
What to watch for once the pilot is live
Resistance rarely shows up as an email saying “I don’t want to use this.” It shows up as the tool being quietly worked around: people keeping the old spreadsheet running in parallel, routing exceptions back to manual process, or using the tool only when someone’s watching. Build a short check-in at the two-week and six-week marks that asks the team directly what’s getting in the way, rather than relying on usage logs alone to tell the story - logs show what happened, not why.
Where to start
None of this replaces defining the pilot’s success criteria properly - it runs alongside it. If you haven’t yet nailed down the baseline, the metric and the governance answers for the pilot itself, that’s the foundation this checklist sits on top of. Our complimentary AI-Readiness Data Check is built to surface exactly that: twelve questions, about ten minutes, and a plain picture of your data, systems and governance position before you scope a pilot - the same picture that makes the staff conversation concrete instead of reassuring in the abstract.