Production adds conditions a demonstration does not reveal
During a demonstration, someone selects the document, watches the run and resolves problems immediately. Real work brings simultaneous requests, absent reviewers, unexpected attachments and slow external systems. A rollout plan should make these differences explicit and assign responsibility for their consequences.
Before expanding scope, record the active version, included processes, accounts, limits and stopping criteria. Production should not depend on the constant presence of the person who built the prototype. The operations team needs to know the alternative procedure and be able to activate it. Rehearse that handover with someone who did not develop the system.
Four modes to select for the process
Design shadow mode so it cannot produce external effects. An apparently experimental connector can still write data when it uses operational credentials. The boundary must be technically verifiable, not merely part of the demonstration instructions.
Scroll the table to compare all columns.
| Mode | System behaviour | Evidence before advancing |
|---|---|---|
| Offline evaluation | Processes cases without changing live systems | Expected outcomes and critical cases checked |
| Shadow mode | Produces parallel results without influencing the process | Comparison with real work and measured load |
| Approved drafts | Prepares actions performed only after review | Sustainable queue and working approval controls |
| Limited operational scope | Performs allowed actions on a defined category | Tested monitoring, stopping and recovery |
Illustrative example: enabling document extraction
The pilot reads one document format and prepares a draft. The first release includes that format and an identified user group; other documents retain the manual path. The team checks correct fields, review volume, waiting time and unrecognised cases.
If a supplier changes its layout, that format can be routed to review without stopping the others. Adding a second language or different documents requires its own evaluation cases. Success on the first format is not sufficient evidence for every company document. Keep scope rules explicit so new inputs do not silently become production commitments.
Prepare stopping and recovery before they are needed
Google SRE describes canary releases that expose a change to part of the traffic before broader rollout. For business processes, adapt the principle to meaningful categories, users or locations rather than inventing a universally safe percentage.
- Identify who can pause new processing and the command or procedure they use.
- Define what happens to active and queued cases.
- Separate reverting the software version from correcting effects already produced.
- Preserve a list of cases needing reconciliation after an incident.
- Test the manual path and restart procedure as well as the stop control.
Hand over a system the team can operate
Handover includes operating instructions, company-controlled accounts, incident contacts and repeatable evaluation cases. Give each alert an owner and an action: a dashboard nobody checks is not an operating procedure.
Agree when to review scope and which signals trigger an earlier check: more exceptions, new formats or model and integration changes. Document the decision to expand, maintain or reduce autonomy. Release starts ordinary system operation; it does not remove the need to review how the process behaves as the business changes.
A template to work from.
AI rollout plan
A staged plan with owners, acceptance evidence and instructions for stopping and recovering work.
Download the Markdown templateAI operations runbook
Instructions available to the responsible team: signals, alerts, initial diagnosis, recovery and periodic review.
Download the Markdown templateAutomation handover worksheet
A handover record with accessible materials, accepted responsibilities, an operating exercise and assigned outstanding work.
Download the Markdown templatePractical questions
How long should the pilot run?
Until it provides sufficient evidence on the agreed cases and conditions. A fixed duration without representative volume or exception testing does not establish readiness.
Can we move directly to full automation?
It depends on the process and consequences. You still need evidence on real cases, enforceable boundaries, monitoring and tested recovery. Draft mode is often useful for measurement.
Does rollback undo completed actions?
No. Restoring a software version does not remove sent emails or changes already recorded elsewhere. Reconciliation and correction need a separate plan.
References and method
Progressive release and observation before expansion. The modes and scenario are operational adaptations proposed by Stolen Orbit.