AI incident response against real clocks
Lesson 4 of 5 in Human Oversight, Post-Deployment Monitoring, and Incident Response.
An AI incident is an event where an AI system’s development or use caused — or, for a near miss, credibly almost caused — harm: to people, rights, property, infrastructure, or the organisation itself. The definition matters operationally because what you classify as an incident determines what gets investigated, reported, and learned from. Programs that only count outages miss the characteristic AI failures: the quietly biased quarter, the confidently wrong chatbot, the drifted model denying the wrong people.
AI incidents differ from classic IT incidents in three ways that reshape the playbook. Detection is statistical — there is often no crash, only a metric sliding or a pattern of complaints, so monitoring thresholds and complaint channels are your smoke detectors. Scope is retroactive — when a model has been wrong for six weeks, every decision in that window is suspect, and remediation means re-scoring past cases, not just fixing forward. And containment has AI-specific moves:
- Rollback to the previous model version (which you kept warm, because decommissioned ≠ deleted);
- Disable the model and fall back to human process or a rules baseline (which you rehearsed, so throughput does not collapse);
- Guardrail hotfix — tighten input filters, output checks, or confidence thresholds while the root cause is investigated;
- Constrain scope — keep the system live but route affected segments or high-stakes cases to humans.
Root-cause analysis then reaches for the vocabulary you already have: which bias source, which drift type, which attack class, which oversight failure. That shared taxonomy between testing and incident response is what makes postmortems cumulative instead of anecdotal.
| Incident type | Trigger | Deadline | Regime |
|---|---|---|---|
Serious incident (standard) | Causal link to the high-risk AI system established or reasonably likely | 15 days | EU AI Act Art 73 |
Death of a person | Suspected causal relationship between the system and the death | 10 days | EU AI Act Art 73 |
Widespread infringement / critical infrastructure | Widespread fundamental-rights infringement or serious, irreversible disruption of critical infrastructure | 2 days | EU AI Act Art 73 |
Personal data breach | Breach of personal data likely to risk individuals’ rights — AI incidents frequently double as data breaches | 72 hours to the supervisory authority | GDPR Art 33 |
Notice the interplay: one bad day can start multiple clocks simultaneously. A biased credit model that wrongly denied a protected group may be an Art 73 fundamental-rights incident and a GDPR matter and a sectoral report (financial regulators have their own regimes) and a contractual notification to enterprise customers. The playbook therefore assigns a regulatory-notification owner whose only job during an incident is mapping triggered regimes and their deadlines — while others contain and investigate. Communications discipline matters too: what you tell customers and regulators becomes evidence; accuracy beats reassurance.
Tool: AI Incident Tabletop — Run the tabletop: your genAI assistant has been giving harmful financial advice at scale. Contain it, investigate, and file the right reports before the 15/10/2-day clocks expire.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.