The model works. The benchmark holds. The demo runs cleanly in front of the executive sponsor. Six months later the pilot is either quietly deprioritized, indefinitely “in evaluation,” or technically live but used by no one. The same pattern repeats across companies, industries, and model generations.
The diagnosis is almost never the model. It is three ownership questions that nobody answered before the pilot was approved, and that production exposes the moment the system has to run without a project team standing behind it.
Diagnosis
The pilot environment hides everything that matters
A pilot is a controlled environment. Someone wires the data, someone manages the workflow, someone explains the output to whoever is in the room. The pilot succeeds because a small team is doing all the work that production is supposed to do automatically.
When the pilot moves to production, that team disbands. The work they were doing does not. It just has no owner. Three categories of work, three missing owners, three predictable failure modes.
Each one is independently sufficient to kill the production version. Most pilots that fail hit at least two of the three.
Data
Failure mode 1: nobody owns the data pipeline
In the pilot, someone wired the data by hand. CSV exports from one system, manual joins against a second, a one-off script someone wrote on a Friday to reshape the third. The model got fed clean inputs. The output was good. Everyone agreed the pilot worked.
In production, the data engineering team has to take that pipeline over. Except they were not in the pilot. They do not know the system exists, do not know what it consumes, and have no allocated budget for the ingestion work. Their roadmap is set quarters in advance. The pilot’s data needs land on their backlog as an unfunded request from a team they have never worked with.
The cost of building production-grade ingestion for an AI system is routinely an order of magnitude higher than the cost of the original AI build itself. Reliable streaming, schema enforcement, monitoring, backfill capability, lineage, the security review that comes with any new pipeline touching customer data: none of this existed in the pilot. All of it has to exist in production. None of it is on anyone’s plate.
The decision-relevant question is not whether the data engineering team can build it. They can. The question is whether they have been told to, with budget, before the pilot was approved. If not, the pipeline is the bottleneck and the model becomes irrelevant.
P&L
Failure mode 2: nobody owns the P&L
Innovation budget built the pilot. Innovation budget is for proving things work. It is not for keeping things running.
Production requires three things innovation budget cannot provide: a recurring line item in someone’s operating budget, an SLA that someone will get paged for at 3 AM, and a person whose performance review depends on uptime. Innovation teams do not own SLAs. They own pilots. The handoff is not a budget transfer. It is a transfer of accountability across reporting lines, and most enterprises do not have a clean playbook for it.
The org chart problem is the deeper version of this. Innovation typically lives under the CTO, the CDO, or a dedicated AI office. Production runs in the business unit that will use the system. The handoff requires the BU executive to accept the system into their P&L, fund it from operating budget, hire or reassign the operators, and own the consequences when it breaks. None of that happens unless someone with authority over both the innovation team and the BU forces the conversation.
The conversation rarely happens because nobody in the pilot phase had a reason to start it. Innovation gets credit for shipping the pilot. The BU has no incentive to volunteer for an unbudgeted obligation. So the pilot enters a holding pattern: technically working, nominally in production, structurally unowned.
The decision-relevant question is which executive has signed up for the operating cost on day one, before the pilot was funded. Not “supports it.” Not “is enthusiastic about it.” Has it on their budget, with a name and a number.
Workflow
Failure mode 3: nobody redesigned the workflow
This is the failure mode that looks like everything is fine until day 30, when the operations review shows the team using the AI system has the same headcount, the same cycle time, and the same backlog they had before the pilot started. Often worse.
The reason is operational. The team kept their existing process and added the AI on top. The senior analyst who manually wrote the credit memo now manually writes it and reviews the model’s draft. The claims adjuster who used to triage manually now triages manually and also rates the model’s recommendation. Two workflows running in parallel, one for the work and one for the AI, with the human in the loop on both.
The cost goes up, not down. The team did not save time. They added a step. The model is doing real work, but the savings the business case promised require the old work to stop. It did not stop, because nobody had the authority to make it stop.
The team that built the pilot is almost never the team that does the work. The pilot team has technical authority. They do not have process authority. Telling a senior analyst to retire the workflow they have used for fifteen years is a change-management decision that requires the operations leader to make it, document it, and enforce it. That decision was not in the pilot scope, was not assigned to anyone, and was not made.
The result is the most expensive failure mode of the three because it is invisible from the model side. The model is performing. The system is “in production.” The metrics that matter, cycle time, cost per transaction, throughput, did not move. Production looks fine and the business case has quietly failed.
The decision-relevant question is which operations leader has agreed to redesign the workflow before the pilot starts, and committed to retiring the old process on a specific date.
The Call
The gate before the pilot
The three failure modes share a structure. Each one is a question about ownership that the pilot phase does not surface and that production exposes. Each one is solvable. None of them are solvable retroactively.
The gate before approving any enterprise AI pilot is three names on a single slide:
The data owner. Named individual on the data engineering team, with budget allocated for production ingestion in the next planning cycle, signed off by the data leader.
The P&L owner. Named BU executive, with the operating cost in their budget, with an SLA they have agreed to be accountable for.
The workflow owner. Named operations leader, with a documented commitment to retire the old process by a specific date, on a defined success threshold.
If those three names are not on the slide, the pilot does not get approved. Not “approved with conditions.” Not “approved pending discussion.” Not approved.
This is not optional rigor. The pilot will succeed regardless. The model will work. The demo will run. Six months later the production version will fail for one of the three reasons above, and the post-mortem will conclude that the technology was not yet mature enough, when in fact the ownership structure was not yet decided.
If there is not a name attached to each of the three, you are not funding a pilot. You are funding a demo.