Does the EU AI Act require incident reporting?

Yes. EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents to the relevant national competent authority. A serious incident is defined as an incident that directly or indirectly causes death, serious harm to health, property damage, or significant disruption to critical infrastructure.

What AI incidents trigger GDPR reporting obligations?

GDPR Article 33 requires notification to the supervisory authority within 72 hours when a data breach is likely to result in risk to individuals' rights and freedoms.

Who should own AI incident response in my organization?

AI incident response should not live solely in cybersecurity or IT.

AI Incident Response Plan: What Regulators Expect

TL;DR: EU AI Act Article 73 requires 15-day notification for serious AI incidents. GDPR adds 72-hour data breach notification when personal data is involved. Most organizations have cybersecurity IR plans that do not cover AI performance failures. The gap is now a compliance risk.

When a cybersecurity incident happens, most organizations have a playbook: contain the breach, assess scope, notify affected parties, report to regulators. The playbook exists because breach notification laws have been in force for years and auditors check for it.

AI incident response plans are a different matter. Most organizations do not have one. The AI systems they deploy have never experienced a significant failure, or the failures that have occurred were handled ad hoc, with no documentation of what constituted an AI incident, who owned the response, or what regulatory notifications were required.

That gap is becoming a compliance issue. EU AI Act Article 73, GDPR Article 33 (in AI contexts), and the first wave of state AI law enforcement are all creating documented expectations for how AI incidents should be handled. This guide covers what regulators expect and how to close the gap.

What an AI incident is (and why it is different from a security incident)

The core distinction matters for process design. A cybersecurity incident involves unauthorized access, data exfiltration, or system compromise by an external or insider threat. An AI incident involves an AI system producing an outcome that causes harm or operates outside its intended parameters, whether or not any security breach occurred.

Examples of AI incidents that are not cybersecurity incidents:

A credit scoring AI systematically denies loans at higher rates to applicants from specific zip codes
A medical AI recommends a drug contraindicated for a patient's condition, which a physician follows without catching the error
An AI hiring tool screens out qualified candidates based on proxies that correlate with protected characteristics
A customer-facing AI provides materially false information that a user relies on to their financial detriment

Examples of incidents that are both AI incidents and cybersecurity incidents:

Exfiltration of an AI model's weights (theft of the model itself)
Poisoning of training data through unauthorized access to a training pipeline
Adversarial manipulation of an AI system that causes it to misclassify inputs in ways that cause harm

Most existing cybersecurity IR plans cover the second category. Almost none cover the first. Since the first category is now subject to regulatory notification requirements, the absence of an AI-specific IR plan is a gap.

What regulators require

EU AI Act Article 73

For providers of high-risk AI systems, Article 73 requires reporting to the national competent authority of the member state where the incident occurred when a "serious incident" takes place.

A serious incident under the EU AI Act is defined as an incident that:

Directly or indirectly causes the death of a person
Causes serious damage to the health of a person
Causes significant disruption to the management and operation of critical infrastructure
Results in damage to property, or significant economic disruption

The notification timeline is 15 calendar days from when the provider becomes aware of the incident. Where the incident poses an imminent risk of spreading or creating further harm, the initial notification must be sent immediately, with the full report following within 15 days.

Providers must notify their deployers when a serious incident occurs. Deployers must report incidents to providers (not directly to national competent authorities) and maintain records for national competent authority review.

Colorful PHP code on a dark screen in close-up, representing EU AI Act serious incident reporting under Article 73

GDPR notification applies when an AI incident involves personal data. The 72-hour clock starts when the organization "becomes aware" of the breach. The notification must include: the nature of the breach, categories and approximate number of individuals affected, likely consequences, and measures taken or proposed.

