AI Incidents and Change Management

Fact-check status

Reviewed claim by claim on 2026-09-02 against the primary or official sources identified inline as S1 and S2. Recommendations are design guidance unless a cited standard makes them normative.

Key jargon

Term	Plain-language meaning
Incident	An event that harms or threatens users, systems, data, compliance, or service objectives. S1
Containment	Immediate action limiting an incident's reach or impact. S1
Root cause	The underlying conditions that allowed the incident, beyond its visible symptom. S1
Post-incident review	A structured analysis producing evidence, lessons, owners, and corrective actions. S1

Key concepts

AI incidents can originate in models, prompts, data, retrieval, tools, providers, policy, or human workflow. S1
Preserve evidence and version identity before changing the system, then convert findings into regression tests. S1

Concept map

flowchart LR
    A["Detect and classify incident"] --> B["Contain and preserve evidence"]
    B --> C["Recover known-good service"]
    C --> D["Learn and add regression case"]

Diagram semantics verified against S1 and S2 on 2026-09-02.

Incident classes

Sensitive disclosure, harmful or unauthorized effect, prompt injection, poisoned retrieval, model/provider outage, severe quality regression, runaway cost, policy bypass, data-rights issue, or misleading high-impact decision. S1

Response

Stop or reduce affected capability. S1
Preserve run, model, prompt, retrieval, tool, identity, and effect evidence. S1
Revoke credentials or tool authority where needed. S1
Determine affected users/data/actions. S1
Roll back the complete versioned system. S1
Notify required owners and stakeholders. S1
Add representative regression tests before re-release. S1

Exercise

Tabletop a retrieval assistant citing a poisoned document. Define detection, containment, corpus rollback, affected-answer search, user communication, and new evaluation cases.