17. Incidents, issues and root causes

New to the field? Start with the definition of AI governance.

This chapter extends two things the book already has. The Incident Pipeline pattern (chapter 05) wires detection to a report with the statutory timer running; the Article 73 clock table in the regulatory map (chapter 08) says how long that timer is. Neither says what counts as an incident below the serious threshold, how to rank severity, who pulls which lever, how to find the cause, or what to do when one event starts four clocks at once.

One contrast first. Security incident response, the sibling discipline’s home ground, handles compromise: an attacker, a vulnerability, a breach. AI incident management inherits its lifecycle and many of its tools, but the harm set is wider (discrimination, unsafe advice, rights infringements, misinformation acted upon) and the failure is often behaviour rather than compromise: a model that drifts, an agent that uses a permitted tool in a harmful way. Nothing was breached, and people were still hurt. The deliverable is a governed event with an evidence trail, not only a restored service.

Incident, hazard, issue and serious incident

Four words decide whether a clock starts, so define them before anything else.

The OECD’s definitions are the most widely shared starting point. An AI incident is an event, circumstance or series of events where the development, use or malfunction of one or more AI systems directly or indirectly leads to harm: injury or harm to the health of people, disruption of critical infrastructure, violations of human rights or of legal obligations protecting fundamental, labour and intellectual property rights, or harm to property, communities or the environment. An AI hazard is the same kind of event where the AI system could plausibly lead to such an incident¹. The OECD paper also defines graded terms (serious AI incident, AI disaster, serious AI hazard), and its common reporting framework uses that ladder as the values of its severity field¹².

The EU AI Act defines only the top of the ladder. A serious incident under Art. 3(49) is an incident or malfunctioning of an AI system that directly or indirectly leads to one of four outcomes: (a) the death of a person or serious harm to a person’s health; (b) a serious and irreversible disruption of the management or operation of critical infrastructure; (c) the infringement of obligations under Union law intended to protect fundamental rights; or (d) serious harm to property or the environment³. A separate defined term, widespread infringement (Art. 3(61)), covers acts contrary to Union law that harm the collective interests of individuals across several Member States; it shortens the reporting deadline, as the clocks section shows³.

Two more terms are house definitions, and the book uses them consistently:

• An issue is a defect, deviation or control weakness that has not produced an event: an eval that regressed below its threshold in staging, a drift alert, a model card that no longer matches the deployed version, a guardrail whose false-positive rate has doubled. An issue is tracked to closure with an owner and a due date. In ISO/IEC 42001 terms most issues are nonconformities handled under clause 10.2⁴.
• A near miss is a hazard that a control (or luck) interrupted: the guardrail blocked the exfiltration attempt, the human reviewer caught the invented dosage. No harm occurred, but the path to harm was real. The GPAI Code of Practice asks providers to report “individual or aggregate data on near misses” connected to a serious incident, which tells you near misses are evidence, not noise⁵.

The distinction that matters most in practice is between severity and reportability. Severity is a judgement about harm on your internal scale. Reportability is a separate test, run once per regime, against that regime’s trigger. A moderate incident can still be notifiable (a small personal data breach under GDPR); a severe one can fall outside every regime’s scope (a non-high-risk system with no personal data involved). Keep the two decisions in separate fields, made by named people, with timestamps.

A severity scale mapped to the clocks

A severity scale is a policy, so write it as one. The scale below has four incident levels and one level for issues. It is illustrative; what matters is that each level names a harm test, maps to the legal classes it can trigger and carries a default response.

Three rules make the scale work under pressure.

1. Classify up, downgrade with evidence. At triage you rarely know the full harm. Classify against the most severe plausible reading and record why; downgrade when evidence narrows it. The AI Act supports this reading: the outer deadlines run from awareness, and the “reasonable likelihood” of a causal link is enough to call for the report³.
2. Severity follows harm, not cause. A trivial bug that caused a death is SEV-1; a sophisticated attack that a guardrail stopped is SEV-4. Technical interest is not a severity input.
3. The scale is code. The harm tests and the regime triggers are evaluated by a rule engine when an incident opens, so the first classification and the clocks it starts are reproducible, versioned and auditable. A human can override; the override is logged with a reason.

Two caveats on the mapping. The AI Act classes apply only to high-risk systems (for Art. 73) and to GPAI models with systemic risk (for Art. 55), and the GPAI classes differ slightly: the Code of Practice adds a five-day class for serious cybersecurity breaches, including exfiltration of model weights⁵. And the OECD values are a vocabulary for reporting, not a legal threshold.

The response lifecycle

