Licenses are distributed, training is delivered, dashboards show activity. And the work still happens the way it always did. Adoption is not a training outcome. It is what happens when workflows, leadership behavior, incentives and learning all move in the same direction.
Training raises competence and usually raises usage. People try the tool, some keep using it, and a usage curve appears that looks like progress. What it measures is individual experimentation, not a change in how the organization works.
The gap is structural, not motivational. If the workflow, the approval chain, the quality expectations and the performance measures all assume the previous way of working, then using AI creates extra effort for the person and no visible benefit for the team. Rational people stop.
This is why pilots so often succeed and change nothing. A pilot suspends the normal conditions: attention, support, freedom to experiment. Return the work to its usual environment without changing that environment, and the behavior reverts with it.
It helps to separate four distinct states that are often collapsed into one word. Most organizations are measuring the first two and reporting them as the fourth.
Four distinct states
Whether leaders use these tools themselves, talk openly about where they are unhelpful, and protect the time it takes to learn. Nothing signals more clearly what is genuinely expected.
If the process, the handoffs and the performance measures still reward the old way of working, adoption stays a personal hobby rather than a shared practice.
Adoption spreads horizontally. A recurring moment where a team shows each other what worked and what did not does more than a course, because it is specific to their work.
People need to be able to say that a tool produced something wrong, or that they chose not to use it, without it counting against them. Without that, feedback disappears and only success stories travel.
Time and permission to try things against real problems, with a shared understanding of what would count as a useful result.
Clear, usable guidance on what is allowed with which data removes the hesitation that quietly suppresses adoption in regulated and risk-aware organizations.
Adoption does not mean maximum AI usage. It means AI is integrated where it genuinely improves the work, and deliberately absent where it does not.
Usually because the surrounding conditions have not changed. The workflow still expects the old output, the review still takes the same time, the metrics still reward the same behavior, and using the tool adds a step rather than removing one. Training addresses capability. Non-adoption is rarely a capability problem.
No. Prompting skill helps someone get a better result from a tool in isolation. It says nothing about which parts of their work should change, how quality is judged now, who reviews what, or how the team's process adapts. Those are work-design and organizational questions, and they are where adoption actually stalls.
Usage is measurable activity: logins, prompts, sessions. Adoption is a change in how work gets done that persists when attention moves elsewhere. You can have high usage and no adoption, when people use tools alongside unchanged processes. You can also have modest usage and real adoption, when a few workflows have genuinely changed.
Pilots create temporary conditions: visibility, sponsorship, permission to work differently. When the pilot ends, those conditions end, and there is often no plan for how the new way of working survives contact with normal capacity, normal metrics and normal priorities. The pilot proved feasibility, which is not the same as proving it can be sustained.
They work when they are designed as part of the operating approach and not as a volunteer enthusiasm scheme. They fail when champions are chosen for their interest in technology, given no time, no mandate and no connection to how decisions are made, and left to evangelize tools their colleagues have no reason to adopt.
Champions are most effective when they are not primarily technology evangelists. Their real value is helping teams explore their own problems, facilitating Human–AI work design in the local context, capturing honest feedback about what is not working, and connecting local experimentation back to broader organizational learning. That requires protected time, a clear remit and a route for what they learn to reach the people who can act on it.
By changing the things enthusiasts cannot change on their own: the workflows, the quality standards, the review steps, the incentives and the way progress is measured. Enthusiasts show what is possible. Only the organization can make it the default. Treating adoption as a change-of-work problem rather than a change-of-mind problem is the shift that matters.
Measurement moves from activity counts to whether specific work now happens differently and better.
Effort concentrates on a small number of workflows that genuinely change, rather than broad shallow enablement.
Advocates get time, scope and a feedback route, and become a source of organizational learning rather than internal marketing.
What is not working travels upward, which is the only way the approach can be corrected while it still matters.
Expectations become credible because leaders demonstrate both the use and the limits in their own work.
The change holds after the program ends, because it lives in the process rather than in the enthusiasm.
If you are building an adoption approach, an advocate network, or trying to understand why a promising pilot did not spread, I am glad to think it through with you. This work also runs as a workshop, and I speak on the topic.
Or write directly to sara@bermudez-t.com.