The EU AI Act, DORA and your AI: what a bank actually has to prove

The deadline moved. The obligations underneath it did not.

The EU AI Act (Regulation (EU) 2024/1689) applies in phases, not all at once. Its prohibited practices have been in force since 2 February 2025. Its rules for general-purpose AI, governance and penalties followed on 2 August 2025. The heavy tier, the obligations for high-risk systems, was due on 2 August 2026, until the Digital Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026) pushed the stand-alone high-risk deadline (Annex III) to 2 December 2027 at the latest, and the deadline for high-risk AI embedded in regulated products (Annex I) to 2 August 2028.

So the high-risk duties around, say, a credit-scoring model land in December 2027, not this year. That is real relief, but it is not a pause. Banned uses are banned today. And the evidence a high-risk system needs, the documentation, the logging, the oversight designed into the workflow, takes many months to stand up honestly, not a weekend before an audit. For scale, the penalties are not symbolic: up to 35 million euro or 7% of global turnover for a prohibited use, up to 15 million euro or 3% for a high-risk breach.

Which of a bank's AI is “high-risk”

The Act is risk-based: a small set of unacceptable uses is banned, a defined list of high-risk uses carries the heavy obligations, limited-risk uses owe transparency, and everything else is largely free. For a bank, the line that matters is in Annex III, point 5(b): AI systems used to evaluate the creditworthiness of natural persons or establish their credit score are high-risk, with one carve-out, AI used to detect financial fraud is not.

A practical test cuts through the classification faster than the legal text: does the system inform, recommend, or decide? The closer it sits to a decision about a person's access to credit or a service, the higher the risk. Credit scoring, loan-approval decision support and automated creditworthiness assessment fall squarely in scope. Fraud detection, back-office optimisation and a support chatbot do not carry the high-risk load, though the chatbot still owes transparency and, as we will see, all of them remain ICT you have to govern.

Your AI is ICT. DORA already covers it.

Here is what the December 2027 date hides. An AI model, its data pipeline and its inference API are ICT systems, and very often ICT services bought from a third party. That means DORA (Regulation (EU) 2022/2554), which has applied to financial entities since 17 January 2025, already governs them:

• Article 6 puts your AI inside a documented ICT risk-management framework that must be reviewed at least once a year, not a separate AI binder.
• Article 28 puts the model and API providers behind your AI into the register of information on ICT third-party arrangements, with concentration-risk analysis and exit strategies. A single foundation-model vendor sitting under three business lines is exactly the concentration DORA wants named.
• Incident reporting and resilience testing apply to AI-driven services like any other critical ICT service.

So the comfortable idea that AI governance can wait for 2027 has a hole in it: DORA is governing your AI now, and its supervisors are not waiting.

Two rulebooks, one control set

The most useful point in the current debate is also the simplest: do not run AI governance as a programme parallel to your resilience programme. The AI Act's high-risk duties, risk management, data governance, technical documentation, logging and traceability, human oversight, accuracy and robustness, post-market monitoring, map almost one-to-one onto controls DORA already asks you to operate. Build the machinery once, then tag each control for both regimes. One inventory, one risk classification, one evidence trail, two rulebooks satisfied.

From policy to evidence

Both texts judge you on what you can show, not on what you wrote. Put the obligations side by side and the AI programme has to be able to produce:

• An inventory of every AI system, with a named owner and its business purpose, because you cannot govern what you have not listed (AI Act risk-management duty; DORA Art. 6)
• A risk classification per system: prohibited, high, limited or minimal, with inherent and residual levels (AI Act risk tiers)
• Technical documentation and logging that make each decision traceable and reconstructable after the fact (AI Act Art. 11–12)
• Human oversight designed in for decisions about people, not bolted on afterwards (AI Act Art. 14)
• Accuracy, robustness and bias testing, with results retained as evidence (AI Act Art. 15)
• Post-market monitoring and an incident path aligned with your DORA reporting (AI Act Art. 72; DORA incident reporting)
• An assessment of every AI and model provider, tiered by criticality and kept current (DORA Art. 28)

None of that is a document you write once. It is a set of records you keep, which is why the December 2027 date is misleading: the deadline is the exam, the evidence is the coursework, and the coursework starts long before.

How SynapseRM answers it

That is the logic SynapseRM is built on. The trap in all of this, running AI governance as a programme parallel to the resilience one you already operate, is exactly what a single data model avoids: you do not stand up an AI silo next to the risk and third-party registers, you treat each AI system and each model provider as a first-class object in the registers you already run.

• The AI inventory is your asset inventory. Each AI system enters the asset referential with an owner, a business purpose and a CIAT criticality, so “list every AI system with clear ownership” is a view, not a project.
• Classification and residual risk, per system. Every system carries its risk tier and its inherent and residual levels, the same lifecycle the register applies to any other risk.
• Model providers are third parties. The TPRM module holds every AI and API vendor in the DORA register of information, tiered by criticality, with concentration and exit questions answered, matching Article 28 literally.
• Obligations mapped, once. Controls map to each system and are tagged for both the AI Act and DORA, so a single control produces evidence for both audits instead of two parallel binders.
• Human oversight and accepted risk, recorded. Where a residual risk is accepted, it lives in the Exception Registry with a justification, an owner and an expiry date, the accountability both regimes expect.
• Evidence on demand. An immutable history of who changed what and when, a read-only auditor role, and reports in one click. When a supervisor asks how a model decision was reached or which providers sit under a business line, the answer is an export, not a working week.

The high-risk date is 2027. The inventory that everything else hangs from is a job for today. Start there, and the deadline becomes a formality instead of a scramble.