Your ICT risk framework, your incident playbook, your third-party register: none of it disappears, and none of it is enough. The AI Act attaches to what your models do, and it asks for four things DORA never asked for. Here is exactly where the gap is.
A DORA programme is not a blank slate for the AI Act. Four of its pillars produce artefacts you can reuse directly, and knowing which ones stops you rebuilding what you already own.
DORA Art. 5-16. Governance, asset inventory, risk appetite. The AI system is already in your ICT estate: it is already on this register.
What DORA requires →DORA Art. 17-23. Detection, classification, the 4h / 72h / one-month clock. The machinery exists; the AI Act simply points it at a second regulator.
Incident reporting →DORA Art. 28-30 and the Register of Information. If you bought the model, the vendor is already in your register with contractual and audit rights.
Third-party risk →DORA Art. 24-27, up to TLPT. A testing culture and evidence trail the AI Act's conformity work can lean on.
TLPT →This is the table that matters. On the left, the DORA artefact you already produce. In the middle, what the AI Act wants that your artefact does not deliver. On the right, the article that says so, on our sister site, in full.
| Domain | What DORA already gives you | What the AI Act adds on top | Read it |
|---|---|---|---|
| Risk management | ICT risk framework across the estate (Art. 5-16) | A risk system for the model itself: accuracy, robustness, bias and fundamental-rights risk, maintained across the whole lifecycle. Your ICT framework does not look at any of these. | Art. 9 ↗ |
| Data governance | Data classification and integrity controls | Governance of the training, validation and test sets: relevance, representativeness, and an examination for bias. There is no DORA equivalent at all. | Art. 10 ↗ |
| Documentation | ICT policies, Register of Information | Technical documentation to Annex IV, plus automatic logging over the system's lifetime. Closer to a product file than to a policy. | Art. 11-12 ↗ |
| Human oversight | RACI, management body accountability | Oversight built into the system by design, with a named, competent human who can actually interrupt or override an output. An org chart does not satisfy this. | Art. 14 ↗ |
| Incidents | Major ICT incident → competent financial authority, 4h / 72h / 1 month (Art. 19) | A serious incident involving a high-risk system also goes to the market surveillance authority. Different regulator, different trigger, different clock. One event, two filings. | Art. 73 ↗ |
| Third party | Due diligence, contractual clauses, audit rights (Art. 28-30) | You must verify the provider actually did the conformity assessment and affixed the CE marking, and know that modifying their model can make you the provider. | Art. 25-26 ↗ |
| Transparency | nothing comparable | Tell people they are dealing with an AI; mark synthetic content machine-readably. Applies whatever the risk tier, and it is the first deadline to land. | Art. 50 ↗ |
| Registration | Register of Information, filed with your supervisor | High-risk systems must additionally be registered in the EU database. A different register, a different authority, a different purpose. | Art. 49, 71 ↗ |
Read the table as a gap list, not a mapping exercise. Rows one, two, four and seven have no DORA counterpart at all: that is where the real work is.
This single question decides how heavy your obligations are, and most financial institutions answer it wrongly on their first pass. It does not turn on who you are. It turns on what you did to the model.
The default position for most banks. Use the system per its instructions, assign competent human oversight, monitor it, keep the logs, inform the people it decides about, and verify that your provider did their part.
The full compliance file lands on you: quality management system, conformity assessment before the system goes live, CE marking, registration in the EU database, post-market monitoring.
Put your name on it, modify it substantially, or repurpose it, and you become the provider. All of Article 16 follows. This is not a technicality; it is the most expensive mistake available here.
Fine-tuning a purchased credit-scoring model on your own loan book is a substantial modification. You bought a system and you procured a vendor, but under Article 25 you are now its provider, and you owe the conformity assessment, the CE marking and the EU database entry that you assumed the vendor had already handled. Teams discover this after the model is in production.
The Digital Omnibus on AI moved these dates. The Council gave its green light on 29 June 2026, deferring the high-risk obligations by over a year, but leaving the transparency duties exactly where they were. Plan against the new calendar, not the one in older guidance.
A deferral is not a reprieve. Conformity assessment on a high-risk system is a year of work, not a quarter, and the transparency deadline does not move.
Six questions. Prohibited, high-risk under Annex III, GPAI, transparency-only or minimal, plus whether you are the provider or the deployer, which is the part people get wrong. Free, no signup, instant.
Annex III is a list of named use cases, not a judgement about how important a system is to your business. Read against what these three sectors actually run, the list comes back surprisingly empty. Each page below classifies the real systems, one by one.
Fraud detection is excluded from Annex III by name. AML is not in it. KYC selfie-match is excluded. One system is high-risk, and it is probably not the one you were worried about.
AI Act for payment institutions →Algorithmic trading is not in Annex III. Neither is robo-advice. Your algos are already governed: by MiFID II and RTS 6, not by this Act. Map, do not rebuild.
AI Act for investment firms →Blockchain analytics, market surveillance, trading bots, KYC verification, none of it is high-risk. For a MiCA-authorised CASP the AI Act is a disclosure exercise, not a conformity programme.
AI Act for CASPs →This page maps the AI Act onto your existing DORA programme. For the text of each obligation, scope, wording, guidance: go straight to the article on our AI Act site.
Social scoring, emotion inference at work, untargeted face scraping. Already in force since February 2025.
Read Article 5The test that decides whether your system is high-risk at all. Start here before anything else.
Read Article 6Your DORA ICT risk framework does not cover accuracy, bias or fundamental-rights risk across the model lifecycle.
Read Article 9Training, validation and test sets: representativeness, bias examination. No DORA equivalent.
Read Article 10Oversight by design, with a real ability to override the model. Goes beyond a RACI matrix.
Read Article 14What you owe when you buy a high-risk model rather than build it: the default position for most banks.
Read Article 26A second reporting channel, to the market surveillance authority. It does not replace DORA Art. 19.
Read Article 73Go further: premium resources
59-page manual: all five pillars, six-phase roadmap, 34 worked examples.
Free self-paced course + a verifiable certificate you can add to LinkedIn. Start here.
Article 30 clause library, Register of Information build guide, exit playbooks, CTPP oversight.
Consulting delivers momentum. Resiplan keeps it running. Many clients combine both.
Expert-led engagements: gap analysis, implementation, TLPT preparation.
All five DORA pillars automated: register, incidents, vendor risk, dashboards, no more spreadsheets or a dedicated team.
Consulting to kick-off + Resiplan to sustain. Our most popular combo.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.