Classifying an AI agent failure under DORA uses the same criteria as any ICT incident: clients and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of services and economic impact. What differs is measurement. Agent failures are often silent and systematic, so duration runs from the first wrong action and integrity carries extra weight.
What do the classification criteria require, in plain words?
DORA (Regulation (EU) 2022/2554), applying from 17 January 2025, requires financial entities to classify ICT-related incidents and report those that are major. In substance, the criteria are:
- clients, financial counterparts and transactions affected, by number, relevance and amount;
- reputational impact, such as media attention, complaints or loss of clients;
- duration and service downtime;
- geographical spread, especially across member states;
- data losses, covering availability, authenticity, integrity and confidentiality;
- criticality of the services affected, including whether they support critical or important functions;
- economic impact, direct and indirect costs and losses.
DORA's technical standards set thresholds and say how criteria combine. In substance, an incident is major when it affects critical services and meets enough of the other thresholds. Repeated incidents with the same apparent root cause can be assessed together. Check the detailed thresholds in the standards rather than estimating. The reporting process that follows is described in DORA incident reporting when an AI agent fails.
Who classifies, and when?
The financial entity classifies, whether the agent runs in-house or on a vendor's platform, and must do so quickly enough to meet reporting deadlines. Vendor platforms are ICT third parties, as explained in DORA makes agent providers your ICT third parties, so contracts should oblige them to provide the facts you need fast.
Classification should be repeatable. Write down how each criterion is measured for agents before the first incident, not during it.
How do the criteria apply to an agent failure?
Take an illustrative case: a payments agent at a mid-sized bank applies a wrong currency rule for part of a day, so a few hundred cross-border transfers settle at the wrong amount. Nothing went offline.
Clients and transactions. Count every client and transaction the agent touched in the window, from the action record, not from complaints received. Complaints lag and undercount.
Duration. DORA measures from when the incident occurred, not when it was detected. For an agent, that is the first wrong action. If you only know when someone noticed, your duration will be wrong.
Downtime. Possibly none. The agent kept running. That is why availability-based thinking misses agent incidents.
Data losses. Here the integrity criterion bites. Wrong amounts written to ledgers and payment messages are integrity losses, even though no data went missing.
Criticality. Payments execution is almost certainly a critical or important function.
Geographical spread. Cross-border transfers may touch clients in several member states.
Economic impact. Refunds, remediation costs and staff time to correct each transfer.
Reputational impact. Client complaints and any media attention.
On those facts, the incident could well be major. A team looking only at uptime would have recorded no incident at all.
How do you set up classification for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Measure clients and transactions affected | Query the action record for every case touched in the window | Case and transaction list with amounts |
| Measure duration correctly | Identify the first wrong action, not the first alert | Timeline from timestamped actions |
| Assess data integrity | Identify records and messages the agent wrote wrongly | Integrity impact list |
| Assess criticality | Map each agent capability to the functions it supports | Capability-to-function map |
| Assess geographical spread | Record client jurisdiction per affected case | Jurisdiction breakdown |
| Assess economic and reputational impact | Estimate remediation and track complaints and media | Impact estimate and complaint log |
| Detect recurrence | Link incidents with the same root cause across time | Root cause register |
| Repeatable method | Written classification guide for agent incidents | Approved guide and training records |
The recurrence row matters for agents. A flaw in a brief or a source can produce small incidents that individually fall below thresholds. Linked by root cause, they may not. The framework feeding this is covered in DORA ICT risk management framework for AI agents.
What will a supervisor ask?
- How did you measure the duration of this agent incident?
- How did you count affected clients, and why should we trust the count?
- Why did you treat this as non-major?
- Have there been earlier incidents with the same cause?
- How quickly did your vendor give you the facts you needed?
What does DORA classification not cover?
It does not classify the agent itself; DORA classifies incidents. Classifying an AI system by risk tier is a separate exercise under the EU AI Act, for which see the EU AI Act risk classification checklist. It does not decide GDPR breach notification, which has its own test. And it does not decide whether the vendor counts as an ICT third-party provider, covered in are AI agent vendors ICT third-party providers under DORA. For the wider map, 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
Pryme files every action with its time, capability, version and verdict, so the first wrong action and every affected case can be found by query. That gives classification a measured duration and an exact count of clients and transactions, rather than an estimate built from complaints.
Questions people ask
Can an incident with no downtime be major?
Yes. Downtime is one criterion. An agent that keeps running while corrupting data or transactions can meet the thresholds through clients affected, integrity losses and economic impact.
Should near misses be classified?
Record them. A held action that a person caught is not an incident, but a pattern of near misses is evidence that a control is doing heavy lifting and that the agent needs attention.
Who decides the classification?
A named role in the incident process, usually in operational risk or IT risk, with input from the agent's business owner. The decision and its reasoning should be recorded.