AI adoption: why a good product is not enough

There is a specific moment in AI projects: the system works. Tests pass, quality is judged acceptable, access is opened to the teams. Technically, the job is done. A few weeks later, the business process looks exactly like it did before, with one more tool in the browser.

This guide is about what happens after go-live. It is not generic change management: AI systems create adoption problems of their own. Their outputs are probabilistic, their errors are often plausible, the human role shifts, and users have to learn something counter-intuitive — when not to use the system at all.

Deployed is not used

The first confusion to clear up is between states. A system can be deployed without being used. It can be used without being used well. It can be used well by a handful of people without being part of how the team works. These four situations call for different actions, and confusing them leads teams to answer an organisational problem with a model improvement.

1. 1

   Deployed

   available

   The system is reachable, authentication works, permissions are set. This is a technical state and says nothing about usage.

2. 2

   Used

   open

   People are using it. That may still be exploratory, occasional, or limited to a few curious users.

3. 3

   Correctly used

   competent

   People use it on cases where it helps, verify what needs verifying, and know when to stop.

4. 4

   Embedded in the work

   process

   The process has been redefined around the new split of tasks: the system is no longer an option next to the work, it is part of it.

No generic adoption figure tells you where a project sits on that ladder. What matters is knowing the real state, use case by use case.

Start from the real work, not the tool

Before training, communication or enablement, the work has to be described as it actually happens. That description is often missing from AI projects, because a convincing demo made everyone assume the need was understood.

• The current process, including the informal steps nobody documents.
• The people involved, their workload, their expertise, their room to manoeuvre.
• The decisions made, and the point at which they become irreversible.
• The real friction, which is not always the friction management sees.
• The information actually used, and the information available but ignored.
• The exceptions, which often account for a large share of the work.
• Accountability: who answers for the outcome, to whom, with what consequences.
• Risk: what an error costs, and who pays for it.

Until that work is done, "we are adding a copilot" does not describe a transformation; it describes an addition. It says nothing about which step disappears, which step changes nature, and which verification becomes necessary.

Define the new human / AI split

Adoption requires making explicit a division of labour that otherwise settles by default, inconsistently from one user to the next. Six questions are enough to set the frame.

• What the system proposes: a suggestion, a draft, a ranking, an extraction, a hypothesis.
• What it may execute on its own, and within which strict limits.
• What a human checks every time, and what is only sampled.
• What a human decides, without treating the proposal as an official recommendation.
• When to escalate: out of scope, sensitive case, disagreement with the system, doubt.
• Who remains accountable for the decision and its consequences, by name.

Human-in-the-loop is not a guarantee in itself. Someone asked to quickly approve proposals that are mostly correct will end up approving the incorrect ones too. The useful question is not "is there a human?" but "does that human have the time, the information and the mandate to say no?".

Build calibrated trust

AI systems fail in a particular way: their errors look like their successes. A wrong answer can be well written, coherent and persuasive. That is what makes calibration more important than the level of trust itself.

• Over-trust: the user accepts without review, including where an error is expensive.
• Systematic distrust: the user redoes everything, and the tool becomes extra work.
• Calibrated trust: the user knows which tasks the system handles well, which it does not, and adapts verification accordingly.

Three levers help, and none is sufficient alone. Repeated experience on cases whose answer is already known; explicit usage rules that draw the boundary; and visible limits, meaning the product's ability to show where a result came from, what it did not take into account, or when it is working outside its usual ground.

Training that goes beyond the interface

Training people on "how to use the tool" assumes the difficulty is the interface. In AI systems the difficulty is judgement: deciding whether this particular output, in this particular context, can be used as it is.

• Capabilities: what the system does well, on which content, within which scope.
• Limits: what it does not know, what it ignores, what it cannot see.
• Suitable and unsuitable cases, expressed with examples from the domain.
• Verification: what to re-read, how to cross-check, which source prevails.
• Confidentiality: what may and may not be submitted to the system.
• Escalation: who to turn to when a case falls outside the frame.
• Feedback: how to report an error so that it leads somewhere.

There is no universal format. A single session rarely works: understanding limits is built on encountered cases, and therefore over time.

Observe adoption without inventing metrics

Many projects build a usage dashboard before deciding what they are trying to observe. A query count tells you neither whether the work is better done, nor whether the system is used where it is relevant. Rather than a standard KPI, it is more honest to keep observation categories and pick those that make sense for the use case.

• Usage: who uses it, on which cases, at which step of the process.
• Quality of the output, judged by the people accountable for it.
• Errors: their nature, their relative frequency, their severity.
• Human corrections: what is systematically rewritten after the system.
• Workarounds: what people do on the side, and why.
• Drop-off: who tried and stopped, and what triggered it.
• Understanding: can users say when not to use it.
• Time or effort, where measurement is genuinely possible without artificial reconstruction.
• Unintended effects, including on neighbouring roles and downstream steps.

The right signal depends on the use case: for a drafting aid, a passage that is always rewritten is more informative than usage volume; for a decision aid, the frequency of justified disagreements matters more than an acceptance rate.

Teaching scenario: a document summarisation copilot

The scenario below is fictional and used for teaching purposes. It describes no real organisation and contains no measured data.

A team ships a copilot that drafts a first summary from internal documents. The system works: summaries are readable and generally faithful. Access is opened to the whole department.

Why shipping is not enough

Two divergent behaviours appear immediately. Some people reuse the summary almost as it is, including on sensitive files where an omission has consequences. Others do not use it at all, because they cannot tell whether the most recent documents are covered, and prefer not to take the risk. Neither reaction is irrational: what is missing is shared information about the system's scope.

What needs clarifying

• The summary is a working draft, never a document that can be sent as it stands.
• Whoever sends it remains accountable for the content, including what they did not read.
• Covered documents are listed, and so are those that are not covered.
• Files in a sensitive category follow the existing procedure, without the copilot.

Which errors to watch

Three families deserve attention: omissions, harder to spot than a factual error; plausible statements that are absent from the sources; and cases where the system confidently processes a document it should not have processed, such as an outdated version.

How to collect feedback

A useful report is one that costs its author almost nothing. A button that opens a long form will not be used. A one-click report, combined with a regular review of a few real cases with two or three users, usually yields more information than a satisfaction survey.

How to adjust

Not every adjustment is technical. Narrowing scope to one document category, surfacing the source date, adding a cross-review step on sensitive files, or simply removing a poorly served use case: these are organisational decisions as much as product decisions, and they often do more for adoption than a change of model.

What this says about a profile

Bringing an AI system into real work is a distinct skill from building it. It shows through decisions: a scope deliberately narrowed, an accountability made explicit, a use case dropped after observation. That kind of trace, more than a list of tools, is what makes a profile readable on these topics.

• Adoption
• Human-in-the-loop
• AI literacy