AI incidents trigger GDPR reporting when the incident involves unauthorized disclosure of personal data, the AI system processes personal data in a way that constitutes a security breach (e.g., outputs that expose other users' data), or the incident results in personal data being processed outside its stated purpose in a way that endangers individuals.

A critical timing issue: the 72-hour GDPR clock and the 15-day EU AI Act clock can run simultaneously for the same incident. Organizations that have not mapped these obligations in advance will struggle to meet both timelines.

US state laws

State AI laws imposing incident reporting are at an earlier stage of development, but the EU AI Act framework is being used as a template. The Great American AI Act discussion draft proposes a 72-hour federal reporting requirement for critical AI safety incidents. Organizations operating under EU AI Act jurisdiction should treat their EU incident response process as the baseline for a US framework.

The seven components of an AI incident response plan

1. Incident classification criteria

Define what constitutes an AI incident at your organization. Without a definition, every team will make its own judgment about whether something is an "incident" requiring documentation versus an operational issue that gets handled in the ticket queue.

At minimum, classify incidents across two dimensions:

By source: model failure (the AI produced an unexpected output), data failure (the training or inference data caused a problem), integration failure (an AI system connected to a downstream process in a way that caused harm), and deployment failure (the AI system was used in a context for which it was not validated).

By severity: P1 (serious harm to persons or regulatory notification required), P2 (potential harm, requires immediate investigation and documentation), P3 (performance degradation or minor out-of-scope behavior, requires documentation but not immediate escalation).

2. Detection and triage

Most AI incidents are not self-evident. Unlike a server outage (the system is clearly down), an AI performance failure may manifest as a statistical pattern in outcomes, a complaint from an affected user, or a discovery in a periodic audit.

Define detection channels: user complaint flow, automated performance monitoring (output distribution tracking, confidence score monitoring), internal audit cycles, and regulatory inquiry (regulator asks about an incident before you knew one occurred).

Assign triage ownership. Who receives an AI incident report and makes the initial severity classification? This person needs both technical AI literacy and knowledge of regulatory obligations, which means the cybersecurity NOC is not the right first recipient for most AI incidents.

3. Preservation

When an AI incident is classified P1 or P2, immediately preserve:

The model version in production at the time of the incident
The input data for the affected inference (if retainable under privacy obligations)
System logs covering the inference period
Any performance monitoring data that predates the incident (to establish whether anomalies were detectable in advance)

If your organization does not have model versioning and rollback capabilities, an AI incident investigation becomes significantly harder. The incident response plan should flag this as a prerequisite.

4. Notification chain

Map the notification chain before any incident occurs. For each incident severity level and applicable regulation, document:

Internal notification: who within the organization must be told, in what order, by when (e.g., "P1 incidents: AI governance lead, legal, CISO, and relevant product owner within 2 hours of classification")
Provider notification: if you are a deployer, who is your contact at the AI provider, and what is the SLA for their response?
Regulatory notification: for which regulations does a P1 incident trigger mandatory reporting, to which authority, and within what timeline?

For EU AI Act Article 73, the national competent authority for the member state where the incident occurred must be notified within 15 days. If your organization does not know which EU NCA is responsible for your sector and country, that gap should be closed before an incident happens.

5. Root cause analysis

Regulators expect more than "an error occurred." They expect a documented analysis of why the AI system produced the harmful output and what was done to prevent recurrence.

AI root cause analysis differs from traditional software root cause analysis. The root cause is rarely a bug in the code. It is more likely:

Distributional shift: the inference input was different from the training distribution
Labeling error in training data: the system learned an incorrect pattern
Inadequate pre-deployment validation: the harmful behavior was present in the model but not detected
Human override failure: a human review process that was supposed to catch errors did not
Context mismatch: the AI system was deployed in a context outside its intended use

The root cause analysis should be documented with enough specificity to be meaningful to a regulator with technical AI expertise. "The model made an error" is not a root cause.

6. Remediation and documentation

Document what was changed in response to the incident. For serious incidents, regulators will expect evidence that remediation actually occurred:

Was the model retrained or replaced?
Were training data sources audited?
Was the deployment context modified?
Were human oversight procedures strengthened?
Was affected-party notification provided?

Maintain a separate incident log (not just a ticket) that tracks P1 and P2 incidents, their classification, the regulatory notification timeline, the root cause finding, and the remediation status.

7. Affected party notification

For incidents that caused harm to identifiable individuals, define your process for notifying affected parties. GDPR Article 34 requires direct notification to individuals when a breach is likely to result in a high risk to their rights and freedoms. EU AI Act does not currently impose direct notification obligations on providers for affected individuals (notification is to competent authorities), but GDPR can layer on top.

Even absent a legal obligation, your organization's response to AI-caused harm to individuals will be a significant factor in any regulatory enforcement decision.

Immediate action items

This week: Determine whether your organization has any existing AI incident response documentation. If not, create a two-page interim document that covers: (1) the definition of an AI incident, (2) the P1/P2/P3 severity classification, and (3) the regulatory notification timelines applicable to your context (EU AI Act Article 73, GDPR Article 33, or applicable state law). An imperfect interim plan documented in writing is better than no plan.

This quarter: Conduct a tabletop exercise. Simulate a P1 AI incident and trace through who does what, by when, and to whom. Tabletop exercises consistently surface gaps that no paper process catches, particularly around "who owns the determination that this is an AI incident."

For the EU AI Act deadline context and how serious incident reporting fits into your August 2026 preparation, see the EU AI Act August 2026 sprint checklist. For the AI vendor contractual dimension of incident response, the agentic AI vendor contract clauses guide covers what incident response SLAs and notification obligations should look like in vendor agreements.