TL;DR: AI incident reporting is now a distinct legal obligation, separate from data breach notification. EU AI Act Article 73 requires serious incident reports within 15 days for high-risk AI system deployers (shorter for life-threatening incidents). In the US, sector-specific obligations apply in banking, healthcare, and autonomous vehicles. GDPR Article 33 may run concurrently. A single, well-designed incident response process can satisfy all of these regimes at once.
Incident reporting has long been a feature of data protection law. GDPR Article 33 requires reporting personal data breaches to supervisory authorities within 72 hours. US state breach notification laws require notice to affected individuals and, in some states, to regulators. These obligations are familiar to most compliance teams.
What is newer, and less understood, is that AI regulations have added a parallel track of incident reporting obligations that is not about personal data breaches. It is about AI system failures that cause harm. Whether or not personal data is involved, certain AI system outputs and malfunctions now trigger mandatory reporting to regulatory authorities.
In 2026, this parallel track is real and active. EU AI Act Article 73 obligations for high-risk AI system deployers apply now. National market surveillance authorities are setting up reporting channels. And sector-specific US regulators are increasingly treating AI system failures as reportable events under existing model risk and product safety frameworks.
This guide maps all of the applicable obligations, explains what triggers each one, and shows how to build an incident response process that handles all of them without building a separate process for each.
Why AI incident reporting is a distinct obligation
The purpose of AI incident reporting is different from data breach reporting. Data breach reporting is designed to protect individuals whose personal data has been compromised. AI incident reporting is designed to give regulators visibility into AI system failures so they can assess whether the systems were appropriate for their deployment context and whether they met the standards required for high-risk use.
A high-risk AI system that makes incorrect medical diagnoses, issues discriminatory employment decisions, or produces wrong credit scores may cause serious harm without any personal data breach occurring. The AI incident reporting framework is designed to capture these events and give regulators the information they need to act.
This distinction matters operationally. Data breach reporting is owned by privacy or legal teams and has well-established processes in most organizations. AI incident reporting is newer, less familiar, and often has no clear owner. Assigning ownership is the first governance step.
EU AI Act Article 73: serious incident reporting
Who must report
Article 73 imposes reporting obligations on two types of entities:
Deployers of high-risk AI systems: Any organization deploying a high-risk AI system listed in Annex III of the EU AI Act (covering systems in employment, education, access to essential services, law enforcement, border control, and critical infrastructure management, among others) must report serious incidents to the national market surveillance authority.
Providers of high-risk AI systems: Providers who become aware of a serious incident involving their system must also notify the relevant market surveillance authority and investigate.
Operators of GPAI models with systemic risk face additional obligations under Article 73(5), addressed separately below.
What triggers reporting
A serious incident is defined in Article 3(49) of the EU AI Act as any incident or malfunction that directly or indirectly leads to:
- Death of a person, or serious damage to a person's health, safety, or property
- Serious disruption of critical infrastructure
- Breach of Union law obligations protecting fundamental rights
- Serious damage to property or the environment
Not every AI error triggers Article 73. The system producing an incorrect recommendation is not, by itself, a serious incident. The incident becomes reportable when the incorrect output leads to one of the specified harms. The line between a material error and a reportable serious incident will be developed through enforcement practice, but the most obvious cases are clear: an AI-assisted diagnostic tool that produces a false negative contributing to delayed cancer diagnosis, an AI hiring tool that screens out an entire protected class, or an AI-managed infrastructure system that causes a power outage.
Reporting timeline
For most serious incidents: the deployer must report without undue delay, and no later than 15 days after becoming aware of the incident. This is a 15-day (not 72-hour) timeline for the full report, though interim notifications may be appropriate for major incidents.
For incidents involving a direct risk to life, public safety, or critical infrastructure: notification must be immediate, without waiting for the full 15-day window. The regulation uses "without delay" language, which enforcement authorities interpret as hours, not days, for the most serious cases.
After the initial report, the deployer must provide follow-up information as the investigation develops, including the root cause analysis and corrective measures implemented.
Report content
An Article 73 serious incident report should include:
- Identity of the deployer (organization name, contact information)
- Description of the high-risk AI system involved (name, version, provider)
- Date and time of the incident
- Description of what occurred and how it was detected
- The harm caused or potential harm: category (health, safety, fundamental rights), scope (individuals affected, geographic area), severity
- Any product safety or data protection implications
- Corrective measures taken or planned
- Contact person for follow-up
Where to file
Reports go to the national market surveillance authority in the EU member state where the incident occurred or where the deployer is established. As of 2026, EU member states are designating their market surveillance authorities and establishing reporting channels. In practice, this means contacting the designated AI authority in the relevant member state. The European AI Office is coordinating this across member states.
GPAI model incident reporting under Article 73(5)
Providers of general-purpose AI models with systemic risk (those meeting the 10^25 floating-point operations training threshold or designated by the European Commission) face additional obligations under Article 73(5). These providers must report to the European AI Office when:
- They become aware that their model has been used in a way that constitutes a serious incident under Article 73
- There is a material risk to public safety, health, or fundamental rights that the model may be contributing to
The systemic risk designation brings GPAI providers into direct engagement with the European AI Office on incident reporting, as opposed to the national market surveillance authority system that applies to high-risk AI system deployers.
US framework: sector-specific obligations
The US has no general AI incident reporting law as of mid-2026. Federal AI legislation has not passed. However, several sector-specific regulators treat AI system failures as reportable under existing frameworks:
Banking: model risk management (SR 11-7)
The OCC, Federal Reserve, and FDIC joint guidance on model risk management (SR 11-7, updated through interagency guidance in 2023 and 2025) requires banks to report material model risk events to prudential regulators. An AI system used in credit decisioning, fraud detection, or customer risk scoring is a model for SR 11-7 purposes. Material failures, biased outputs affecting lending decisions, or model drift that causes systematic errors in regulatory-relevant applications must be reported. The definition of "material" is contextual, but failures affecting a large number of customers or producing discriminatory outcomes are clearly material.
Healthcare: FDA medical device reporting
AI and machine learning software that qualifies as a Software as a Medical Device (SaMD) under FDA regulations is subject to Medical Device Reporting (MDR) requirements under 21 CFR Part 803. Manufacturers must report:
- Deaths and serious injuries caused by or contributed to by the device: within 30 days (or 5 days for urgent safety events)
- Certain malfunctions that could cause or contribute to death or serious injury if they recur: within 30 days
In 2025, FDA issued updated guidance on AI/ML-based SaMD that clarifies when an AI model update constitutes a device change requiring pre-market notification and when it is covered under the manufacturer's predetermined change control plan. Material AI errors in diagnostic or treatment decision systems are reportable under MDR regardless of these pre-market obligations.
Autonomous vehicles: NHTSA
Under NHTSA General Order 2021-01, manufacturers and operators of automated driving systems must report crashes involving their systems within 24 hours (for serious injuries or fatalities) or within 10 days (for other reportable crashes). AI system failures contributing to automated vehicle crashes are reportable events.
Aviation: FAA
AI systems used in aviation must comply with FAA aviation safety reporting requirements. Crews and operators are required to report incidents and accidents involving automation systems through the Aviation Safety Reporting System (ASRS), and manufacturers must report under the Safety Reporting Programs that apply to their certification basis.
FTC enforcement expectations
The FTC has not issued formal AI incident reporting regulations, but has signaled through enforcement actions and guidance that AI incidents involving consumer harm will be scrutinized under Section 5 of the FTC Act (unfair or deceptive practices). Practical implication: if an AI system causes consumer harm that the company discovers and does not disclose or remediate, the FTC may treat the failure to act as an unfair practice in a subsequent enforcement action. This is not a formal reporting obligation, but it creates pressure to treat material AI consumer harm incidents with the same urgency as reportable events.
GDPR Article 33 interaction
GDPR Article 33 requires notifying the supervisory data protection authority within 72 hours when a personal data breach is likely to result in a risk to individuals. An AI incident that also involves personal data may trigger both Article 33 and EU AI Act Article 73 simultaneously.
Example: A high-risk AI system used in employment decisions produces outputs that, due to a processing error, expose candidates' medical information to unauthorized parties. This is both a personal data breach (Article 33) and a serious AI incident (Article 73) because it involves a fundamental rights breach.
In this scenario, two reports go to two different authorities:
- The GDPR Article 33 personal data breach report goes to the supervisory authority (data protection authority) within 72 hours.
- The EU AI Act Article 73 serious incident report goes to the national market surveillance authority within 15 days (or sooner if the incident involves serious health or safety risk).
Both reports require incident details, but with different emphases. The Article 33 report focuses on personal data: categories of data, number of data subjects, likely consequences, and measures taken. The Article 73 report focuses on AI system function: what the system did, what harm resulted, and what corrective measures are planned for the AI system.
Building an incident log that captures both sets of fields from the beginning of the investigation allows both reports to be prepared from the same documentation.
Building an AI incident response process for multiple regimes
The classification decision
When an incident is logged, the first step is classification. A trained first responder applies the classification guide to determine which reporting obligations may apply. The key questions:
- Does this incident involve a high-risk AI system deployed in the EU? (EU AI Act Article 73)
- Does this incident involve a personal data breach? (GDPR Article 33 or US state breach notification)
- Does this incident involve an AI system in a regulated sector: banking, healthcare, autonomous vehicles, aviation? (Sector-specific reporting)
- Does this incident involve consumer harm that may attract FTC attention? (FTC soft obligation)
The answers determine which reporting timelines start running.
Incident log fields
Every incident log entry should capture:
- Incident date, time, and how it was detected
- Description of what the AI system did or failed to do
- The AI system involved (name, version, provider, deployment context)
- Whether the system is a high-risk AI system under EU AI Act Annex III
- Whether personal data was involved (categories, approximate number of records affected)
- Harm caused or risk of harm (health, safety, financial, fundamental rights)
- Corrective measures taken immediately
- Regulatory reporting determination (which obligations apply, timelines)
- Owner and follow-up dates
- Final outcome and root cause summary
Incident report template
An AI incident report that covers EU AI Act, GDPR, and US sector-specific requirements needs the following sections:
Section 1: Incident identification Organization name, incident reference number, date of incident, date of report
Section 2: AI system description System name, version, provider, deployment use case, whether the system is a high-risk AI system under the EU AI Act (if yes: which Annex III category)
Section 3: Incident description What occurred, how it was detected, timeline of events from detection to containment
Section 4: Impact assessment Persons affected (number and categories), harms realized or at risk (health, safety, financial, fundamental rights, data), whether personal data was involved
Section 5: Corrective measures Immediate actions taken to contain the incident; planned remediation of the AI system; communication to affected parties
Section 6: Regulatory notifications For each applicable reporting obligation: authority to be notified, applicable deadline, report status (not yet filed / filed on [date] / reference number)
Section 7: Post-incident review Root cause, systemic changes to prevent recurrence, updates to AI policy or monitoring procedures
Incident classification guide: reportable vs. internal
Not every AI problem requires regulatory notification. Use this guide to classify incidents:
| Category | Description | Likely reporting obligation |
|---|---|---|
| Critical | AI system output contributes to death, serious injury, or major fundamental rights violation | EU AI Act Art. 73 (immediate); GDPR Art. 33 if personal data breach; sector MDR if medical device |
| High | AI system produces systematic discriminatory outputs; AI-assisted credit decisions with disparate impact; AI medical system malfunction without injury | EU AI Act Art. 73 (15 days); sector-specific if applicable |
| Medium | AI system error affects a large number of users; vendor breach affecting AI inputs; AI hallucination in a client-facing product | GDPR Art. 33 if personal data breach; internal incident record; FTC soft obligation if consumer harm |
| Low | AI output error detected internally; isolated AI tool malfunction without user impact; vendor sub-processor change | Internal incident record; no regulatory report required |
The threshold between High and Critical, and between Medium and High, will be defined over time by enforcement practice. When in doubt about whether an incident rises to reportable level, the safer choice is to notify and provide an explanation rather than withhold notification and risk enforcement consequences for failure to report.
Related reading
- AI incident response plan template 2026
- EU AI Act August 2026 compliance checklist
- EU AI Act deployer evidence gaps for SMEs
- GDPR Article 30 AI tools record of processing activities template
- EU AI Act GPAI provider self-test 2026
- EU AI Act first enforcement actions Q3 2026
- AI governance for small teams, complete guide
