AI adoption is decided in the middle

The first weeks after a go-live nearly always look good. A handful of people use the tool every day, send in improvements and mention in the team meeting what it saves them. Look at who uses it and you mostly see that handful. The rest of the department still works the way it did last month.

My claim: employee AI adoption is decided by the middle group, the sixty to seventy percent who think it’s fine but won’t start on their own. The accelerators use the tool anyway, and the holdouts only move once they see proof. A tool that only the accelerators use never pays for itself.

Why don’t employees use an AI tool?

Usually because nobody showed them what the tool does for their own tasks. Unwillingness is rarely the reason. The middle group is willing enough, but won’t work out on their own how a new system fits into a full week.

The standard plan makes this worse. “We build the tool, then we run a training, then people will use it.” In that order, the users only get a say once every decision has been made. People who helped frame the problem use the solution sooner, and their input makes the tool better too. So adoption starts at problem analysis, months before the training.

A second reason is uncertainty about what is allowed. While legal and IT spend months on an AI policy, some employees use personal ChatGPT for work documents, and the most careful people wait for permission. A one-page policy on day one solves more than a legally watertight document in month six.

Who decides whether AI adoption succeeds in an organisation?

The middle group, because it is the largest. In every organisation I see three groups. The accelerators experiment on day one. The holdouts, fifteen to twenty percent, are sceptical or too busy and only move on proof. In between sits the majority, who join in once it feels easy and safe.

The mistake I saw most often: all the attention goes to the accelerators. They are enthusiastic, show up to the sessions and give feedback, so it feels like progress. But they don’t bring the middle group along by themselves. What is obvious to an accelerator, a colleague in the middle group needs to see working on their own work at least once.

For the business case this matters a lot. In an NBER study of roughly 5,000 customer support agents, an AI assistant made people 14% more productive on average. The least experienced gained 35%, the top performers close to nothing. So the gain sits with the people who still have the most to learn, spread across the whole team. If you count on that gain, you need broad adoption.

National figures show the same gap between using AI and getting something out of it. According to Sharp (December 2025), 74.4% of Dutch SMEs have integrated AI into their operations. In BCG’s 2024 survey of 1,000 executives, 26% of companies could show tangible value from AI. These are different studies of different groups, so you cannot subtract one number from the other. They do show that “we use AI” measures something different from “it pays off”. Both sources are on my AI statistics page.

Is AI training enough to bring employees along?

No, not if the training is the end point. Training after delivery comes too late: the decisions about the problem have already been made, without the people who do the work. That is why I don’t sell standalone training as the end product.

What works looks more like coaching than a class. In the hands-on sessions I run, people use AI for their own tasks and learn when to check an output before building on it. That second part carries a lot of weight. People remember the one mistake longer than the 99 good answers, and a tool they distrust, they work around.

Support from a manager belongs here too, and it shows up as time: time to practise, ask questions and help decide. An email saying everyone should start using the tool does not count as support.

How do you bring employees along with AI after go-live?

Spend the first four weeks on the middle group, with examples from their own work and colleagues who guide them. This is the order I follow:

1. Two champions. A champion is an employee, not the IT manager or the director, who sees what the tool means for their own work. Find the first one in week one of the project and give them access, time and a say. If only one person understands the tool, maintenance becomes fragile, so make sure there are two by week four.
2. A one-page policy on day one. Which data may go in, which may not, and who to ask about a borderline case.
3. Examples from the middle group’s work. Pick a few tasks they do every week and show what the tool does with them. The builder’s demo convinces the accelerators, and you already have those.
4. Colleagues guide colleagues. Give the accelerators a different role: each one guides a colleague from the middle group through their first real tasks.
5. Discuss where the tool helps and where it doesn’t. Let the tool show its sources and say what it doesn’t know. Talk through the first mistake as a team, with an explanation, before it travels around without one.
6. Time in the calendar. The manager makes room to practise during working hours, also after the first week.
7. After four weeks, measure who still uses the tool outside the accelerators. The total number of users tells you little. If it is still mostly the first group, don’t build new features; go back to step 3.

What should you ask an agency that implements AI?

Ask what happens in week one with the people who will use the tool, and what the plan is for the sixty percent who won’t start on their own. If the answer is “a training after delivery”, adoption is not part of the project. That question is one of ten in my memo on 35+ AI implementations. How to judge the rest of an agency is in my buyer guide.

A tool is done once the middle group uses it without someone sitting next to them. Until then the implementation is still running, even if the software has been live for months.