NIST’s incident-response guidance changed shape in April 2025. SP 800-61 Revision 3 superseded the 2012 revision and its circular lifecycle (preparation; detection and analysis; containment, eradication and recovery; post-incident activity) with a model built on the six CSF 2.0 functions, arguing that incidents are now frequent and long, and that lessons should be shared as soon as they are identified⁶. The phases below keep the familiar verbs, because on-call engineers think in them, and map each to the CSF function NIST now uses.

Detection needs more channels than the runtime signals from layer 04. The GPAI Code of Practice expects providers to review police and media reports, social media, research papers and incident databases, and to facilitate reporting by downstream modifiers, downstream providers and users by telling them of direct reporting channels, to the provider or to the AI Office, where these are available⁵. A deployer that only watches its own dashboards will learn about some incidents from a journalist. Staff are a channel too: a channel for raising concerns (chapter 12) routes their reports into the same pipeline, and for a high-risk provider the post-market monitoring plan is a standing source (post-market monitoring and serious incidents under the AI Act, chapter 18).

Containment is where the runtime patterns earn their keep. A kill switch that revokes one agent’s scope without breaking the fleet, a runtime guardrail tightened by a config push, and a registry that knows the live and the last good version turn “contain” from a meeting into a command. The NIST AI RMF names the capability: mechanisms and assigned responsibilities to “supersede, disengage, or deactivate” AI systems whose performance or outcomes are inconsistent with intended use⁷.

Freeze before you fix

The instinct after containment is to fix the thing. For a high-risk system the AI Act says wait: after reporting a serious incident, the provider investigates, including a risk assessment and corrective action, but must not perform any investigation that alters the system in a way that may affect the later evaluation of the incident’s causes before informing the competent authorities³. Engineering reads that as a preservation step between contain and eradicate:

• Snapshot the system as it was. Model version and hash, system prompt, policy and guardrail versions, tool scopes, retrieval index snapshot, configuration and feature flags, all keyed to the registry id and the incident id.
• Seal the traces. The Art. 12 logs and the runtime traces for the incident window, exported to tamper-evident storage. Deployers must keep a high-risk system’s automatically generated logs, where under their control, for at least six months unless other law says otherwise³; an open incident is a reason to hold them longer.
• Record who touched what. Every containment and diagnostic action is logged with its actor, so the evaluation of causes can separate the incident from the response.
• Fix on a branch, not in place. Eradication runs as a change to a new version; the incident version stays reproducible.

Retention outlives the incident. The Code of Practice commits GPAI signatories to keep incident documentation for at least five years from the documentation or the incident, whichever is later⁵. The frozen evidence also feeds the defence file that product liability law now lets a court order disclosed (chapter 20).

Playbooks, RACI and drills

A playbook is the response to one failure mode, written before it happens. Keep it short enough to read during the incident and specific enough to act on without interpretation.

# playbook: indirect-prompt-injection (illustrative)
trigger: guardrail rule output.exfil.* fires, or a tool call to an unregistered domain
first_15_minutes:
  - page: on-call engineer, AI governance engineer
  - contain: revoke agent tool scope "http:egress" via kill switch; keep read scopes
  - preserve: snapshot registry entry, prompt, retrieval index; seal traces for the window
decision_rights:
  kill_switch: on-call engineer (no approval needed)
  customer_notice: DPO
  regulator_filing: legal, on DPO or system-owner recommendation
evidence_checklist: [trace_ids, guardrail_events, affected_records, scope_revocation_event]
regimes_to_assess: [gdpr_art33, gdpr_art34, nis2_art23, ai_act_art73]

The decision-rights block matters most. Whoever is on call must be able to pull the kill switch without asking, because containment that waits for a committee is not containment. Filing with a regulator is the opposite: it needs named owners with the authority to sign. A RACI makes both explicit (R responsible, A accountable, C consulted, I informed):

Adapt the columns to your organisation; do not drop the rows. Each row is an artefact someone must produce, and an empty cell at 2 a.m. is a gap an auditor will find later.

Drills are the control; the playbook is the claim. The book treats an untested kill switch as a claim, not a control, and the same test applies to the playbook. Run tabletop exercises on a schedule, score them and keep the result as evidence:

• Scenarios. Rotate through the failure modes below: an indirect prompt injection that exfiltrates data; drift that produces discriminatory outcomes; a vendor that silently changes the model behind an API; an agent loop that burns budget and calls tools thousands of times; confident, wrong advice acted on by a user.
• Measures. Time to classify, time to contain, time to a draft report for each clock, and whether each clock would have been met. Track mean time to detect (MTTD), to contain (MTTC) and to recover (MTTR) across real incidents and drills separately.
• Evidence. The drill produces the same records a real incident would (record, clocks, draft reports, containment events), tagged as a drill. An auditor asking “can you report on time?” gets a query over drill results, not a promise.

AI-specific failure modes

