A service team tests an AI assistant that drafts replies to customer enquiries. In a demonstration, it produces a reasonable answer within seconds. Several weeks later, most staff are still writing their own replies. The pilot sponsor describes the problem as resistance to change, while the team says checking the drafts takes longer than starting again.
Both observations concern adoption, but they suggest different interventions. More training might help someone who cannot use the tool. It will do little for a reviewer who must search three systems to establish whether a confident answer is correct. Before deciding that an organisation needs a stronger AI culture, it is useful to examine what people actually have to do to produce an acceptable result.
AI adoption barriers are the conditions that prevent a proposed use from becoming useful, dependable work. Some concern model capability. Others concern information, permissions, incentives, cost, or unresolved responsibility. Diagnosing them requires following the workflow far enough to see where the apparent benefit disappears.
AI Adoption Barriers at a Glance
The barriers fall into four connected groups: strategy and leadership; data and technology; people and culture; and governance, risk, and compliance. The table provides a starting point for diagnosis. A project can face several of these barriers at once, so the next step is to establish which one is actually preventing progress.
| Barrier | What it looks like in practice | Practical response |
|---|---|---|
| Strategy: no clear AI strategy | Disconnected pilots have no shared business objective, delivery roadmap, or agreed measure of return. | Connect each use to a business priority, name an outcome owner, and set criteria for continuing, expanding, or stopping. |
| Leadership: insufficient executive support | Teams can run demonstrations but cannot secure funding, resolve competing priorities, or assign ongoing responsibility. | Give a sponsor authority to resolve dependencies and commit resources beyond the trial. |
| Value: unclear use cases | A technically impressive demonstration addresses a minor task or adds more checking than it saves. | Test a defined operational problem against current quality, handling effort, and cost. |
| Data: poor quality and fragmentation | Inaccurate records, scattered documents, or outdated policies produce unreliable answers and extra verification. | Identify authoritative sources, correct the records needed for the use, and assign responsibility for maintenance. |
| Technology: legacy integration | The assistant cannot access necessary account information or write results into existing systems reliably. | Test permissions, interfaces, and handoffs early; include integration work in the delivery estimate. |
| Economics: rising operating and token costs | Inference, storage, compute, and review costs grow as usage expands, eroding projected savings. | Estimate the full cost per completed task under realistic volumes and exception rates. |
| Capability: workforce skills gaps | Specialist delivery expertise is unavailable, or employees lack time and practical training to use outputs safely. | Plan technical support and role-specific learning using representative tasks and failure cases. |
| Culture: resistance and fear | Staff or managers worry about displacement, changed workflows, or loss of expertise and control. | Discuss intended job changes openly and involve affected people in workflow design. |
| Trust: too little confidence or too much reliance | People avoid useful assistance, or accept confident answers without sufficient checking. | Demonstrate where the system works, teach verification, and make escalation and manual work straightforward. |
| Security and privacy: uncertain data protection | Confidential information, personal records, supplier retention, or data location requirements remain unresolved. | Review the proposed data flows, access controls, supplier terms, and applicable privacy requirements. |
| Legal and regulatory uncertainty | Approval stalls over accountability, biased outcomes, intellectual property, or which obligations apply. | Assign decision owners and obtain advice on the specific use, recording the evidence required for approval. |
Strategy and Leadership Must Connect Pilots to Delivery
A clear AI strategy identifies which business problems merit investment and how the organisation will judge progress. Without that connection, teams can accumulate experiments that compete for the same specialists and never establish a measurable return. A roadmap should identify priorities, dependencies, accountable owners, and the evidence needed before further funding is committed.
Executive support matters when a pilot reaches decisions the delivery team cannot make alone. For the reply assistant, a sponsor may need to secure access to account information, agree protected training time with service managers, and fund ongoing support. Endorsing AI in principle leaves those practical decisions unresolved. Sponsorship needs enough authority and continuity to carry a useful pilot into routine work.
Use-case selection is a related but distinct barrier. A clear strategy cannot rescue an application that solves an unimportant problem. Start with an operational need and a baseline, then establish whether AI improves the complete task enough to justify the effort and risk.
Establish Where Progress Stops
A stalled project needs a more specific description than low readiness. Is the organisation struggling to identify a worthwhile use, obtain approval, access data, achieve acceptable quality, persuade people to use the system, or support it after deployment? Each stage has different evidence and different owners.
For the reply assistant, the team could examine a sample of real enquiries. Record which ones the assistant can handle, what reviewers change, where they obtain supporting information, and whether the final reply reaches the customer sooner. Include abandoned drafts. Counting only accepted suggestions would hide the effort spent rejecting the rest.
The result may reveal that ordinary delivery questions work well, but refund disputes depend on account history the assistant cannot access. That is a narrower and more useful finding than saying the model lacks business knowledge. It suggests either restricting the initial scope or investigating the missing integration.
This diagnosis also prevents a long readiness checklist from becoming an indefinite prerequisite. An organisation does not need to resolve every data problem before testing one bounded workflow. It needs to identify the conditions that matter for that workflow and establish whether they can be met.
The Claimed Benefit May Not Survive the Full Task
Generating a draft quickly is a technical capability. Reducing the effort required to send a correct response is a business outcome. Between those two points sit review, correction, approvals, system entry, and sometimes additional conversations with the customer.
Suppose a draft saves four minutes of writing but adds five minutes of verification. The experiment has still produced useful information: generation was not the main constraint under those conditions. A better knowledge source, a narrower task, or a different interface might change the result. Expanding the licence allocation would not establish that benefit by itself.
Evidence from other workplaces can inform expectations without settling the local case. In the NBER working paper Generative AI at Work, Brynjolfsson, Li, and Raymond studied a conversational assistant used by customer support agents. They reported an average productivity improvement of 14%, measured as issues resolved per hour, with substantial differences across worker groups. That result concerns a particular intervention and setting; it is not a general return forecast for business AI.
Local measurement should therefore include accepted output, total handling effort, quality, and relevant downstream effects. A faster reply that produces more repeat contacts may have moved work elsewhere. Conversely, a modest time saving may be valuable when it also improves consistency or helps new staff handle unfamiliar cases.
The adoption strategy article develops how to select and fund such experiments. The diagnostic question here is whether the proposed outcome remains plausible once the whole task is included.
Information Problems Become Workflow Problems
An assistant retrieving internal documents may find several versions of a policy, each written clearly and stored in an accessible location. Retrieval can surface the documents without establishing which one applies. A plausible answer assembled from an expired policy can be harder to detect than a missing answer.
The organisation needs ownership of the source material. Someone must establish which policy is authoritative, how exceptions are recorded, and what happens when guidance changes. For the reply assistant, that might mean maintaining a current returns policy with effective dates and a named business owner. It need not begin with a complete reconstruction of the document estate.
Access creates a separate constraint. A staff member may be authorised to see one customer’s account but not another’s. An AI application must preserve those boundaries across retrieval, generated answers, caches, and logs. A broad search index can make information easier to find while introducing access problems that were less visible in the original systems.
These issues are sometimes described collectively as poor data quality, but the remedies differ. Incorrect records require correction. Ambiguous authority requires a decision. Missing permissions require an access design. Treating all three as a model problem makes the next investment difficult to justify.
Legacy Systems Can Prevent Useful Integration
Even reliable information may be difficult to use when it sits in older systems with limited interfaces or inconsistent identifiers. The reply assistant might draft an answer but still require an adviser to copy account details between applications and enter the result manually. Those handoffs can consume the apparent saving and introduce errors.
Test the integration with the actual systems and permissions needed for the workflow. Establish whether information can be retrieved with sufficient freshness, whether results can be recorded correctly, and what happens when an interface fails. Include integration development and maintenance in the estimate before assuming that a successful standalone demonstration can become a dependable service.
Employee Concerns Can Identify Real Design Defects
People may hesitate because they do not understand the tool, because they doubt its output, or because they expect its use to affect their job. Those concerns deserve separate conversations. A generic awareness session cannot answer an unresolved question about performance assessment or staffing.
If the organisation intends to use adoption data in employee evaluation, it should explain what is measured and how it will be interpreted. Staff handling difficult cases may accept fewer suggestions for good reasons. A target based on suggestion acceptance could discourage the scrutiny the organisation needs.
Training should use representative work, including examples where the assistant should be corrected or set aside. A service adviser needs to know how to check a claim against an authoritative source, recognise an unsupported commitment, and continue through the manual process. Familiarity with prompting is useful, but it does not replace knowledge of the underlying service.
Specialist capacity is a separate issue from everyday AI literacy. A project may need people who can connect systems, evaluate output quality, design access controls, and support the service. Establish whether that expertise is available internally or through suppliers, who will maintain the work, and whether staff have time to learn. Providing a tool without either delivery expertise or protected learning time leaves a capability gap that enthusiasm alone cannot close.
Employee participation can also expose interface problems. Reviewers may need the source passage beside the proposed reply, a clear indication of missing account information, or a way to reject a draft without losing their own work. These changes address the cost of using the system directly.
Trust should follow evidence about appropriate use. People should be able to rely on the assistant for tasks it handles consistently while remaining cautious about cases outside that scope. Increasing trust indiscriminately would be a poor objective.
This creates a trust paradox: low confidence can prevent people from gaining useful experience, while high confidence can make an incorrect answer harder to challenge. Supported practice with known examples, visible source material, and clear escalation routes can help people build familiarity without treating fluent output as proof of accuracy.
Approval Delays Often Conceal Unassigned Decisions
A pilot can wait for security, legal, procurement, and operations without anyone being able to say what remains unresolved. The delay may reflect a legitimate concern, such as uncertainty about supplier retention of customer information. It may also reflect an approval process that has no defined decision owner or evidence requirement.
For each unresolved issue, record the question, the person able to answer it, and the consequence for the proposed use. Can customer records be submitted under the contracted service terms? Who approves the residual risk of an incorrect draft? Who can suspend access if information is exposed? These are decisions that can be assigned and completed.
Separate security and privacy questions from wider legal uncertainty. The first includes exposure of confidential information, supplier access, retention, and any applicable data residency constraints. The second can include responsibility for harmful errors, biased outcomes, and rights to use input material or generated output. Each question needs an answer for the proposed workflow; grouping them under a general concern about AI makes it harder to establish what would permit the project to proceed.
Existing law may already apply even where AI-specific regulation is developing. New Zealand’s Privacy Commissioner explains how the Information Privacy Principles apply to AI and recommends a privacy impact assessment before use. That provides a concrete starting point for examining personal information rather than treating regulatory uncertainty as a reason to postpone every discussion.
The appropriate review depends on the use. An internal drafting assistant and a system determining customer eligibility involve different consequences. The compliance article explains how to establish the applicable obligations without assuming that one checklist covers every deployment.
Production Introduces Costs the Pilot May Have Excluded
A small trial can rely on an enthusiastic specialist who fixes prompts, checks unusual answers, and manually repairs missing information. That support may be acceptable during investigation. It needs to become visible before the organisation estimates the cost of expansion.
Production requires a service owner, support arrangements, controlled releases, supplier management, monitoring, and a fallback. The model bill is only part of the expense. Review effort, integration maintenance, evaluation, and incident handling can matter more for a workflow with modest transaction volumes.
Token charges and inference usage can grow with longer conversations, larger retrieved documents, repeated attempts, and additional model calls. Storage and compute add further costs where required by the design. Estimate these expenses at expected usage and at a higher-volume scenario, alongside human review and support. A low-cost demonstration does not establish an affordable cost per completed task at production scale.
Vendor dependency should be examined through concrete changes. What happens if the supplier replaces a model, changes a service limit, or makes a useful feature unavailable? Exporting prompts will not necessarily reproduce behaviour elsewhere. A practical contingency identifies which parts of the workflow can continue manually and what evidence would be needed before changing providers.
Expansion can also alter the case mix. Volunteers may handle straightforward enquiries and know when to intervene. A wider group will encounter different exceptions and require more explicit guidance. The organisation should test those conditions before treating a successful pilot as evidence for unrestricted use.
Choose the Next Intervention From the Evidence
An adoption review should end with a decision that addresses the observed barrier. If checking takes too long, investigate verification and source quality. If people lack permission to use necessary records, resolve the access design. If no owner will fund ongoing support, reconsider whether the proposed benefit justifies a service commitment.
Some uses should remain limited, and some should stop. That can be a sound outcome when the experiment has shown that quality, cost, or risk cannot meet the intended conditions. Record the reason so the organisation can distinguish an unsuitable use from one that might become viable after a specific dependency changes.
Progress becomes easier to assess when the barrier is expressed as an answerable question. The service team can establish whether a restricted assistant reduces total handling effort for delivery enquiries. It cannot meaningfully complete an instruction to overcome resistance in general. A precise diagnosis gives the next investment a purpose and gives the organisation a way to know whether it worked.
