Why 90% of European companies use AI and fewer than 40% see results

McKinsey's MGI research published in 2024 found that roughly 90% of European companies report using AI, but fewer than 40% report seeing measurable results from it.

Read that number twice. Nine out of ten say yes, we are using it. Fewer than four out of ten can point to something that actually changed.

There is a six-in-ten gap between adoption and outcome. Sixty percent of companies are spending time, money, and internal energy on AI and cannot show what it produced.

Technology explains little of that gap. Translation explains most of it.

Translation, not transformation. The word matters.

Transformation is what everyone talks about. The vision. The future state. The slide about where the company will be in 2028. Transformation is the pitch deck.

Translation is what nobody talks about. It is the work of taking something vague, like "we should use AI for operations," and turning it into a specific workflow that runs on real data, produces a real output, and is used by a real person who has no choice but to rely on it because it is better than what they had before.

Translation is the boring part. It is mapping a process. Cleaning data. Naming who decides what. Writing acceptance criteria. Sitting in the room where the ops director says we have always done it this way and asking what would happen if the system did the first six steps and she only handled the exceptions.

Most companies skip translation. They buy a demo. They sign a contract. They announce an AI initiative. And then the distance between the demo and Monday morning turns out to be about ten thousand details that nobody scoped.

There is a pattern that explains most of the gap.

A leadership team decides to invest in AI. They pick a use case. The use case is usually described at a high level. Reduce customer service response time. Automate contract review. Improve demand forecasting. Better reporting.

These are not use cases. These are outcomes. And they are described at a level of abstraction that makes them impossible to scope, impossible to test, and impossible to fail on.

A use case has a specific input, a specific process, a specific output, and a specific person who will use it. The contract that arrives via email from supplier X, classified by type, routed to the right approver based on value, with a flag if the terms deviate from the standard, ready for review by the procurement lead before close of business.

When the use case is defined at the outcome level, the implementation expands to fill whatever time and budget exists. Nobody knows what done looks like. Nobody knows what failure looks like either. The project continues because stopping would mean admitting the scope was never defined.

The company spends six months and a significant amount of money. Something is delivered. It may match the specification and still sit unused, because the thing people needed was never what the company specified.

The second pattern is quieter but equally expensive.

The company does define a use case well. The scope is tight. The data is available. The workflow is mapped. A system is built and it works in the test environment.

Then it goes live. And the people who were supposed to use it do not use it.

The system works, but using it requires people to change how they work, and nobody designed that change. Nobody sat with the team and explained what would be different, what would be faster, what would stop, or who would own what now. The delivery was correct. Adoption never followed.

Training cannot rescue a system designed without the people who must use it. If someone needs a one-hour session to understand why the new system is better than their spreadsheet, the design missed their reality.

The people who use AI tools at work are not using them because they were trained. They are using them because the tool solved a problem they had that morning. The same principle applies to any internal system. If it does not solve a Monday problem, it will not survive Tuesday.

The third pattern is the one that explains why the gap persists.

Most companies measure AI investment by spend, not by outcome. They count how many pilots are running. How many vendors are being evaluated. How many people attended the AI workshop. How many use cases are on the roadmap.

They do not count how many workflows actually changed. How many hours came back to the business. How many decisions got faster. How many errors stopped happening. How many clients noticed a difference.

What you measure is what you manage. The companies in the forty percent measure differently. They do not ask did we deploy AI. They ask did something change in how this part of the company operates, and can we show what changed.

That is a smaller question. It is also the only question that produces results.

There is a version of this that is worth sitting with.

Your company is probably in the ninety percent. You are using AI somewhere. ChatGPT for drafts. Copilot for code. Maybe a pilot in customer service. Maybe a dashboard that was impressive three months ago and nobody checks anymore.

The useful question is whether you can point to something specific that works differently now because of it.

Forget the demo and the proof of concept. Look for something in production that a real person relies on every week and would genuinely miss if it stopped working on a Monday morning.

If you cannot point to that thing, you are in the sixty percent. Your people may be capable and the technology ready. The missing piece is the translation work: moving from the abstract to the specific, from the roadmap to the workflow, from the investment to the outcome.

That work looks mundane and makes for a poor board slide. It closes the gap.

The gap between nine out of ten and four out of ten comes down to discipline: start small, define specifically, measure honestly, and keep going until something actually works.

Most companies do not lack AI capability. They lack the patience to translate it.