DORA has applied across the EU since 17 January 2025 (EIOPA), but 2026 is the year it actually starts biting for AI workloads. BaFin published guidance on 30 January 2026 folding LLMs into its existing ICT risk rules, and on 18 November 2025 the European Supervisory Authorities designated 19 companies, including AWS, Google Cloud, and Microsoft, as critical ICT third-party providers under direct EU oversight (EBA/ESMA/EIOPA). If your bank runs LLM workloads on a hyperscaler API, that dependency is now a documented, board-level line item, not background infrastructure.
This guide is for EU bank technology and risk teams deciding whether to keep AI workloads on hyperscaler AI APIs or move them to EU-based GPU rental or on-prem infrastructure. It covers what DORA actually requires for AI systems, why the concentration-risk math is pushing banks off hyperscaler APIs, and what to check in a GPU cloud contract before you sign. For the parallel EU regulatory picture on model governance and data residency (not financial-sector specific), see our EU AI Act compliance guide.
What DORA Actually Requires for AI Systems in 2026
DORA does not create a separate AI rulebook. It requires banks to run AI systems, including LLMs, through the same ICT risk management framework that already governs every other piece of technology touching a critical or important function: risk management, incident reporting, resilience testing, and third-party oversight.
The Four ICT Risk Pillars and Where AI Fits
DORA's binding ICT risk framework runs across four chapters (Kiteworks):
| Pillar | Articles | Where AI Fits |
|---|---|---|
| ICT risk management | Art. 5-16 | Governance, asset inventory, and risk appetite must cover LLM deployments the same way they cover core banking systems |
| Incident classification and reporting | Art. 17-23 | A model outage, hallucination-driven decision error, or third-party model update that breaks production counts as a reportable ICT incident if it meets severity thresholds |
| Digital operational resilience testing | Art. 24-27 | Includes threat-led penetration testing (TLPT) for significant entities, covered below |
| ICT third-party risk management | Art. 28-44 | Governs the contract, exit plan, and concentration-risk assessment for every AI vendor, including model APIs |
DORA also encourages voluntary threat-intelligence sharing between entities, a lighter fifth thread that sits alongside these four binding pillars rather than adding new obligations of its own.
BaFin's January 2026 Guidance: LLMs Go Into the Existing ICT Framework, Not a Separate One
BaFin published "Guidance on ICT Risks in the Use of Artificial Intelligence at Financial Entities" on 30 January 2026, aimed at CRR institutions and Solvency II insurers (BaFin). The core message is explicit: generative AI and LLMs are not a new regulatory category. They get embedded into the existing DORA-compliant ICT risk framework across the full AI lifecycle, data acquisition, model development, operation, and retirement (Jones Day).
BaFin states plainly that "the implementation and operation of AI systems can entail significant risks" and that "the security and resilience of an AI system must be guaranteed in every phase" (BaFin). For a bank technology team, the practical reading is this: if you already have a DORA-compliant ICT risk process for your core banking stack, your LLM deployment needs to plug into that same process, the same asset inventory, the same incident classification thresholds, the same third-party contract review, not a bolt-on AI governance track that runs in parallel.
TLPT and Testing Obligations for Generative AI Systems
Threat-led penetration testing is mandatory at least every three years for entities classified as significant, including G-SIIs among credit institutions, under the TIBER-EU framework (financialregulations.eu). A national competent authority can order more frequent testing after a major incident or an unremediated finding.
BaFin's guidance specifically flags LLMs and generative AI as harder to test than conventional ICT systems, citing their complex architectures and reliance on peripheral, frequently-updated third-party models (Jones Day). That difficulty compounds when the model itself sits behind a hyperscaler API you don't control the version or weights of. A red team probing a self-hosted, version-pinned model has a fixed target. A red team probing a hosted API that the vendor can silently update mid-engagement is testing a moving target, and documenting that gap is now part of your TLPT scoping conversation.
Why EU Banks Are Moving LLM Workloads Off Hyperscaler APIs
The concentration risk that DORA now forces banks to document didn't appear in 2026. It's been there for years. What changed is that it's no longer informal risk-committee knowledge, it's a supervised, penalty-bearing compliance line item with named vendors attached to it.
AWS, Google Cloud, and Microsoft Are Now Directly Supervised as Critical Third-Party Providers
On 18 November 2025, the ESAs published the first official list of 19 designated critical ICT third-party providers (CTPPs) under DORA Article 31(9), naming AWS, Google Cloud, and Microsoft among them (EBA/ESMA/EIOPA; FStech). CTPP status puts those three under direct joint oversight by the EBA, ESMA, and EIOPA, including annual risk analyses, on-site inspections, and mandatory cooperation (AWS Security Blog). AWS's own framing captures the trade-off well: "operational resilience is both a compliance requirement for DORA and a business necessity" (AWS Security Blog).
What CTPP designation does not do is quietly clear a bank's own paperwork. A designated provider being under Lead Overseer supervision doesn't reduce a financial entity's existing DORA obligations for contractual requirements and due diligence on that same vendor relationship (DLA Piper). If your bank's compliance team assumed "AWS is now regulated, so our AWS Bedrock contract is covered," that assumption is wrong. You still run your own Article 28-30 assessment on top of the EU-level oversight.
Concentration Risk Is a Documented, Board-Level Requirement Under Article 29
Article 29 requires financial entities to assess and document ICT concentration risk before entering new arrangements, and the underlying dependency is real: an ECB analysis of 2023 outsourcing registers found more than 30% of significant EU banks' total outsourcing budgets flow to just ten providers, most headquartered outside the EU (Mitratech). Add generative AI workloads on top of core infrastructure outsourcing, and a bank running its LLM stack on the same hyperscaler that already hosts its core banking platform is stacking concentration risk on concentration risk in a single vendor relationship.
The financial stakes for getting this wrong are real on both sides. Financial entities face fines up to 2% of total annual worldwide turnover for material non-compliance (Avenga). Designated CTPPs face separate periodic penalty payments of up to 1% of average daily worldwide turnover for continued non-compliance with Lead Overseer remediation orders, running for up to six months (DLA Piper). Neither number is trivial for a board risk committee to sign off on without documentation.
The Exit Strategy Gap in Hyperscaler AI API Contracts
Article 28 requires financial entities to maintain exit strategies for any ICT service supporting a critical or important function, covering data portability, contractual lock-in, transition timelines, and provider-insolvency contingencies. Contracts signed before 17 January 2025 had to be renegotiated to include these clauses, with no grace period (FluxForce).
Here's where hyperscaler AI APIs specifically create a gap that a generic cloud-infrastructure contract doesn't. Exiting an IaaS relationship means moving VMs and data. Exiting a managed LLM API relationship means untangling a model you never held the weights for, prompt engineering and fine-tuning artifacts tied to a proprietary API surface, and inference logs formatted around that vendor's schema. A model API vendor can also silently deprecate or replace the underlying model version behind the same endpoint name, which is a functional lock-in mechanism no exit clause fully neutralizes unless the bank controls the weights itself. This is a documented reason more compliance teams are pushing engineering toward self-hosted open-weight models on rented GPU capacity, where the exit path is: copy the weights, redeploy the container, done.
Choosing a DORA-Ready GPU Cloud: Data Residency, Exit Plans, and TLPT Readiness
No GPU cloud is "DORA compliant" in the way a vendor can be FedRAMP-authorized or SOC 2-attested. DORA obligates the bank, not the infrastructure provider, so the real question isn't "does this vendor have a DORA badge," it's "does this vendor's contract, data residency posture, and technical architecture make it possible for us to meet our own Article 28-30 obligations." That distinction matters, because a vendor implying otherwise is a red flag, not a selling point.
Data Residency and the Register of Information
Financial entities must maintain a Register of Information covering their ICT third-party arrangements, which national competent authorities consolidate and submit to the ESAs by 31 March each year (EBA). The 2026 submission reflects contractual arrangements in place as of 31 December 2025, which means every GPU vendor your bank uses for AI inference or training needs to already be documented with a specific facility location, not a vague "EU region" designation.
Choosing a GPU cloud with explicit node-level location visibility, rather than a black-box regional label, simplifies that register significantly: you can name the actual data center and its compliance certifications instead of trusting a provider's abstraction layer. For a broader map of EU-region GPU providers and how each handles data residency, our GPU cloud providers in Europe guide covers the provider landscape in more detail.
What Article 30 Requires in Your GPU Cloud Contract
Article 30 mandates specific clauses in any ICT third-party contract supporting a critical or important function: service descriptions, SLAs, the financial entity's own audit rights, the regulator's audit rights, data security standards, business continuity obligations, and termination rights (FluxForce). Before signing a GPU rental contract for a production AI workload, confirm in writing that each of these is present, and where in the contract it lives. A vendor that can't point to a specific clause for regulator audit rights is not ready for a DORA-scoped workload, regardless of how good its uptime numbers are.
Building an Exit Plan That Actually Holds Up
An exit plan that satisfies Article 28 needs to survive an actual test, not just exist on paper. For AI infrastructure specifically, that means:
- Own the weights. Self-hosted open-weight models (Llama, Qwen, Mistral, and similar) mean your exit plan is "redeploy the container elsewhere," not "renegotiate access to a proprietary endpoint."
- Standard tooling, no proprietary SDK lock-in. Docker images and SSH access port to a new provider in hours. A vendor-specific orchestration layer doesn't.
- Documented transition timelines. Test how long it actually takes to move a training or inference workload to a second provider, and put that number in the plan, not an estimate.
- A named alternative provider, not a hypothetical one. Provider-insolvency contingency planning under Article 28 expects a real fallback, not "we'd figure it out."
Confidential Computing for TLPT and Audit Readiness
For banks handling sensitive financial data during inference, TLPT scoping and audit documentation both benefit from a technical control that goes beyond contractual promises: confirming the cloud provider itself cannot see data in use. NVIDIA's confidential computing mode encrypts VRAM and provides remote attestation, meaning a red team (or a regulator) can verify that even privileged infrastructure access doesn't expose plaintext model inputs or outputs during inference. Our confidential GPU computing guide covers the deployment pattern on H100 and B200 hardware for exactly this kind of regulated audit trail.
DORA-Compliant GPU Cloud Checklist for 2026
Run through this before signing any GPU cloud contract for a workload that touches a critical or important banking function:
- Confirm the vendor can name the specific data center facility for every node, not just a region label, for your Register of Information entry
- Verify all seven Article 30 contract clauses are present in writing: service description, SLA, your audit rights, regulator audit rights, data security standards, business continuity, termination rights
- Test your exit plan's actual transition timeline before you need it, not after
- Confirm the deployment uses standard tooling (Docker, SSH, open model weights) rather than a proprietary SDK that recreates hyperscaler-style lock-in
- Document concentration risk if the same vendor, or its parent group, already hosts other critical functions for your bank
- Confirm confidential computing or equivalent technical controls are available if the workload will be in TLPT scope
- Re-run the assessment annually ahead of the 31 March Register of Information submission, not just at contract signing
Spheron pools GPU capacity from 5+ providers across EU data center partners, giving bank technology teams node-level location visibility instead of a black-box region label, full root access for custom audit logging, and no proprietary SDK lock-in on top of standard Docker and SSH tooling. None of that is a DORA certification, because no such certification exists, but it's the set of properties that makes a bank's own Article 28-30 documentation straightforward rather than a fight with a vendor's support team. For teams evaluating self-hosted deployment as the exit-ready alternative to a hyperscaler LLM API, current on-demand pricing looks like this:
| GPU | On-Demand (per GPU/hr) |
|---|---|
| H100 SXM5 | $2.54 |
| A100 80G SXM4 | $1.69 |
Pricing fluctuates based on GPU availability. The prices above are based on 17 Jul 2026 and may have changed. Check current GPU pricing → for live rates.
For the equivalent compliance picture under a different framework, see our SOC 2 compliant GPU cloud providers guide and, for US public-sector buyers facing the same "no vendor has a badge yet" gap, our FedRAMP GPU cloud buyer's guide. And if concentration risk on hyperscaler infrastructure is part of your board's concern, our AWS outages and neo cloud resilience piece covers the reliability side of that same dependency question with concrete incident data.
A DORA-ready AI stack starts with infrastructure you can document, audit, and exit on your own terms, not a hyperscaler API you're locked into. Spheron gives bank technology teams EU-region node selection, full root access, and standard tooling with no proprietary lock-in.
Frequently Asked Questions
No. Unlike FedRAMP or SOC 2, DORA does not issue a certification a vendor can hold. DORA imposes obligations directly on the bank: manage ICT risk, document third-party dependencies, hold audit rights, and maintain an exit plan. A GPU cloud can support those obligations (EU data residency, Article 30 contract clauses, audit cooperation) or make them harder to meet, but no provider can hand a bank a DORA badge.
Designation as a critical ICT third-party provider (CTPP) puts AWS, Google Cloud, and Microsoft under direct joint oversight by the EBA, ESMA, and EIOPA, but it does not remove a bank's own due-diligence, contracting, and concentration-risk obligations for that vendor relationship. A bank using a designated CTPP still has to run its own Article 28-30 assessment, contract review, and exit planning.
At least once every three years for entities classified as significant, including G-SIIs among credit institutions, following the TIBER-EU framework. A national competent authority can order more frequent testing after a major incident or unremediated finding. BaFin's January 2026 guidance flags generative AI and LLMs as harder to test than conventional ICT systems because of their complexity and the pace of third-party model updates.
No. BaFin's January 2026 guidance folds AI systems, including generative AI and LLMs, into the existing DORA-compliant ICT risk management framework rather than creating a parallel regime. The guidance covers the full AI lifecycle: data acquisition, model development, ongoing operation, and retirement.