L8.4.1 — AI incident reporting obligations

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 8 — AI Governance, Risk & Compliance Framework tags: EU AI Act Article 73 · GDPR Articles 33-34 · HIPAA Breach Notification Rule · NIST AI RMF Manage 4.2

Learning objectives

1. Identify the three regulatory regimes that may impose AI incident reporting obligations on a typical AI product.
2. Recognize the cross-jurisdictional reporting matrix for a common incident scenario (PII disclosure).

Core content

Three regulatory regimes that may apply

For a typical AI product touching personal data, three reporting regimes may simultaneously apply:

1. EU AI Act Article 73 (high-risk AI systems). Providers of high-risk AI systems must report serious incidents to the market surveillance authority of the Member State where the incident occurred. "Serious incident" includes: death or serious harm to health, serious disruption of critical infrastructure, serious or irreversible disruption of management of critical infrastructure, harm to property or environment, or fundamental rights infringements. - Timeline: immediately upon establishing the causal link (or reasonable likelihood), and not later than 15 days after awareness for general serious incidents; not later than 2 days for incidents resulting in death or serious harm; not later than 5 days for critical-infrastructure disruptions.

2. GDPR Articles 33-34 (personal data breach). Controllers must notify the supervisory authority of a personal data breach without undue delay and where feasible within 72 hours; data subjects must be notified when the breach is likely to result in high risk to their rights. - Timeline: 72 hours to authority; data-subject notification timing depends on risk.

3. Sector-specific (HIPAA, FedRAMP, financial-services frameworks). Depending on data type and jurisdiction: - HIPAA Breach Notification Rule — for ePHI: notify affected individuals within 60 days; notify HHS for breaches affecting 500+ individuals immediately, less than 500 annually. - FedRAMP incident reporting timelines for federal systems. - Financial services: state attorney-general timelines, EU NIS2 for some categories.

The cross-jurisdictional matrix for one incident

A common scenario: your LLM-powered SaaS exposes user PII via a training-data extraction attack on a fine-tuned model. The incident affects EU customers and US healthcare customers.

Regime	Trigger	Timeline	Audience
EU AI Act Art. 73	If your system is high-risk + incident is serious	15 days (or shorter for some categories)	EU member state market surveillance authority
GDPR Art. 33	Personal data breach affecting EU data subjects	72 hours	Lead supervisory authority + affected data subjects (if high risk)
HIPAA	ePHI exposed	60 days (individuals) + immediate HHS for 500+	Affected individuals + HHS + media (for 500+ in a state)
Customer contracts	Per MSA SLA	Often 24-72 hours	All affected customers

Triggering all three simultaneously is not unusual. Your IR playbook (L7.6.1) must address parallel notification flows.

What reporting requires

