---
title: "The friction map of AI adoption"
url: https://zerofive.ai/en/blog/ai-governance/ai-adoption-friction-map
canonical: https://zerofive.ai/en/blog/ai-governance/ai-adoption-friction-map
language: en
published: 2026-11-04
updated: 2026-10-31
author: "ZeroFive.AI"
tags: AI maturity, AI adoption, AI Rating, decision gates, delegation levels, shadow AI
abstract: "Licences measure how widespread AI is, not how mature. Seven states from spontaneous use to AI-native processes, and the decision resolving each friction."
---

# The friction map of AI adoption

**In short.** The number of active licences and the share of people using an assistant measure how widespread AI is in a company, and say very little about how mature the organisation is. We propose reading maturity through friction, the friction a company has already resolved and the friction it is paying for right now. The map we use lists seven states, from spontaneous use to AI-native processes, and next to each friction it shows the decision that resolves it and the gate or AI Rating dimension against which that decision is checked.

When AI reaches the agenda of a board of directors, the first slide almost always reports a diffusion figure: licences purchased, monthly active users, sometimes hours saved as estimated by the users themselves. These figures are easy to collect, because the vendor produces them, and easy to push up, because an internal campaign or a mandatory training course is enough to move them.

Two companies with the same share of active users can, however, be in opposite conditions. In the first, the assistant is used to rephrase emails and the rest of the work is unchanged; in the second, three processes already run with AI doing the work and a person checking it, with a named owner and a procedure to roll back if something breaks. The dashboard shows them as identical, and whoever has to decide where the next budget goes has nothing in hand to tell them apart.

## Adoption metrics

Diffusion metrics have a limit that is more insidious than their shallowness. As soon as they become a target, the organisation finds a way to hit it, and the measure stops saying anything about real work: a quarterly target on active users is met with one login a week, and a training programme assessed on the number of certificates can close without a single process having changed.

Diffusion is still a useful data point, provided it is treated as a starting condition. In our [AI Rating](/en/services/ai-rating) adoption has a dimension of its own, Confidence, measured through indicators of real use and user trust alongside Readiness, Delivery and Risk, as we described in the article on the [four dimensions of AI maturity](/en/blog/ai-governance/four-dimensions-ai-maturity). Even four well-built scores, though, describe a state, and on their own they do not say what the next decision is or who should take it.

Getting to that decision requires a different reading, one that starts from what the organisation is experiencing as a problem.

## Friction as a unit of measure