Most AI incidents are system incidents, not model incidents: the model behaved as models do, and the system around it (retrieval, tools, prompts, oversight) turned that behaviour into harm. The table names the failure modes that recur, the signal that usually detects them and the first containment move.

Two practical points follow. First, a failure mode is a hypothesis at triage and a finding only after root-cause analysis; do not let the first label stick. Second, every row maps to a test that could have caught it earlier (an adversarial case, a subgroup eval, a drift threshold), which is why the after-action review ends in the eval suite, not in a slide. For agents, chapter 23 extends the table into the agent incident taxonomy.

Root-cause analysis

Root-cause analysis (RCA) answers “why did this happen, and why did our controls not stop it?” The second half is the part AI governance engineering adds: an incident is also evidence that a control failed, was missing, or was never designed.

Who takes part

Run the review as a small incident review board with a standing core and invited specialists:

• a facilitator who is not in the reporting line of anyone involved;
• the system owner, who is accountable for the CAPA;
• the ML or data engineer who knows the model and its data;
• the AI governance engineer, who owns the mapping from cause to control and to obligation;
• security, when an adversary or a vulnerability is plausible;
• the DPO and legal, when personal data or rights are involved;
• someone who represents the people affected (customer operations, a domain expert, a clinician), so harm is described from the receiving end.

The board meets for every SEV-1 and SEV-2 incident and samples SEV-3 incidents and near misses. It decides four things and records each as a decision: the confirmed causes, the CAPA items and owners, the changes to the risk register, and closure.

Techniques

Five whys. Ask why the harm happened, then why that happened, until you reach a cause you can change. It is fast, but it follows one chain, while AI failures usually have several contributing causes (a data gap and a missing eval and an oversight step that rubber-stamped). It also tends to stop at “human error”, which is where analysis should start.

Fault tree analysis. Start from the top event (the harm) and decompose it through AND and OR gates into the conditions that had to hold for it to occur; IEC 61025 standardises the method¹⁰. It suits governed AI systems well, because controls are layered: a harmful output reached a customer only if the model produced it AND the output guardrail missed it AND no human review applied. The tree shows which layers failed together, and which single fix would have broken the chain.

Blameless post-mortem. The review looks for contributing causes “without indicting any individual or team”, on the premise that people acted reasonably on what they knew and that you can fix systems and processes but not people¹¹. Set the triggers for a mandatory post-mortem in advance (every SEV-1 and SEV-2, every regulatory filing, every kill-switch pull) so that writing one is routine, not an accusation¹¹.

A cause taxonomy that points at controls

A cause taxonomy is useful only if each class names the control that should have caught it. Code every confirmed cause against one or more of these classes:

The taxonomy is not only a learning device; regulators ask for it. The Commission’s reporting template for GPAI serious incidents has a root-cause field that asks for the model outputs that led to the incident and the factors behind them, including the inputs used and any failures or circumventions of systemic-risk mitigations¹². NIS2’s final report asks for “the type of threat or root cause” likely to have triggered a significant incident¹³. DORA goes further: recurring incidents that are individually below the major threshold count as one major incident when they occur at least twice within six months with the same apparent root cause and together meet the criteria¹⁴. Inconsistent cause coding therefore does more than spoil your statistics: under DORA it can hide a reportable incident. The OECD reporting framework keeps its own cause-adjacent fields (whether the incident is linked to the training data, to the AI model, or to the interaction of several AI systems) that the same coding can fill².

CAPA: from incident to risk register and eval suite

CAPA (corrective and preventive action) is the output of the review. The corrective action fixes this instance: patch, retrain, roll back, re-scope. The preventive action stops the class of failure recurring anywhere in the fleet: a new eval case for every similar system, a policy change, a registry field made mandatory. ISO/IEC 42001 places this in clause 10.2⁴; the NIST AI RMF asks that incidents and errors be communicated to relevant AI actors, including affected communities, and that tracking and response processes be documented⁷. For high-risk providers the AI Act adds hard edges: a provider with reason to consider a system non-conforming must immediately bring it into conformity, withdraw, disable or recall it, and inform distributors and deployers; where it presents a risk, the provider investigates the causes with the reporting deployer and informs the market-surveillance authority³.

Every closed incident should leave five artefacts behind:

1. A regression eval. The incident becomes a test case that fails on the incident version and passes on the fix, wired into the eval gate so the failure cannot ship again unnoticed.
2. A risk register change. Either a new risk or a re-scored existing one, with the incident id attached. The link runs both ways: the incident record lists the risks it realised, and the risk entry lists the incidents that realised it. The risk method itself is chapter 13, risk management.
3. A control change where the fault tree found one: a tightened guardrail, a narrower scope, a new oversight checkpoint.
4. A playbook update, if the response itself was slow or unclear.
5. An evidence record that the CAPA was verified: the new eval passes in CI, and the runtime metric has stayed at baseline for a defined window.

