We use cookies to improve your experience and analyse site traffic.
We use cookies to improve your experience and analyse site traffic.
A serious incident under Article 3(49) includes death, serious harm, infrastructure disruption, or fundamental rights infringement, with indirect causation sufficient. Three reporting timelines apply: two days, ten days, and fifteen days from awareness. All events assessed against the threshold must be logged regardless of outcome.
Article 3(49) defines a serious incident as an incident directly or indirectly resulting in death or serious harm to health, serious and irreversible disruption to the management or operation of critical infrastructure, infringement of obligations under EU law intended to protect fundamental rights, or serious harm to property or the environment.
Article 3(49) defines a serious incident as an incident directly or indirectly resulting in death or serious harm to health, serious and irreversible disruption to the management or operation of critical infrastructure, infringement of obligations under EU law intended to protect fundamental rights, or serious harm to property or the environment. Indirect causation is sufficient: an AI system's output that contributes to a harmful decision through the deployer's operational process constitutes a serious incident even though the deployer, not the system, made the final decision.
The reporting regime is tiered by severity. Widespread fundamental rights infringement or serious critical infrastructure disruption requires reporting within 2 days from awareness under Article 73(1)(a). Death or suspected causal link to a death requires reporting within 10 days under Article 73(1)(b). All other serious incidents meeting the Article 3(49) definition require reporting within 15 days under Article 73(1)(c). The clock starts when the deployer becomes aware of the incident and establishes a reasonable likelihood of a causal link between the AI system and the harm.
The deployer's reporting chain has two paths depending on whether the provider is responsive.
The deployer's reporting chain has two paths depending on whether the provider is responsive. The primary path is notification to the provider without undue delay, providing the system identity, date and time of the incident, a description of what occurred, the suspected causal link to the AI system, the affected persons, and the immediate actions taken by the deployer.
Where the provider is unreachable, unresponsive, or established outside the EU without an authorised representative, the deployer reports directly to the market surveillance authority of the member state where the incident occurred, within the tiered timelines. This direct reporting path ensures that regulatory notification is not blocked by provider non-cooperation.
Evidence preservation is critical and must begin immediately upon detection. All related evidence is preserved: system logs from the deployer's environment, operator records documenting the human oversight decisions surrounding the incident, affected case data showing the specific inputs and outputs involved, complaint records from affected persons, and all communications with the provider. The break-glass procedure should be activated if harm is continuing, stopping the system's processing while preserving the forensic record.
Every event assessed against the Article 3(49) criteria is logged in the deployer's incident register regardless of whether it was ultimately determined to constitute a serious incident.
Every event assessed against the Article 3(49) criteria is logged in the deployer's incident register regardless of whether it was ultimately determined to constitute a serious incident. The register records the event description, the detection date, the triage outcome as serious incident confirmed, ruled out, or under investigation, the severity classification determining the applicable reporting timeline, the investigation status and findings, the corrective actions taken, and the closure date.
The incident register serves as evidence that the deployer has a functioning incident detection and assessment process. It provides a basis for trend analysis: recurring near-miss events may indicate a systemic problem requiring proactive intervention. It also protects the deployer in the event of a dispute about whether a reporting obligation was met. The register is retained in Module D5 of the deployer compliance record and available for inspection by the competent authority.
Compliance-related communication between the deployer and provider must be structured, documented, and retained.
Compliance-related communication between the deployer and provider must be structured, documented, and retained. The deployer reports three categories of information to the provider: incident reports when events meeting or potentially meeting the Article 3(49) criteria are detected, monitoring data where contractually required under the PMM framework, and deployment context changes that could affect the risk profile or FRIA validity.
The deployer should expect four categories of communication from the provider: update notifications with timing, content, and impact assessment for each system change; known issue disclosures when the provider identifies problems that may affect the deployer's use; PMM findings relevant to the deployer's specific deployment context; and end-of-life notification with transition guidance and a timeline when the system is being withdrawn.
All compliance-related communications are logged with date, subject, content summary, and any action items. This log is retained in Module D5 and available for inspection. For organisations with automated infrastructure, a structured reporting portal or API endpoint captures mandatory fields ensuring the provider receives the information it needs. For organisations using procedural approaches, a communication log spreadsheet, structured feedback form templates, and quarterly review meetings provide the minimum viable communication framework.
The deployer reports directly to the market surveillance authority within the tiered timelines. The deployer's reporting obligation is not contingent on provider responsiveness.
Yes. Every event assessed against the Article 3(49) criteria is logged regardless of outcome. This complete record demonstrates diligence in applying the assessment criteria.
Aggregate operational metrics including inference volume, error rates, output distribution summaries, and override rates. The pipeline transmits aggregate statistics, not raw inference data.
System logs, operator records, affected case data, complaint records, and provider communications, preserved immediately upon detection before investigation begins.