Why AI Adoption Fails at the Training Step

Most AI adoption programmes die in the room where everyone loved the demo. Someone shows the tool doing something genuinely impressive, the room nods, a few people ask sharp questions, and six weeks later usage numbers are flat. The tool didn’t fail. The plan around the tool did.

That pattern would matter less if the cost of getting it wrong were still measured in a wasted training day. It isn’t anymore. The pace at which models, copilots and agentic features are shipping right now means an organisation that stalls at the training step isn’t just losing a quarter — it’s rolling out version one of a tool against a workforce still not competent in it while version three is already live. Disruption doesn’t wait for the plateau to clear.

I watched an earlier version of this stall in 2001, teaching SAP BusinessObjects to rooms across Europe who had never touched a query builder. The demo part was easy. The hard part came after, when people went back to their desks and reached for the Excel export they already knew, because the new interface hadn’t yet earned the friction it cost them to use it correctly. Competence and excitement are not the same currency, and a demo only buys you the second one.

The Change Management & Adoption Enablement series names this precisely: a working pilot and an adopted pilot are two different projects, and most AI budgets are spent as if they weren’t (Playbook 1, The Adoption Gap). The distance between “that’s impressive” and “I use this every day” is a practice gap, not a knowledge gap. Nobody adopts a tool because they understood a slide about it. They adopt it because they were bad at it a few times, in a setting where being bad at it didn’t cost them anything, and then they got less bad.

Training programmes almost never build that setting on purpose. A facilitator runs a polished walkthrough, calls it enablement, and wonders why the room that applauded never opens the tool again on its own. The fix is to split training into two jobs: role-based training mapped to the actual task a specific person already does (Playbook 3, Role-Based Enablement), and a coaching layer afterward that closes the knowing-doing gap through repetition with feedback, not a second session (Playbook 4, Building Ability).

There’s a version of this failure I’m now seeing that’s specific to 2026, and it’s worse than the generic one. Some of the small businesses asking me about local AI, running an open-weight model on their own hardware instead of sending everything to a public chatbot, treat the deployment decision as the hard part and the training step as an afterthought, exactly the order I warned about with licences-first rollouts. But a local model isn’t a drop-in replacement for the ChatGPT tab someone already knows. It usually sits behind a narrower interface, built for a specific task like document classification or invoice extraction, and it offers none of the general-purpose comfort of a public chatbot. Ask someone to switch from a tool that answers anything to one that only does one thing well, without walking them through why, and you’ll watch them quietly reopen the free chatbot on their phone within a week, which is precisely the reversion the training step exists to prevent, except now it’s also a governance failure, because that phone isn’t covered by the data map you just spent a month building.

The local setups I’ve seen fail have almost always failed at this exact step, not at the hardware. The setup ran, the model classified documents correctly in testing, and then nobody owned the week where the invoicing clerk was slower and more frustrated than she’d been with the tool she was told to stop using. That’s the same six weeks I described above; it just now has a server in the back room instead of a training slide.

What separates organisations where this sticks isn’t better software or a longer rollout — it’s whether they let people fail on real work instead of a synthetic example, and whether someone is explicitly accountable for the weeks that follow. Adoption regresses within roughly ninety days without deliberate reinforcement, because old habits are the default gravity (Playbook 5, Reinforcement). Login counts in week two tell you nothing about week thirteen, and neither does a clean benchmark result from the vendor demo.

None of this is unique to AI, and it wasn’t unique to query builders in 2001 either. It’s the same mechanism I saw for a decade doing 1:1 coaching through people’s personal transitions: understanding a new way exists and adopting it are separated by a messy middle where you’re worse at the new thing than you were at the old one, publicly, for a while. Organisations are just as allergic to that middle as individuals are — and when the tool itself keeps changing underneath the training material, that middle keeps getting longer, not shorter, unless something is designed to hold people through it.

So the actual design question for an AI rollout, local or cloud, isn’t how to get people excited about it. It’s who owns the six weeks where people are visibly, uncomfortably bad at the new way, measured against something firmer than sentiment, like the Change Scorecard’s four numbers of usage, non-reversion, confidence and observed competence (Playbook 6). And it’s the same person who should be answering the question I now ask every owner considering local AI: who’s still maintaining this, and training people on it, in three years?