Eleven Gates Between an AI Pilot and Production, and Only Two of Them Are Technical

Which eleven things must be true before a pilot is production?

Eleven conditions have to hold at the same time before an AI pilot can honestly be called production, and only two of them are technical. The nine that remain are operational: ownership, escalation, fallback, exception rules, cost basis, spend ceilings, downstream readiness, a baseline measured on live traffic, and a data decision with a name on it.

Every pilot I have been asked to look at was already performing those nine informally, usually through one person who read the outputs and quietly fixed what was wrong. That work appears in no pilot report, so it appears in no rollout plan, and the rollout inherits the workflow without it.

Eleven conditions must hold before an AI pilot becomes production, and nine of them are operational rather than technical, so the decision that governs the outcome is a supervision and ownership decision, not a model decision.

Where each kind of gate fails is why the balance falls the way it does. A technical gate fails at build time, loudly, in front of the engineers who can fix it. An operational gate fails ninety days after go-live, quietly, as a wrong output that reaches a customer — by which point the pilot budget has closed, the person who used to catch it has been reassigned, and the remedy is a headcount conversation rather than a pull request.

What are the eleven gates, and how do you check each one in a week?

Each row is checkable now, with people you already have, without a new tool.

#	Gate	Type	How you verify it this week	What it costs to skip
1	Input contract: what a well-formed job is, and what a malformed one does	Technical	Feed it twenty of last month's bad inputs and count the rejections	Quality drifts with no error raised
2	Run record: per-run cost, model and prompt version, captured input	Technical	Ask for last week's worst run; time how long it takes to assemble	The first expensive failure cannot be explained or fixed
3	A named owner with hours in their week	Operational	Find the name in a job description or resource plan	The workflow has an audience, not an owner
4	Escalation with a second name and a response clock	Operational	Send a test exception, see who answers inside the clock	Exceptions pile up in a queue nobody owns
5	A fallback still staffed and exercised in the last thirty days	Operational	Run the manual path once on purpose and write down what broke	An outage reveals the fallback retired itself months ago
6	A written exception policy: which outputs are held, and who may release them	Operational	Apply the rule to three outputs already sent	One plausible wrong output leaves with your name on it
7	Cost per successful run, a ceiling, and stop authority that needs no meeting	Operational	Ask for last month's figure with abandoned runs in the numerator	Spend rises in a flat-volume month and no step can be blamed
8	A review cadence with a drift threshold	Operational	Check the recurring review exists on a calendar for the next ninety days	Drift gets dated by argument instead of by record
9	A downstream process changed to accept the output	Operational	Watch one run from trigger to final use, counting the re-keying	You automated one step and created a copy-paste job
10	A baseline measured on live traffic, not the pilot sample	Operational	Score 500 live runs against the metric you reported	You manage a number that no longer describes the system
11	Data decision: retention window, deletion path, named approver	Operational	Ask for the retention setting and the per-subject deletion runbook	One deletion request becomes a project with a deadline

Why are the technical gates the cheap half?

Both technical gates are bounded, one-time, and buyable. An input contract is a schema, a rejection path, and a decision about what an invalid job does — days of work, reviewable like any other interface. A run record is smaller than teams expect: built alongside the workflow, it added two to four engineer-days to a three-week job in my own experience. Retrofitted onto something already running, the same work takes two to four weeks, because you are reconstructing decisions nobody wrote down and reconciling them against logs that may have aged out of retention.

The design question underneath the second gate is which fields make a failure explainable afterwards — the version stamps, the input hash, the attempt index, the terminal state. There is a detailed treatment of how to record an AI workflow run so a failure is reproducible after the fact, and it belongs with whoever builds this, because those choices are cheap during construction and expensive to add later.

Why do the nine operational gates resist being bought?

Because none of them is a deliverable. Each is a recurring commitment held by a person inside your company, and no vendor can hold it for you: what is being committed is attention, not software.

