Short answer. A serious incident under the EU AI Act is an incident or malfunction of a high-risk AI system that directly or indirectly leads to death, serious harm to health, serious and irreversible disruption of critical infrastructure, a breach of fundamental rights protected by EU law, or serious damage to property or the environment. Providers must report it to the national market surveillance authority within 15 days of becoming aware, within 10 days if a death may be involved, and within 2 days when critical infrastructure is disrupted. The obligation applies from 2 August 2026.
A serious incident is a real-world harm, or a near-miss with a clear causal link to the AI system, rather than a routine bug or a slow response time. The AI Act names four outcome categories: death or serious damage to a person’s health, serious and irreversible disruption of critical infrastructure, infringement of fundamental rights protected under EU law, and serious harm to property or the environment. If a high-risk system contributes to one of these, the clock starts.
For a bank or insurer, the fundamental-rights category is the one that bites most often. Consider three concrete cases:
The point is not to catalogue disasters. It is to see that ordinary FS&I use cases, scoring, triage, fraud, sit exactly where serious-incident risk lives. Ableneo shipped 34 production AI projects in 2025, and 94% of them use large language models, so the systems that now need incident discipline are already in the workflow, not a future concern.
The serious-incident rules sit in Article 73 of Regulation (EU) 2024/1689. They apply to providers of high-risk AI systems placed on the Union market, and the obligation becomes enforceable on 2 August 2026, the same date most high-risk obligations take effect. The European Commission published draft guidance and a standardized reporting template in 2025 to make the process consistent across Member States, with the final version expected to apply from that August 2026 date.
For financial services and insurance, this lands on top of an existing incident-reporting culture built around DORA and supervisory expectations from bodies like the National Bank of Slovakia. That overlap is deliberate in the law, and it changes what a Slovak, Czech, or Austrian institution actually has to file. Getting the interaction right is the difference between one clean report and a duplicated, contradictory paper trail across two regulators.
A serious incident covers death, serious health harm, critical-infrastructure disruption, fundamental-rights breaches, or serious property and environmental damage caused by a high-risk AI system.
Speed is tiered by severity. The general rule is a report without undue delay and no later than 15 days after the provider or deployer becomes aware of the incident. If the incident may have caused a death, the deadline tightens to 10 days. If it involves a widespread infringement or a serious and irreversible disruption of critical infrastructure, the report is due within 2 days. Reporting starts immediately once a causal link between the AI system and the harm is established or reasonably suspected.
The law accepts that full facts take time. Where necessary to meet the deadline, a provider may file an initial, incomplete report and follow it with a complete one. The practical lesson: build a process that can file something accurate within 48 hours, then supplement it. A team that waits for a perfect root-cause analysis will miss the 2-day tier every time.
The formal reporting duty sits with the provider of the high-risk AI system, the organization that develops it and puts it on the market under its own name. Many banks and insurers are deployers, not providers, when they buy a scoring or fraud engine from a vendor. In that case the deployer’s duty is to inform the provider immediately once it identifies a serious incident. The Commission’s draft guidance reads “immediately” as within 24 hours.
There is a backstop. If the deployer cannot reach the provider, or the provider fails to act, the deployer itself must report to the market surveillance authority. So a deployer cannot treat this as purely the vendor’s problem. The contract needs a named escalation path, a 24-hour notification clause, and a fallback that lets the institution file directly when the vendor goes quiet.
The AI Act avoids double regulation for sectors that already report incidents. For financial entities covered by DORA, and for critical-infrastructure and medical-device regimes, a simplified approach applies: those institutions continue to report operational and ICT-related incidents through their existing channels, and the AI Act’s serious-incident obligation is triggered only for infringements of fundamental rights. A model outage that DORA already captures does not generate a separate AI Act filing, but a discriminatory lending decision does, because DORA does not cover that harm.
This is why an FS&I incident playbook cannot be copied from a generic AI Act checklist. The institution has to map each harm type to the right regulator: ICT and operational resilience events to the DORA route, fundamental-rights harms to the AI Act market surveillance authority. Some incidents will need both. A single triage rule at the start of the process decides which path, or paths, a given event takes.
Start with an inventory. You cannot report incidents from systems you have not classified, so the first move is knowing which AI systems in the estate are high-risk under Annex III, credit scoring and insurance pricing and underwriting are named examples. Then define a serious-incident trigger in plain language that a first-line operator can apply, tied to the four outcome categories. Third, set the causal-link and clock-start rules so the team knows when the 2, 10, or 15-day timer begins. Fourth, wire the DORA and AI Act routing decision into the same intake, so one event is classified once and sent to the right authorities without duplication.
Serious-incident reporting rewards institutions that treated governance as part of the build, not a document written after go-live. Ableneo works inside regulated FS&I environments across Slovakia, the Czech Republic, and Austria, with roughly 80% of projects reaching production, and that production track record is where incident discipline is proven. We design the classification, causal-link, and routing logic into the system so a bank can meet the 2-day tier without a fire drill. See how we structure regulated AI delivery on our AI transformation practice.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.