The Last Mile of AI Adoption
Resistance is often the organisation's roughest available form of risk intelligence.
The machine works; the organisation hesitates
At 9.10 on a Monday morning, a service operations team watches an AI assistant process a sample of routine customer cases. It retrieves the relevant policy, drafts a response and proposes the next action in seconds. The demonstration is not theatrical. The answers are mostly sound, the interface is familiar, and the improvement is visible.
By Thursday, the proposal to extend it has acquired six conditions: legal wants a clearer record of how recommendations were produced; operations wants an exception route; information security wants the retrieval boundary tested; finance wants the benefit case separated from vendor estimates; the workforce forum wants to understand how roles will change; and the service director will not accept accountability for decisions she cannot reliably inspect.
The usual diagnosis is resistance. It is also lazy.
In the present wave of enterprise AI, the last mile is often described as a failure of appetite: leaders have not moved quickly enough, employees do not trust the tools, and governance has become a brake. Yet the pattern that recurs is more interesting. Organisations are not resisting intelligence in the abstract. They are resisting an incomplete transfer of judgement into operating systems whose errors, ownership and economics remain only partly visible.
That resistance is not always wise. It can protect status, postpone difficult choices and turn legitimate assurance into endless review. But it is usually rational before it becomes obstructive. It is the organisation asking questions that a successful pilot was never designed to answer.
The pilot and the enterprise are testing different propositions
A pilot asks whether a model can perform a bounded task under favourable conditions. An enterprise has to ask whether a changed system of work can perform repeatedly when demand varies, data is imperfect, policies conflict and someone must answer for the consequences.
These are not larger and smaller versions of the same test. They are different tests.
The pilot isolates capability. The enterprise inherits interdependence. A drafting assistant may produce a good response, but the operating question is whether the response remains good when the source document is outdated, the customer belongs to a protected category, the case falls between two policies, or the recommended action creates a financial commitment. Accuracy averaged across a test set does not settle any of those questions.
| Pilot question | Enterprise question | The hidden gap |
|---|---|---|
| Can the model do the task? | Can the service absorb the model’s failures? | Exception design |
| Is the answer usually good? | Which errors are tolerable, and who decides? | Risk appetite |
| Is the user faster? | Does total work fall after checking and rework? | End-to-end economics |
| Can the model retrieve the policy? | Who owns currency, access and provenance? | Information stewardship |
| Will people use it? | How do roles, measures and authority change? | Operating-model redesign |
The distinction matters because organisations frequently advertise the first answer as evidence for the second. When the receiving function objects, it appears conservative. In reality, it has been handed a capability result and asked to accept an operating liability.
Resistance is often the organisation’s roughest available form of risk intelligence.
That intelligence arrives in untidy language. A supervisor says the tool “does not understand the difficult cases”. A compliance officer requests another control. An experienced handler quietly continues to use the old process. Each response can look like reluctance. Underneath it may sit a precise but unarticulated concern: the proposed design has no stable place for contextual judgement, no named owner for the knowledge base, or no credible way to distinguish assistance from decision.
The work was never as standard as the process map claimed
AI programmes are exposing an old fiction. Many enterprise processes appear standard only because experienced people continually repair them.
The documented process shows a sequence of boxes. The actual work contains pauses, phone calls, remembered precedents, informal escalation and tacit distinctions between cases that look identical in the system. These acts are rarely celebrated as productivity. They are the connective tissue that keeps the service reliable.
Consider a composite claims operation handling 1,200 cases a week. A controlled trial uses an AI assistant to summarise documents and draft disposition notes. On the central 70 per cent of cases, average preparation time falls from eleven minutes to six. The headline is compelling: five minutes saved, roughly seventy hours a week.
The trouble sits in the remaining cases. About one case in twenty contains conflicting evidence, a vulnerable claimant, an unusual policy endorsement or correspondence that changes the interpretation of the file. Before the trial, senior handlers spotted these cases early and moved them into a different rhythm. During the trial, the draft looked polished enough that less experienced handlers spent longer establishing whether the exception mattered. Review time on that small category rose from eighteen minutes to thirty-one, and two near-misses revealed that escalation criteria were understood socially rather than encoded anywhere.
The trial did not show that the technology had failed. Nor did it prove that the workforce was resistant. It revealed where the organisation had been relying on invisible expertise.
That is the practical significance of the last mile. Adoption is not the act of placing a model beside a process. It is the act of deciding which parts of judgement should be expressed in data, which should remain human, and how the boundary will be maintained as policies, models and people change.
The nearer AI moves to consequential work, the less adoption resembles software deployment and the more it resembles a renegotiation of authority.
Resistance has several motives, and management confuses them at its peril
Not all hesitation deserves the same response. A single change campaign will fail because the apparent resistance contains different bargains.
- Epistemic resistance: people do not know when the system is reliable. A confident answer and an uncertain answer may look alike, while the grounds for the recommendation are difficult to inspect.
- Professional resistance: the tool changes what counts as expertise. A role built around producing an answer may become responsible for validating one, but validation can be both harder and less visible.
- Moral resistance: employees are asked to act on recommendations while remaining personally answerable for outcomes. “Human in the loop” offers little reassurance if the human lacks time, information or genuine authority to disagree.
- Economic resistance: local users see the checking, exception handling and service disruption that a central business case discounts. Their caution may be a response to costs displaced into their function.
- Political resistance: AI redistributes discretion. It can move influence from professional communities to process owners, from front-line judgement to central standards, or from internal teams to external providers.
These motives overlap, but they do not yield to the same intervention. Training may reduce epistemic uncertainty; it will not resolve accountability without authority. Better communication may explain the economic case; it will not make a poor exception process workable. Executive sponsorship may force use; it cannot make tacit knowledge explicit by declaration.
The most damaging response is to treat every objection as a deficit of understanding. That posture makes adoption adversarial. People learn that the safe language is not “the design is incomplete” but “I need more confidence”. Leaders then supply confidence-building sessions while the operating issue remains untouched.
The strongest case for moving faster
There is a serious opposing view. Enterprise caution can become self-justifying. Demands for perfect explainability, complete data and fully settled regulation can defer action indefinitely. Models and provider capabilities are changing quickly; learning comes from use, not committee debate. Competitors that tolerate manageable uncertainty may improve their processes while cautious organisations continue to study theirs.
This argument is right about three things.
First, no design can remove uncertainty. Second, organisations often demand a standard of proof from AI that they never required from manual work. Human decisions are inconsistent, poorly documented and shaped by fatigue; the current state must not be romanticised. Third, some governance activity is theatre: controls are added because they are legible to committees, not because they materially reduce risk.
But speed and seriousness are not opposites. The choice is not between reckless scale and frozen scrutiny. It is between learning architectures that expose operating truth and demonstrations that conceal it.
A faster path is possible when uncertainty is bounded deliberately. Start with a narrow decision right, known sources, explicit exclusions, sampled review and a named stop condition. Measure total case effort rather than model response time. Publish the exceptions, not only the average. Give a service owner authority to change the workflow when evidence changes. This does not wait for certainty; it creates a disciplined way to learn without pretending that a successful output is a successful operating model.
The strongest organisations are therefore not those with the fewest objections. They are those that can convert objections into testable design questions.
The adoption contract
The final mile becomes tractable when the organisation makes an explicit contract among the people funding the change, running the service, assuring the risk and doing the work. The contract need not be a new bureaucracy. It is a set of decisions that are too often left implicit.
- Name the unit of adoption. Do not adopt “AI”. Adopt a defined change to a workflow: for example, machine-drafted case summaries reviewed by accredited handlers before disposition. The narrower sentence reveals ownership and limits.
- Separate recommendation from authority. State what the system may propose, what it may execute, and what always requires human judgement. If the human may override, record whether that discretion is real or merely ceremonial.
- Design the exception before the average. Identify the conditions that route work away from the standard path, who receives it, and the capacity required. A system that is efficient only when nothing unusual happens is not an enterprise system.
- Make assurance operational. Define the evidence that will be reviewed, the frequency of sampling, the thresholds that trigger intervention and the person authorised to pause or narrow use.
- Recalculate value at the service boundary. Include checking, rework, knowledge maintenance, incident handling and displaced demand. A five-minute task saving is irrelevant if it creates seven minutes elsewhere.
- Offer a fair role bargain. Say which activities diminish, which responsibilities grow, how performance measures will change, and how people will acquire the judgement required for the new role.
This contract changes the emotional character of adoption because it changes the material one. Trust is no longer requested as an attitude. It is supported by boundaries, evidence and recourse.
What the last mile is really measuring
The current enthusiasm for copilots and increasingly agentic systems tempts us to interpret adoption as a race between technological capability and organisational inertia. That picture flatters both sides. Technologists become the impatient future; the enterprise becomes the stubborn past.
A more honest reading is that AI has arrived at the boundary between formal process and lived judgement. It is making organisations confront how little of their real operating model has ever been written down. Policies exist, but precedence does not. Accountability exists, but decision rights blur. Data exists, but ownership of meaning remains distributed. Roles exist, but much of their value lies in exceptions that productivity measures ignore.
This is why the last mile feels disproportionately difficult. It contains work postponed by earlier transformations: cleaning information, clarifying authority, redesigning measures, surfacing tacit expertise and deciding which risks the organisation is actually prepared to take.
There is a temptation to view these tasks as friction around the technology. They are the transformation.
The enterprises that progress will not eliminate rational resistance. They will become better at listening to what it contains, distinguishing protectionism from operating knowledge, and turning concern into an explicit experiment or design choice. They will also know when to stop listening: once an objection has been translated into a test, evidence must be allowed to decide.
AI adoption will remain uneven because the work itself is uneven. Some tasks are stable, observable and reversible; others are ambiguous, consequential and dependent on context. Mature adoption respects that difference. It moves quickly where the cost of error is bounded and deliberately where responsibility cannot be automated away.
The last mile is not crossed when people finally agree that the machine is impressive. It is crossed when the organisation can say, without evasion, how machine capability and human accountability now fit together.