Serious incident vs malfunction: where to draw the line
Not every AI bug is reportable. Learn the Article 3(49) threshold that separates a software malfunction from a serious incident requiring notification.
The regulatory threshold is harm, not failure
Article 3(49) of the EU AI Act defines a serious incident as an incident or malfunctioning that directly or indirectly leads to death, serious health damage, disruption of critical infrastructure, breach of fundamental rights obligations, serious property or environmental damage, or serious harm to health or safety — including psychological harm.
A software bug, model drift, or unexpected output only becomes a reportable incident if it causes or could potentially cause one of these outcomes. The test is the actual or potential severity of the consequence, not the technical nature of the failure.
Near-misses: when potential harm triggers reporting
The EU AI Act does not limit reporting to incidents that have already caused harm. A near-miss that could have resulted in a serious outcome should be assessed against the Article 3(49) criteria.
For example, a healthcare AI temporarily misclassifying a critical diagnosis before human review catches it is worth evaluating — the potential severity is high even if the actual outcome was contained. Document your reasoning either way to build an audit trail.
Practical triage framework
When an anomaly is detected, apply a two-step test: (1) Did or could the anomaly result in one of the six harm categories listed in Article 3(49)? (2) Is the potential severity serious (not trivial)? If both answers are yes, activate the formal incident reporting workflow under Article 73. The 15-day clock starts from the moment you become aware.
Log all triage decisions — including those where you determine the event is not a serious incident — in your post-market monitoring system. This evidence protects you if the assessment is later questioned by a market surveillance authority.