They Loved the Demo. They Went Back to the Spreadsheet.

The failure I see most often does not look like a failure at all, which is why it goes unnoticed for months.

The system got built. It works. It does what the specification said, and the demo went well enough that people said nice things in the meeting. Training happened. Everyone nodded. For about two weeks usage looks fine.

Then it drifts. Someone finds a case the system handles awkwardly and does that one by hand. The old spreadsheet, which was never deleted, gets opened for that exception. Then for a second kind of exception. Within six weeks the spreadsheet is running the department again and the new system is a tab nobody opens, and here is the part that should worry you most: nobody will tell you. There is no incident, no complaint, no meeting. It just quietly reverts, and you find out a year later when you ask what happened to the thing you paid for.

This is not a technology failure. The technology is sitting there working perfectly, waiting. It is a failure of adoption, and it is the most common way money gets wasted on AI. It is also, unlike most of the failure modes in this field, extremely well documented.

Nobody had time to change

Start with the least dramatic reason, because it is the biggest one, and it is nobody’s fault.

KPMG surveyed 2,239 Canadian employees in 2025 and found something worth reading twice. Thirty-six percent had received AI training and then never started using the tools. Another thirty-seven percent started after training and then stopped. In both cases the reason given was the same: too busy, too overwhelmed to change their work processes.

Sit with that for a moment. Nearly three quarters of trained employees either never began or began and quit, and the reason was not that the tool was bad, or that they were resistant, or that they did not understand. It was that changing how you do something takes slack, and there wasn’t any.

This is the thing that gets missed when a rollout is planned. Learning a new process is slower than the old process for a while. That temporary slowdown lands on people who are already at capacity, which means the new way is punished exactly when it is hardest, and the old way is right there, and it works. Anyone would revert. You would revert.

The same research found that only 48% of Canadian employees thought their employer’s AI training was actually helpful, while 83% said they wanted to learn to use the tools better. The appetite is there. The training and the room to use it are not.

It made more work, not less

The second reason is more uncomfortable, because it means the tool did the opposite of what it promised.

A study by Upwork and Workplace Intelligence, surveying 2,500 people across four countries including Canada, found that 77% of employees using AI said the tools had added to their workload rather than reduced it. Where did the time go? Reviewing and correcting AI output, learning the tools, and being handed more work because AI was supposed to make them faster. In the same study, nearly all senior leaders expected productivity gains.

That gap between the floor and the executive suite is the whole story. From above, the tool is a multiplier. From the desk, it is a new thing to check, on top of everything else, with the expectation of more output attached.

This is what happens when the system is added beside the work instead of built into it. The work does not shrink. It gains a step.

Using it made them look bad

The third reason is the one that surprised me most, and it explains a great deal of behaviour that otherwise looks irrational.

Slack’s Workforce Index surveyed more than 17,000 desk workers and asked why they hide their AI use. Nearly half said they would be uncomfortable telling their manager they had used AI for a common task. The reasons were that it feels like cheating, that they would be seen as less competent, and that they would be seen as lazy. Company policy was the least cited reason.

So the barrier is shame, not rules. In an office where the culture quietly treats using the tool as a shortcut, adoption does not fail loudly, it fails silently, because the sensible move for any individual is to keep their head down. And notice that this is the identical mechanism that produces staff using unapproved AI tools on the quiet. The same social pressure that stops people using your sanctioned system is what drives them to use an unsanctioned one privately. You get the worst of both: no adoption of the thing you paid for, and no visibility into the thing they actually use.

One mistake and it’s dead

The fourth reason has a name in the research literature, and it long predates AI.

Psychologists call it algorithm aversion. In a well-known set of experiments published by Dietvorst, Simmons and Massey, people who saw an algorithm make a mistake abandoned it much faster than they abandoned a human who made the same mistake, even when they had already seen the algorithm outperform the human overall. We forgive people for being wrong. We do not extend that to machines.

