One Incident, Two Regulators: DORA Article 19 vs AI Act Article 73
Your credit-scoring model starts systematically rejecting applicants from one postcode. You catch it on a Tuesday. Who do you tell, and by when? If your answer comes only from your DORA incident playbook, it is incomplete — and the part it is missing goes to a regulator your incident team has probably never contacted.
Two channels, and neither discharges the other
DORA and the AI Act both impose incident reporting. They are not alternatives, they are not a superset and a subset, and satisfying one does not satisfy the other. They differ in every dimension that matters operationally.
| DORA — Article 19 | AI Act — Article 73 | |
|---|---|---|
| What triggers it | A major ICT-related incident, classified against the RTS criteria | A serious incident involving a high-risk AI system |
| Who you tell | Your competent financial authority | The market surveillance authority |
| Who files | The financial entity | Primarily the provider — deployers must inform the provider |
| The clock | Initial 4h / intermediate 72h / final 1 month | Without undue delay after establishing the causal link |
| What it is about | Operational disruption of your ICT estate | Harm caused by the AI system, including to fundamental rights |
Back to the postcode
Work the example through both regimes.
Under DORA, ask the Article 18 classification questions: clients affected, duration, geographic spread, data losses, economic impact, criticality of the service. A scoring model quietly skewing outcomes may well fail to reach the major-incident thresholds. The service was available. Nothing was lost. It answered every request within SLA. Your incident may not be reportable at all.
Under the AI Act, the question is different: did the system cause, or is it capable of causing, serious harm — including infringement of fundamental rights obligations under Union law? Systematically denying credit on a proxy for a protected characteristic is precisely the harm Annex III point 5(b) exists to guard against. This is squarely an Article 73 matter, and it goes to a regulator your DORA process does not talk to.
The same event, therefore: possibly not a DORA incident, definitely an AI Act one. Now invert it. A cloud outage takes your scoring service down for six hours. That is a textbook DORA major incident. It is not an AI Act serious incident at all — the model did no harm, it simply was not there.
If you are the deployer, you still have a job
Article 73 puts the reporting duty primarily on the provider of the high-risk system. Most banks buy their models, so most banks are deployers — which does not let them out of the loop. A deployer who identifies a serious incident must inform the provider, and it is the deployer who is actually in a position to notice, because the deployer is the one watching the outcomes in production.
Two things follow. First, your contract needs a route for this: a named channel, a timeframe, and an obligation on the provider to tell you what they filed. Second — and this is the one that bites — if Article 25 flipped you into being the provider because you fine-tuned the model, the filing obligation is yours. Institutions that have not worked out their role will discover it during an incident, which is the worst possible moment.
What to change in your playbook
You do not need a second incident process. You need your existing one to ask two more questions.
- Add an AI branch to the classification tree. After the DORA severity assessment, ask: did a high-risk AI system contribute to this event, and did it cause or risk serious harm — including to fundamental rights? A "no" on DORA severity must not terminate the tree.
- Add outcome monitoring, not just availability monitoring. Your ICT monitoring watches whether the model responds. Nothing watches whether it responds correctly across cohorts. Distribution drift and disparate-impact checks belong in operations now, not only in model validation. This is what Article 72 post-market monitoring is for, and it is the detection layer for Article 73.
- Name the second regulator. Find out today which authority is your market surveillance authority for AI. Most incident teams cannot answer this. It is not a question to research at hour four.
- Put the provider notification path in the contract, with a deadline that lets them meet theirs.
Our ICT incident analyzer classifies an event against the DORA criteria; the AI Act exposure check tells you whether the system involved is high-risk in the first place, which is the precondition for Article 73 applying at all. The cross-obligation table on our AI Act hub sets the two regimes side by side.
The text of Article 73 on the reporting of serious incidents and Article 72 on post-market monitoring is on our sister site regulation-ai.eu.
This article is analytical guidance for compliance and legal teams, not legal advice. References: EU AI Act (Regulation (EU) 2024/1689), the Digital Omnibus on AI (Council green light, 29 June 2026), DORA (Regulation (EU) 2022/2554), and the Commission guidelines on GPAI of 18 July 2025.
