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.

Updated

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. 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. 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. 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. 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. 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. 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.

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.

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.

The button prepares an email in your own email program, for you to send. Privacy policy (draft)