A reportable incident notification typically includes: - Nature of the incident (what happened, what's the AI angle). - Affected categories of data / individuals / systems. - Timeline (when did it start, when discovered, when contained). - Likely consequences. - Mitigation measures taken or proposed.

Plus, for EU AI Act specifically: which provisions of the Act were affected; what the system's risk classification is.

The L7.6.1 IR playbook's "communication" section is the engineering-side input to these notifications; legal/compliance owns the actual filing.

Practical guidance

Three operational practices:

1. Identify your reporting obligations before an incident. Map your jurisdiction footprint (where customers are), data types handled, applicable regimes. Document in your IR playbook with specific contact addresses for each regime's authority.

2. Build the notification template once. Pre-draft notification templates (subject to legal/compliance approval per incident). Reduces the time-to-notification during a real incident — every hour matters under 72-hour clocks.

3. Track reporting outcomes. Post-incident: what was reported, when, to whom, with what regulator response. Feeds the next-incident IR and feeds program-improvement loops.

The compliance / engineering interface

Reporting is owned by legal/compliance. The AI security engineer's job is to: - Detect the incident (logging + abuse detection from L7.4.*). - Reconstruct the chain (logging + tabletop from L7.9). - Provide the technical details the notification needs (timeline, affected data, mitigation). - Confirm containment (engineering controls).

Get to know your legal/compliance counterparts before an incident. The relationships pay off when the 72-hour clock starts.

Real-world example

Several 2025-2026 disclosures triggered EU AI Act Article 73 reporting. The published post-incident reports (where vendors chose to publish) are useful templates for what good reporting looks like. The pattern: factual, time-sequenced, with explicit mitigation status. Avoid PR speak; regulators specifically penalize vague reporting.

Key terms

• EU AI Act Article 73 — serious-incident reporting for high-risk AI systems.
• GDPR Articles 33-34 — personal data breach notification.
• HIPAA Breach Notification Rule — ePHI exposure notification.
• Cross-jurisdictional matrix — multiple regimes potentially triggering on a single incident.

References

• EU AI Act Article 73.
• GDPR Articles 33-34.
• HIPAA Breach Notification Rule (45 CFR §§ 164.400-414).
• L7.6.1 (the IR playbook this connects to).

Quiz items

1. Q: Name the three regulatory regimes most likely to impose AI incident reporting on a typical AI product. A: EU AI Act Article 73 (high-risk systems); GDPR Articles 33-34 (personal data breaches affecting EU subjects); sector-specific (HIPAA for ePHI; FedRAMP for federal; financial-services frameworks).
2. Q: What's the GDPR breach notification timeline? A: Notify supervisory authority without undue delay, and where feasible within 72 hours. Data subject notification when breach likely results in high risk to their rights.
3. Q: Whose job is incident reporting at most organizations, and what's the AI security engineer's contribution? A: Legal/compliance owns the actual filing. AI security engineer detects the incident (logging + abuse detection), reconstructs the chain (logging + tabletop), provides technical details (timeline, affected data, mitigation), and confirms containment.

Video script (~580 words, ~4 min)

[SLIDE 1 — Title]

AI incident reporting obligations. Five minutes.

[SLIDE 2 — Three regulatory regimes]

For a typical AI product touching personal data, three reporting regimes may simultaneously apply. One: EU AI Act Article 73. Providers of high-risk AI systems must report serious incidents to the market surveillance authority of the Member State where the incident occurred. Serious incident includes death or serious harm, critical-infrastructure disruption, fundamental-rights infringements. Timeline: immediately upon establishing causal link, not later than 15 days for general serious; 2 days for death or serious harm; 5 days for critical-infrastructure.

Two: GDPR Articles 33-34. Controllers must notify the supervisory authority of a personal data breach without undue delay and where feasible within 72 hours. Data subjects notified when breach is likely to result in high risk.

Three: sector-specific — HIPAA, FedRAMP, financial-services frameworks. HIPAA Breach Notification Rule for ePHI: 60 days for individuals; immediate HHS for 500+. FedRAMP incident timelines for federal. Financial services: state AG timelines, EU NIS2 for some categories.

[SLIDE 3 — Cross-jurisdictional matrix]

One incident, multiple regimes. Common scenario: your LLM-powered SaaS exposes user PII via a training-data extraction attack. Affects EU customers and US healthcare customers. EU AI Act 73: 15 days, EU member state authority. GDPR 33: 72 hours, lead supervisory authority plus affected data subjects. HIPAA: 60 days individuals plus immediate HHS for 500+. Customer contracts: often 24-72 hours per MSA SLA.

Triggering all three is not unusual. Your IR playbook must address parallel notification flows.

[SLIDE 4 — What reporting requires]

Reportable incident notification typically includes: nature (what happened, AI angle). Affected categories (data, individuals, systems). Timeline (when started, when discovered, when contained). Likely consequences. Mitigation measures taken or proposed.

Plus for EU AI Act specifically: which provisions of the Act were affected, what the system's risk classification is.

L7.6.1 IR playbook's "communication" section is the engineering-side input. Legal/compliance owns the actual filing.

[SLIDE 5 — Three practical practices]

Three operational practices. One: identify your reporting obligations before an incident. Map jurisdiction footprint, data types, applicable regimes. Document in IR playbook with specific contact addresses. Two: build the notification template once. Pre-draft templates subject to legal approval. Reduces time-to-notification during real incident — every hour matters under 72-hour clocks. Three: track reporting outcomes. Post-incident: what was reported, when, to whom, regulator response. Feeds next-incident IR.

[SLIDE 6 — Compliance/engineering interface + up next]

Reporting is owned by legal/compliance. AI security engineer's job: detect the incident (logging + abuse detection from L7.4). Reconstruct the chain (logging + tabletop from L7.9). Provide technical details the notification needs. Confirm containment.

Get to know your legal/compliance counterparts before an incident. Relationships pay off when the 72-hour clock starts.

Next: documentation artifacts — model cards, system cards, data sheets. Two lessons. Then case study, then lab.

Slide outline

1. Title — "AI incident reporting obligations".
2. Three regimes — three-card layout with timelines.
3. Cross-jurisdictional matrix — the table from the lesson body.
4. What reporting requires — five-bullet list + EU AI Act addendum.
5. Three practices — three-card layout.
6. Compliance/engineering interface — handoff diagram + up next.

Production notes

• Recording: ~4 min. Cap 5.
• Slide 3 (the matrix) is the reference learners will save.