BlogDelivery
What must be in place before an AI pilot goes into production
A pilot shows that a system can do the work while its builders watch. Production needs what lets other people run it when nobody is watching: a regression test set that runs on every change, versioned prompts and models with a rollback path, monitoring of quality and cost as well as uptime, a named owner with a support route, and a staged rollout. Check these in a readiness review before the switch, not after the first incident.
What changes when the pilot team stops watching
- Noticing failures. In the pilot, the builders read most outputs. In production, monitoring and a sampled review have to find what goes wrong.
- Changing the system. A prompt edited in a notebook becomes a versioned release that goes through a pipeline and can be rolled back.
- Testing. Anthropic's evaluation guidance separates capability evals, which start with a low pass rate and show what to improve, from regression evals, which should pass almost entirely and protect what already works. Production needs the second kind.
- Support. A message to the developer who built it becomes a support route, a runbook and someone on call during the hours the process runs.
- Volume. A few hundred test cases become full volume with peaks, provider rate limits and the occasional outage.
A readiness review borrowed from SRE
Google's SRE teams run a production readiness review before they accept responsibility for a service, using a checklist specific to that service. It asks, for example, whether all user-visible failures are monitored with alerting and whether errors reach central logging. For an AI process service, the checklist adds items that classic services do not have.
- 1
Regression suite
Held-back cases plus every failure found in the pilot, run on each change to a prompt, model, tool or retrieval setting. A regression blocks the release.
- 2
Versions and rollback
Prompts, model identifiers and tool definitions are versioned together, and the previous version can be redeployed. The AWS Generative AI Lens recommends versioned prompt templates for exactly this reason.
- 3
Monitoring
Errors, latency and cost per case, plus quality signals: the sampled error rate, the escalation rate and periodic runs against the ground truth set to catch drift.
- 4
Targets with consequences
A few targets for quality, turnaround and cost, with an agreed action when one is missed. The SRE book advises keeping objectives few and simple.
- 5
Safe failure
When the model provider times out or is down, cases go to the manual queue and are not lost or half processed.
- 6
Owner and support
A named owner, a support route for the hours the process runs, and a runbook for the failures seen so far.
A hypothetical go-live gate
Imagine a claims triage pilot that met its acceptance criteria. At the readiness review, the regression suite passes, a rollback has been rehearsed in staging, the sampled error rate appears on a dashboard and a team lead in claims has accepted ownership. One item fails: nobody has tested what happens when the model provider is unavailable. Go-live waits until a staged outage shows cases landing in the manual queue. A single open item is enough to postpone go-live, because it covers a failure path nobody has yet seen work.
Handing over to the team that will run it
In Google's model, the reviewers train the receiving team with design overviews, deep dives into request flows and hands-on exercises, then transfer responsibility step by step while the developers stay available as backup for a period. For an AI system, the exercises are specific: read failure transcripts together, run the regression suite on a proposed prompt change, perform a rollback and explain a jump in cost per case. Define the end of the backup period by an event, such as the operating team handling a rollback alone, rather than by a date.
Switching on in stages
The AWS lens describes deployment as a controlled rollout that scales to real data and usage. For a process, that usually means a shadow stage where the system runs and people still do the work, an assisted stage where the system proposes and people decide, then one case type or one region at a time. Each stage needs its exit criteria and its rollback trigger written down before it starts. Broader questions about running many agents across an engineering organisation belong to our article on the autonomous software factory.
The autonomous software factoryWho owns an AI system after the pilot
Questions
How long should the pilot team stay involved after go-live?
Until the operating team has handled the events that matter without help, such as a rollback, a provider outage and a release through the regression suite. Agree those events in advance so that the end of the handover is visible.
Does an AI process need round-the-clock on-call?
It depends on when the process runs and how it fails. If a failure sends cases safely to a manual queue, support during the process's working hours may be enough. That is the owner's decision, made with the failure behaviour tested.
Does the checklist apply if the pilot used a vendor's product?
Yes. Some items become questions for the vendor, such as how model changes are announced and whether a previous version can be restored. Your own regression suite remains the way to check the answers.
Related services
More from the blog
Autonomous software factory
What it takes for coding agents to carry scoped work from issue to merge, which work fits, and where people stay in control.
AI system ownership
Who owns the prompts, models, data, test set and failures of an AI system once the pilot team leaves, who approves which change and who can switch it off.
AI pilot success criteria
What an AI pilot has to show before the next stage is funded, and how to write acceptance criteria before anyone chooses a tool.
Sources
- The Evolving SRE Engagement Model, chapter 32 of Site Reliability Engineering (Google)
- Demystifying evals for AI agents (Anthropic, January 2026)
- Generative AI lifecycle, AWS Well-Architected Generative AI Lens
- GENOPS03-BP01 Implement prompt template management, AWS Well-Architected Generative AI Lens
- GENOPS01-BP01 Periodically evaluate functional performance, AWS Well-Architected Generative AI Lens
- Service Level Objectives, chapter 4 of Site Reliability Engineering (Google)
Talk to an engineer
Bring one piece of work you would like to improve. The call takes 30 minutes and needs no access to your systems or your data.
Booking runs on Google Calendar.
Prefer to write first? Leave your email and a few lines, and we reply with times.
Look for the draft in your email program
Send it from there, and an engineer replies in person with times for a 30-minute call. If no draft has opened, write to us at miki@cloudsail.com.