Skip to content
Public trust standard

When AI work goes wrong: contain it, tell the truth, and change the job

An incident plan should be usable at 2 a.m. by someone who did not write the policy.

Published August 24, 2026 · Reviewed against current product boundaries

What counts as an incident

  • Customer or company information reached the wrong person or account.
  • An external action happened outside the approved rule.
  • The system produced or relied on a consequential false fact.
  • A connected provider or workflow failed silently.
  • Access remained active after it should have been removed.
  • A model, prompt, integration, or record change materially altered job behavior.

The first hour

  • Stop or narrow the affected job.
  • Preserve logs and the relevant records.
  • Revoke or reduce access if the connection is involved.
  • Name one incident owner.
  • Identify affected customers, records, and external actions.
  • Do not speculate in customer communication.

The next steps

Correct reversible external effects. Determine whether legal, contractual, security, privacy, insurance, or regulatory notification duties apply. Tell affected people what happened, what information or action was involved, what is contained, and what they should do.

Find the system cause behind the bad output: job design, source record, permission, approval rule, provider behavior, or human review.

Close the incident with a change

Document the timeline, scope, cause, correction, and new control. Retest the job before restoring it. A closed ticket with an unchanged workflow is not a resolved incident.