In brief. If an AI pilot has stalled, the model is almost never the reason. Adoption fails where the operating model stayed still, in what people can actually do, in who is allowed to change the work, and in what the organisation genuinely rewards. The audit that unsticks a pilot looks at the operating model, not the tool.

This is not a hunch, it is the shape of the failure data. When researchers study the work rather than the tooling, human and organisational factors edominate the reasons AI initiatives stall, and technical limitations sit well down the list. That pattern holds across separate bodies of evidence, and it points somewhere other than the model.

Here is the part that should trouble any leader who has funded one of these. The pilot worked, the demo landed, the model did what it was asked, and the business case read well on the day. Three months later the usage curve is flat. The view that says "the pilot succeeded, so we are nearly finished" has no account of that flat line, because the flat line did not come from the technology.

Leaders debug the tool because that is where the money and the visible artefacts are, and that is exactly why the diagnosis goes wrong.

The research is blunt about the split, and Prosci's analysis attributes 62% of implementation difficulties to human factors against 16% for technical challenges. Its wider study of 1,107 professionals puts the figure at 63%, with user proficiency alone accounting for the single largest share. The summary from that work is worth keeping on a wall, the technology works, and the real challenge is that employees are not using it, or not using it well.

The market data tells the same story from the outside. Enterprise AI is still, in the main, experimentation rather than deployment. When Accenture reported three hundred generative-AI projects for three hundred million dollars, the arithmetic gave away the mix, a great many pilots and very little production. Around 30% of large-company chief information officers, in a survey taken as this wave began, did not expect to deploy anything before 2026. The spending is real, the demos are real, and very little of it has crossed into the daily workflow.

So the costume is convincing for an honest reason. The budget line, the dashboard, the model comparison and the vendor shortlist all sit on the technology side of the ledger, so when something goes quiet, attention travels to the place with the most moving parts, and the organisation starts adjusting the one component that was probably fine.

Every system before this one asked people to conform to the tool, and AI asks them to decide where it fits, which is a redesign of the work, not a slot on the training calendar.

This is the difference that catches experienced change teams out. A traditional rollout has a defined endpoint, you move people onto the new system and the project closes. AI inverts that relationship, because it hands each person an open-ended capability and asks them to work out, in their own judgement, where it belongs. The most common place adoption fails is the gap between knowing and doing, what Prosci frames as the distance from Knowledge to Ability. A completed training module records that someone received information, it says nothing about whether they can apply it under real conditions, in the workflow that actually matters.

There is a structural reason this is hard, and it has little to do with willingness. Organisations are far messier than their process maps suggest, and Ethan Mollick reaches for an old idea from organisational theory, the garbage-can view, in which real decisions run on unwritten rules and negotiated, undocumented practice rather than on the tidy diagram. Automation has always needed the clear rules and defined processes that these organisations quietly lack, which is why scaling AI across a company is harder than a successful pilot makes it look. Meanwhile a large share of workers, more than four in ten by one measure, already use AI informally to solve their own problems, in ways the organisation cannot see and has never codified.

The corrective from the research is consistent. Do not plug AI into the existing workflow and expect the workflow to carry it. Redesign the roles so the machine takes the repetitive, data-heavy load and people move up into the judgement, and let that redesign, rather than the tool itself, be the thing you deploy. End-to-end redesign of the work drives real engagement in a way that dropping a tool onto an unchanged process never does.

A pilot only becomes real when the incentives and capabilities change with it, and if the management system still rewards the old behaviour, you have espoused change, not adoption.

Roger Martin makes this point about strategy in general and it lands squarely here. A new choice is only real if the management systems and the capabilities move with it, and if they are left untouched the change is merely espoused, a statement of intent the organisation never actually adopted. His illustration is useful because it is not about technology at all. Sears identified e-commerce correctly and early, yet its profit-and-loss structure and its incentive plans were still built around individual physical stores, so a store manager who helped a customer buy online was, in effect, penalised by the very system meant to be driving the new strategy. Management systems, he argues, are the nervous system of a strategy, and a nervous system that still fires for the old behaviour will win.

The same mechanism appears in the behavioural research on adoption. Once the tool works, the barriers that remain are largely about control and ownership, where concerns about control accounted for a substantial part of the decision to adopt at all, and giving people a genuine sense of ownership raised adoption markedly. Neither of those levers sits inside the model, both sit inside the operating model.

The default corporate response makes matters worse. Faced with a new technology, organisations reach for the familiar playbook, they centralise it, monitor it and restrict it. With AI that instinct backfires, because the sanctioned, watched, locked-down version is often visibly worse than what people already carry on their own phones, so real usage goes quiet, the most capable people stop talking about how they actually work, and the organisation loses the one source of knowledge that could have told it where AI genuinely helps.

There is a single question that separates the two kinds of problem, and it is worth making a habit. When a pilot stalls, ask honestly, if a perfect model landed tomorrow, would adoption follow? If the answer is no, the problem was never the technology.

When the costume comes off, the real problem is almost always at one of three seams.

A stalled pilot usually has at least one of these split wide open, and no amount of model tuning will close it.

The organisations that get this right treat adoption as a redesign rather than a deployment. One large professional-services firm built its programme around practice and peer coaching rather than a tool launch, with experienced users embedded to help colleagues find genuine uses. Others went structural, where one merged its technology and human-resources functions so work could be redesigned by the people who owned both halves of it, and another deliberately simplified a process before letting any AI near it. The common thread is not the software they chose, it is that each of them changed the operating model around the software.

Sometimes it really is the technology, and the discipline cuts both ways. If the honest answer to the counterfactual is "yes, a better model would fix this", then treat it as a capability problem and do not over-rotate on change work. Some tasks are still beyond the current models. Some pilots are blocked by data access or integration rather than behaviour. Some sit in regulated ground where the constraint is legal, and the right first call is a lawyer, not a workshop. The test earns its keep precisely because it sends you to the change work only when the change work is the thing that is broken.

This is a choice between a tactical fix and a structural one, and the stalled pilot in front of you already says which it needs. Take your most stuck initiative and run the counterfactual this week, and if a better model would not move it, stop the model comparison. Put the person who owns the process, the manager who sets the incentives, and the people who do the work in one room, and redesign the work around the capability you already have. That meeting, not the next model, is what moves the number.

If a better model tomorrow would not move your adoption, you do not have a technology problem. You have an operating-model problem wearing a technology costume.

P.S. Before a pilot goes anywhere near production, it is worth running the same three seams as a checklist, proficiency, authority and incentive, and being honest about which are actually ready. We have codified the pre-production readiness scorecard we use for exactly that, for readers who would rather start from the finished version than build their own from scratch.