They are also individually small, which is exactly why they get cut. A review cadence is two hours a month; a fallback drill is an afternoon. Nobody objects to any single one, and when planning tightens there is no artifact to point at, so the line disappears and the workflow runs a quarter without it.

Three of them are interdependent, which is why partial adoption collapses. An escalation clock is meaningless without a written exception policy, because the second person cannot be paged about a category that has never been defined. A fallback cannot be drilled without an owner who has hours. The nine are adopted as a set or they are performed by one person until that person leaves.

What do the eleven cost, and which figures are knowable?

Two external figures are worth knowing, clearly labelled as estimates about populations rather than predictions about your workflow. A RAND report from August 2024 estimated that more than 80 percent of AI projects fail, roughly twice the failure rate of non-AI IT projects. Gartner forecast in July 2024 that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025 — abandoned, not failed, meaning projects that worked and were dropped. Both describe the same gap, and neither tells you anything about your own numbers.

Your own numbers are knowable, and they divide the same way the gates divide.

Line	Once or recurring	Figure I use	Basis
Technical gates 1 and 2	Once, at build	2 to 4 engineer-days onto a three-week workflow	My estimate from workflows I have shipped; 2 to 4 weeks if retrofitted
Gates 3, 4 and 6 in the first month	Recurring	One dedicated person for month one, then 1 to 2 hours a week	My estimate, roughly 0.1 to 0.25 of a role
Gates 5 and 8	Recurring	About 3 hours a month	My estimate
Gates 2 and 11 storage	Once, then steady	Tens of kilobytes per run, under 100 MB a month at 2,400 runs	Measured on run records I keep

Then do the arithmetic on volume and exceptions, because it decides whether you are choosing supervised or unsupervised operation. Six thousand jobs a month at a 0.4 percent exception rate is twenty-four exceptions — about one per working day. During the pilot that was one person's afternoon each week. In production it is nobody's inbox, and it stays invisible until an audit or a customer finds the pattern.

The metric to put in the budget line is cost per successful run: total spend in a window divided by successful runs in the same window, with abandoned runs counted in the numerator. It is auditable, it survives a change of provider, and it refuses to flatter a workflow that retries its way to a correct answer.

Which gates fail first in practice?

Gate 5, the fallback, and gate 6, the exception policy. The fallback fails because everybody remembers a manual process that ran for years and assumes it is still available; the people who knew it have moved on, and nobody noticed the handover never happened. The exception policy fails because during the pilot the operator used judgement, and judgement does not transfer to a document that was never written.

Gate 3 fails most expensively, because an owner without allocated hours is an announcement. I ask for the name before any rollout approval, and for whose current work gets deprioritised to answer a page; if the answer is nobody's, the owner is decorative.

Gate 9 surprises people most. Automating a step does not change the process around it, so teams end up with an AI output that a human re-types into the system of record: the manual work is smaller, the cycle time is not, and the headcount case collapses on inspection.

What do you do when a gate cannot be met by the date?

Three options, and only one of them is usually chosen. Narrow the scope until all eleven hold: a workflow handling three document types with every gate closed is worth more than one handling twenty with nine. Ship supervised, with a written commitment to a named reviewer and a date for removing the supervision, priced as an operating cost rather than a temporary condition. Or do not ship, and keep the pilot running while the gates close.

What is not on the list is shipping and telling yourself the model will cover the tail. That option loses money twice: once in the incident, and again in the credibility of the team asking for a second attempt.

What should be on one page at the pilot review?

Put the eleven on a single sheet, with a name and a date against each one, and bring it into the review instead of a slide about accuracy. Two lines will be closed within a week by the people who built the workflow, because they are bounded engineering tasks with a definition of done. The other nine will take a quarter and a signature each, and they are the reason a second attempt at the same rollout usually works when the first one did not. The question in that room is not whether the model is good enough — you would not be holding the review if it were not — it is whether the company is willing to own the nine things one person has been doing quietly since the pilot started.