What Counts as a “Serious Incident” Under the EU AI Act, and Who Reports It
A surprising amount of compliance stress around the EU AI Act comes down to a single, deceptively simple question: when does a problem with an AI system become a “serious incident” that must be reported, and by whom? Many teams assume this is just another internal risk-management label—something to log, triage, and fix quietly. Under the Act, it’s a legal trigger with a clock attached. The most common mistakes are not about sophisticated legal interpretation; they happen because teams misread the reporting threshold, misidentify the responsible reporter, or wait until they’ve “confirmed” root cause and remediation before notifying anyone.
The EU AI Act’s logic is straightforward: high-risk AI systems are allowed on the market only if the provider can demonstrate and maintain control over foreseeable harms. Reporting is part of that control system. It’s not designed to punish honest mistakes; it’s designed to make sure authorities learn quickly when real-world deployment produces outcomes that cross a severity line. The practical implication is that your incident playbook cannot be limited to security breaches or classic product defects. It must treat certain AI failures—especially those that touch health, safety, fundamental rights, or significant societal disruption—as reportable events even when the underlying software is “working as intended.”
At its core, a “serious incident” under the EU AI Act is not merely an error, a complaint, or a model drift metric going out of bounds. It’s an event linked to an AI system that results in, or could reasonably be considered to result in, serious harm. That harm can be physical, psychological, or economic, and it can affect individuals or groups. In practice, the threshold is closer to “material real-world consequences” than “technical malfunction.” A model that produces a wrong label in a test set is not, by itself, a serious incident. A model that contributes to a medical mis-triage, an unsafe actuation, an unlawful denial of a benefit, or a discriminatory employment outcome can be—especially if the impact is severe, widespread, or difficult to reverse.
The second misunderstanding is thinking the incident must be proven to be caused by the AI system before reporting. Teams often wait for forensic certainty: was it the data pipeline, the user interface, the human reviewer, the downstream policy, or the model? The Act’s reporting concept is intentionally practical: if the AI system is plausibly implicated and the consequences cross the seriousness line, the duty to report can arise even while the investigation is ongoing. That means your internal process should separate the decision to notify from the decision to conclude. You can report with what you know, then follow up with what you learn.
So what kinds of harms are “serious” in the sense the Act cares about? A useful way to think about it is to look at the nature of the harm and the intensity of the impact rather than the novelty of the bug. Physical injury and threats to life are the most obvious. But serious incidents also include major impacts on health (including mental health), significant property damage, and outcomes that substantially interfere with people’s ability to exercise fundamental rights. That last category is where many teams stumble: they treat discrimination, unlawful exclusion, or procedural unfairness as reputational issues rather than safety issues. Under the EU AI Act’s framing, a high-risk AI system that meaningfully contributes to discriminatory outcomes in hiring, education access, creditworthiness, migration, or essential services can trigger serious-incident reasoning when the consequences are grave, repeated, or systemic.
It also helps to recognize what does not have to be present. A serious incident is not limited to complete system failures. It can arise from “successful” predictions if those predictions are used in a way that leads to severe harm. Likewise, it’s not limited to malicious attacks. An adversarial prompt, data poisoning, or model extraction might be relevant if it results in serious harm—but the trigger is the harm, not the novelty of the threat. A compliance program that only asks “did we get hacked?” will miss the far more common reality: harmful outcomes produced by normal operation under real-world constraints, ambiguous inputs, rushed human review, and misaligned incentives.
The timeline is the other piece most teams get wrong, largely because they import habits from other regimes. The EU AI Act’s serious-incident reporting duty is designed to be fast. The clock generally starts when the obligated party becomes aware of the incident, not when the postmortem is written. Teams often lose days to internal debates over classification: “Is it truly serious?” “Is it really the model’s fault?” “Do we have enough details to file something credible?” The correct posture is to decide quickly whether the severity threshold is plausibly met and whether the AI system is involved in a way that matters. If yes, you report within the required timeframe and then keep investigating. If you later determine it was not serious or not linked, you can clarify in follow-up communications; the bigger risk is failing to notify on time.
Equally important is identifying who reports. Many organizations assume the deployer—the company actually using the AI tool in operations—always reports, because they are closest to the harm. The EU AI Act, however, places primary reporting responsibility on the provider of the high-risk AI system. Providers are the entities that develop the system or have it developed and place it on the market or put it into service under their name. That’s often a software vendor, but it can also be a large enterprise building a high-risk system for its own use if it qualifies as putting it into service. This is where vendor–customer contracts can quietly clash with legal reality: a customer may promise to “handle notifications,” but the statutory duty can still sit with the provider, who must be able to meet it.
Deployers aren’t off the hook. They have their own obligations to use systems according to instructions, monitor operation, keep logs when required, and cooperate. In practice, deployers are frequently the first to detect a serious incident because they see the operational outcome. If the deployer doesn’t have a clear route to notify the provider immediately, the provider may miss its deadline. This is why incident reporting under the EU AI Act is not just a legal memo; it is an operational interface between two organizations. A mature setup makes “notify the provider” a default step in any event that plausibly crosses the seriousness threshold, even if the deployer is not legally the primary reporter.
The most common operational failure here is the “support ticket trap.” Someone notices a harmful outcome, files a ticket, and the vendor enters a normal triage queue optimized for uptime and feature bugs. Days pass. By the time the issue reaches the compliance function, it’s already late. If you are a provider, you need a channel where potential serious incidents are escalated immediately, distinct from routine customer support. If you are a deployer, you need to know exactly how to reach the provider’s compliance-capable escalation path, not just their help desk.
A second recurring failure is over-scoping the definition: teams treat any user complaint as a serious incident and drown the process in noise, which leads to alarm fatigue and slow decision-making. The fix is not to narrow the definition to “only deaths,” but to establish clear internal criteria for what triggers rapid assessment. For many teams, that means focusing on outcomes involving serious physical harm, substantial health impacts, significant financial loss to individuals, major disruption of essential services, or credible indicators of systemic rights impacts such as repeated discriminatory denials in high-stakes contexts. The point is to preserve urgency for the events the Act is designed to surface quickly.
Cross-border complexity adds another wrinkle. The report generally goes to the competent market surveillance authority, and the “where” can depend on how and where the system is placed on the market or used. Teams often stall because they don’t know which authority is correct, and they treat that uncertainty as a reason to wait. The better approach is to pre-decide, as part of readiness, who owns the “authority mapping” task and to maintain it as part of your compliance operations. Uncertainty should trigger escalation, not delay.
If you want a practical way to align engineering, product, legal, and customer operations without turning every anomaly into a fire drill, build your incident process around three questions that can be answered quickly: Did a real-world event occur that involves a high-risk AI system? Did it cause or plausibly contribute to serious harm (or a near-miss that could reasonably have led to serious harm)? Are we within the reporting clock from awareness? When the answer is “yes” or “unclear,” the default should be escalation and a preliminary notification path—not a prolonged internal debate aimed at certainty. The goal is speed with honesty, not perfection with delay.
Ultimately, the EU AI Act’s serious-incident reporting duty is less about paperwork and more about organizational reflex. Teams get it wrong when they treat reporting as an optional after-action task, or when they assume the closest operator will handle it informally. Getting it right means designing for the messy middle: uncertain causality, partial information, shared responsibility across provider and deployer, and real people affected in real time. When your processes make it easy to escalate early, notify within the timeline, and update as facts emerge, compliance stops being a scramble and becomes what the Act intends it to be: a disciplined feedback loop that reduces harm as systems meet the world.