There is a pattern that repeats itself frequently in companies that have been using AI tools for months: licenses are active, access is enabled, and yet real usage is low. Some teams use them intensively, others have barely touched them. The enthusiasm of the first days faded without anyone noticing too much.
The usual explanation is that the tool was not as good as promised, or that people did not have time. But in many cases the problem is simpler and harder to solve at the same time: nobody taught people how to use it in the context of their actual work.
The gap that is starting to become visible is not between companies that use AI and companies that do not. It is between those that deployed tools and those that also enabled their people. These are two different decisions, and the second is the one most frequently skipped.
Part of the problem is how training is understood. The most common model is to bring in a generic prompting course, organize a two-hour session, and consider the matter closed. The result is almost always the same: a few people leave eager to try things, most return to their usual workflow, and within three weeks usage is back to where it was before. Not because people resist change, but because learning to use a tool in the abstract is very different from integrating it into work that is already being done every day.
When enablement does not happen, the problems go beyond return on investment. A person who does not fully understand what a tool is for or what its limits are can end up using it in ways that generate real risk: sharing sensitive information with platforms that do not meet the company's security standards, using powerful tools for trivial tasks while ignoring the use cases that actually justify the investment, or producing outputs nobody validates because it is assumed the AI does not make mistakes. And when that happens, management sees low returns and draws the wrong conclusion: that AI is the problem. It is not. The problem is that adoption never really happened.
What moves the needle is not the course. It is accompaniment tied to real work.
When someone learns to use an AI tool in the context of their specific tasks, with examples from their area and applied to the problems they are already trying to solve, the adoption curve changes. Not because the person is more intelligent or more motivated, but because the distance between what they learned and what they need to apply becomes very small. The habit forms when the effort of using the tool is less than the perceived benefit. That almost never happens after a generic course.
There is another factor that gets underestimated: adoption needs internal sustaining. A person inside the team who uses the tool, shares what works, helps when someone gets stuck, and keeps the momentum alive beyond the initial launch. Without that role, even if informal, most implementations stall. Not on the first day, when everything is new. In week three, when the urgency of day-to-day work takes over again.
In the adoption processes we have run at fuubo, the difference is consistent: when we work with teams in their real context, usage rates go up, use cases get implemented for real, and return becomes visible with concrete evidence. Not as a promise, but as a measurable result the organization can show. That is what allows the conversation with management to shift from "what are we paying for?" to "where do we apply this next?".
This is a design problem, not a willpower problem. A company that launches an AI tool without thinking about how it will sustain the habit of use is making an implicit decision: betting that the tool is good enough that people will adopt it on their own. That happens very rarely.
August is when many mid-sized companies start planning budgets and training for the following year. It is a good opportunity to ask an honest question: what percentage of the team is actually using the AI tools they are already paying for? And if the answer is low, the next question is not whether more technology is needed, but whether a different enablement model is needed.
Deploying a tool is the easy part. What takes more effort, and matters most, is turning it into a new way of working.