Every operator has watched this happen. The system misclassifies one invoice in a way that looks stupid, somebody says “see, it doesn’t work,” and that sentence does more damage than the error ever could. The tool is now on probation permanently, and any future mistake confirms the verdict.

The practical consequence is that the first two weeks matter far more than they should. A system that is right 92% of the time but conspicuously wrong on day three may never recover, while the same system that gets an easy win in front of people early will survive the same error later. That is not rational and it is entirely human, and it should shape how you sequence a rollout: put the reliable, visible, low-stakes wins first.

And the ones who trust it too much

The mirror problem is rarer but more expensive, and it deserves saying because the fix for one can worsen the other.

The Melbourne and KPMG study of 48,340 people across 47 countries found that 66% rely on AI output without evaluating its accuracy, and 56% report having made mistakes in their work because of AI.

So the population splits. Some people do not trust the tool and quietly stop using it, which wastes the licence. Others trust it completely, stop checking, and let errors through, which is worse than wasting the licence. Both are failures of calibration, and you cannot fix either with a memo saying “use good judgment.”

The only durable answer is to stop making trust the variable that decides whether output is correct. Build the checking step into the workflow itself so that verification happens because the process requires it, not because someone felt suspicious that morning. That also means it survives staff turnover, which a culture of vigilance does not.

What the successful ones did differently

The pattern is consistent enough across the research to state plainly: the organisations that get value redesigned the work; the ones that did not, bolted the tool on beside it.

McKinsey’s ongoing survey work finds that fundamental workflow redesign is the organisational change most strongly correlated with financial impact from generative AI, while roughly four in five users have simply layered AI on top of existing processes. That is correlational, self-reported, and published by a firm that sells workflow redesign, so hold it loosely. But it lines up with everything above. A tool that lives in its own tab requires a person to remember it, decide to use it, and switch context. A tool built into the screen they already have open requires nothing.

Then there are the smaller things, which matter more than they sound.

Put it in the path. Inside the existing tool, at the moment the work happens. If the system requires a detour, the detour is where adoption dies.

Give people the time to be slow. Budget for a temporary productivity dip, say so out loud, and do not raise output expectations in the same quarter. The 37% who stopped were not defeated by the software. They were defeated by their own calendar.

Make it safe to use, and safe to criticise. Say plainly that using the tool is expected and not cheating. Then ask, repeatedly, what it is getting wrong, and be visibly pleased when someone tells you.

Log the overrides. When someone does something other than what the system suggested, capture it. This is the cheapest diagnostic you will ever have, and it converts silent abandonment into information you can act on. A cluster of overrides on one case type is a specification you did not write.

Name who owns the exceptions. Every system leaves a residue it cannot handle. If nobody owns that residue, the residue becomes a spreadsheet, and the spreadsheet becomes the process again.

How to tell whether it actually took

Login counts will lie to you. People log in.

Three better signals. Compare against the baseline you wrote down before launch, which is the whole reason that baseline has to exist; if you skipped it, you now have an argument instead of an answer. Watch the override rate and whether it is falling. And go and look for the shadow spreadsheet, because if the old process is still running in parallel after six weeks, the new one has not been adopted, whatever the dashboard says.

That last one is not a modern phenomenon. Information systems researchers have been documenting it since the enterprise software rollouts of the 1990s, under names like workarounds and shadow systems: when a new system is harder, slower, or missing something, people keep the old one alive beside it. It is not sabotage. It is competent people making sure the work still gets done. It is also the clearest possible signal that the system does not yet fit the job.

The part worth carrying out the door

The failure mode is not that the software broke. It is that the software worked and the humans went around it, for reasons that were entirely reasonable from where they were standing: no time to change, more work than before, a social cost to being seen using it, and one early mistake that settled the matter.

None of those are fixed by a better model. All of them are decided before the build, in choices about where the thing sits, how much room people get, who owns the hard cases, and whether it is safe to admit the tool is imperfect.

A system nobody uses is not a cheaper failure than a system that does not work. It is a more expensive one, because you paid the full price and got a spreadsheet.