Mandatory AI incident reporting is becoming an operational requirement, not just a policy proposal. Under the EU AI Act, serious-incident reporting rules for high-risk AI systems became applicable on 2 August 2026, making it important for providers and deployers to know who must act, what may qualify as an incident, and how quickly information must move.
The reporting picture has more than one track. Providers of high-risk AI systems face obligations under Article 73, while providers of general-purpose AI models with systemic risk have separate expectations to track, document, and report serious incidents. The practical challenge is to connect those legal duties to detection, investigation, escalation, and corrective action without assuming that every AI failure follows the same reporting route.
What mandatory AI incident reporting now requires
Direct answer: Under the EU AI Act, providers of high-risk AI systems must report serious incidents to the relevant authorities. Deployers that identify a serious incident must immediately inform the provider, followed by the importer or distributor and the relevant market surveillance authorities. Providers of general-purpose AI models with systemic risk have a separate duty to track, document, and report serious incidents and possible corrective measures to the AI Office and, as appropriate, national authorities without undue delay.
The distinction between these duties matters. A rule for a high-risk AI system should not be treated as an interchangeable rule for a general-purpose model with systemic risk, even when a model is used inside a system. The Commission addresses the two reporting tracks in different guidance, and the AI Act text remains the legal backbone for determining the applicable obligation.
For high-risk AI systems, the Commission says the rules that include serious-incident reporting became applicable on 2 August 2026. Its stated purpose for reporting is to detect risks early, ensure accountability, and enable quick action. Those aims explain why a report is not merely an administrative record produced after an investigation is finished: it is part of how authorities learn about potentially consequential failures while a response may still be needed.
The Commission published draft guidance and a serious-incident reporting template for stakeholder feedback before the rules applied. That preparatory work offers a way to organize reporting, but guidance and templates should be read alongside the regulation rather than substituted for it. EUR-Lex’s consolidated AI Act text, including Article 73, is the essential reference for the reporting procedure and the associated provider and deployer responsibilities.
Reporting also sits within a wider compliance stack. The Commission’s AI Act overview connects it with registration, transparency, corrective actions, and cooperation with market surveillance authorities. An organization that can file a report but cannot identify the affected system, explain what happened, or coordinate follow-up has addressed only one part of the problem.
Who reports an AI incident: providers, deployers, and model developers
The first operational question is not which form to fill out. It is which role the organization holds in relation to the affected AI system or model. Different teams may encounter the same event at different points: a deployer may observe the real-world consequence, while a provider may hold the technical records needed to examine the system’s behavior.
High-risk AI providers carry the authority-facing reporting duty
The AI Act service desk states that providers of high-risk AI systems must report serious incidents. That makes provider escalation a critical path when an incident first appears outside the provider’s own operations. Providers need a means of receiving credible signals, preserving relevant information, assessing the event, and determining how to fulfill the applicable reporting procedure.
This does not mean a provider should wait for a complete technical explanation before taking a potential incident seriously. The death-related rule expressly refers to a causal link that is suspected, not only one that has been conclusively proven. The distinction is important when evidence is still incomplete and the people investigating the event are working against a legal deadline.
Deployers must pass serious incidents onward
Deployers have their own duty when they identify a serious incident. They must immediately inform the provider first, then the importer or distributor and the relevant market surveillance authorities. A deployer therefore cannot assume that notifying its vendor is the entire response described in the rules.
That sequence calls for a practical contact map. A deployer should know which provider is associated with the deployed system, which importer or distributor is relevant, and how the appropriate market surveillance authority can be reached. The organization should also be able to pass along what it actually knows without turning uncertain observations into definitive technical conclusions.
Systemic-risk GPAI providers follow a distinct track
For providers of general-purpose AI models with systemic risk, the Commission’s GPAI guidance calls for tracking, documenting, and reporting serious incidents and possible corrective measures to the AI Office and, as appropriate, national authorities without undue delay. The Commission has also published a reporting template intended to operationalize Article 55 reporting and help these providers demonstrate compliance.
This is not a general statement that every developer of every AI model has identical reporting duties. The relevant model classification and the organization’s role must be established first. Where a systemic-risk model is involved in a downstream product, clear communication between the model provider and the system operator can help each party understand what evidence it holds and which reporting track it may need to address.
- Provider of a high-risk AI system: Establish how serious incidents reach the team responsible for Article 73 reporting and follow-up.
- Deployer of a high-risk AI system: Establish how staff recognize and immediately escalate a potential serious incident to the parties identified in the rules.
- Provider of a systemic-risk GPAI model: Establish how serious model incidents and possible corrective measures are tracked, documented, and communicated under the separate GPAI framework.
These roles may require coordination, but coordination is not the same as shifting away responsibility. A contract can specify contacts and information-sharing procedures; it should not be mistaken for a replacement for obligations attached to a party’s role under the AI Act.
What counts as a serious AI incident?
“Incident” can describe anything from a minor service interruption to an event with lasting consequences. The EU reporting question is narrower and more consequential: does the event meet the applicable serious-incident criteria? The Commission’s recital guidance describes serious incidents broadly enough that teams should not limit screening to physical injury alone.
- Death: An event leading to a person’s death demands particular attention because Article 73 sets a specific reporting rule when a causal link with the AI system is established or suspected.
- Critical infrastructure disruption: Serious and irreversible disruption of critical infrastructure is among the consequences identified in the Commission’s guidance.
- Fundamental rights: Infringements of protections for fundamental rights under Union law can fall within the serious-incident picture; the issue is not confined to equipment damage.
- Property or environmental harm: Serious damage to property or the environment is also identified in the Commission’s description.
These categories make triage more demanding than searching for a single type of system malfunction. A concerning outcome may emerge through operational monitoring, complaints, a safety investigation, or information held by an organization using the system. A useful intake process records both the reported consequence and why the AI system may be connected to it, while leaving room for that assessment to change as evidence develops.
The presence of harm is not, by itself, a reason to make an unsupported causal claim about an AI system. Equally, uncertainty about causation should not be used as a reason to ignore a credible signal. For the death-related deadline, the legal wording explicitly covers a suspected causal link, so an organization needs a way to distinguish a reasonable suspicion requiring escalation from a conclusion that still needs investigation.
Classify the consequence before debating the form
A practical screening record can start with the observed outcome: who or what was affected, whether the consequence is ongoing, and which serious-incident category may be implicated. It can then identify the AI system or model involved, the setting in which it was used, and the information supporting or weakening a possible connection. This keeps the first assessment focused on the reporting question rather than on completing every field of a final technical account.
Some events will remain difficult to classify. For example, a technical fault may be obvious while its real-world impact is still unknown, or a serious outcome may be clear while the AI system’s role is disputed. Those are reasons to preserve the evidence and escalate the uncertainty, not to force an early yes-or-no conclusion from incomplete information.
The Commission’s 2026 report on AI incidents indicates that only certain incident categories were analyzed further. That is a useful sign of the broader policy move toward structured classification, but it is not a shortcut to deciding whether a particular event is reportable. The applicable AI Act provisions and the facts of the event remain the starting points.
How the AI Act’s death-related reporting deadline changes incident response
The clearest deadline in the supplied rules concerns an incident in which a person dies. Article 73 says the report must be provided immediately after the provider or deployer establishes, or suspects, a causal link with the AI system, and no later than 10 days after becoming aware of the incident. The two parts of that rule should be read together: the outer limit does not turn an immediate reporting requirement into permission to wait.
This wording creates two facts an incident team must be able to reconstruct: when it became aware of the incident, and when a provider or deployer established or suspected the causal link. If those moments differ, both matter. A process that records only the date of a completed internal investigation may miss the point at which the duty to act was already engaged.
- Capture the first credible alert. Record when the organization learned of the event, the source of the alert, and what was known at that moment. Keep the original account rather than replacing it with a later summary.
- Escalate possible causation promptly. Route evidence of a possible connection with the AI system to the people responsible for legal and technical assessment. Mark what is observed, what is inferred, and what remains unresolved.
- Notify the required parties. If a deployer identifies a serious incident, its immediate notification sequence matters. The provider’s reporting task should have an identified owner and a route to the relevant authority.
- Preserve a decision trail. Record when suspicion arose, who made the assessment, what information supported it, and which actions followed. A later refinement of the facts should not erase the earlier timeline.
This workflow is not an attempt to replace Article 73 with an internal checklist. It is a way to make compliance feasible when evidence is scattered across operations, safety, security, and vendor-management teams. An organization can adapt the steps to its structure, but it cannot assume that a normal, slower investigation cycle will fit a rule framed around immediate action once causality is suspected.
The death-related 10-day outer limit should not be casually applied to every serious AI incident. The supplied facts identify that specific deadline and the separate “without undue delay” language for systemic-risk GPAI reporting; they do not establish one universal clock for all events. Teams should check the applicable provision and current official guidance for the event and role in question rather than relying on a simplified company-wide slogan.
Why GPAI incident reporting includes cybersecurity events
For general-purpose AI models with systemic risk, an incident may concern the model or the infrastructure supporting it, not just an immediately visible harm from a deployed application. The Commission’s GPAI guidance expects providers to track, document, and report serious incidents and possible corrective measures to the AI Office and, where appropriate, national authorities without undue delay.
The Commission’s FAQ explicitly connects this reporting duty with serious cybersecurity breaches related to the model or its physical infrastructure. It identifies self-exfiltration of model parameters and cyberattacks as examples that can fall under the obligation. That connection broadens the set of teams likely to discover a reportable signal: model safety specialists may not be the first people to see an intrusion alert or infrastructure anomaly.
Connect security alerts to model-incident assessment
A cybersecurity alert does not automatically answer every reporting question. Security staff may know that an attack occurred but still be investigating its scope, while model teams may understand potential implications without holding the underlying security logs. The reporting process needs a handoff between those functions so that an event is assessed for its relevance to the model, its infrastructure, and the applicable serious-incident obligation.
Useful initial records include what system or infrastructure was affected, what behavior was observed, when the team first knew about it, and which containment or other corrective measures are being considered. Those records are not a substitute for a legal assessment. They make that assessment possible and help the provider explain how its understanding developed over time.
The Commission’s GPAI reporting template is designed to operationalize Article 55 reporting and help providers demonstrate compliance. A template can promote consistent information, particularly where several internal teams contribute to a report. It cannot, on its own, detect a breach, decide whether an event is serious, or ensure that the AI Office and any appropriate national authorities are contacted without undue delay.
There is also a practical boundary to keep clear: a downstream organization’s complaint about an AI-enabled product and a serious cybersecurity breach involving the underlying model may reach different people and raise different reporting questions. A shared incident intake channel may help capture both, but the triage should identify the affected system or model and the relevant reporting track rather than merging distinct duties into a single generic “AI incident” category.
Building a reporting process that supports corrective action
Mandatory reporting works best when it is connected to the organization’s ability to understand and address the underlying event. The Commission presents reporting alongside registration, transparency, corrective actions, and cooperation with market surveillance authorities. That framing points toward a process with accountable owners and usable evidence, not simply a form that appears at the end of a crisis.
Define an intake route before an incident occurs
People need to know where to send a potential serious-incident signal. That includes staff operating a high-risk system, teams receiving user complaints, technical personnel monitoring failures, and security teams watching the infrastructure of a systemic-risk model. Intake should allow an uncertain report to be escalated without requiring the first person who sees it to make a final legal classification.
A practical intake record distinguishes the reporter’s observation from later analysis. It can capture the affected system or model, the apparent consequence, the first known time of the event, the first time the organization became aware of it, and the parties already informed. Keeping those details separate reduces the risk that a polished later account obscures what was known when an immediate notification decision had to be made.
Assign decisions to the right people
Technical investigators can analyze system behavior, but they may not know which market surveillance authority is relevant. Legal or compliance staff may understand the reporting rule, but they need reliable operational facts. A defined escalation group can bring together the necessary expertise and identify who is authorized to send required notices, approve reports, and coordinate corrective measures.
For deployers, this also means treating provider contact information as operational data rather than a detail buried in procurement files. For providers, it means receiving and assessing deployer notices in a way that preserves their timing and content. Where importers or distributors are involved, the notification route described for deployers should be understood before an event makes it urgent.
Use templates as aids, not as the decision-maker
The Commission’s draft guidance and reporting template for serious incidents involving high-risk AI systems, and its separate GPAI template for systemic-risk models, can help teams organize information. They are valuable precisely because incident reports often draw on facts held in different places. A template should prompt collection and communication; it should not become a reason to delay escalation until every answer is settled.
- Detection: Make safety, operational, rights-related, environmental, property, and relevant cybersecurity signals visible to the people who assess incidents.
- Triage: Record the potential serious consequence, the AI connection under examination, and the applicable provider, deployer, or GPAI role.
- Notification and reporting: Maintain the required contact routes and a record of when each relevant party or authority was informed.
- Follow-up: Link the incident record to investigation findings, possible corrective measures, and cooperation with authorities where required.
This approach has a trade-off. A highly centralized process can improve consistency but may become a bottleneck when immediate action is needed. A fully decentralized process may be faster at first but can leave teams applying different definitions or overlooking a required recipient. The workable middle ground is clear escalation ownership paired with permission for front-line staff to raise uncertainty quickly.
Can AI incident reports be harmonized across EU rules?
Organizations may already manage cybersecurity and other regulatory incident processes alongside their AI Act work. That creates an obvious efficiency question: can one internal incident record support several reporting obligations? The policy case for greater alignment is gaining attention, but alignment should not be confused with assuming that different laws share identical triggers, recipients, or deadlines.
A 2026 Council document concerning the Digital Omnibus on AI highlights “significant overlap” between AI Act cybersecurity requirements and other EU cybersecurity law and explicitly points to incident reporting as an example. The observation supports closer coordination between internal AI and cybersecurity teams. It does not establish that a report made under one regime automatically satisfies another.
The OECD has also pushed a common AI incident-reporting framework. Its 2025 report describes data required for each incident report and notes that the framework can be adapted with additional mandatory criteria for a particular reporting context. That offers a useful design principle: collect a coherent core set of incident facts once where possible, then add the fields and actions that the applicable legal route requires.
A shared internal record could track the event timeline, the affected AI system or model, the observed consequence, the evidence behind a suspected causal link, the status of investigation, and the notifications already made. Separate workflows can then determine whether the event engages Article 73, the systemic-risk GPAI duty, or another applicable process. This reduces duplicated fact-gathering without flattening meaningful legal differences.
There are limits to standardization. A serious infringement of fundamental-rights protections may require different expertise from a cyberattack on model infrastructure. A deployer’s immediate notification duty also differs from a provider’s authority-facing report. If a common form hides those distinctions, it can create the appearance of consistency while making an urgent decision harder to see.
The Commission’s work with incident data, including its 2026 report that analyzed only certain categories further, points toward more structured classification. Better classification may help organizations compare events and learn from them over time. For any individual event, however, the immediate task remains concrete: establish what happened, identify the relevant duty holder, preserve the timeline, and act under the applicable rule.
Mandatory AI incident reporting advances the EU’s ability to identify serious AI risks and respond to them, but its effectiveness depends on what happens before a report is submitted. High-risk system providers and deployers need a reliable escalation path; systemic-risk GPAI providers need one that connects model oversight with cybersecurity and infrastructure monitoring.
The most useful next step is to test an organization’s reporting path against a plausible incident: who would notice it, when would suspicion be recorded, which parties would be informed, and who would decide what to report? Answers grounded in the AI Act text, current Commission guidance, and the organization’s actual systems are more valuable than a generic incident form that no one can use under pressure.
