EU AI Act Incident Reporting: What to Do When Your AI System Causes Harm

When a high-risk AI system causes or contributes to serious harm, the EU AI Act requires specific, time-bound reporting to national authorities. This is not optional, not discretionary, and not something you can handle with an internal post-mortem alone.

Article 62 establishes the serious incident reporting framework. If you provide or deploy high-risk AI systems, you need a process in place before an incident happens — because when it does, the clock starts immediately.

What counts as a serious incident

The EU AI Act defines a "serious incident" as any incident or malfunctioning that directly or indirectly leads to:

• Death or serious damage to health of a person
• Serious and irreversible disruption of the management and operation of critical infrastructure
• Breach of obligations under EU law intended to protect fundamental rights
• Serious damage to property or the environment

The threshold is "serious" — not every bug, every incorrect prediction, or every user complaint triggers a report. But the definition is broad enough that many real-world AI failures could qualify:

• A hiring AI that systematically discriminates against a protected group — this breaches fundamental rights obligations
• A credit scoring AI that incorrectly denies credit to thousands of eligible applicants — potentially serious financial harm
• A medical AI that misclassifies a condition, leading to delayed treatment — health damage
• A critical infrastructure management AI that causes a service outage — infrastructure disruption

Reporting timeline and process

Article 62 establishes a two-stage reporting process:

Initial report

• Life-threatening or fatal incidents: Report within 2 days of becoming aware the incident is likely caused by or related to the AI system. This is a preliminary notification — you do not need a full root cause analysis.
• Non-fatal serious incidents: Report within 15 days of becoming aware.
• Widespread malfunctioning: Report within 15 days of becoming aware of a malfunctioning that constitutes a breach of fundamental rights obligations.

Follow-up report

After the initial report, you must provide a detailed follow-up within a reasonable period, including:

• Root cause analysis
• Corrective actions taken or planned
• Whether the system has been recalled, withdrawn, or modified
• Any communication to affected persons

Reports go to the market surveillance authority of the member state where the incident occurred. If the incident occurred in multiple member states, report to each relevant authority.

Provider vs deployer responsibilities

Both providers and deployers have incident reporting obligations, but they differ:

Provider obligations

• Report serious incidents to the market surveillance authority of the member state where the incident occurred
• Conduct a root cause investigation and implement corrective measures
• If the system presents a risk: take immediate action to recall or withdraw it
• Inform all deployers of the system about the incident and any corrective actions
• Maintain a register of serious incidents and corrective actions

Deployer obligations

• Report serious incidents to BOTH the provider AND the relevant market surveillance authority
• Suspend use of the system if it presents a risk — do not wait for the provider to act
• Cooperate with the provider's investigation
• Preserve all relevant logs and evidence
• Take interim measures to protect affected persons

Building an incident reporting process

Do not wait for an incident to figure out your process. Build it now. Here is what a compliant incident response process looks like:

1. Detection and triage

• Define what triggers an investigation — user complaints, anomalous outputs, performance degradation, external reports
• Assign an incident owner who can assess severity within 24 hours
• Create a severity classification: critical (life-threatening), serious (other qualifying harm), non-serious (monitor but no mandatory report)

2. Initial assessment

• Determine whether the AI system caused or contributed to the harm
• Assess whether the incident meets the "serious incident" definition
• Identify the affected member state(s)
• Decide whether to suspend the system immediately

3. Reporting

• Use the standardised form (once published by the Commission — until then, contact the relevant authority directly)
• Include: system identification, incident description, affected persons, immediate actions taken, provider details
• Start the clock: 2 days for life-threatening, 15 days for other serious incidents

4. Investigation and remediation

• Conduct root cause analysis
• Implement corrective actions — model retraining, output filtering, usage restrictions, or system withdrawal
• Document everything for the follow-up report

5. Communication

• Notify deployers (if you are a provider) or the provider (if you are a deployer)
• Inform affected persons where appropriate
• Update your system documentation to reflect any changes made

Post-incident obligations

After a serious incident, you have ongoing obligations:

• Corrective action tracking: Market surveillance authorities may require specific corrective measures. You must implement them and demonstrate compliance.
• System modification: If the incident revealed a systematic issue, you may need to modify the system for all deployments — not just the one where the incident occurred.
• Updated risk assessment: The incident must feed back into your Article 9 risk management system. Update your risk analysis, add the incident as a known risk, and adjust mitigation measures.
• Documentation update: Your technical documentation (Annex IV) and instructions for use (Article 13) must be updated to reflect any changes made as a result of the incident.

Incident reporting is not a bureaucratic formality. It is a core safety mechanism that protects both the people affected by AI systems and the companies that build and deploy them. Having a clear, tested process in place is one of the most practical things you can do for compliance — because the worst time to figure out your incident process is when an incident is happening.