Here's a pattern I've watched play out for over a decade, first with training, then with software, and now with AI.
An organisation identifies a real problem. Leadership commits real money. A capable team selects a genuinely good tool. It launches with an announcement, a training session and high expectations. Six months later, usage has collapsed to a handful of enthusiasts, the steering committee is discussing "change fatigue," and the project is quietly reclassified from transformation to learning experience.
The post-mortem will blame the model, the vendor, the data or the culture. It's almost never any of those. The project failed in the first meeting, when everyone in the room made the same silent assumption:
If we give people access to the capability, they will use it.
Access is not adoption. It never has been. Every organisation already has proof of this sitting in its own systems: the training library nobody finishes, the CRM fields nobody fills, the intranet nobody reads. AI doesn't change that dynamic. In one important way, it makes it worse.
The blank box problem
Most enterprise AI deployments hand people a chat interface, a blank box that can do almost anything, which is precisely the problem. A blank box transfers the hardest part of the job to the user: knowing what to ask, when to ask it, and what good looks like. The people who thrive with it are the ones who were already your most capable operators. The people who needed help most stare at the cursor, try two prompts that produce mediocre results, and conclude the tool isn't for them.
That's not a training deficiency. It's a design decision. A system that waits to be asked has quietly selected for the users who least need it.
The alternative is a system that steers: one that lives inside the actual workflow, understands the context, and proposes the next action instead of waiting for a question. The difference sounds subtle. In adoption terms it's the whole game, because most people don't need an oracle. They need to know what to do next, today, with the situation in front of them.
Three questions that predict the outcome
You can forecast an AI initiative's fate before a dollar is spent by asking three questions about its design, none of which are about technology:
- Whose behaviour changes, and what exactly do they do differently on a Tuesday? If the answer describes a capability ("they'll be able to...") rather than a behaviour ("they will..."), the project is a library, not a system.
- Where does the system live? If using it requires leaving the place where the work happens, every use is a decision, and decisions decay. Systems that sit inside the workflow get used; destinations get visited, then abandoned.
- How does it learn after launch? Launch is the midpoint of an AI project, not the end. If there's no designed loop, feedback captured, outcomes tracked, behaviour shaping the next release, the system is at its best on day one and decays from there.
Governance deserves an honourable mention as the fourth question, because it's usually approached backwards: as a review gate bolted on after the build. Applied that way, it slows everything and protects little. Designed in from the start, the organisation's standards applied at the point where content and decisions are generated, governance stops being the brake and becomes part of the business case. In regulated environments, it often is the business case.
Architecture before intelligence
There's a sequencing error underneath most failed AI projects: reaching for intelligence before fixing the journey it's supposed to amplify. AI is an amplifier. Point it at a well-designed workflow and it compounds the value. Point it at a broken journey and you get the same confusion, delivered faster and more fluently.
The unglamorous work comes first: understanding intent, sequencing the journey, defining the next action at every stage, deciding what signals matter and where a human belongs in the loop. Do that, and the AI layer has clean decision points to operate on. Skip it, and no model, however capable, can compensate, because the model isn't the system. The behaviour is the system.
AI isn't something you train people on. It's something you deploy into the way they already work.
What this means for your next initiative
Start with a behaviour, not a use case list. Pick one job, one moment, one action you want to be different, and design the system backwards from it. Put the system where the work already happens. Make the first experience a steer, not a blank box. Build the feedback loop into the architecture before launch, because you won't retrofit it after. And treat governance as a design input, applied where output is generated.
None of this is as exciting as a model announcement. All of it is the difference between an AI project that changes how an organisation executes and one that becomes next year's cautionary slide. The technology has been ready for a while now. The projects that fail don't fail on capability. They fail on the first assumption, and the good news is that assumption is entirely within your control.