A serious incident under the EU AI Act is an incident or malfunction of a high-risk AI system that leads, directly or indirectly, to death or serious harm to health, serious disruption of critical infrastructure, a breach of fundamental rights obligations, or serious harm to property or the environment. A deployer must tell the provider immediately, then the authorities.
What counts as a serious incident?
The Act defines it in substance as an incident or malfunctioning of an AI system that directly or indirectly leads to any of:
- the death of a person, or serious harm to a person's health;
- a serious and irreversible disruption of the management or operation of critical infrastructure;
- the infringement of obligations under EU law intended to protect fundamental rights;
- serious harm to property or the environment.
The reporting duty applies to high-risk systems. Providers must report serious incidents to the market surveillance authority of the member state where the incident occurred, within deadlines that shorten with severity, and must investigate, assess risk and take corrective action without altering the system in a way that would affect the investigation before telling the authorities.
For an AI agent in a regulated business, the third and fourth limbs are the likely ones. An agent that discriminates against applicants, discloses personal data at scale, or makes decisions about people without lawful safeguards may infringe fundamental rights obligations. An agent that moves money wrongly, at volume, may cause serious harm to property.
What must a deployer do?
Under Article 26, a deployer who has identified a serious incident must immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities. If the deployer cannot reach the provider, the provider's reporting duties apply to the deployer as far as they can.
Separately, a deployer who has reason to think a high-risk system presents a risk must inform the provider and the authority and suspend its use. That duty can arise before any incident has happened. The full set of duties is in EU AI Act Article 26: deployer obligations when you run an AI agent.
Which party reports what depends on roles, which is not always obvious with agents; see who is the provider and who is the deployer of an AI agent. If you built the agent, you are likely its provider and carry the main reporting duty yourself.
Why are agent incidents harder to spot and contain?
A scoring model's malfunction shows up in its scores. An agent's malfunction shows up in actions spread across systems: payments, messages, record changes. Three features make incidents harder:
- Speed and volume. An agent can repeat the same faulty action hundreds of times before anyone looks. The harm in a serious incident is often in the repetition.
- Indirect causes. The Act counts incidents that lead to harm indirectly. An agent that writes a wrong figure into a customer record, which another process later uses to refuse credit, has caused harm indirectly.
- Manipulation. An agent following instructions hidden in a document an outsider sent is malfunctioning in the Act's sense, even though the model did as it was told.
The practical consequence is that containment has to come first and be fast. Stop the capability, stop pending actions, then establish what happened.
What steps should a deployer take?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Identify incidents | Alerts on unusual volume, value, refusal and complaint patterns per capability | Alert log with response times |
| Contain | Stop control halts the capability and pending tool calls; work handed back to people | Stop event with time and decision-maker |
| Preserve evidence | Append-only action record; no changes to the agent before investigation is agreed | Integrity checks; change freeze record |
| Inform provider immediately | Named contact and route in the provider contract | Notification with timestamp |
| Inform authorities | Incident procedure naming the authority and the information required | Notification and acknowledgment |
| Assess harm to people | Identify every affected person from the action record | Affected-person list |
| Remediate | Reverse what can be reversed; contact and compensate as appropriate | Remediation records |
| Learn | Root cause analysis feeding risk management and bounds | Analysis report; changes made |
Keep a short decision tree ready. Most incidents will not be serious within the Act's meaning, but many will still be personal data breaches under GDPR, operational incidents under DORA for financial entities, or conduct matters for your financial regulator. One triage should route each incident to every regime that applies.
The duties above sit within the wider deployer set in our deployer obligations checklist under the EU AI Act, and the definition of the role itself is in what a deployer is under the EU AI Act.
What will a supervisor or auditor ask?
- When did you first know something was wrong, and when did you stop the agent?
- How did you decide it was or was not a serious incident?
- When did you inform the provider and the authority?
- How many people were affected, and how do you know the list is complete?
- What changed afterwards to prevent a repeat?
What does the serious incident duty not cover?
It applies to high-risk systems; incidents involving other agents fall to other regimes. It does not replace GDPR breach notification, DORA incident reporting or your regulator's own reporting rules, all of which may apply to the same event on different timetables. And it does not define what counts as serious harm to property in numbers; that is a judgement you should document. For how this fits the wider set of rules, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, every action an agent attempts passes through the minimum chain and its verdict is filed in an append-only record, so the list of affected cases comes from a query, not a reconstruction. A certification run that clears no depth drops an agent to depth 1 the same day, which limits it to reading while the incident is investigated.
Questions people ask
Is a wrong payment made by an agent a serious incident?
It can be, if it causes serious harm to property, but a single recoverable error usually will not meet that bar. A systematic fault affecting many customers is more likely to. Document the reasoning either way.
Must a deployer report incidents involving non-high-risk agents?
Not under the AI Act's serious incident duty. Other regimes may still require it, such as GDPR for personal data breaches or DORA for major ICT incidents at financial entities.
Can we fix the agent before reporting?
Contain it straight away. Avoid changing it in ways that would affect the investigation before the authorities are informed, and record anything you did change and why.