Two cross-checks keep the link to the risk register honest. A risk scored “low likelihood” that already has two incidents attached is mis-scored. An incident that matches no risk in the register is itself a finding: risk identification missed it, and that goes on the CAPA list too.

{
  "capa_id": "CAPA-2026-041",
  "incident_id": "INC-2026-0918-01",
  "type": "preventive",
  "cause_codes": ["adversarial", "integration_and_tooling"],
  "action": "Add indirect-injection cases from quarantined documents to injection-resistance.v5",
  "owner": "team-support-platform",
  "due": "2026-10-02",
  "risk_ids": ["RISK-017"],
  "verification": { "eval_suite": "injection-resistance.v5", "result": "pending" }
}

Measure the loop, not the paperwork: recurrence rate by cause class, CAPA items closed and verified on time, the share of incidents that produced a regression eval, and MTTD and MTTC trends. Those are realised-risk-reduction numbers; a count of post-mortems written is not.

Deployer duties: inform the provider, suspend use

Most organisations meet AI incidents as deployers of a system someone else built. For high-risk systems, Art. 26(5) sets three duties³:

• Monitor the system’s operation on the basis of the instructions for use and, where relevant, inform the provider for its post-market monitoring.
• Inform and suspend. Where the deployer has reason to consider that using the system as instructed may present a risk within the meaning of Art. 79(1), it informs the provider or distributor and the market-surveillance authority without undue delay, and suspends use.
• Report serious incidents up the chain. Where the deployer identifies a serious incident, it immediately informs first the provider, then the importer or distributor and the market-surveillance authority. If it cannot reach the provider, Art. 73 applies to the deployer mutatis mutandis: the deployer inherits the reporting clock.

Two carve-outs apply: the duty does not cover sensitive operational data of law-enforcement deployers, and for financial institutions the monitoring duty is deemed fulfilled by complying with their internal-governance rules under financial-services law³. These duties apply with the rest of the high-risk regime, from 2 Dec 2027 for Annex III systems after the Digital Omnibus (see chapter 08).

Each duty needs an engineered artefact, and none of them exists by default:

Suspension is a kill switch for a system you do not own. You cannot revoke a vendor’s weights, but you can stop sending it traffic; test that you can, and how long it takes, before you need it. The Incident Pipeline builds the deployer side. The Vendor / Model Due-Diligence Gate is where the two-way notification terms belong: the provider tells you about incidents and corrective actions that affect your deployment, and you have a named channel to tell the provider. The same logic runs further up the chain for GPAI: the Code of Practice asks model providers to tell downstream providers, modifiers and users how to report serious incidents, directly or to the AI Office⁵. Deployment governance as a whole is chapter 15, governing deployment, whose external communications plan carries the notices to users, affected people and authorities.

The overlapping clocks

One event can start several clocks. An indirect prompt injection that leaks customer data from a high-risk system run by a bank can, at once, be a serious incident under the AI Act, a personal data breach under GDPR and a major ICT-related incident under DORA; at a non-financial essential entity the same leak could be a significant incident under NIS2. Each regime has its own trigger, recipient, deadline and content. The table puts them side by side, as of 2026-09-24.

Reading the table

The triggers are not the same event. GDPR, NIS2, the CRA and Art. 73 count from awareness. DORA’s four-hour clock counts from classification as major, with an outer limit of 24 hours from awareness; a classification made after those 24 hours starts its own four-hour clock (Art. 5(2) of RTS 2025/301)¹⁹. Art. 73 also asks for the report immediately once a causal link, or its reasonable likelihood, is established, with the day counts as outer limits³. RAISE counts from a determination or a reasonable belief²³. An incident record therefore needs a timestamp per trigger, not one “opened at”: first signal, awareness decision, classification per regime, causal link established, and each submission.

Some regimes defer to others. NIS2 steps aside where a sector-specific Union act imposes at least equivalent incident notification, which is how DORA displaces NIS2 reporting for financial entities¹³. The AI Act narrows itself in a similar way: for Annex III systems whose providers are already under equivalent Union reporting obligations, and for AI in medical devices, Art. 73 reporting is limited to fundamental-rights infringements (Art. 3(49)(c))³. According to a law-firm summary of the Commission’s draft guidance, the draft applies this to sectors such as NIS2 critical infrastructure²⁴. Which regimes count as “equivalent” for a given system is a legal call; record it per system in the registry, not per incident under pressure.

Dates are moving. Four points to re-check before relying on the table, all as of 2026-09-24:

