Why your team isn’t using the AI system, and what to prepare before launch

A system can get almost everything right and still go unused. The four pieces to prepare before launch so that does not happen….

Table of Contents

An AI system can get almost every case right and still go unused. Most of a project’s value is lost after go-live, when the team stops trusting the output and drifts back to the spreadsheet. AI adoption in companies is prepared before launch, with four pieces: a measured baseline, a period in which the system runs alongside people without deciding anything, a clear map of what gets reviewed and what does not, and named people on the client’s side.

Using AI is not the same as getting value from it

The AI Index 2026 from Stanford University brings together the figures from McKinsey’s annual survey: 88% of companies say they use AI in at least one function. In most functions, fewer than 10% use agents at scale. The gap between those two numbers is where the problem sits. Many companies have experimented, few have changed how they work.

In Portugal the gap is wider. The same report puts generative AI adoption among the Portuguese population at around 20%, while Spain is above 40%. In a University of Melbourne and KPMG survey of 48,000 people, Portugal is among the three countries where workers say they get the least support from their employer to learn AI.

Why the team does not use the system

The reasons tend to be these, and almost none are technical.

  • Nobody knows whether the system is helping. Without a measure of how the process worked before, there is no way to show that 30 hours a month became 2. The team feels the effort of the change and does not see the gain.
  • The team does not trust the output. If the system got two things wrong in the first week, people start checking everything by hand, and the system becomes extra work.
  • Nobody knows what to check. If every result looks the same, people either check everything or check nothing. Both go badly.
  • The first reaction is to refuse. A new tool is often met with “this isn’t for us”. That refusal is predictable and says little about the system’s value, but if nobody plans for it, it ends up deciding the project.
  • Nobody on the client’s side owns the system. When the person who followed the build moves role, nobody is left to explain the system to the team.

The four pieces to prepare before launch

1. The baseline

Before building, the process is measured as it runs today: how long each task takes, what share of cases has errors, how long it takes to get a response. With it you prove the gain and decide whether automation is worth it. It also gives the team a number they recognise. The method is in how to measure a process before automating it.

2. Shadow mode

For a few weeks, the system runs in parallel with people, on the same cases, and decides nothing. At the end, what the system would have done is compared with what people did. The team sees the system get its own cases right before depending on it, and errors surface while they still cost nothing. How to set up this period is in shadow mode: how to test an AI system without touching the process.

3. The review map

Every output from the system comes with a confidence level. Anything that passes the rules with high confidence flows through untouched, and anything below goes to a person with the reason explained. The team knows exactly where to look, and review time goes to the cases that need it. How to decide where the line sits is in where AI fails, and how to decide what to review.

4. Named people

On the client’s side, three roles need an owner. One person corrects the system and helps tune it. Another can explain to the team why the system decides the way it does, and the third makes sure it keeps working, a role that in our projects sits with maintenance. What each of them needs to learn is in how to train your team to work with AI.

Start with a small group

The initial refusal fades with use and with results people can see. So launch starts with a small group that wants to try it. That group uses the system for a few weeks, and its results are shown to everyone else, with the baseline figures alongside.

It helps to separate two kinds of refusal. The one that comes from the tool being new fades with time. The one that points to a real problem in the system (a field that lands in the wrong place, a common case that always fails) has to be fixed, and it is some of the best information a project gets in its first weeks.

What gets checked every month

After go-live, adoption is measured like any other result. Monthly maintenance first checks whether people are actually using the system and whether the gain shows up in the baseline indicators. Then it confirms that the system still passes its test set of real cases, and that the three roles on the client’s side still have owners.

When usage drops, the cause is usually one of these four pieces, and rarely the AI model. The underlying question, who owns the process in the long run, is in buy an AI tool, or hand the process to someone who runs it. The reasons many projects stall before reaching this point are in why most AI projects fail.

Frequently asked questions

Why is the team not using the AI system we delivered?

Almost always for one of four reasons. Nobody measured the process beforehand so the gain is invisible, the team does not trust the output, nobody knows what to check, or nobody on the client’s side owns the system. The AI model is rarely the cause.

What is shadow mode?

A period of a few weeks in which the system runs in parallel with people, on the same cases, without deciding anything. At the end, what the system would have done is compared with what the team did, before the process changes.

How long does AI system adoption take?

There is no fixed timeline, because it depends on the volume of the process and on the team. With a measured baseline, shadow mode and a small group starting first, adoption can be tracked week by week and you can see early whether it is working. Without these pieces, the system may never be used.

Who should own the system on the client’s side?

Three people, or one person with three roles. One corrects and tunes the system, another explains to the team why it decides the way it does, and the third makes sure it keeps working. The last role can sit with whoever handles maintenance.

See it working: eight hours of document intake per client, down to one. Or see how we build AI systems.

Have a system your team stopped using?

It can often be recovered without changing the model. Book a call and we will work out with you which of the four pieces is failing.

Newsletter

Get our insights straight to your inbox.

Cases, articles, reports, and our take on what’s happening in the market.

Done. You’re on the list.

Blog

Related articles