Key takeaways
- An AI incident is any event where an AI system’s development, deployment or malfunction leads, directly or indirectly, to real-world harm. That is wider than a software bug and wider than a workplace accident.
- Under EU AI Act Article 73, providers of high-risk AI systems must report serious incidents to national market surveillance authorities. The duty applies from 2 August 2026.
- The deadlines are tiered and short: 2 days for a widespread infringement or a serious disruption of critical infrastructure, 10 days where a person dies, and 15 days for other serious incidents.
- A serious incident is defined in Article 3(49): death or serious harm to health, serious and irreversible disruption of critical infrastructure, a breach of fundamental-rights obligations, or serious harm to property or the environment.
- AI incident reporting works only when it sits on a repeatable internal workflow: detect, classify, decide reportability, notify on time, then investigate and remediate.
What is incident reporting, and what makes an AI incident different
Incident reporting is the practice of capturing and documenting an unexpected event so an organisation can understand what happened, contain the damage and prevent a repeat. In workplace safety, healthcare and IT service management the discipline is mature: a near miss, an injury or a system outage gets logged on a standard form with the who, what, when, where and why, and the record feeds investigation and corrective action. AI changes the shape of the problem, and that is where AI incident reporting parts ways with the generic version. The harm from an AI system is often indirect. A model does not trip a worker or spill a chemical; it produces an output that a person or another system acts on, and the damage surfaces downstream. An incorrect medical triage suggestion, a biased loan rejection, or a content-moderation failure can each cause serious harm without any single visible malfunction. The chain from cause to consequence can be long, statistical and hard to attribute. That is why regulators and standards bodies have written AI-specific definitions. The OECD, in its 2024 paper Defining AI Incidents and Related Terms, sets the reference taxonomy. It defines an AI incident as an event where “the development, use or malfunction of an AI system directly or indirectly leads to harm” such as injury, disruption of critical infrastructure, human-rights violations, or property or environmental damage (OECD, 2024). It separates an AI hazard, a circumstance that could plausibly lead to an incident, from an AI incident, where harm actually occurs, and adds an AI disaster as a serious AI incident that disrupts a community or society. Those distinctions decide what an organisation must watch for, log and, in some cases, report. They also map closely onto how AI Sigil approaches AI risk management.
The EU AI Act obligation: Article 73 serious-incident reporting
For organisations operating in or selling into the European Union, this stops being good practice and becomes law. The mechanism is Article 73 of the EU AI Act, the spine of any EU AI Act compliance programme for high-risk systems.
Who must report and to whom
The text is direct: “Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities” of the Member State where the incident occurred (EU AI Act, Article 73). Deployers are not bystanders. Where a deployer becomes aware of a serious incident, the obligation flows through to inform the provider and, in defined cases, the authority.
What counts as a serious incident
The trigger is the Article 3(49) definition. A serious incident is an incident or malfunction that directly or indirectly leads to one of four outcomes: the death of a person or serious harm to health; a serious and irreversible disruption of the management or operation of critical infrastructure; an infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment. If none of those four apply, the event may still be worth logging internally, but it is not a reportable serious incident.
The reporting deadlines
Article 73 sets a tiered clock, and the clock is short.
- 2 days: a widespread infringement, or a serious and irreversible disruption of critical infrastructure.
- 10 days: the death of a person.
- 15 days: all other serious incidents.
The baseline rule ties everything together: the provider reports immediately after establishing a causal link, or the reasonable likelihood of one, between the AI system and the incident, and in any event no later than 15 days after becoming aware. Because those windows are tight, the Act lets a provider submit an incomplete initial report and follow it with a complete report once the facts are clearer.
After the report
Reporting is the start, not the end. Following a serious incident, the provider must, without delay, perform the necessary investigations, including a risk assessment of the incident, and take corrective action. The market surveillance authority then has seven days to take appropriate measures.
When the clock starts, and the September 2025 Commission guidance
The hardest operational question is when the clock begins. The duty is tied to awareness plus a causal link: the deadline runs from the moment the provider establishes, or could reasonably establish, a link between the AI system and the harm. In September 2025 the European Commission published draft guidance and a reporting template to make this workable (Latham & Watkins, 2025). The draft, issued on 26 September 2025 and open to consultation until 7 November 2025, clarifies that an indirect causal link is enough. It gives the example of an incorrect medical analysis that leads to later harm, or a flawed AI loan assessment. It also addresses overlap with sector rules: for critical-infrastructure operators already reporting under NIS2, only incidents involving a fundamental-rights breach need a separate Article 73 report, while other incidents follow the sectoral channel. The obligation applies from 2 August 2026, when the AI Act’s high-risk rules take effect. Organisations that wait until then to design a workflow will be building it under deadline pressure, during a live incident.
GPAI and systemic-risk incidents
High-risk systems are not the only ones in scope. Providers of general-purpose AI models with systemic risk carry their own incident duties under Article 55. They must track, document and report serious incidents to the AI Office, together with possible corrective measures. The GPAI Code of Practice, whose Safety and Security chapter was finalised in July 2025, turns that duty into concrete commitments for signatories: maintain serious-incident tracking, report relevant information to the AI Office and national authorities on defined timelines, and keep the documentation that supports post-incident analysis. For the largest model providers, AI incident reporting becomes a continuous monitoring obligation rather than an occasional filing. AI Sigil treats this as part of an organisation’s wider AI governance platform, not a separate silo.
How AI incident reporting fits the standards: NIST and ISO
Regulation sets the floor. Voluntary standards give an organisation the operating model. The NIST AI Risk Management Framework organises trustworthy-AI work into four functions: Govern, Map, Measure and Manage (NIST AI RMF). Incident response lives mainly in Manage, which calls for post-deployment monitoring, mechanisms to capture and act on problems, and documented incident response, recovery and change management. Govern adds the policies and accountability that keep those mechanisms in place rather than letting them lapse. ISO/IEC 42001, the AI management-system standard, places incident management inside a certifiable Plan-Do-Check-Act cycle. An organisation running a 42001 management system maintains a defined process for handling AI incidents, links it to risk treatment, and shows auditors evidence that the loop closes. For a team that already runs ISO/IEC 27001 for information security, the AI incident process can be designed to interlock with the existing security-incident process rather than compete with it. Mapping these standards to a single control set is a core part of any AI risk management effort.
Building an internal AI incident reporting workflow
A reporting obligation is only as good as the process behind it. A workable AI incident reporting workflow has four stages, and a named owner for each.
Detect and intake
Most AI incidents are first noticed by a user, a support agent or a downstream system, not by a dashboard. Give every channel a single intake point: a form, a queue or a hotline that anyone can use without judging in advance whether the event is reportable. Capture the basics on intake, namely what happened, which system, when, and the observed harm, so the clock-relevant facts exist from minute one.
Classify and decide reportability
This is the decision the deadlines hinge on. Run each intake against the Article 3(49) test: did the event lead, directly or indirectly, to death or serious health harm, critical-infrastructure disruption, a fundamental-rights breach, or serious property or environmental harm? A short decision tree, owned by a named role, keeps the judgement consistent and documented. Record the reasoning even when the answer is no, because that record is the organisation’s defence if the call is later questioned.
Notify within the deadline
Once an event is classified as a serious incident, the tiered clock applies. Identify the right market surveillance authority, prepare the report on the Commission template, and file within 2, 10 or 15 days as the category requires. Use the incomplete-initial-report option rather than miss the window.
Investigate, remediate and log
After filing, investigate root cause, run the risk assessment Article 73 requires, and take corrective action. Log everything in a register that ties the incident to the system, the model version, the affected users and the remediation. External databases such as the AI Incident Database (AIID), the AIAAIC repository and the OECD AI Incidents Monitor are useful reference points for learning from incidents across the wider industry, a practice the CSET reviewed in its January 2025 framework brief.
How AI incident reporting differs from other regimes
One event can trigger several duties at once. A data breach inside an AI system may be a GDPR personal-data breach, with its 72-hour notification to the supervisory authority under Article 33, an Article 73 serious incident, and, for a financial entity, a DORA ICT-incident report. NIS2 adds obligations for essential and important entities, and sector rules for medical devices, aviation or financial services add more. The practical lesson is to map reporting obligations once, in advance, and design a single intake that can fan out to the right regimes. A team that treats AI incident reporting as a standalone EU AI Act task will end up filing the same event three times in three formats under three clocks, or, worse, miss one. Centralising the obligation map is something an AI governance platform is built to do.
FAQ
What is AI incident reporting? AI incident reporting is the structured process of detecting, documenting and, where legally required, notifying authorities about events in which an AI system causes or contributes to harm. Under the EU AI Act it is a legal duty for providers of high-risk and certain general-purpose AI systems, not only an internal good practice. What are the steps for reporting an AI incident? Detect and log the event at a single intake point; classify it against the Article 3(49) serious-incident definition; if it qualifies, notify the relevant market surveillance authority within the applicable deadline; then investigate root cause, run a risk assessment and take corrective action. Keep a written record at every step, including the reasoning for events you decide not to report. What are the elements of an AI incident report? At minimum: a description of what happened, the AI system and model version involved, when the organisation became aware, the type and severity of harm, the people or assets affected, the suspected causal link, and the corrective measures taken or planned. The Commission’s Article 73 template structures these fields for submission. What is a serious incident under the EU AI Act? Article 3(49) defines it as an incident or malfunction that directly or indirectly leads to the death of a person or serious harm to health, a serious and irreversible disruption of critical infrastructure, a breach of fundamental-rights obligations under Union law, or serious harm to property or the environment. When does Article 73 reporting apply, and how fast must I report? The obligation applies from 2 August 2026. Deadlines run from when the organisation becomes aware and can establish a causal link: 2 days for a widespread infringement or serious critical-infrastructure disruption, 10 days where a person dies, and 15 days for other serious incidents. How is AI incident reporting different from a data-breach notification? A GDPR breach concerns personal data and carries a 72-hour notification deadline. An AI Act serious incident concerns harm from the AI system itself, on the 2, 10 or 15-day clock. The same event can trigger both, plus sector regimes such as NIS2 or DORA, so the duties should be mapped together rather than handled in isolation.
Conclusion
AI incident reporting is moving from a safety-culture nicety to a hard legal obligation with short deadlines and named accountability. The organisations that will handle it calmly are the ones that decide now who owns the intake, how a serious incident is classified, and which authority gets notified within which window. The work to do before 2 August 2026 is not legal interpretation alone; it is the standing process that turns Article 73 into something a team can actually run. AI Sigil helps regulated teams turn obligations like this into running, auditable processes inside one governance system.