• The high-risk regime applies to Annex III systems from 2 Dec 2027 and to Annex I systems from 2 Aug 2028, after the Digital Omnibus postponed Chapter III, Sections 1 to 3 (Art. 113(c))³⁴. Art. 73 sits in Chapter IX and was not itself postponed, but it reaches a system only once Art. 6 classifies it as high-risk, so in practice it follows the same dates (verify with counsel); the GPAI duties in Art. 55 already apply (see chapter 08).
• The Omnibus left the Art. 73 deadlines unchanged but added Art. 75(1a): providers of high-risk systems under the AI Office’s exclusive competence (broadly, systems built on the provider’s own GPAI model and systems in very large online platforms or search engines) report serious incidents to the AI Office¹⁵²⁵.
• The Commission published draft Art. 73 guidance and a reporting template on 26 Sep 2025, aligned with the OECD’s incidents monitor and common reporting framework²⁶. Whether the final guidance has since been adopted is not confirmed here (verify).
• A separate Digital Omnibus proposal (COM(2025) 837) would change GDPR breach notification and add a single entry point for incident reports. It is tabled, not adopted: as of the Parliament’s 1 Aug 2026 update, amendments were under discussion and the Council’s mandate had stalled²⁷. Commentators report a longer GDPR deadline limited to high-risk breaches (verify). The 72-hour rule stands; chapter 19 covers AI-specific privacy breaches and the 72-hour clock.
• Outside the EU the clocks differ again: chapter 21 lays out the incident clocks across regimes.

One record, many reports

The engineering answer to overlapping clocks is not a better calendar. It is one incident record that holds the facts once, and a generator per regime that renders the report that regime wants, each with its own timer. The clocks live in the record, and the pipeline alerts on the nearest deadline:

{
  "incident_id": "INC-2026-0918-01",
  "clocks": [
    { "regime": "gdpr_art33", "trigger": "aware", "trigger_at": "2026-09-18T15:02:00Z",
      "due_at": "2026-09-21T15:02:00Z", "status": "submitted",
      "submitted_at": "2026-09-20T10:40:00Z" },
    { "regime": "nis2_art23", "trigger": "aware", "trigger_at": "2026-09-18T15:02:00Z",
      "status": "not_applicable",
      "rationale": "not significant under Art. 23(3); signed off by security IR lead" },
    { "regime": "ai_act_art73", "status": "not_applicable",
      "rationale": "csa-01 is not a high-risk system (registry class: limited risk)" }
  ]
}

A “not applicable” decision is evidence too. Write it down with its rationale and its owner; the question an authority asks a year later is usually “why did you not report?”, and the answer should be a record, not a memory.

The incident record

Design the record once, around what the most demanding recipients ask for, and every other report becomes a projection of it. The templates page has the incident record fields as a JSON Schema with a filled example. Two public schemas set the bar. The Commission’s template for GPAI serious incidents asks for ten items: start and end dates, the resulting harm and the victims or affected group, the chain of events, the model involved, the evidence available, the provider’s response, its recommendation to the authorities, a root-cause analysis, patterns from post-market monitoring including near misses, and submitter information¹². The OECD common reporting framework defines 29 criteria in eight dimensions (metadata, harm details, people and planet, economic context, data and input, AI model, task and output, other information)².

Store the record as structured data in the assurance store, and emit its control-relevant parts as machine-readable evidence: CAPA items map naturally to an OSCAL plan of action and milestones (POA&M), the native model’s place for open findings and their remediation²⁸. That is the Machine-Readable Evidence pattern applied to incidents, and it lets an auditor query “all SEV-2 incidents in Q3 with open CAPA” instead of asking for a spreadsheet.

Learning from public incident databases

Your own incident history is small and biased toward what you already detect. Public repositories widen it, as long as you know what they are. This site keeps two curated starting points: the incident cases written as post-mortems and the harms atlas, which maps harms by level to the control that catches each.

• AI Incident Database (AIID). Run by the Responsible AI Collaborative, it indexes harms and near harms from deployed AI, in the manner of aviation and computer-security incident databases. It classifies incidents with several taxonomies (the CSET AI Harm Taxonomy, a Goals, Methods and Failures taxonomy, and the MIT AI Risk Repository’s) and offers full database snapshots for download²⁹.
• OECD AI Incidents and Hazards Monitor (AIM). An automated monitor of AI incidents and hazards reported in the news media, which keeps incidents and hazards apart as the OECD definitions do³⁰.
• AIAAIC Repository. An independent register of incidents and controversies involving AI, algorithms and automation, across sectors from facial recognition to automated hiring³¹.
• MIT AI Risk Repository. Not an incident database but a structured catalogue of AI risks with causal and domain taxonomies, useful for checking that your cause taxonomy and risk register have no blind spots³².

