Compliance · 22 June 2026

DORA and the EU AI Act: Why On-Prem AI Is No Longer Optional for Banks

Two regulations have quietly redrawn the map for how financial institutions are allowed to use artificial intelligence. The Digital Operational Resilience Act (DORA) has applied across the EU since January 2025. The EU AI Act entered into force in August 2024 and is still phasing in: its bans and general-purpose-AI rules already apply, and the high-risk obligations most relevant to banking now take effect in December 2027, after the EU’s 2026 “Digital Omnibus” pushed back the original 2026 deadline. Read together — and in banking, they have to be read together — they point to a conclusion that compliance teams are reaching one by one: for regulated financial work, AI that sends your data to someone else’s cloud is becoming very hard to defend.

This is not a story about banning AI. It is a story about where it runs, what it can prove, and who is accountable when a regulator asks. On-premise and sovereign AI answers all three. Here is why.

What DORA actually requires of your AI stack

DORA is an operational-resilience regulation, not an AI regulation — which is exactly why it catches AI. Any tool that processes critical or important functions falls inside its scope, and a generative-AI system that drafts risk reports, reconciles models, or reads incident logs is doing precisely that kind of work.

Four DORA obligations bear directly on how you deploy AI:

ICT risk management. Your AI tooling is ICT. It has to sit inside a documented risk-management framework, with controls you can describe and evidence. A black-box SaaS endpoint you cannot inspect is difficult to bring inside that framework.

ICT third-party risk. This is the sharp one. If your AI runs on an external provider — particularly a non-EU hyperscaler — that provider becomes a critical ICT third party. You inherit obligations around exit plans, subcontracting transparency, audit rights, and concentration risk. Every prompt that leaves your perimeter is a third-party dependency you now have to govern.

Incident reporting. DORA requires major ICT-related incidents to be reported within tight windows. If a component of your AI pipeline is opaque or offshore, reconstructing what happened — and evidencing it within 24 hours — becomes materially harder.

Resilience testing. You must be able to test the systems that support critical functions. You cannot meaningfully test what you cannot see or control.

The common thread is control. DORA rewards architectures where the institution can inspect, test, evidence, and account for every component. It penalises architectures where critical processing happens somewhere you can neither see nor fully govern.

What the EU AI Act adds on top

Where DORA asks “can you keep operating and prove it?”, the AI Act asks “is this AI system governable, documented, and lawful?” Several of its requirements land squarely on financial-services use cases — credit scoring and certain insurance-pricing uses are explicitly treated as high-risk, and most AI used in regulated decision-making attracts obligations regardless.

For high-risk systems the Act expects, among other things: risk management across the lifecycle, data governance, detailed technical documentation, record-keeping and logging, human oversight, and transparency. Even where a use case is not formally high-risk, the direction of travel is identical to DORA’s — you must be able to document what the system did and why.

A system you can document end-to-end, that logs its own reasoning, and that runs on infrastructure you control is straightforward to bring into compliance. A consumer-grade AI endpoint, where you cannot see the model, the logging, or the data flows, is not.

Why the two regulations push the same way

Stack the requirements and a single architecture keeps satisfying all of them:

Data residency and control — DORA’s third-party risk and the AI Act’s data-governance duties both favour processing that stays inside your perimeter.
Auditability — DORA wants evidence-grade incident and risk reporting; the AI Act wants technical documentation and logging. Both want a system whose every output traces back to a source.
Accountability — both regulations make the institution, not the vendor, answerable. You cannot outsource the liability, so you want to minimise what you outsource the control of.

The cheapest path to satisfying DORA, the AI Act, GDPR and NIS2 at once is not four separate compliance projects bolted onto a public AI tool. It is choosing AI that is sovereign by architecture in the first place.

The “EU servers” trap

The most common objection at this point is: “Our vendor offers EU hosting, so the data stays in Europe.” That is not the protection it appears to be.

A US-headquartered provider remains subject to US law — including the CLOUD Act — regardless of where the servers physically sit. Data residency in Frankfurt does not by itself defeat a lawful US access request to the parent company. For a bank reasoning about DORA third-party risk and the AI Act’s governance expectations, “EU region” on a hyperscaler is a weaker control than it sounds. Genuine sovereignty means the data is processed inside infrastructure you control, under EU jurisdiction, with no normal-operation path out. That is a higher bar than a hosting region — and it is the bar regulators are moving toward.

What on-premise, sovereign AI looks like in practice

This is the model Diana is built on. AI agents run on your own infrastructure or a sovereign EU cloud. Client financials are processed where they live: no external call in normal use, no training on your data, no egress. The output is evidence-grade — every figure and statement in a DORA ICT risk report links back to the source document and page, so a regulator’s request is answered, not improvised.

Concretely, that means a compliance team can hand the system the work it would otherwise do by hand — assemble the ICT risk register, evidence the incident log within the reporting window, draft an underwriting summary from the filing — and get back a finished, sourced document, produced entirely inside the institution’s walls. The architecture is the compliance argument: because nothing leaves, the third-party-risk, residency, and auditability questions largely answer themselves.

The takeaway for compliance and IT leaders

DORA and the EU AI Act do not forbid AI in banking. They raise the standard for how it is deployed — toward control, evidence, and accountability that public AI services struggle to meet. On-premise, sovereign AI is not the cautious option any more; for regulated financial work, it is becoming the defensible default. The institutions moving early are the ones treating their AI architecture as a compliance asset rather than a compliance problem.

Frequently asked questions

Does DORA apply to AI tools?

Yes. DORA governs ICT systems supporting critical or important functions. Generative-AI tools that produce risk reports, reconcile models, or process regulated data fall within its ICT risk-management and third-party-risk requirements.

Is a public AI tool with EU hosting enough for DORA and the AI Act?

Usually not. A non-EU provider remains subject to its home jurisdiction (e.g. the US CLOUD Act) even with EU-region servers, and you still inherit third-party-risk obligations. Processing inside your own perimeter is a stronger, simpler control.

Does the EU AI Act treat banking AI as high-risk?

Several financial use cases — such as credit scoring and certain insurance-pricing uses — are treated as high-risk, attracting documentation, logging, human-oversight and risk-management duties. Even non-high-risk uses face transparency and governance expectations.

How does on-premise AI make compliance easier?

When AI runs on infrastructure you control, data residency, third-party risk, auditability and accountability are addressed by the architecture itself — rather than by bolting controls onto an external service you cannot inspect.

Can the output be evidenced for a regulator?

With a system like Diana, yes — every figure and statement links to its source document and page, so reports are audit-ready against DORA, MiFID II and the AI Act.

Diana is the sovereign AI workspace for regulated European teams — specialist agents produce finished, cited documents inside your own perimeter.

Request a deployment →See the architecture