AIPOM Risk-Control Incident Playbook
What Is It
Connect material AI risks to preventive controls, detection, triage, containment, fallback, rollback, communication, evidence preservation, investigation, remediation, learning, and external reporting where applicable.
Why Use It
Policies do not stop incidents, and generic software response may miss probabilistic behavior, model or context changes, human overreliance, affected groups, vendor dependencies, and regulatory reporting duties.
When to Use It
Use before operation or expanded autonomy, and revise after material change, near miss, incident, or exercise. Engage accountable legal and regulatory specialists; this playbook does not determine compliance or reporting obligations.
What It Produces
- Risk-to-control and detection map
- Severity, triage, containment, rollback, and escalation rules
- Roles, decision authority, communications, evidence preservation, and reporting routes
- Exercise, remediation, learning, and verification plan
Who Should Participate
Include the Team Lead, Product Manager, Product Operations where present, product and technical owners, operations, security, privacy, legal, risk, communications, domain experts, affected-user representation, and the accountable executive.
Evidence to Bring
Bring behavior contracts, autonomy boundaries, scorecards, monitoring, data and context flows, dependencies, incident systems, policies, prior failures, reporting duties, contacts, and tested rollback mechanisms.
How to Do It
- Define system scope, consequences, affected parties, jurisdictions, and accountable owner.
- Map hazards and failure modes to preventive, detective, corrective, and recovery controls.
- Define signals, severity, confidence, triage, and thresholds for containment or stop.
- Assign incident command, technical action, product decision, communications, specialist review, and accountability.
- Specify safe state, fallback, rollback, access restriction, and vendor escalation.
- Define internal and external communications, affected-party support, and required reporting routes with specialists.
- Preserve logs, versions, inputs, outputs, context, decisions, and chain of custody without destroying evidence through premature changes.
- Define investigation, root and contributing factors, remediation, verification, and reopen criteria.
- Feed learning into behavior, evaluation, context, controls, training, and portfolio decisions.
- Run tabletop and technical exercises; record observed gaps and owners.
Key Concepts
- Detection must map to an authorized action.
- Safe state differs by product and consequence.
- Near misses are operating evidence.
- Investigation should preserve evidence and avoid scapegoating operators.
Organizational Applications
Use for harmful outputs, unauthorized actions, privacy or security events, evaluation regression, context corruption, vendor failure, automation bias, and affected-group harm.
Common Pitfalls
- Copying a generic incident plan without AI behavior
- Defining severity with no affected-party view
- Naming rollback that has never been tested
- Changing the system before preserving evidence
- Making legal or communications review the incident commander
- Closing incidents without verifying remediation
Combine With
Use aipom-production-evidence-review for recurring signals, aipom-trust-assurance-pack-builder for current trust evidence, and aipom-initiative-readiness-review to block launch when recovery is unready.
Assets and Templates
- Risk-control incident template
- Synthetic worked example
- Weak example
Sources
- NIST AI Resource Center, AI RMF Core. Manage 4 covers monitoring, incident response, recovery, communication, and change management. Accessed July 17, 2026; NIST notes AI RMF 1.0 is under revision.
- European Union, Regulation (EU) 2024/1689, especially Articles 9, 72, and 73 on lifecycle risk management, post-market monitoring, and serious-incident reporting for systems in scope. Accessed July 17, 2026.
- OECD.AI, AI Incidents. Supports consistent incident concepts and learning from reported risks and incidents. Accessed July 17, 2026.
Requirements vary by role, system, sector, and jurisdiction. Completing this skill does not establish compliance or replace specialist judgment.
1---2name: aipom-risk-control-incident-playbook3description: Design preventive controls, detection, triage, containment, rollback, communication, investigation, remediation, learning, and reporting for AI incidents.4---56# AIPOM Risk-Control Incident Playbook78## What Is It910Connect material AI risks to preventive controls, detection, triage, containment, fallback, rollback, communication, evidence preservation, investigation, remediation, learning, and external reporting where applicable.1112## Why Use It1314Policies do not stop incidents, and generic software response may miss probabilistic behavior, model or context changes, human overreliance, affected groups, vendor dependencies, and regulatory reporting duties.1516## When to Use It1718Use before operation or expanded autonomy, and revise after material change, near miss, incident, or exercise. Engage accountable legal and regulatory specialists; this playbook does not determine compliance or reporting obligations.1920## What It Produces2122- Risk-to-control and detection map23- Severity, triage, containment, rollback, and escalation rules24- Roles, decision authority, communications, evidence preservation, and reporting routes25- Exercise, remediation, learning, and verification plan2627## Who Should Participate2829Include the Team Lead, Product Manager, Product Operations where present, product and technical owners, operations, security, privacy, legal, risk, communications, domain experts, affected-user representation, and the accountable executive.3031## Evidence to Bring3233Bring behavior contracts, autonomy boundaries, scorecards, monitoring, data and context flows, dependencies, incident systems, policies, prior failures, reporting duties, contacts, and tested rollback mechanisms.3435## How to Do It36371. Define system scope, consequences, affected parties, jurisdictions, and accountable owner.382. Map hazards and failure modes to preventive, detective, corrective, and recovery controls.393. Define signals, severity, confidence, triage, and thresholds for containment or stop.404. Assign incident command, technical action, product decision, communications, specialist review, and accountability.415. Specify safe state, fallback, rollback, access restriction, and vendor escalation.426. Define internal and external communications, affected-party support, and required reporting routes with specialists.437. Preserve logs, versions, inputs, outputs, context, decisions, and chain of custody without destroying evidence through premature changes.448. Define investigation, root and contributing factors, remediation, verification, and reopen criteria.459. Feed learning into behavior, evaluation, context, controls, training, and portfolio decisions.4610. Run tabletop and technical exercises; record observed gaps and owners.4748## Key Concepts4950- Detection must map to an authorized action.51- Safe state differs by product and consequence.52- Near misses are operating evidence.53- Investigation should preserve evidence and avoid scapegoating operators.5455## Organizational Applications5657Use for harmful outputs, unauthorized actions, privacy or security events, evaluation regression, context corruption, vendor failure, automation bias, and affected-group harm.5859## Common Pitfalls6061- Copying a generic incident plan without AI behavior62- Defining severity with no affected-party view63- Naming rollback that has never been tested64- Changing the system before preserving evidence65- Making legal or communications review the incident commander66- Closing incidents without verifying remediation6768## Combine With6970Use `aipom-production-evidence-review` for recurring signals, `aipom-trust-assurance-pack-builder` for current trust evidence, and `aipom-initiative-readiness-review` to block launch when recovery is unready.7172## Assets and Templates7374- [Risk-control incident template](template.md)75- [Synthetic worked example](examples/worked-example.md)76- [Weak example](examples/weak-example.md)7778## Sources7980- NIST AI Resource Center, [AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/). Manage 4 covers monitoring, incident response, recovery, communication, and change management. Accessed July 17, 2026; NIST notes AI RMF 1.0 is under revision.81- European Union, [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), especially Articles 9, 72, and 73 on lifecycle risk management, post-market monitoring, and serious-incident reporting for systems in scope. Accessed July 17, 2026.82- OECD.AI, [AI Incidents](https://oecd.ai/en/site/incidents/). Supports consistent incident concepts and learning from reported risks and incidents. Accessed July 17, 2026.8384Requirements vary by role, system, sector, and jurisdiction. Completing this skill does not establish compliance or replace specialist judgment.
Dean Peters