The AI pilot worked. So why is it still not in production?

An AI pilot can prove that a model can perform a task, answer a question or improve one step of a process. It does not yet prove that the capability can become part of the organisation's day-to-day work, with real people, accountability that passes between departments, exceptions nobody planned for and systems that do not always describe the same reality in the same way.

The gap already shows in the data. In McKinsey's The state of AI in 2026, nearly nine in ten respondents report regular use of AI in at least one business function.

The demo is the easy part

A pilot has clear edges. You choose a use case, define the data sources, work with a small group of users and know, more or less, what you set out to prove. When something is unclear, there is a person in the room who knows the process: someone who explains an exception, picks the right document or corrects an assumption the system made.

That human work is almost invisible, but it is critical. In practice, the people around a pilot supply part of the context the system is missing. They know what actually matters, who has the authority to decide, which figure is more current and what counts as an exception in this particular case. That is natural at the experimental stage. It is also why an impressive demo can make the road to production look shorter than it really is.

In production, nobody can count on someone standing beside every decision and translating the organisation for the system. The capability has to meet the work as it runs on an ordinary day: when the information is incomplete, when accountability passes from one person to the next, and when the case in front of it does not look quite like the example the pilot was built on.

Production is where you meet the real organisation

Suppose an AI system detects that an order is likely to be late. In a pilot you can set a simple rule: if the delivery date slips past the target, alert the manager. Inside a real organisation, the same slip can mean entirely different things. Perhaps the date was already changed with the customer's approval. Perhaps the missing material is on its way. Perhaps this customer has a different escalation policy. Perhaps the delay only matters because another project depends on it.

And that meaning does not live in the data alone. It lives in the history of the process, in the people who hold accountability, in the authority to make a decision, in the exceptions accumulated along the way and in the working habits the organisation has built up over years.

This is also where adoption comes in. A system can be technically right and still never become part of the work if employees do not know when to trust it, when to stop it, who is accountable when something goes wrong, and how its recommendation fits a process that already exists. Moving to production is not just moving a model from one environment to another. It is a change in how people and a system work together.

More data is not the same as understanding the organisation

The natural response to this difficulty is to connect the AI to more sources: the ERP, the CRM, the project management system, documents, email and more. Those connections matter, but what they supply is raw material. On their own, they do not define what the information means inside the work.

The same project can appear under one name in the finance system, under another identifier in the operational system and under an internal nickname in documents. A business decision can sit in meeting minutes while the systems still reflect the previous state. An experienced employee connects these things almost without thinking, because they know the organisation. A system does not acquire that knowledge just because it was given access to one more source.

This is where two ideas need to be kept apart. Operational context is the meaning and the circumstances a system has to understand to act correctly inside the organisation. An operational model is the structured asset that represents that meaning and maintains it over time, through the business entities, the relationships between them, their states, events, accountability and decisions.

AI can help discover relationships, suggest updates and support the upkeep of the model, but it is not the model itself. The distinction matters most in production, because the capability has to rest on a stable representation of the organisation even as the model, the agent or the use case changes.

What has to become explicit before you scale?

Much of what an organisation knows lives between its systems. Anyone who knows the work knows what the central business object is, what depends on what, who holds accountability at each stage, who may approve an exception and which events changed the situation along the way. In production, these things have to be explicit enough for a system to work from them, rather than receive them from a person sitting next to it.

That does not mean turning every procedure and every hallway conversation into a hard rule. Quite the opposite. The places where there is uncertainty, where human judgement is needed, or where there is more than one source of truth have to be represented too. The goal is not to erase the organisation's complexity, but to make it something that can be understood, reviewed and updated.

That is also where people's role in the process comes from. A person is not only the one who fills in what the AI does not yet know. Often they hold the business authority, define the exception or are accountable for the outcome. A system that goes into production has to fit that structure of accountability, not route around it.

Once the foundation exists, value starts to compound

One of the important differences between a one-off pilot and an organisational capability is what remains after the first use case. If every new initiative starts again from connecting sources, identifying the entities, working out accountability and mapping the exceptions, the organisation is rebuilding the same foundation every time.

With a shared operational model, what has been learned about the organisation stays as an asset. A new use case can rest on the same objects, relationships, events and accountability rules instead of starting from zero. One capability might deal with spotting risk, another with a management view of where things stand, and later, agentic capabilities can rest on the same foundation. The value compounds: not just one more use of AI, but organisational infrastructure that becomes more useful as processes and context are added to it.

That is also the right way to read Project NANDA's famous figure. The preliminary working paper The GenAI Divide: State of AI in Business 2025 found that 95 percent of organizations are getting zero return from generative AI. The important point in the paper is not that AI does not work, but that the gap opens when tools do not learn the context, do not fit the existing work and never become a capability the organisation knows how to maintain over time.

The 95 percent refers to organizations, not pilots. On the paper's own funnel, 60 percent of organizations evaluated tools, 20 percent ran a pilot and 5 percent implemented successfully, so about a quarter of those that ran a pilot reached implementation. It is a preliminary working paper that has not been peer reviewed. We set out the full correction of that number separately.

This is the layer HIVO builds

HIVO is the operational system of record for enterprise AI. It builds and maintains a shared operational model above the source systems, so that business objects, relationships, states, events, accountability and decisions are represented in a single frame that is updated as the organisation changes.

It is not another data storage layer, and it is not an abstract operational context rebuilt for every question. The operational model is the asset that holds structure and meaning over time. Operational context is what people and systems need to draw from it to understand what is happening and what is relevant at a given moment.

The core systems keep doing their jobs. The ERP remains the system of record for transactions, the CRM for customers, and other systems for their own domains. HIVO holds the layer that represents how those things connect into one piece of work, so that each new capability does not have to learn the organisation again from the beginning.

For more on the difference between information and operational context, see What happens after the demo.

From a pilot that works to a capability that works

A pilot answers an important question: is the task possible? Production has to answer a broader one: can the capability work day after day inside an organisation where people, authority, systems and exceptions change all the time?

So the next step in adopting AI is not only to improve the model or connect more data to it. It is to turn what the organisation already knows about itself into a shared model that can be maintained, and to build further capabilities on it without starting over each time.