We call friction a recurring cost the organisation pays because a decision is missing. It can be recognised without analysis tools, because the people doing the work describe it (the pilot stuck for months, the legal department's question nobody can answer), and it always has a cost that can be expressed in lost time or tied-up budget.

What makes friction useful as a measure is its link to a decision. A technical gap is closed by buying or building something; friction is resolved when someone with the authority to do so sets a rule or names an owner. And every decision taken well brings out the next friction, which was hidden behind the bigger one: once tools are authorised and use becomes visible, the question shifts from who uses AI to what has changed in the work.

This sequence makes it possible to read maturity as a position that can be checked. If a company says it runs AI-first processes but the friction it describes is still the lack of a criterion for choosing use cases, the declared position and the real one do not match, and that gap is already a finding of the assessment.

## The friction map

The map we use with clients lists seven states. For each one it shows the typical friction, the decision that resolves it and the reference in our method, meaning the decision gate or the AI Rating dimension against which that decision is checked.

| | State | Friction | Decision that resolves it | Reference |
|---|---|---|---|---|
| 01 | Spontaneous use | Shadow AI: company data in prompts and no record of what goes into the models | Usage policy, authorised tools and a record of what goes into the models | AI Risk |
| 02 | Authorised tools | Adoption as a KPI: licences are counted and nobody knows what has changed in the work | Maturity measured across four dimensions, with critical gates that do not offset one another | G1 Readiness |
| 03 | Maturity measured | No criterion: every function brings its own use case and there is no rule for saying no | Every use case comes in with a Value Case and a non-AI alternative ruled out in writing | G0 Legitimacy |
| 04 | Portfolio decided | Pilot purgatory: the prototype proves what it had to and is left without an owner | Hypothesis stated before the prototype, named owner and rollback before going live | G2 Validation, G4 Scale |
| 05 | AI-first processes | Fragmented context: every system rebuilds from scratch knowledge scattered across folders and people | Company knowledge readable by agents, with an owner and an update cycle | AI Readiness |
| 06 | Company OS | Autonomy to be declared: agents can act on their own and nobody has decided how far | An autonomy level declared for each system, consistent with its risk class | G3 Authorisation |
| 07 | AI-native processes | Accountability: who answers for a decision taken by an agent in front of an audit | Adoption measured over time and an owner for every delegated decision | G5 Oversight |

The rows are in order because each decision presupposes the previous one. A portfolio of use cases cannot be decided without a measure of readiness, and an agent's autonomy level cannot be seriously declared if the agent works on fragmented knowledge whose updating nobody tracks.

## From spontaneous use to measurement

The first friction is one almost every company has been through. People use whichever chatbot they prefer, often with a personal account, and contracts and customer data end up in the prompts. The cost stays invisible until it becomes an incident, which is why the decision that resolves it concerns the Risk dimension before any other: a usage policy people can understand, authorised tools that make the personal alternative unnecessary, a record of what goes into the models. We wrote about it in the piece on [shadow AI](/en/blog/approfondimenti/shadow-ai-company-risks-policy).

With authorised tools, use finally becomes visible, and the friction of the second row emerges. The organisation sees who uses AI and does not see what has changed, and the temptation is to turn the number of active licences into the result of the programme. The decision needed is a maturity measurement that looks beyond diffusion, with minimum thresholds on every dimension: it is the first of our organisational gates, G1, and its criterion is that no dimension falls below threshold, because [critical gates](/en/blog/ai-governance/critical-gates-ai-maturity) are not offset by excellence elsewhere.

Once maturity has been measured, every function arrives with its own use case. It is a good sign, and it becomes friction when there is no rule for choosing, and above all for saying no. The rule we use is gate G0: a use case enters the portfolio only with a [Value Case documenting a non-AI alternative that was assessed and ruled out](/en/blog/strategia/value-case-non-ai-alternative-ruled-out), written before knowing what the answer will be. A significant share of requests is solved by deterministic automation or a change of process, and finding that out early costs far less than finding it out after a prototype.

## Going live

The fourth row is where most projects stall. The prototype works, the demo convinces, and six months later the system is still in pilot because nobody owns it, nobody planned what to do if it stops working, and the budget to take it into production was never allocated. The [recurring causes of stalled pilots](/en/blog/approfondimenti/stalled-ai-pilots-recurring-causes) are almost always of this kind.

Two decisions resolve this friction, and they sit at the two ends of the prototype. Before starting it, a falsifiable hypothesis must be stated, meaning what it has to prove and against which threshold, and that is the criterion of gate G2. Before putting it into operation, a [named owner](/en/blog/ai-governance/ai-agents-named-owner-production) and a rollback procedure must be in place, and that is the criterion of gate G4. Without the first, nobody knows whether the prototype worked; without the second, nobody knows whom to call when it stops working.

Past this step, processes become AI-first: AI does the work and a person reviews every output. Here a less visible and very costly friction emerges, because every system rebuilds the context it needs from scratch. Information about customers and procedures is scattered across shared folders, inboxes and people's heads, and each agent pieces it together in its own way, with different results on the same topic. The decision needed concerns the Readiness dimension: company knowledge organised to be read by agents, with an owner and an update cycle, what we call the [AI Company OS](/en/blog/strategia/connect-ai-to-company-data-ai-company-os).

## Agent autonomy

When agents work on shared and reliable knowledge, they can do much more than before, and this opens the friction of the sixth row. Agents are technically able to act on their own (sending a message, changing an order) and nobody has decided how far they should go. The decision is gate G3: each system needs a declared autonomy level consistent with its risk class, declared again whenever autonomy grows. We described the logic in the [delegation levels](/en/blog/strategia/ai-assisted-ai-first-ai-native-delegation-levels) and in the [agents' delegation perimeter](/en/blog/ai-governance/ai-agents-four-layers-delegation-perimeter).

AI-native is not a goal for every process. There are activities, such as an acquisition or a dispute, where judgement must stay human even when the technology would allow otherwise, and stating that is part of the same decision.

The last row describes processes where agents work end to end, within policies and guardrails written by people, with adoption measured over time according to the criterion of gate G5. It is also the row where we see the next friction coming, organisational before it is technical: who answers for a decision taken by an agent when a customer contests it or an auditor examines it. Accountability has to be assigned before the process becomes AI-native, decision by decision, and the issue goes beyond internal governance, as we wrote about [Article 25-vicies of Italy's Legislative Decree 231/2001](/en/blog/compliance/italy-decree-231-article-25-vicies-ai).

## Functions on different rows

No company sits on a single row. Marketing may run AI-first processes while the legal department is still at shadow AI, operations may be stuck on the fourth row with a prototype nobody owns, and HR may have licences for everyone without knowing what has changed in the work.

The average of these positions describes an organisation that does not exist, which is why the rating is read dimension by dimension and, where needed, function by function. The lowest row on the Risk dimension is also the one that constrains all the others, because a critical gate that has not been passed blocks the overall class however advanced processes are elsewhere.

## Using the map in a company

The map works better as a conversation tool than as a questionnaire. In a meeting with function heads, we ask each of them to describe the friction their team is paying for this week, without naming a tool. The answers fall onto the rows almost by themselves, and the mismatches between declared position and described friction are where the assessment starts.

From there the question for leadership changes shape. Instead of asking how much the company has adopted AI, it asks which decision each function is missing to move to the next row and who has the authority to take it. That is a question a board can discuss and assign to someone, which never happens with a licence count. On how to set up that discussion, see the article on [how to present the state of AI to the board of directors](/en/blog/ai-governance/presenting-ai-to-the-board).

To see which row your organisation is on, function by function, you can [start an AI Rating](/en/start-ai-rating) or [book an assessment call](https://calendly.com/fabiolalli/zerofive).