Use them in four ways. Seed the risk register: pull the incidents recorded for deployments like yours and check that each has a matching risk. Write the eval before the incident: turn a public incident into a test case against your system, feeding the red-team suite alongside the MITRE ATLAS technique catalogue³³. Calibrate the severity scale: check that real incidents land where your harm tests say they should. Feed GPAI monitoring: the Code of Practice lists incident databases among the sources providers should review⁵.

Know the limits. Media-sourced collections over-represent the newsworthy, the consumer-facing and the English-speaking; one event can appear several times; and none of them gives base rates. Use them to find failure modes you had not imagined, not to estimate how often yours will occur. The reading list keeps the current links under incident and risk repositories.

What you can do this week

1. Write the severity scale as policy. Five levels, a harm test per level, the regime triggers per level; run your last three incidents through it and fix the rules until the results match what you would decide by hand.
2. Add the timestamps. Give every incident ticket aware_at, a per-regime applicability flag with owner and rationale, and a due time per clock. Backfill the open incidents.
3. Run one tabletop. Indirect prompt injection against your most connected assistant: pull the kill switch, preserve the evidence, draft the GDPR notification. Record the times.
4. Test the suspension path for one procured system. Confirm the provider’s incident contact is in the registry entry and that you can stop traffic to the system, and measure how long it takes.
5. Code three past events. Assign cause classes from the taxonomy to your last three incidents or near misses, and add one regression eval for each.

Maps to: EU AI Act Art. 3(49), 20, 26(5)–(6), 55(1)(c), 72, 73, 75(1a) · GPAI Code of Practice, Safety and Security Commitment 9 · GDPR Arts. 33–34 · NIS2 Art. 23 · DORA Art. 19 · Cyber Resilience Act Art. 14 · ISO/IEC 42001 (clause 10.2, Annex A.8) · NIST AI RMF (Manage 2.4, 4.1, 4.3) · NIST SP 800-61r3 · OWASP LLM01:2026, Agentic ASI02/ASI08/ASI10 · Layer 04 Runtime Controls & Observability · Layer 05 Assurance & Continuous Compliance. Mappings are illustrative, not a claim of conformity.

Sources

