# AI rollout plan

Define how a project moves from testing into real operations. Increase exposure only after checking quality, review capacity and the handling of exceptions.

Revision: 2026-09-24

## When to use it

Before activating a workflow, enabling external actions or extending an automation to new users and higher volumes.

## Expected output

A staged plan with owners, acceptance evidence and instructions for stopping and recovering work.

## 1. Check entry conditions

Confirm the tested version is the version being released. The people operating the process must be able to find instructions, access and support channels.

### Version and scope

List configuration, systems, users and included case categories; explicitly separate what remains excluded.

________________

### Evidence required before release

Link evaluation results, integration tests, permissions and checks of the human review path.

________________

### Release owner and support

Identify who authorises activation, who watches the first cases and who provides cover.

________________

> Illustrative example, replace with your own: Illustrative example: activate an identified version for one request category. The owner also verifies that rejected cases reach the manual work queue.

## 2. Define the stages

Choose a progression appropriate to the system’s effects. A read-only or draft stage can expose outcomes without executing final actions.

### Stages, cohorts and observation

Describe which cases enter each stage and how much evidence to gather before considering expansion.

________________

### Measures and progression criteria

Include critical errors, review time, queues, completion and reconciliation; set conditions appropriate to the risk.

________________

### Recorded stage decision

Specify who decides to expand, correct or stop and which results they must examine.

________________

> Illustrative example, replace with your own: Illustrative example: generate internal drafts first, then enable them for a small reviewer group. Expansion depends on queue capacity as well as average quality.

## 3. Prepare stopping and recovery

Stopping software does not unsend emails or reverse completed writes. Plan how to distinguish completed, pending and uncertain cases.

### Stopping conditions

Specify events requiring immediate suspension and problems that allow only one category to be restricted.

________________

### Fallback and communication

Explain how manual work resumes, how users are informed and how queued cases are preserved.

________________

### Recovery and reauthorisation

Define effect reconciliation, corrections, tests to repeat and conditions for enabling the workflow again.

________________

> Illustrative example, replace with your own: Illustrative example: a duplicate order suspends automatic creation. Before reactivation, reconcile orders from the affected window and verify the correction.

## Pitfalls to avoid

- Using a calendar date as the only condition for expanding a release.

- Testing the stop procedure only after the first incident.

- Confusing a software rollback with reversal of effects already produced.

Stolen Orbit — https://stolenorbit.com/en/templates/ai-rollout-plan/