April 2027 | Samuel Sum

In 2024, I wrote about pilot purgatory: the gap between a promising prototype and a deployed production system. In 2026, I wrote about pilot purgatory 2.0: the same problem, but with agents instead of models. Now it is 2027, and the problem has evolved again.

Pilot purgatory 3.0 is not about technical failure. The system works. It has been running in a test environment for months. The users like it. The metrics are good. The business case was made. And yet it never moves to production.

The reason is not technical. It is organisational. Nobody wants to own it.

Why ownership is the blocker

A pilot is typically sponsored by someone with a problem and a budget. That person wants to see if AI can help. The pilot is built, tested, and evaluated. It works. At this point, the question changes from “does it work?” to “who is responsible for it now?”

The answer is often unclear. The sponsor may have moved on to a different priority. The IT team may not have the capacity to operate it. The business unit that would use it may not have the budget to maintain it. The data science team that built it may be a central function that does not own production systems.

The result is a system that works but has no home. It sits in a test environment, serving a small group of users, until the budget expires or the team is reassigned. The pilot never ended. It just faded. The system is still running, but nobody is accountable for it, and nobody is investing in it.

I have seen this pattern repeatedly in Hong Kong. The pilot is celebrated in a quarterly review. The team that built it is praised. Then the next quarter arrives, the budget is reallocated, and the pilot continues to run in the background because nobody has the authority to shut it down and nobody has the mandate to scale it. It becomes a zombie system: technically alive, operationally dead.

The agentic complication

In 2027, the ownership problem is worse for agentic systems, because the risk is higher. A model that predicts a churn score is a recommendation. An agent that sends a retention offer is an action.

The person who owns the agent is accountable for the actions it takes.

This accountability cannot be delegated to the data science team. The data science team can build the agent. It cannot decide whether the agent should send an offer to a customer, or what the offer should be, or what happens if the customer complains. Those are business decisions. They require a business owner.

The pilot purgatory 3.0 problem is that the business owner is often not identified until after the pilot is complete. At that point, the conversation is not “should we build this?” but “who is willing to take responsibility for it?” The answer is often nobody. The business owner who might have been willing to sponsor a pilot is not willing to accept accountability for an autonomous system that sends offers to customers. The risk is too high, and the upside is not clear.

How to force the ownership question

The solution is not technical. It is procedural. The ownership question should be answered before the pilot begins, not after it ends.

I have started using a simple test before any pilot is approved. I ask the sponsor: “If this works, who will be accountable for the decisions it makes?” If the answer is vague—”we’ll figure that out,” “the team will manage it,” “we need to discuss with legal”—the pilot is not ready to start.

If the answer is specific—”the head of customer retention will own it, and her team will operate it”—the pilot has a destination. The governance can be designed for that destination. The transition from pilot to production has an owner.

This test does not guarantee success. It does guarantee that the ownership question is addressed before the budget is spent. The pilot may still fail for technical reasons. But it will not fail because nobody wanted to own it. That failure mode is preventable, and it should be prevented before the first line of code is written.

What to do if the pilot is already stuck

Many organisations are already in pilot purgatory 3.0. The system works. It has no owner. The budget is running out. The team is frustrated.

The first step is to name the problem. It is not a technical failure. It is an ownership failure. The conversation should be with the sponsor, not the technical team. The question is not “how do we fix the system?” but “who is willing to own it, and what do they need to say yes?”

The second step is to accept that the answer might be no. If no business owner is willing to take responsibility for the agent’s actions, the pilot should be shut down. Continuing it consumes resources and creates risk without a path to value. Shutting it down is not a failure. It is a decision. The organisation that cannot shut down an unowned pilot is an organisation that will accumulate zombie systems.

The third step is to document the lesson. The next pilot should start with the ownership question. The organisation that learns this pattern will stop accumulating pilots that cannot transition. The organisation that does not learn will continue to build systems that work and cannot be deployed.

A structural change

The deeper fix is structural. Pilots should not be approved without an identified business owner and a defined operating model. The data science team can build the system. The business owner is accountable for its actions. This should be agreed before the first line of code is written.

This is not how most organisations work. Pilots are often funded as experiments, with the expectation that the successful ones will find a home. But in the agentic era, the home must be found first.

The risk of an unowned agent is too high to leave to chance.

Gartner’s prediction that 40% of agentic AI projects will be cancelled by the end of 2027 describes the outcome of this failure mode. The projects are not cancelled because the technology fails. They are cancelled because the organisation cannot answer the ownership question. The cancellation is the organisation’s way of admitting that it never had a destination for the pilot.

Pilot purgatory 3.0 is not a technical problem. It is a governance problem. The solution is not a better model. It is a clearer answer to the question: who owns this?

Samuel Sum writes about data science, machine learning, and the professional realities of building AI systems in Asia. He is based in Hong Kong. Views are his own.