From pilot to capability: why AI experiments do not scale themselves

AI pilots often begin well. A motivated person selects a problem, gathers data, tries a tool and achieves a result that previously seemed impossible. The demonstration creates enthusiasm, and the question appears: “How do we take this across the company?”

Then progress stalls.

Not necessarily because the technology fails. The pilot worked because of conditions that were not visible: one person knew every exception, corrected inputs, interpreted results and resolved every problem manually.

A pilot demonstrates possibility

The role of a pilot is to reduce uncertainty. It can show that a model understands certain documents well enough, that a task can be accelerated or that users find value. That evidence is important, but limited.

A capability exists when different people can obtain consistent results, the system works within the real workflow, risks are controlled and the organisation knows how to improve it.

There are at least five layers between those two states.

People

Who uses, supervises and maintains the solution? What do they need to learn? What happens when the person who drove the pilot is unavailable?

Training is not teaching buttons. It is developing the judgement to recognise results, exceptions and limits.

Process

At what point does AI enter? Which step changes? Who receives the output? How is an exception handled?

If the workflow depends on manually copying and pasting between five systems, scaling its use may increase risk instead of reducing work.

Context and data

Is the information available, current and authorised? Is there a source of truth? How do we stop each team from creating its own version of policies and instructions?

A good model with inconsistent context produces inconsistency with great confidence.

Platform and operations

How is the system authenticated, logged, evaluated and updated? Which cost limits exist? Who responds to a failure, and how does the process return to a safe state?

The prototype could depend on an individual account. A capability needs organisational ownership.

Governance and learning

Which uses are permitted? How are risks reviewed? What evidence justifies increasing autonomy? Where are corrections recorded, and how do we decide which learning to incorporate?

Governance is not a committee added at the end. It is the design of boundaries that allow exploration without losing visibility.

Scaling does not always mean expanding

Sometimes the right learning is to keep the solution small. A case works because it has bounded context and an expert nearby. Generalising it may destroy its value.

The question is not how to make everyone use the pilot. It is which capability the organisation deserves to retain and what shape it should take.

Transfer the capability

At re-active.org, I care about ensuring that the outcome is not dependency. Work ends better when the team can observe, adjust and continue the system. That requires documentation, training based on real cases and the involvement of the people who will operate the solution from the first cycles.

Implementation does not begin after the prototype. It begins when we decide which learning should remain after it.

Sources and references

• DORA’s 2025 report on systems, workflows and teams in AI adoption.
• NIST AI Risk Management Framework.
• Primary source: Victor’s experience in transformation, training and team evolution.