You approve the third AI program this year. The board paper looks the same as the last two: discovery phase, build phase, run phase, each with a nominated project manager, a defined budget, and a clean hand-off. It clears governance without much debate.
In Brief
- The pilot-not-product pattern in enterprise AI is generated by the Plan-Build-Run operating model, not by delivery execution or budget.
- Plan-Build-Run separates planning from operating, so the people who scope AI investment never see whether their scope produced value.
- Project funding closes at handover, so the ongoing product-development work an AI system needs after go-live is never resourced.
- The single question that changes what an executive is approving is who owns the product continuously across its whole life.
Eighteen months later, you have three programs and no operational product. Every pilot demonstrated something in a controlled setting. None of them turned into a system the business actually runs on. Your delivery teams are competent. The budget was adequate and the vendors delivered exactly what the statements of work asked for. And still, the pattern holds.
What you are looking at is a pattern generated by the operating model you approved when you separated the work into three phases and gave each phase to a different set of people. This is the structure doing what it was designed to do. It is not a delivery failure. It is not a resourcing problem either.
Plan-Build-Run behaves as designed
The separation of planning, building, and operating (Plan-Build-Run) was designed for an era when the technology being introduced was well-understood, the requirements could be specified up front, and the system was expected to sit still once installed. The model rewards a clean hand-off at each boundary because that is the point at which one team can be released and another can be tasked. Governance, funding, and vendor contracts all sit on top of those boundaries.
AI systems do not sit still. A model in production changes with every new data pattern, every user interaction that no specification anticipated, and every downstream decision made on the basis of its outputs. There is no version of an AI product that can be planned, built, and then released to run untouched. What the model needs is continuous ownership of the product across its whole life: the same people making decisions about what it does, how it is built, and how the business uses it. That is precisely what the Plan-Build-Run boundaries prevent.
The failure mode is not that the phases are executed badly. Where it goes wrong is that the boundaries themselves make continuous product ownership structurally impossible. Three separate features of the model each generate a specific version of the pilot-not-product outcome.
Three structural features generate the same outcome
The features below sit inside almost every enterprise operating model in Australia. Each one, on its own, has a plausible governance rationale. Applied to AI in combination, they generate the pattern the board keeps seeing.
Feature #1: The plan-operate separation
The people who scope the AI investment do not carry the run-time consequence of their scoping choices. The strategy team defines the use case, the value hypothesis, and the target metric. That work is handed to a build team, which is handed to an operations team once the pilot is deemed complete. By the time the model is running in the business, the people who chose what it was for are two organisations removed from what it now does.
So the diagnostic feedback loop that AI products depend on never closes. The planners never see the run-time evidence. The operators never had authority over the scope. Whether the scope choice produced the value it predicted, and what the scope needs to become if it did not, is a question nobody is positioned to ask. The gap between the intended product and the deployed product is nobody’s job to reconcile. The pilot proves the concept and then the concept sits, because there is no ownership structure for the ongoing decisions that would make it a product.
Feature #2: The project funding boundary
Enterprise AI programs are funded as projects, and projects have a defined end. Funding is authorised to prove the concept, run the pilot, and hand it over. What is not funded is everything that has to happen after handover to make the pilot a system the business runs on: the second data pipeline, the model retraining cycle, the response to the first material behavioural drift, the redesign when users find a way to use it that nobody anticipated.
Those things all cost money and none of them are in the project. When they surface, they surface as unfunded work sitting on an operations team that was never resourced to do product development. The pilot goes into a support queue. Development stops. Six months after production release, the value curve flattens, because the funding envelope closed at handover. The technology did not stop working; the money that would have made it a product was never allocated. The next AI program is then approved with the same project shape and reproduces the outcome.
Feature #3: The discipline hand-off gate
Each function inside Plan-Build-Run optimises for its own deliverable. Strategy signs off when the business case is approved, delivery signs off when the pilot passes acceptance, and operations signs off when the system is stable in support. No function is measured on the outcome that spans all three: a working AI product that the business is using at scale and getting value from.
So the hand-off gates become the effective governance. Each gate is a moment at which a document is signed and the work becomes someone else’s problem. Because no one owns the path from investment to value, accountability for the outcome disperses at every boundary. The program is not failing because individuals are performing badly. It is failing because the operating model has no single accountable owner for the product’s whole life. Without that owner, the decisions that a live AI system needs made every week get made by no one, or by whoever happens to be in the room.
The cost only surfaces after several cycles
The immediate consequence of these three features is that AI investment does not yield operational products. That is uncomfortable but manageable in the first cycle. It becomes serious in the second and third.
Each cycle, the organisation gets better at running pilots and no better at running the products those pilots were supposed to become. The delivery machinery hardens around the phase model: vendors are procured against it, business cases are written against it, the funding calendar is built around it. The gap between what the executive committee believes the AI portfolio is producing and what is actually operating in the business widens with every approval cycle. McKinsey’s Rewired to Outcompete found that companies capturing meaningful value from digital and AI investment had rebuilt the operating model, not the delivery method, to sustain the product past deployment. Companies that did not made repeated investments and captured little of the promised value (McKinsey, 2023).
By the fourth or fifth cycle, direct spend on pilots that never became products is the smaller cost. The larger cost is the erosion of executive confidence in the AI portfolio as a category, and the loss of the strategic advantage the investments were meant to create. Once that ground is ceded, buying it back costs orders of magnitude more than the original investment would have.
The question before your next approval
What this means for senior leaders: Before signing off the next AI investment, one question changes what you are actually approving. Ask your CFO this: once this system is in production, which single team holds the budget, the accountability, and the authority to keep developing it, and is that funding continuous or does it end at go-live? If the honest answer names three teams and a funding envelope that closes at handover, you are approving another pilot regardless of what the paper calls it. The Plan-Build-Run structure will do to this investment exactly what it did to the last three.
The executive who sees where continuous ownership sits before the money is committed is working with a different AI portfolio eighteen months later than the one who inherits a set of pilots that no single team was ever structured to own (Hodgson, 2026).
References
- Hodgson, M. (2026). Evolve: The operating model AI demands. Chapter 2: Plan-Build-Run is producing the failure. Zen Ex Machina.
- McKinsey & Company. (2023). Rewired to outcompete.
