AI capability is built, not installed.

Most companies still roll out AI like software. Buy the licences, do a demo, tell people to use it, wait for productivity. A few enthusiasts take off. Most people stay passive. The token bill grows, and nothing in how the company works has changed.

That result is predictable. It is also avoidable, but only if you stop treating AI adoption as one thing.

Two tracks, two speeds

AI adoption happens on two tracks that move at very different speeds and need very different things.

The individual track is about how people work. From quick questions in a chat tool, to deep work with real documents, to AI connected to mail and calendar, to people in finance and operations building their own tools. This track can move fast. A capable operations person can go from the first level to the fourth in weeks. The barrier is culture and skill, and the cost is modest.

The organisational track is about how the company works with AI together. From teams sharing prompts, skills and templates in a common folder or Git repository, to small task agents, to a common AI infrastructure where systems, data and skills are connected, to autonomous agents, to agents built into what the company sells. This track is slow, because each level has prerequisites that compound: first culture, then infrastructure, then process and data, then the business model itself.

The tracks are not independent, and the dependency runs one way. The organisational track only starts once most people use AI for real work. People have to believe in the tool before they will share a way of working with it, let alone run a process through it. When the organisation gets ahead of its people, AI initiatives become theatre: pilots that look good in a steering group and get worked around on the floor.

The individual track: training, practice, support

People do not get value from AI because a tool exists. They get value from:

• Their own skills, built for specific use cases in their own work.
• Real tasks, not exercises, as the source of those skills.
• Room to experiment, without looking stupid.
• Help, when they get stuck.

Leadership’s job on this track is short:

• Clear data rules, on which data can go into which tools. Once people work with real documents, the question of what is allowed stops being theoretical.
• Budget and access, so everyone knows what cost is okay.
• Training, matched to where each person is, not one workshop for everyone.

Then ask whether it helps. Individual impact is hard to put one number on, so ask people directly, every quarter: how much does AI help you in your work, and what share of your work is AI-supported? High usage with low perceived help means the training is not landing on real work.

And expect the same habit problem as with any tool. I once rolled out a genuinely good tool with three trainings and a room that loved the demo. Three weeks later, nobody used it. Training is not adoption. People change when the old way of working stops being the easy one.

The organisational track: a shared way of working first

The first step is also one of the hardest: a shared way of working within the team. To get real value, a team has to use AI in a common way, with similar tools, shared skills and prompts, and the same workflows. Often none of that is there. People work in slightly different ways, and the skill that produces high quality for Peter produces poor quality for Sarah.

Level one is about building that common practice and vocabulary. It is the basis for teams getting shared value, and when a team writes down how it works with AI, it has started to define its process. Once that is in place, teams can start building small agents and scheduled workflows.

Real investment can be needed from level three, the common AI infrastructure: one governed environment where systems and data are connected and shared skills are live. How much depends mostly on how much governance you need. Some companies can use a cloud business plan with connectors and skills switched on. Others will need their own infrastructure.

Leadership’s job on this track is ownership and gates. One common environment with a named owner, where the AI policy is a setting, not a document. One named owner per process, who owns the data and the AI running in it too. Quality gates agreed before go-live: a test set of real cases, an acceptable error rate, and what happens when it is wrong. And impact measured against a baseline in cycle time, errors or cost per case, not counted in agents, prompts or users.

AI under the hood is not AI capability

Putting AI into a single process, such as suggested replies in the support tool or a classification step inside an integration, is not a step on either track. It can be a good efficiency case, but it is AI used under the hood of classical automation. The people around it do not work differently, the company’s data is not connected, and the next agent is no easier to build. It is installed, not built, and it is not AI capability.

What is your next step?

Unless your people already use AI deeply in their own work, invest there first. Your best operations person working at level four may deliver more value this year than a half-built organisational initiative.

You can start on the organisational track in parallel, but not as a standalone project. It only works on top of people who already use AI for real work, so let it follow them, not lead them.

Encourage experimentation, and be honest about where it leads. When someone builds something useful, it has to move to the organisational track: into company git, documented, understood by a second person, and tested again when the model underneath changes. Otherwise you have automated a key-person dependency. Prepare people for that move. They will give up some of their personal tweaks, so that everyone gets better.