I've watched this play out four times in the last twelve months. An innovation team builds something impressive. An AI prototype that classifies documents, summarises reports, or triages requests. The demo goes well. Leadership is excited. And then someone asks the question that kills 80% of enterprise AI pilots: "Right. So who runs this in production?"
The Pattern
Here's how it works. The CEO reads an article, attends a conference, or gets pitched by a vendor. "We need to do something with AI." An innovation team is assembled, usually a few technical people with permission to experiment. They pick a use case, build a prototype, and demonstrate it to leadership.
The prototype is good. It does what it was designed to do in a controlled environment with curated data. Everyone agrees: this should go into production.
And then the handoff begins. Or rather, doesn't begin. Because nobody designed for the handoff.
87%
of AI projects never make it past the pilot stage
Source: Gartner, 2023
Why Handoffs Fail
Different Mandates
Innovation teams are mandated to explore. Their success metric is "did we prove this could work?" Operations teams are mandated to deliver reliable, predictable service. Their success metric is "did anything break today?"
These mandates create fundamentally different risk appetites. The innovation team thrives on uncertainty. The operations team eliminates it. Asking operations to adopt something built by innovation, with innovation's tolerance for edge cases and exceptions, is asking them to accept risk they're structurally incentivised to reject.
Different Standards
The prototype works in a demo. It handles the happy path well. It processes the ten example documents the team tested with. But production means thousands of documents with inconsistent formatting, missing fields, and edge cases nobody anticipated.
Innovation teams build to demonstrate feasibility. Operations teams need production standards: error handling, monitoring, fallback processes, documentation, and someone to call at 2am when it breaks.
The gap between prototype and production isn't a small polish step. It's often a full rebuild. And nobody budgeted for that.
No Organisational Home
The innovation team built it, but they're not responsible for running it. Operations didn't build it, and they don't feel ownership. IT wasn't involved in the architecture, and they have concerns about security and integration. The finance team hasn't approved the ongoing model costs.
The pilot sits in organisational limbo. Everyone agrees it's valuable. Nobody owns it. After a few months, the innovation team moves on to the next experiment, and the pilot quietly dies.
The pilot didn't fail technically. It failed organisationally. It had no home, no owner, and no budget beyond the experiment.
Tim Hatherley-Greene
Chief Operating Officer
Designing for the Handoff
Involve Operations from Day One
Not at the handoff. Not after the demo. From the start. An operations representative in the prototype team changes the questions that get asked: "How does this handle errors?" "What happens when the data quality drops?" "Who monitors this?" These questions feel like they slow innovation down. They actually speed up production.
Define Production Standards Before You Build
What does "production-ready" mean for this specific capability? Define it upfront. Security review. Data governance. Monitoring and alerting. Fallback process. Documentation. Support model. Cost model. If the innovation team knows these standards from the start, they can build toward them rather than discovering them at the handoff.
Budget for the Transition
The prototype cost $50,000. The transition to production will cost $150,000. This is normal. But most business cases only account for the prototype. When the transition budget is requested, it feels like scope creep or failure. It's neither. It's the actual cost of going from "this works" to "this runs."
Build the full lifecycle cost into the initial business case: prototype, transition, production operations, and ongoing maintenance. If the business case doesn't justify the full cost, the pilot shouldn't start.
Assign Ownership Before the Pilot Launches
Before anyone writes a line of code, answer: "When this works, who runs it?" If the answer is unclear, figure it out first. The operational owner should be involved in the pilot, shape the requirements, and be ready to receive the handoff on day one of production.
Create a Transition Team
For the 4-8 weeks between "pilot proven" and "production live," create a blended team. Innovation members who built it. Operations members who'll run it. A shared mandate: get this into production with production standards, then hand over completely.
This transition period is where knowledge transfer happens. Not through documentation (though that helps). Through working together. The operations team needs to understand not just what the system does, but why it was designed this way, what the edge cases are, and what to expect when things go wrong.
The Real Problem
The innovation-to-operations handoff isn't a process gap. It's a structural issue in how most enterprises approach AI. Innovation is treated as a separate activity from operations, with separate teams, separate budgets, and separate success metrics.
The organisations that will succeed with AI are the ones that blur this boundary. Where innovation is embedded within operational teams, not alongside them. Where the people who identify opportunities are the same people who'll use the solutions. Where "pilot" and "production" aren't separate phases but a continuous flow from experiment to operation.
That's harder to organise. It's less clean on the org chart. But it eliminates the handoff that kills most AI pilots.
If you're planning an AI pilot, my one piece of advice: start from the end. Design the production operating model first. Then work backward to the pilot. The pilot exists to prove that the production model is viable. Not the other way around.