Building Safe AI Automation Workflows

The loop

A safe AI automation workflow is a sequence of gates. Each stage produces a record the next stage depends on, and no stage can be skipped.

1. 01PlanTargets, steps, expected results, risk and rollback, written down as a versioned artifact.
2. 02ApproveAn authorised person approves that exact plan version.
3. 03ExecuteA deterministic executor runs only the approved steps.
4. 04ValidateIndependent read-only checks compare observed state with expected results.
5. 05ReportA report is generated from the records, not from memory or a summary.

Plan

A plan is an artifact, not a conversation. It lists the exact targets, each step with its expected result, the pre-checks and post-checks, the stop conditions and the rollback. Giving the plan a version and a content hash makes it possible to prove later that what ran is what was approved.

Approve

• Bind approval to the plan's hash. Any edit, including a different target or argument, requires a new approval.
• Separate duties: whoever or whatever proposed the plan cannot approve it.
• Make approvals expire, so an old approval cannot be reused for a change made weeks later.

Role-based authorisation

• Requester: describes the need and the business context.
• Engineer: owns the technical plan, reviews AI proposals and decides.
• Approver: authorises changes within a defined risk level.
• Operator or runner: executes released work and cannot alter it.
• Auditor: reads plans, evidence and reports without changing them.

AI components act within these roles, never above them. They can draft and analyse, but authority stays with people.

Execute

The executor runs the released plan with bounded time per step and records a receipt for each action: sent, applied, failed or unknown. A lost connection is recorded as unknown, not as failure or success, because the change may have been applied.

Failure handling

• Stop on the first failed check rather than continuing with the remaining steps.
• Do not retry a change automatically. Read the real state first, then decide.
• Keep partial evidence; failed runs are part of the record and are not deleted.
• Let a person decide on rollback, using the rollback defined in the plan.

Evidence collection and validation

Evidence is what turns a claim into a verifiable result: pre- and post-change state, the commands or API calls with secrets masked, timestamps, tool and package versions, and hashes linking evidence to the plan. Validation should only report PASS when the evidence shows the expected state for every target. A target with no evidence cannot pass; a partial reading is a warning, not a success.

Report and audit trails

Generate reports from the recorded plan, approvals, receipts and verification results. Freeze each report with a version, so later edits create a new version instead of rewriting history. Combined with an append-only log of handoffs between people and automated components, this gives auditors a complete chain from request to result.