AI adoption takes more than a service subscription: organizations have to learn 🪣

TL;DR: buying an AI service subscription does not mean that a company has adopted AI. Value appears when people learn to use it inside their work, have a reason to do so, and receive the time and mandate to change the process.

A subscription is not transformation 🧾

Picture a fairly common scene. A company adds AI to its quarterly plan, assigns a budget, and organizes a demonstration session. Then come a few activated accounts and a dashboard showing the number of logins.

After a few weeks, AI is confined to a few individual micro-tasks. The core activities of marketing, finance, or customer support remain exactly the same. Leadership concludes that people have not understood the potential yet. People conclude that the latest corporate tool has little to do with their actual work.

The budget was spent. The way of working stayed the same.

I am borrowing the leaky bucket metaphor from a conversation about this topic: you can pour in more subscriptions, workshops, and enthusiastic announcements, but the investment keeps draining away if there is no path connecting technology to real activities.

AI does not enter a company when the subscription arrives. It enters when it changes the work a person knows how to do, wants to do, and is allowed to redesign.

The problem is not just learning an interface. It is learning to see work as something that can be observed, broken down, and improved.

Real work has no demo 🫧

People who use AI every day tend to overestimate the speed of adoption. When a tool has become part of your daily work, it seems natural that it could become part of everyone else’s work too.

Most people, however, are not waiting for another technology lab. They are dealing with deadlines, customers, procedures, and existing responsibilities. That is not a moral failure: it is the context in which every new habit must prove that it deserves space.

That is why the question what are the AI use cases? often starts in the wrong place. Use cases are not cards to hand out to every department. They are answers to problems someone already experiences, with a recognizable cost and owner.

Useful training starts with the flow: where do we wait, repeat, or correct more than necessary? Then it looks for where AI can help, where it must not intervene, and what controls are needed. The goal is not to convince someone that AI is interesting. It is to show an improvement they recognize as their own.

From tool to work 🔧

A company used to training people on a new CRM will naturally ask for a course on the new AI assistant. It is an understandable request: the product changed, so teach the product.

With AI, that model breaks. The tool is not confined to one department or one procedure. It can change how people analyze a document, prepare a decision, answer a customer, or build a plan.

Training should therefore follow the work, not the application’s menu. For example:

• observe a week of repetitive, high-friction activities;
• choose one concrete task with a verifiable outcome;
• try AI inside that flow, keeping human control and appropriate data handling;
• compare the result with the previous way of working;
• decide whether the new method should be kept, corrected, or abandoned.

A concrete example: a software team can use AI to prepare a first map of an incident’s possible causes and gather signals scattered across logs and tickets. The demonstration takes minutes. Value appears only if the team verifies the hypotheses, updates the runbook, and reduces the time needed for the next incident.

A demo shows a possibility. Repeated work shows a capability.

Three steps, not a medal 🪜

Not everyone needs to become an agent inventor. But calling every use of a tool adoption makes it impossible to understand where the organization really stands.

A more useful path distinguishes three steps:

1. Access: I know the tool exists and recognize its main limitations;
2. Practice: I apply it to a real activity in my role, with an explicit outcome and control;
3. Redesign: I change the workflow, transfer what I learned, and check whether the change holds over time.

The first step prevents ignorance. The second produces early results. The third changes how work is organized.

The most important step, and the one most often missing, is the move from practice to redesign. Someone can use AI to draft a first version and then return to exactly the old procedure. They have tried a feature, but they have not yet changed a system of work.

That does not mean forcing everyone to become an expert. One role may need the first step, another the second, and a small group of enablement leads the third. The choice must be explicit, otherwise a company confuses access, use, and value.

Attitude needs conditions 🧠

Curiosity matters. So does abstraction: recognizing that an idea seen in one industry can be adapted to another. But calling everything mindset risks placing the responsibility on individuals alone.

The ability to redesign work grows when the organization creates concrete conditions. At least four elements are needed:

• relevant examples, built around the role’s problems rather than generic demos;
• feedback, to understand whether the output is correct, useful, and safe;
• protected space, so experimentation does not become a secret second shift;
• sharing, so a good solution does not remain one person’s private trick.

Asking a marketing lead to innovate while keeping one hundred percent of their previous workload means relying on luck. If innovation matters, it needs a place in the work, an objective, and a recognizable mandate.

Direction keeps learning from evaporating 🎯

“We want to be more efficient” is a correct and almost useless sentence. Efficient for what?

A company needs a concrete reason: serve more customers without increasing operational load, reduce time spent on repetitive activities, improve the quality of a decision, or create space for more strategic work.

That direction is not a slogan for the meeting room. It is the criterion for choosing exercises, evaluating results, and deciding what to automate. If a team wants to reduce time lost during incident triage, AI is not just an interesting demo: it is a means judged by diagnosis quality and recovery speed.

Without a why, every AI lab becomes a collection of tricks. With a why, even a small improvement can become a new habit.

Five questions before the next subscription ✅

Before subscribing to another AI service, leadership should answer these questions:

1. Which concrete activity do we want to change?
2. Which problem makes the change desirable for the person doing the work?
3. Which step is needed: access, practice, or redesign?
4. What time has been protected for learning and experimentation?
5. How will we distinguish occasional use from a new habit and from produced value?

If the answers do not exist, the problem is not that another tool is missing. The adoption design is missing.

This article is a preview of the adaptive organizations series, coming in the following weeks. The series will explore use cases, measurement, governance, and workflow redesign: not a catalog of tools, but a more deliberate way for an organization to learn how to change.

Fix the bucket before adding more water. In a company, that means designing learning before multiplying accounts. That is where the adaptive organizations series begins: not with a catalog of tools, but with how an organization learns to change.