The AI pilot worked. Three months later nobody uses it

The demo goes well. The system does in thirty seconds what used to take twenty minutes. Everyone nods.

Three months later half the team has stopped opening it. Six months on, somebody concludes that AI didn't work for them.

It did work. The implementation didn't happen.

This is not an isolated pattern. A 2025 MIT analysis found that 95% of corporate generative AI pilots delivered no measurable return. Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027 — and the reasons it gives are not model quality, but escalating costs, unclear business value and inadequate risk controls.

Why this is hard

Because a pilot and an implementation are two different jobs, and most organisations treat success at the first as success at the second.

A pilot runs under ideal conditions: selected data, motivated participants, the vendor in the room, a few weeks of attention. An implementation is the opposite: real data, tired colleagues, holiday cover, competing priorities, and nobody watching.

Gartner also names a related problem it calls "agent washing" — rebranding existing tools such as chatbots, robotic process automation and assistants as agentic AI. By its estimate, of the thousands of vendors claiming agentic capability, roughly 130 are genuine. Start a project on that kind of promise and the disappointment won't be with AI; it will be with the label.

The five reasons behind it

1. There was no baseline. If you didn't measure how long the process took and how many errors it produced before, you have nothing to compare against afterwards. The discussion then turns on opinion, and opinion always favours the old process, because the old process is familiar.

2. The tool sits beside the workflow, not inside it. If a colleague has to leave the system they normally work in, copy data across and open another window, they will drift back to where the work actually happens once the novelty wears off.

3. Nobody owns it. The pilot has a sponsor who presents it, but no one whose daily job is to handle the exceptions and feed the errors back. What belongs to nobody withers.

4. There is no exception route. This is the most common cause and the least visible. When the system is uncertain, the user has to know what happens next. Without that route, the first difficult case sends everyone back to manual work — because manual is at least predictable.

5. The benefit and the cost land in different pockets. One department pays, another gains. This is sharpest in hourly-billing professions: finish faster and you bill less. Most implementations stay silent on this question, and that is precisely why they fail.

How to choose what to automate

Three conditions, all at once.

The process runs at least weekly, ideally daily. There is nothing to save on something that happens once a month.

The process is measurable: there is a number that already exists — cycle time, item count, error rate.

A wrong output surfaces before it causes harm. This is the important one. A wrong automated decision is worse than an unprocessed item, because the unprocessed item will eventually be looked at, while the wrongly closed one never will be again.

It follows that a good first process is almost always one where the system proposes and a person approves. It is no accident that 62% of accounting firms specifically require exactly that: propose, don't act.

What to account for in practice

Seasonality: what works in January carries a different load in April.

Holiday cover: the first summer after go-live shows how far the process is actually embedded.

Losing the champion: if one enthusiastic colleague keeps it alive, the project leaves when they do.

And the security review, which is sometimes longer than the pilot itself. Schedule it at the start, not at the end.

Which failure is the most expensive

Not the cancelled project. At least that one was cancelled.

The expensive failure is the "successful" pilot that is never scaled and never switched off. It runs in the background, consuming licences and attention, used by some people and not others, with half the data in it and half outside.

And it carries a cost that appears on no invoice: the next proposal becomes three times harder. The organisation has learned that "we tried this already". One botched implementation can close the door for years — including on processes that would have worked.

What changes with a proper setup

• Baseline: two weeks of measurement before anything is built, using the same metrics you will measure afterwards
• Embedding: the system appears inside the tool the team already uses
• Owner: one named person for whom this is a task, not a hobby
• Exception route: a defined next step for every uncertain case
• Stop condition: agreed in advance — below which result the project ends. That is not pessimism; it is what turns the project into a decision rather than an opinion

What implementation needs

Two weeks of measurement before anything is built. Access to real data, not sample data — every system performs well on sample data.

A named owner on the client side, with half an hour a week.

And a stop condition fixed in advance. If the numbers haven't moved after three months, the project ends, and that is a legitimate outcome.

Where it runs

The system connects to your existing processes and platforms and runs in your own EU cloud environment.

Your data is not used to train a third party's general models. Start the security review in the first week rather than the last — it is the single step that delays most implementations.

What it doesn't solve

A broken process. If the process isn't clear today, automation will simply do it badly faster. In that case the process has to be fixed first, and we will say so.

A decision nobody wants to own. If work stops at a given step today because there is no one to decide, that is not a technology problem.

And it does not help with a task that runs once a month. There is nothing there to save.

Common questions

If 95% of pilots fail, why start at all?
Because the causes are known and avoidable: no baseline, the wrong process, no owner, no exception route. All of these are implementation design, not technology.

How long before I know whether it works?
On a well-chosen process, six to eight weeks. If nothing shows in the numbers after that, the silence is itself an answer.

What should I measure?
What already exists: cycle time, item counts, error rate, rework. Don't invent a new metric for the project's benefit.

What is the most common mistake in choosing a process?
Picking the most interesting process instead of the most frequent one. A first implementation should be boring.

What if the team resists?
Look at where the saved time goes. If resistance comes from the benefit landing somewhere other than the extra effort, that is a design fault, not an attitude problem.

If you are preparing an AI implementation, there is one thing worth doing before choosing anything: spend two weeks measuring how the process runs today. Without that, what you have at the end of the project is not a result. It is an opinion.