The platform is provisioned. The policy is written. The use case is chosen and the training is booked.
Six months later the licences are eighty per cent assigned and twenty per cent used, and everyone in the steering group is asking why with a slightly tight expression.
Read almost any enterprise AI adoption framework and you will find the same four pillars: get the infrastructure and data ready, stand up governance and risk controls, select and prioritise use cases, then train people. That is sound work. Organisations that skip it end up with shadow tools, unmanaged risk and forty pilots that cannot talk to each other.
The argument here is about what happens once all four are in place. Because you have seen the specific version of this. The manager who attended the training, said it was interesting, and has not opened the tool since. The analyst who tried it once, got a wrong answer, and decided that settles it. The team where two people use it constantly and never mention it to the other nine. The pilot that worked in finance and will not travel to operations, and nobody can say why.
Every barrier left on that list is a people problem. Not some of them. All of them.
Why this layer goes missing
Enterprise frameworks are built by the functions that own the risk: technology, security, legal, central transformation. Those functions can control infrastructure, policy and procurement. They cannot control whether a category manager decides on a Tuesday morning that this is worth being briefly bad at in front of his own team.
So the person-level layer gets handled with the only two instruments a central function has, mandates and training, and both assume the barrier is not knowing how. Usually the barrier is not knowing how it will go for you.
There is a quieter reason too. Underneath most AI rollouts sits a question nobody puts on a slide: if the tool can do it, what am I still here for? Leaders rarely address it directly, because addressing it feels like conceding it. So it stays unspoken, and unspoken fears do not decay. They stop showing up as questions and start showing up as calendar conflicts.
The five steps
1. Diagnose which condition is missing before you design anything
Four questions, asked honestly, team by team.
Do people know what to do? Are they ready and equipped? Is the environment letting them act? Are their efforts being seen and supported?
Each one points at a different problem and a different fix. A clarity problem means the strategy has not been translated into what it looks like for a specific person in a specific role. A readiness problem means people understand the ask but do not yet have the confidence or the conviction, and pushing harder at this stage makes it worse. A conditions problem means motivated, capable people are working against unclear ownership, misaligned incentives, or a system that will not connect to the one beside it. A sustaining problem means people are trying and nobody has noticed.
Most rollouts treat all four as a training problem. That is why the training does not work.
2. Translate the strategy into a Tuesday
The mailroom team does not need a presentation on the AI strategy. They need to know what it looks like on a Tuesday morning in the mailroom.
Same for the accountant with the supplier invoices that land every Tuesday. She sat through the session, she might genuinely care, and none of it told her what to do with the pile on her desk. Good intentions without a clear next step decay fast, especially when the day job is waiting.
So go into the process. Understand how the work actually runs, and work out with the people in it what the new version of their week looks like. Hand them the first three steps, not the strategy.
3. Change the messenger before you change the message
When central IT explains why this matters, people hear: IT wants us to do more work. When someone with the same workload, the same clients and the same boss says it saved them a Thursday afternoon, people hear: someone like me figured this out.
The most useful messenger is not the most expert one. It is someone one step ahead, close enough that the distance still feels walkable, reaching back. Find the two people in each function already using it. Give them fifteen minutes in an existing team meeting rather than a special session, and ask them to show a real task, including where it did not work.
Before you write another message, ask the harder question: am I actually the right person to have this conversation?
4. Pay for practice before you ask for performance
Ask someone to use an unfamiliar tool on live client work and you have asked them to gamble their competence in public. Most people decline quietly, and it gets recorded as resistance.
Give them a task where being bad at it costs nothing and the calculation changes. Say out loud that early outputs will be mediocre, that mediocre is expected, and that nothing produced in the practice period goes near a customer.
Then check confidence rather than intention. Ask: on a scale of one to ten, how confident are you that you could use this for your report next week? If they say four, ask why not two. They will tell you what is already working. Then ask what would make it a seven. They will tell you the actual barrier, usually in one sentence, and it is rarely the one on your risk register.
Someone who says the change matters and rates their confidence at three will not move. Someone at seven usually will.
5. Make the effort visible, then keep removing barriers
Adoption dies in week three, when the first real friction arrives and nobody is watching any more.
Build the loop that catches it. A standing place to bring what went wrong, treated as a problem to solve rather than a failure to report. Then go department by department and ask what specifically is getting in the way. The answer is almost always small and removable: an approval nobody knows how to get, a step that adds friction, a system that does not connect.
And shift recognition from who committed to who did the hard thing. Recognition is not a certificate. It is naming what someone did, specifically, in front of people whose opinion they care about.
Then run the four questions again. People move backwards, and a framework that only runs once is a launch, not an adoption strategy.
AI readiness, enablement and upskilling: the people half of each
The vocabulary around this work keeps multiplying, so it is worth saying where the human layer sits in each term.
An AI readiness assessment usually counts infrastructure, data quality, security posture and skills inventories. All of it matters, and none of it predicts whether the category manager will change how she works in March. The people half of readiness is the diagnosis in step one, and it takes a week of honest conversations.
AI enablement, done well, is not a launch. It is step five running as a standing function: somewhere to bring what went wrong, and someone noticing who is actually trying.
AI upskilling teaches people how to use the tool. Necessary, and not the bottleneck. Most of the people who quietly stopped using AI did not stop because they lacked a skill. They stopped because the first real friction arrived and nothing caught them.
If you are writing an AI rollout plan this quarter, the test is simple: count how many of its pages are about the system, and how many are about the people who have to change how they work. The ratio usually explains the last rollout too.
What this layer gives you
Training tells people how. This tells you who is where, who they will believe, what it costs them to try, how confident they actually are, and what happens the first time it goes wrong.
Infrastructure decides whether the tool can be used. People decide whether it is.
One question to sit with
Think about the team where AI in the workplace has landed flattest.
Which of the four conditions is actually missing there? And who in that team is already one step ahead, waiting to be asked?