Why adoption, not models, decides AI ROI

Leaders spend enormous energy choosing models and building systems, then treat rollout as an afterthought. It is backwards. Every ROI figure for AI is really a figure about people using AI well. That is a change-management problem, not a technical one.

METR’s 2025 randomized controlled trial makes the point sharply. Experienced open-source developers using early-2025 AI coding tools took 19% longer to complete tasks than developers working without them, despite expecting a 24% speedup beforehand and still believing afterward that the tools had made them faster by roughly 20%. Perception of AI benefit and measured benefit were not just different; they pointed in opposite directions. If experienced engineers can be confidently wrong about whether a tool is helping them, the average employee handed a new AI tool with no training and no feedback loop has little chance of self-correcting. That gap is exactly what enablement exists to close.

The 10-20-70 pattern

BCG’s 10-20-70 rule of thumb puts roughly 10% of the effort on algorithms, 20% on technology and data, and 70% on people and process. The systems are necessary; the adoption is decisive. Put differently: most AI budgets are still allocated in almost the opposite proportion to where the value actually comes from. Buying access is not the same as changing work. Deloitte’s 2026 State of AI in the Enterprise survey found that sanctioned worker access to AI tools rose from under 40% to around 60% in a year, yet among workers with access, fewer than 60% used it in their daily workflow. Licenses without a redesigned job are inventory, not impact.

Role-specific enablement, not generic training

A single all-hands “AI 101” session changes almost nothing, because how a controller should use AI has little to do with how a project manager or a field technician should use it. Effective enablement is built around the specific tasks a role actually performs:

• Show the real workflow, not a generic demo: the actual report, ticket type, or document, run through the tool in front of the team that will use it daily.
• Teach the failure modes specific to that role’s tasks: where the system tends to be confidently wrong, and how to catch it before it matters.
• Pair training with the moment of need, not a one-time kickoff. Adoption decays quickly after a single session with no follow-up.

Usage policy essentials

Every organization using AI at work needs a short, specific usage policy, not a forty-page document nobody reads. At minimum it should cover:

• What data may and may not be entered: client information, regulated data, anything covered by an NDA.
• Which tools are approved and what to do if a team wants to use one that isn’t on the list.
• Where human review is mandatory: before an output is sent externally, filed, or acted on financially.
• Who to ask when a use case falls outside the policy’s examples.

A policy nobody has read protects nobody. Keep it short enough that people actually will read it.

Prompt libraries and a champions model

A shared prompt library captures the prompts and workflows that already work for real tasks, including the specific instructions a top performer uses to draft a given document type, so the next person doesn’t start from a blank box. Treat it as a living resource that grows with use, not a static file distributed once and forgotten.

A champions model, with a small number of early, credible adopters on each team recognized (not necessarily paid) for helping colleagues, spreads good practice faster than any centralized training program, because people trust a peer who does their exact job more than a mandate from IT or a slide from leadership. Champions also give you an early-warning system: they are usually the first to notice when a tool update changes behavior, before it shows up in a formal metric.

Measuring adoption, not just access

Seats purchased is a vanity metric. The numbers that show whether adoption is real:

• Active users: weekly or monthly usage against the population given access, not against total headcount.
• Override or rejection rate: how often people discard or heavily edit the AI’s output. High and flat points to a training gap; high and falling is normal early friction.
• Time-to-trust: how long before a new user stops double-checking every result. If this never improves, look at output quality before blaming the user.

Track these per team, not only company-wide. A single average hides the team that never adopted it and the team that is thriving.

Common adoption pitfalls

A handful of mistakes account for most failed rollouts, and they are organizational, not technical:

• Mandating usage without explaining the “why.” A tool pushed top-down with no explanation of the specific problem it solves gets used just enough to avoid trouble, not enough to change outcomes.
• Treating the launch as the finish line. Enablement that stops after week one misses the point where real questions and real friction show up, usually weeks two through six.
• Letting the policy and the training disagree. If the usage policy says one thing and the training shows another, people default to whichever is easier, which is rarely the safer option.
• No feedback channel back to whoever owns the tool. If users hit a wall and have nowhere to report it, they quietly stop using the tool instead of asking for a fix.

Design for it from the start

Adoption is not a phase you bolt on at the end — it is designed in from prioritization onward. That is the thinking behind how Celadon builds for adoption, and why so many pilots die without it; see pilot to production.

Start with an AI Decision Sprint.

A measurement stack for adoption

Measure adoption at three levels rather than collapsing it into license activation. Access asks whether the intended team can use the approved tool. Task coverage asks which recurring tasks are actually being completed with it. Outcome quality asks whether those tasks are faster, better, safer, or more consistent than the baseline. A seat can be active while task coverage and outcome quality remain at zero.

Start with a baseline for one team, not an enterprise-wide target invented in a steering committee. After four to six weeks, compare task-level behavior and outcomes, then decide which practices deserve to spread. Adoption is demonstrated by repeatable work, not enthusiasm scores.