A team has access to an AI assistant. Training is complete, the launch message has gone out and the dashboard shows people logging in. Yet much of the work still follows the old route.
It is tempting to call this resistance to change. Before asking employees to use AI more, examine the task they are trying to finish and the point at which they choose another route. That choice may reveal a capability gap, but it may also reveal a sensible response to extra effort, unclear responsibility or an unsuitable tool.
My VORTA framework connects AI ambition with operational readiness, ownership and adoption. From that perspective, adoption is a design question as well as a people question. The aim is to make appropriate use workable, rather than turn activity in a new tool into the definition of success.
Start with one completed task, not an opinion survey
Ask a willing user to walk through a recent task from the initial request to the accepted result. Include the hand-offs, checking, copying and corrections that happen outside the AI interface. Ask where they used the assistant, where they stopped and what they did instead.
“Why do you not like the tool?” invites a general opinion. “Show me the last point where you switched back” produces a specific observation that can be tested. A person may like the assistant and still find it unhelpful for the part of the job that takes the most effort.
Use an approved, privacy-conscious review method. Prefer a sanitized example or an agreed observation session to collecting private prompts or monitoring individuals indiscriminately. Explain what is being examined and how the findings will be used. The purpose is to understand work, not build a covert performance score.
Five AI adoption barriers that require different responses
1. The new route adds work around the useful step
The assistant may produce a draft quickly while requiring the employee to gather context, remove sensitive information, reformat the result and enter it into another system. If those steps outweigh the useful part, a shorter generation time does not make the whole task easier.
Observe the end-to-end process and identify which extra steps are necessary controls and which are avoidable friction. Integration, a narrower task or a better input format may help. Removing a necessary check solely to increase usage would solve the wrong problem. This extends the discipline of fixing process bottlenecks before adding AI into the adoption review.
2. People cannot tell when the output is reliable enough
A fluent response can still leave its user unsure about sources, exceptions or missing context. Someone who has to defend the final answer may reasonably prefer a slower route they know how to verify.
Ask which uncertainty causes the switch. Does the user need a current source, an explanation of a calculation, a clear indication of missing information or a route to specialist review? Improve the relevant evidence and evaluation. More reassuring language is not a substitute for making the output checkable.
3. The responsibility is clearer than the authority
An employee may be accountable for an error but unsure whether they may reject the AI recommendation, change its output or fall back to the previous process. “Use your judgment” is weak guidance if rejecting the tool is later treated as poor adoption.
Clarify the permitted task, the user’s decision authority and the circumstances for escalation or fallback. A justified override should be explainable without being automatically treated as failure. Equally, a workaround that breaches an important control needs a safe alternative and appropriate intervention.
4. The person needs practice on the actual task
A general introduction does not establish that someone can prepare an appropriate input, recognize an unsuitable response and complete their role safely. Here, targeted practice may be the right intervention.
Use a realistic, sanitized task and observe the difficult decision. Can the employee recognize when information is missing? Can they improve the input without sharing restricted data? Can they decide when to stop? The distinction matters: role-based AI training should address the capability gap that was observed, rather than repeat a presentation everyone has already attended.
5. The task or incentive does not fit the proposal
Some work is too infrequent, too context-dependent or already too straightforward to justify the added step. In other cases, people are measured on speed while the rollout requires additional checking that their workload does not accommodate.
Reconsider the task boundary and operating expectations. The answer may be to reserve AI for a narrower activity, change the workload, redesign the hand-off or stop using it for this task. Training cannot by itself make an unsuitable use case worthwhile.
An illustrative example: an assistant for service replies
Consider a hypothetical service team using AI to draft customer replies. This is a design example, not a client result. Staff open the tool but frequently return to their existing templates.
A task walkthrough shows that the assistant lacks the current case details. Employees must copy information into it, remove personal data, check whether the suggested remedy is permitted and then paste the answer back into the service system. Familiar templates are less flexible, but easier to complete and verify for routine cases.
A generic “embrace AI” campaign would miss the issue. The team could instead test a bounded use: drafting a clearer explanation from an approved, sanitized case summary and a selected policy passage. The employee would still choose the permitted remedy and verify the final reply. Integration could be considered separately if its access and data-handling requirements can be met.
The review should compare the complete task with the existing method, including preparation, checking, correction and hand-off. If the revised use offers no worthwhile improvement at the required quality, retaining the templates is a legitimate outcome. The objective is better service work, not a higher prompt count.
Turn feedback into a decision and a small test
For each important point of abandonment, keep a short record:
- Observation: What task and step did the person leave, and what route did they use instead?
- Explanation to test: Is the likely issue workflow friction, output uncertainty, authority, capability or task fit?
- Evidence: What supports that explanation, and what is still unknown?
- Change: What specific adjustment will be tested, by whom and within which approved boundary?
- Decision: What result would justify keeping, revising or stopping that adjustment?
Do not convert one interview into a finding about the whole workforce. Check whether the same issue appears in different roles or task types. A small review can identify a useful hypothesis while leaving its prevalence uncertain.
Start with the smallest credible change and keep the comparison fair. Use comparable tasks, the same quality requirements and an agreed review period. Include unsuccessful attempts and work completed outside the AI tool; otherwise, the apparent improvement can reflect which tasks were counted rather than what changed.
The NIST AI RMF Playbook, MEASURE 1.2–1.3, supports using end-user feedback and involving relevant users in evaluation. The diagnostic questions here are my practical synthesis for an adoption discussion, not a prescribed NIST checklist or an ISO certification requirement.
Measure appropriate use, not compulsory activity
First define which tasks are eligible for the intended AI use. Then examine how often those tasks are completed successfully, what review effort remains, where rework occurs and why users choose a different route. Report the sample and its limitations alongside the result.
Logins, prompts and training attendance can describe activity. They cannot independently establish that the work improved. Connect adoption observations to a business outcome using the same care discussed in turning AI time savings into business results. Keep quality, risk and the experience of affected people visible alongside efficiency.
When people bypass AI, treat the behavior as evidence to investigate. A useful leadership response makes the right use easier, the limits clearer and the next decision testable.
If your rollout has activity but uncertain practical adoption, schedule a consultation to examine the workflow, the decisions users face and the changes worth testing.