Definition: AI Incident Reporting
AI Incident Reporting is the obligation under Article 73 of the EU AI Act requiring providers, and in defined cases deployers, of high-risk AI systems to notify the market surveillance authority in the Member State where a serious incident occurred, within deadlines of two to fifteen days depending on severity.
Core characteristics of AI Incident Reporting
The duty applies only to serious incidents defined in Article 3(49), not every malfunction a high-risk system generates.
- Applies to providers, with deployers required to notify providers or importers without undue delay
- Covers four outcome categories: death or serious health harm, critical infrastructure disruption, fundamental-rights infringement, or serious harm to property or the environment
- Reports go to the authority in the Member State where the incident occurred
- Allows an initial, incomplete report followed by a complete report once the investigation closes
AI Incident Reporting vs. post-market monitoring
Post-market monitoring is the continuous, internal tracking of how a high-risk system performs after deployment. AI Incident Reporting is a narrower, event-triggered duty that fires only when monitoring, or any other channel, surfaces an event meeting the Article 3(49) threshold, and it is reported externally rather than logged internally.
Importance of AI Incident Reporting in enterprise AI
Incident reporting is one of the few EU AI Act duties the Digital Omnibus left untouched, since it stays on its original schedule rather than the postponed Annex III classification deadline. DigiCert’s 2026 AI Trust Outlook found that 78% of organizations have already had an AI-related incident or vulnerability.
Methods and procedures for AI Incident Reporting
Meeting Article 73 in practice means building a repeatable escalation path rather than reacting ad hoc.
Incident detection and triage
Detection starts with the post-market monitoring signals every provider already collects, supplemented by deployer reports and user complaints. Triage decides whether an event meets the Article 3(49) threshold, since routine errors do not trigger the duty.
- Log every anomaly, malfunction, and complaint tied to the AI system in a central register
- Apply the Article 3(49) test to each event: death, health harm, infrastructure disruption, fundamental-rights infringement, or property or environmental harm
- Assign a named owner who decides, with legal input, when the reporting clock starts
Tiered notification to the market surveillance authority
Once classified as a serious incident, the provider notifies the authority where it occurred, in Germany the Bundesnetzagentur through its KoKIVO unit, or BaFin for financial-sector systems. The deadline depends on severity: two days for widespread infringements or infrastructure disruption, ten days once a causal link to a death is established, and fifteen days for other serious incidents.
Post-report investigation and corrective action
After notifying, the provider must investigate without delay, run a risk assessment, and take corrective action, without altering the system before informing the authority. The authority itself must act within seven days of receiving the report.
Important KPIs for AI Incident Reporting
Tracking this obligation requires indicators distinct from general AI performance metrics.
Detection and documentation speed
- Time from anomaly detection to serious-incident classification decision
- Percentage of incidents reported within the applicable 2/10/15-day window
- Completeness of the initial notification versus the follow-up complete report
- Number of open corrective actions per reported incident
Strategic risk exposure
Boards increasingly ask how many high-risk systems the organization operates and whether each has a named incident-reporting owner, as part of broader AI governance reporting. Bitkom’s 2026 AI study found that 85% of German SMEs still lack a documented AI inventory.
Escalation quality
A low ratio of logged anomalies to escalated serious incidents can mean triage works well, or that events are under-classified to avoid the workload. Reviewing closed-as-not-serious cases periodically distinguishes genuine discipline from quiet underreporting.
Risk factors and controls for AI Incident Reporting
Article 73 carries specific risks that require documented, ongoing controls rather than a one-off policy.
Underreporting and misclassification
The most common failure is labeling a qualifying event as a routine malfunction to avoid the reporting clock. Authorities can request incident logs during an audit, and undocumented near-misses are themselves a red flag.
- Route any event touching health, safety, infrastructure, or fundamental rights through the named incident owner before closing it internally
- Keep the Article 3(49) classification reasoning in writing for every borderline case
- Reassess past incidents if new information later establishes a causal link
Deployer-provider coordination gaps
Deployers must notify without undue delay, but many Mittelstand deployers using a purchased high-risk system have no contract clause defining how fast that escalation must happen, letting knowledge of an incident sit for days before the provider ever learns of it.
Liability and reputational exposure
Failing to report, or reporting late, exposes an organization to compliance-violation fines of up to 15 million euros or 3% of global turnover, separate from any AI liability claim the underlying harm may trigger.
Practical example
A 210-employee machinery manufacturer near Stuttgart uses an AI-based safety-monitoring system that halts a production robot when it detects a worker inside a restricted zone. A sensor calibration drift briefly delayed the stop signal, causing a near-miss injury. The incident owner classified the event as serious health harm within hours, filed an initial report with the Bundesnetzagentur inside the two-day window, and followed up once the root-cause investigation concluded.
- Central incident register covering every anomaly flagged by the safety-monitoring system
- Written Article 3(49) classification decision signed off within 24 hours of detection
- Corrective-action tracker linking each report to a completed remediation step
- Vendor-shared calibration log feeding into the next conformity review
Current developments and effects
Three developments are shaping how organizations plan their Article 73 readiness.
Digital Omnibus preserves the reporting deadline
The Digital Omnibus agreed in May 2026 postponed Annex III classification and conformity assessment obligations to December 2027, but left Article 73 reporting on its original schedule.
- Article 73 reporting stays tied to the original market-entry timeline, not the Annex III extension
- Article 50 transparency duties also remain unaffected
- Providers with systems already deployed cannot rely on the 2027 date
Commission draft guidance and reporting template
The European Commission published draft guidance and a standardized reporting template in October 2025 to help providers classify incidents consistently across Member States.
Convergence with NIS2 and sector incident regimes
Companies already running incident-reporting under NIS2 or sector rules increasingly map those workflows onto Article 73 instead of building a separate track, folding it into a broader AI compliance program.
Conclusion
AI Incident Reporting turns the promise of AI safety into a concrete, time-boxed duty that starts the moment a serious incident occurs. The Digital Omnibus extension applies to classification and conformity assessment, not to this obligation, so organizations operating high-risk systems today already carry a live Article 73 duty. A named escalation path, a documented classification test, and a working relationship with the relevant authority avoid both a missed deadline and the cost of an unmanaged safety failure. Treating incident reporting as an operational capability, not a compliance afterthought, keeps a high-risk deployment accountable.
Frequently Asked Questions
What counts as a “serious incident” under the EU AI Act?
Article 3(49) defines it as an incident or malfunction causing death or serious health harm, serious and irreversible disruption of critical infrastructure, infringement of EU fundamental-rights law, or serious harm to property or the environment. Routine bugs that do not reach one of these thresholds do not trigger the Article 73 duty.
How much time do we have to report a serious incident?
Two days for widespread infringements or critical-infrastructure disruption, ten days once a causal link to a death is established, and fifteen days for other serious incidents. An incomplete initial report is acceptable if a complete report follows.
Does AI Incident Reporting apply to a company with under 250 employees?
Yes. The duty attaches to the system’s high-risk status and the role of provider or deployer, not company size. A Mittelstand manufacturer deploying a high-risk system carries the same duty as a large enterprise.
Do we need our own IT team to run incident reporting, or can we work with a partner?
Most Mittelstand organizations combine internal safety or compliance staff with an external partner for detection tooling and classification support. Companies like Superkind that build AI agents on top of existing enterprise systems already log anomalies and override points as part of the build, giving the process a working data trail instead of a blank page.
What does non-compliance with Article 73 cost?
Failing to report, or reporting late, falls under the compliance-violation tier, carrying fines of up to 15 million euros or 3% of global annual turnover. This is separate from any damages owed if the incident also triggers an AI liability claim.
Which authority in Germany receives these reports?
Germany designated the Bundesnetzagentur (BNetzA) as its central market surveillance authority under the KI-MIG law adopted in February 2026, with a KoKIVO unit coordinating across sectors and BaFin handling regulated financial-sector AI. Reports go to the authority where the incident occurred, not always the provider’s home country.
