Security · Operating decision guide

When should an operator stop an AI workflow?

Otomat editorial · Revised 5 November 2026

Stop the affected capability when its output or action crosses an agreed boundary. Contain the incident, preserve a minimal evidence record and require a scoped acceptance test before restarting.

Define the stop before the incident

Specify failures that must block further action: a restricted record exposed, an unauthorized write, a repeated incorrect commitment or loss of a required source. Name the person who can disable the capability and the person who can authorize restoration. If the only knowledgeable builder is unavailable, the operating team still needs a documented way to prevent further harm.

Contain without spreading the data

Disable the affected tool, permission or workflow and route urgent work through an approved fallback. Preserve versions, timestamps, action identifiers and a limited sample needed for investigation. Avoid pasting sensitive incident content into an unapproved AI tool or a broad chat channel. Follow the company’s established incident and notification process; this checklist does not determine legal notification obligations.

A stop-and-restart decision record
Check	Evidence to bring	Decision or stop condition
Containment	Affected action, disable path and accountable operator	Stop the exposed capability while preserving approved urgent-work routing.
Evidence	Versions, timestamps and minimal permitted reproduction	Avoid copying incident data into unapproved systems.
Correction	Boundary that failed and negative tests that now pass	Do not treat changed wording as a permission repair.
Restart	Acceptance owner, bounded scope and monitored first cases	Resume only the capability supported by the new evidence.

Find the failed boundary

Distinguish a wrong answer from a permission failure or an incorrect downstream action. Identify the source, instruction, identity and tool behavior involved. Reproduce the failure using permitted or synthetic material. A new prompt may improve an answer while leaving the underlying permission defect intact. Ask which control should have stopped the action regardless of the model’s wording.

Restart with a smaller claim

Test the corrected boundary, the original failure and nearby cases that might regress. Confirm the manual queue and customer obligations have been reconciled where applicable. Restore the minimum accepted capability, watch the first cases and keep the prior version available. An incident being closed in a tracker is not by itself evidence that the workflow is safe to resume.

Questions before the decision

Does every wrong answer require a full shutdown?

Use the agreed severity and action boundary. An inaccurate draft and an unauthorized payment instruction have different consequences; define the response before relying on the workflow.

Can the builder approve the restart alone?

Use the company’s decision rights. The operating owner and relevant security or risk owner should accept the corrected behavior within their authority.

Take the evidence sheet to the meeting

Download the blank CSV, assign an owner to each check and record the evidence. Keep completed sheets in your own approved system.

Download the evidence sheet (CSV)

Use the working tools

Blank templates are ungated. Adapt them to the workflow; inputs are not submitted.

Open the operating charter

Sources and limits

These are Otomat’s proposed operating methods and original decision artifacts. External references inform risk management; they do not certify this method or establish client results. Linked sources were selected for this review; their live revision dates may change.

For anonymous documentation and proposal patterns, see delivery evidence and its boundaries.

Related decisions

Bring a workflow to the discussion

Share the business goal and constraints through the mandate process. Do not send sensitive production data in the initial brief.