The email is half-written. “Pleased to announce we’re rolling out [tool name] from Monday. All staff will receive a training link by end of day Friday.” Nobody was consulted. Nobody knows what problem this solves, or what happens to the workflow it touches, or why Monday rather than a date that would give people time to prepare.
This is how AI rollouts begin. It is also how many of them die. BCG’s analysis of AI adoption found usage rising sharply while business impact stayed flat, tracing the gap directly to rollout execution rather than tool selection. Adoption is a change management problem, and the change management almost always happens too late, after the tool is live and the team has already found its own way around it.
If you are a few weeks into an AI mandate and planning your company-wide launch, the most important question is not which tool to announce. It is how the people receiving that announcement were prepared for it.
What does co-creating an AI rollout actually mean?
Co-creation means involving employees in the decisions that affect their work before those decisions are made. For an AI rollout, that covers consulting teams on which problems are worth solving, testing with the people who will use the tool daily, and building feedback into the rollout itself rather than waiting for the quarterly survey. The goal is a genuine voice in how a change that shapes their working day actually lands.
HR Executive’s analysis of organisations that sustained AI adoption identified five practices that separated the ones with genuine buy-in from those that stalled: partnering employees in AI education, co-creating alongside them, communicating context for every decision, distributing accountability rather than centralising it, and establishing clear data rights. The first three are directly linked. Employees who understand why a tool is being introduced, who helped identify the problem it addresses, and who participated in the pilot use it more consistently and raise concerns more usefully when something goes wrong.
Co-creation does not require redesigning the whole rollout by committee. A two-hour workshop with the team most affected by a new tool, run before the tool is selected, produces better requirements, surfaces workflow conflicts earlier, and gives employees the sense of agency that makes the difference between compliance and actual adoption. The investment is modest and the effect on whether the rollout holds tends to outlast it.
Why does the people work determine whether your rollout holds?
AI rollouts almost never fail on technical merit. BCG’s analysis of AI adoption found usage rising sharply while business impact stayed flat, and traced the gap to rollout execution rather than tool selection. Adoption is a change management problem, and the change management almost always happens too late, after the tool is live and the team has already found its own workaround.
Korn Ferry’s review of AI leadership readiness found that leaders focused on efficiency over capability building, deploying tools without developing the team around them, consistently saw lower adoption across their organisations. The instinct to move fast on the technology and handle the people side afterwards is understandable under board pressure. It is also the wrong sequence. When the people work follows the deployment, the delegate is retrofitting buy-in into a tool already live, and employees are adapting to something they had no hand in shaping.
The consequences compound. Employees who were not consulted use the tool inconsistently or not at all. Managers who were not given context cannot reinforce adoption in their teams. The rollout becomes something done to the business rather than built with it, and the delegate spends the next quarter managing resistance rather than demonstrating progress. Schellman’s review of AI deployment failures found that failure traces primarily to organisational and change factors rather than technical ones.
Where does resistance show up in practice?
Resistance in an AI rollout rarely announces itself. Employees seldom tell you directly that a tool is not working for them. What surfaces instead is selective use, workarounds, and engagement data that looks fine on paper while actual behaviour stays unchanged. HR Executive calls this silent sabotage, driven by fears that rarely get voiced unless the rollout creates space for them to surface.
The fears are consistent across organisations. Job displacement is the most frequently reported concern, followed by worries about inaccurate outputs, a lack of transparency about how the AI reaches its decisions, and uncertainty about how employee data is being used. They are the natural reaction to a significant change in how work is structured, presented without context by someone with a mandate to deliver adoption figures.
The practical marker for where resistance is highest is usually the function where the rollout was most top-down. When a team was told what tool they were getting, trained on how to use it, but never asked what problem they needed solved, the adoption figures can look acceptable for the first few weeks. Then they drop. The people doing the work found their own approach. They did not complain. They just stopped.
Surfacing this early requires building a feedback channel into the rollout itself. A standing fortnightly call with early adopters, a shared channel for flagging friction points, a named person the team can raise concerns with. The mechanism matters less than the signal it sends: that questions and doubts are part of the process, not evidence that the rollout is failing.
When should you run workshops, and when is that overkill?
Co-creation workshops earn their time when the tool being introduced will materially change how a team does its core work. If the rollout replaces or reshapes something people do every day, at least one structured session before tool selection, and another before the tool goes live, produces outcomes worth the investment. For narrow, optional, or back-office tools with minimal daily impact, lighter consultation is sufficient.
The format does not need to be elaborate. A pre-selection session works best as a problem-definition exercise rather than a product demo. Bring the team together, ask what takes the most time, what the most error-prone part of the workflow is, and what they would fix if they had a free afternoon. Use those answers to evaluate the tools already under consideration. The team’s input shapes the selection criteria rather than the final choice, which keeps the process manageable without removing the genuine voice.
A post-pilot session, run after a small group has used the tool for two to four weeks, is where the real feedback lives. This is where you learn which parts of the rollout need communication support, which workflows need adjustment, and what the team needs to feel confident enough to recommend the tool to colleagues. Framing the session as “help us get this right before it goes wider” rather than “tell us how the pilot went” makes a material difference to what people share.
Recognition matters here too. Employees who served as early adopters and helped shape the rollout should be acknowledged as contributors, not just early users. Building a community of practice around the tool, even informally, gives adoption somewhere to land beyond the initial launch month.
What connects to this in a well-run rollout?
Co-creation sits within a wider set of practices that separate rollouts with genuine adoption from those that achieve surface compliance. Communicating context is the closest companion. Employees who understand the business reason for the change, not just the training steps, adopt more consistently and are more likely to advocate for the tool when colleagues are sceptical. Accountability distribution and data transparency complete the framework.
The augment framing is worth handling explicitly. Employees who hear that a new tool will remove the repetitive parts of their work so they can focus on higher-value activity respond differently to those who are simply told the business is introducing AI. BizTech Magazine’s guidance on AI implementation flags this as one of the variables most reliably associated with sustained adoption. The framing is not spin. If the rollout is well-scoped, the AI genuinely does remove low-value work. Saying so clearly gives employees a reason to engage rather than a reason to be cautious.
The delegate’s relationship with the founder or board affects this too. If leadership discusses AI in terms of headcount reduction, the team hears it regardless of what the rollout communication says. Aligning messaging across levels before the announcement is part of the change work.
McKinsey’s research on AI in the workplace identifies what they call superagency as the outcome when AI is introduced in a way that builds on employee capability rather than working around it. Organisations that achieve this invest systematically in involving people in how AI is introduced, not just in training them to use it once it is live. The training alone is not sufficient. The change work that surrounds it is where adoption is won or lost.
If you are looking at your rollout plan and the section on people and change is shorter than the section on tool selection, that is the gap to close before the launch email goes out.