1. [1] “Name it to tame it: defining AI incidents and hazards” (Luis Aranda and Karine Perset; summary of the OECD paper “Defining AI incidents and related terms”, OECD Artificial Intelligence Papers, doi 10.1787/d1a8d965-en; AI incident and AI hazard definitions; graded terms serious AI incident, AI disaster, serious AI hazard). OECD.AI. 2024-05-17. https://oecd.ai/en/wonk/defining-ai-incidents-and-hazards (verified: primary)
2. [2] Towards a common reporting framework for AI incidents (OECD Artificial Intelligence Papers No. 34; 29 criteria in eight dimensions; severity values hazard, serious hazard, incident, serious incident, disaster). OECD. 2025-02. https://www.oecd.org/content/dam/oecd/en/publications/reports/2025/02/towards-a-common-reporting-framework-for-ai-incidents_8c488fdb/f326d4ac-en.pdf (verified: primary)
3. [3] Regulation (EU) 2024/1689 (AI Act) of 13 June 2024: Art. 3(49) serious incident; Art. 3(61) widespread infringement; Art. 20 corrective actions and duty of information; Art. 26(5)–(6) deployer monitoring, suspension, serious-incident information and log retention; Art. 73 reporting of serious incidents (2, 10 and 15 days; incomplete initial report; no altering the system before informing authorities; limits in Art. 73(9)–(10)). Publications Office of the EU (EUR-Lex). 2024-06-13. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (verified: primary)
4. [4] ISO/IEC 42001:2023, AI management systems (clause 10.2 nonconformity and corrective action; Annex A.8 information for interested parties). ISO/IEC. 2023. https://www.iso.org/standard/81230.html (verified: secondary)
5. [5] General-Purpose AI Code of Practice, Safety and Security chapter, Commitment 9 serious incident reporting (Measure 9.1 identification sources and informing third parties of direct reporting channels, if available; 9.2 information incl. near misses; 9.3 timelines of 2, 5, 10 and 15 days, intermediate reports at least every four weeks, final report within 60 days of resolution; 9.4 retention of at least five years). European Commission. 2025-07-10. https://ec.europa.eu/newsroom/dae/redirection/document/118119 (verified: primary)
6. [6] NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (supersedes SP 800-61r2; previous life-cycle phases mapped to CSF 2.0 functions). NIST. 2025-04. https://csrc.nist.gov/pubs/sp/800/61/r3/final (verified: primary)
7. [7] AI Risk Management Framework 1.0, NIST AI 100-1 (MANAGE 2.4 supersede, disengage or deactivate; MANAGE 4.1 post-deployment monitoring incl. incident response; MANAGE 4.3 incidents and errors communicated, processes followed and documented). NIST. 2023-01-26. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (verified: primary)
8. [8] LLM01:2026 Prompt Injection (OWASP Top 10 for LLM Applications 2026; direct and indirect prompt injection; entry text in github.com/GenAI-Security-Project/GenAI-LLM-Top10, 2026/final). OWASP GenAI Security Project. 2026-08-03. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ (verified: primary)
9. [9] Top 10 for Agentic Applications 2026 (ASI02 Tool Misuse and Exploitation; ASI08 Cascading Failures; ASI10 Rogue Agents). OWASP GenAI Security Project. 2025-12-09. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (verified: primary)
10. [10] IEC 61025:2006, Fault tree analysis (FTA), edition 2.0 (IEC TC 56 Dependability). IEC. 2006-12-13. https://webstore.iec.ch/en/publication/4311 (verified: primary)
11. [11] “Postmortem Culture: Learning from Failure” (Site Reliability Engineering, ch. 15; blameless postmortems; postmortem triggers set in advance). Google. 2016. https://sre.google/sre-book/postmortem-culture/ (verified: primary)
12. [12] “AI Act: Commission publishes a reporting template for serious incidents involving general-purpose AI models with systemic risk” (template under Art. 55(1)(c) and Commitment 9; ten fields from start and end dates to root-cause analysis, near-miss patterns and submitter). European Commission. 2025-11-04. https://digital-strategy.ec.europa.eu/en/library/ai-act-commission-publishes-reporting-template-serious-incidents-involving-general-purpose-ai (verified: primary)
13. [13] Directive (EU) 2022/2555 (NIS2) of 14 December 2022: Art. 4 sector-specific Union acts; Art. 23 reporting obligations (significant incident; early warning within 24 hours; notification within 72 hours; final report within one month incl. type of threat or root cause); Annex I digital infrastructure incl. providers of public electronic communications networks and services. Publications Office of the EU (EUR-Lex). 2022-12-14. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (verified: primary)
14. [14] Commission Delegated Regulation (EU) 2024/1772, RTS on the classification of ICT-related incidents under DORA (Art. 8: major incidents; recurring incidents with the same apparent root cause, occurring at least twice within six months, count as one major incident). Publications Office of the EU (EUR-Lex). 2024-03-13. https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng (verified: primary)
15. [15] Regulation (EU) 2024/1689 (AI Act), consolidated text of 2026-07-27, Art. 75 (Art. 75(1a), inserted by Reg. (EU) 2026/1744: serious incidents of high-risk systems under the AI Office’s competence reported to the AI Office, Art. 73(2) to (9) applying mutatis mutandis; Art. 73 deadlines unchanged). Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_75 (verified: primary)
16. [16] Regulation (EU) 2024/1689 (AI Act), consolidated text of 2026-07-27, Art. 55 (GPAI models with systemic risk; Art. 55(1)(c) keep track of, document and report serious incidents to the AI Office without undue delay). Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_55 (verified: primary)
17. [17] Regulation (EU) 2016/679 (GDPR) of 27 April 2016: Art. 33 notification of a personal data breach to the supervisory authority (72 hours where feasible; processor to controller; phased information; documentation) and Art. 34 communication to the data subject (high risk). Publications Office of the EU (EUR-Lex). 2016-04-27. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng (verified: primary)
18. [18] Regulation (EU) 2022/2554 (DORA) of 14 December 2022: Art. 3(8) ICT-related incident; Art. 19 reporting of major ICT-related incidents. Publications Office of the EU (EUR-Lex). 2022-12-14. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng (verified: primary)
19. [19] Commission Delegated Regulation (EU) 2025/301, RTS on the content and time limits for major ICT-related incident reports under DORA (Art. 5(1): initial notification within 4 hours of classification and no later than 24 hours from awareness; Art. 5(2): within 4 hours of a classification made after those 24 hours; intermediate within 72 hours; final within one month); report templates in Commission Implementing Regulation (EU) 2025/302. Publications Office of the EU (EUR-Lex). 2024-10-23. https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng (verified: primary)
20. [20] Regulation (EU) 2024/2847 (Cyber Resilience Act) of 23 October 2024: Art. 14 reporting obligations of manufacturers (24-hour early warning; 72-hour notification; final report 14 days after a fix or one month after notification; CSIRT and ENISA via the single reporting platform); Art. 71(2) Art. 14 applies from 11 Sep 2026. Publications Office of the EU (EUR-Lex). 2024-10-23. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (verified: primary)
21. [21] SB 53, Transparency in Frontier Artificial Intelligence Act (Chapter 138, Statutes of 2025; approved 29 Sep 2025; Bus. & Prof. Code 22757.13(c): critical safety incidents reported by any frontier developer, not only a large frontier developer, to the Office of Emergency Services within 15 days, or within 24 hours to an appropriate authority on imminent risk of death or serious physical injury). California Legislative Information. 2025-09-29. https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260SB53 (verified: primary)
22. [22] NY State Senate Bill 2025-S6953B (RAISE Act; signed 19 Dec 2025 as Chapter 699; 72-hour safety incident disclosure). New York State Senate. 2025-12-19. https://www.nysenate.gov/legislation/bills/2025/S6953/amendment/B (verified: primary)
23. [23] “New York Finalizes RAISE Act for Frontier AI Models; Law Takes Effect January 1, 2027” (chapter amendment; all frontier developers, not only large frontier developers, report a critical safety incident within 72 hours of a determination or reasonable belief to the DFS office; 24 hours to law enforcement or public safety agencies on imminent risk). Wiley. 2026-04-03. https://www.wiley.law/alert-New-York-Finalizes-RAISE-Act-for-Frontier-AI-Models-Law-Takes-Effect-January-1-2027 (verified: secondary)
24. [24] “European Commission Publishes Draft Guidance on Reporting Serious AI Incidents” (indirect causation; simplified Art. 73 reporting where equivalent sector obligations apply, limited to fundamental-rights infringements). Latham & Watkins. 2025-10-28. https://www.lw.com/en/insights/european-commission-publishes-draft-guidance-reporting-serious-ai-incidents (verified: secondary)
25. [25] “EU AI Act Update: Digital Omnibus Finalizes 8 Compliance Changes” (AI Office exclusive competence over AI systems built on the same provider’s GPAI model and over systems in very large online platforms and search engines; serious-incident reports from those providers go to the AI Office). Orrick. 2026-07-29. https://www.orrick.com/en/Insights/2026/07/EU-AI-Act-Update-Digital-Omnibus-Finalizes-8-Compliance-Changes (verified: secondary)
26. [26] “AI Act: Commission issues draft guidance and reporting template on serious AI incidents, and seeks stakeholders’ feedback” (published 26 Sep 2025; feedback until 7 Nov 2025; alignment with the OECD AI Incidents Monitor and Common Reporting Framework). European Commission. 2025-09-26. https://digital-strategy.ec.europa.eu/en/consultations/ai-act-commission-issues-draft-guidance-and-reporting-template-serious-ai-incidents-and-seeks (verified: primary)
27. [27] Legislative Train Schedule: The Digital Omnibus Regulation Proposal (COM(2025) 837; status tabled; single reporting point for cybersecurity and data incidents; co-rapporteurs’ draft report 22 Jun 2026; Council mandate vote cancelled 26 Jun 2026; page updated 1 Aug 2026). European Parliament. 2026-08-01. https://www.europarl.europa.eu/legislative-train/theme-a-new-plan-for-europe-s-sustainable-prosperity-and-competitiveness/file-digital-package (verified: primary)
28. [28] OSCAL native model (control layer: catalog, profile; implementation: component-definition, system-security-plan; assessment: assessment-plan, assessment-results, POA&M). NIST. 2026. https://pages.nist.gov/OSCAL/learn/concepts/layer/ (verified: primary)
29. [29] AI Incident Database (harms and near harms from deployed AI; CSET, GMF and MIT taxonomies; database snapshots). Responsible AI Collaborative. 2026. https://incidentdatabase.ai/ (verified: primary)
30. [30] OECD.AI Incidents and Hazards Monitor (AIM; automated monitor of news media; incidents and hazards distinguished). OECD. 2026. https://oecd.ai/en/incidents (verified: primary)
31. [31] AIAAIC Repository (independent register of AI, algorithmic and automation incidents and controversies). AIAAIC. 2026. https://www.aiaaic.org/aiaaic-repository (verified: primary)
32. [32] MIT AI Risk Repository (living database of AI risks; causal and domain taxonomies). MIT FutureTech. 2026. https://airisk.mit.edu/ (verified: primary)
33. [33] MITRE ATLAS: adversarial tactics and techniques knowledge base for AI systems (incl. agents). MITRE. 2026. https://atlas.mitre.org/ (verified: primary)
34. [34] Regulation (EU) 2024/1689 (AI Act), consolidated text of 2026-07-27, Art. 113 (Art. 113(c) as amended by Reg. (EU) 2026/1744: Chapter III, Sections 1 to 3, apply from 2 Dec 2027 for Annex III systems and from 2 Aug 2028 for Annex I systems; Chapter IX, Art. 73 included, is not listed among the postponed provisions). Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_113 (verified: primary)