DORA, the EU's Digital Operational Resilience Act, in force since 17 January 2025, does not regulate AI but treats AI systems as part of the ICT risk a financial institution must manage, bringing AI vendors and deployments under its broader ICT governance requirements. Any AI system a bank or insurer relies on, whether an internally built model or a third-party API, needs to be included in the institution's ICT risk management framework, covered by incident reporting obligations if it fails or is compromised, and factored into resilience testing programs, with the largest institutions subject to more rigorous threat-led penetration testing requirements. A particularly important provision for AI is DORA's ICT third-party risk framework, which requires institutions to maintain a register of critical ICT providers and allows EU supervisory authorities to designate the most systemically important providers, potentially including cloud and AI model providers, for direct oversight. This means a bank using a hosted LLM API needs to assess that provider under the same contractual and risk due diligence DORA requires for any critical technology vendor, including exit strategies and concentration risk. Self-hosting reduces this specific third-party dependency but does not remove the underlying obligation to manage the AI system's operational resilience. Nanobase AI helps financial institutions structure AI vendor and infrastructure decisions with DORA's third-party risk requirements in view.
DORA regulates the ICT footprint, and AI sits inside it
DORA, in force across the EU since 17 January 2025, does not contain AI-specific rules, but every AI system a bank or insurer runs, whether built internally or consumed through a vendor API, counts as ICT infrastructure subject to the regulation's risk management, incident reporting, testing, and third-party oversight requirements. The practical implication is that an AI project cannot be scoped or approved in isolation from the institution's DORA ICT risk register; it needs to be entered into that register and mapped against the same requirements as any other critical system. Institutions that treat AI governance and DORA compliance as separate workstreams typically end up duplicating documentation or missing a requirement that falls between the two teams' scope.
Mapping DORA's core pillars to AI-specific implications
| DORA requirement area | What it requires generally | AI-specific implication |
|---|---|---|
| ICT risk management framework | Documented risk assessment for critical systems | AI system's failure modes and data dependencies must be assessed and documented |
| Incident reporting | Report major ICT incidents within defined timeframes | An AI system malfunction or data breach must feed into the same incident reporting process |
| Digital operational resilience testing | Regular testing, threat-led penetration testing for larger firms | AI systems in scope for testing programs, especially if customer-facing or decision-making |
| ICT third-party risk | Register and oversight of critical providers | Third-party model or cloud API providers assessed and registered as critical ICT providers |
The third-party risk pillar is usually the most consequential one for AI specifically, since a bank consuming a hosted LLM API needs to run the same contractual due diligence, concentration risk assessment, and exit planning DORA requires for any other critical technology vendor.
What to put in a vendor contract for a hosted AI provider
- Explicit data processing and data residency terms covering where prompts, outputs, and any fine-tuning data are stored and processed.
- Incident notification obligations from the vendor to the institution, with a timeframe fast enough to meet the institution's own DORA reporting deadlines.
- Audit rights allowing the institution, or its regulator, to review the vendor's operational resilience practices.
- A documented exit strategy describing how the institution would migrate off the provider if the relationship ends or the provider is designated for direct oversight.
- Concentration risk disclosure if the same underlying model provider serves a large share of the institution's critical functions.
A contract missing the exit strategy clause is the single most common gap institutions discover only after DORA's third-party requirements are already being examined.
Self-hosting changes but does not remove the obligation
Running an AI model on-premise or in a private cloud tenancy removes the specific third-party contractual burden tied to a hosted API provider, since the institution controls the infrastructure directly, but it does not remove the underlying obligation to manage that system's operational resilience, document its risk profile, and include it in incident reporting and testing scope. The compliance work shifts from vendor oversight to internal operational documentation rather than disappearing.
Frequently asked questions
Does DORA apply to a bank's internal AI copilot, not just customer-facing systems?
Yes, DORA's scope is the ICT risk the institution carries, not customer-facing status specifically, so an internal system that a critical business function depends on falls within scope even without direct customer interaction.
What counts as a reportable incident for an AI system under DORA?
A major disruption, data breach, or integrity failure affecting a critical or important function counts, following the same severity thresholds DORA sets for any ICT incident; an AI system feeding a critical function is evaluated under those same thresholds.
Can a single cloud AI provider be designated for direct EU oversight?
Yes, DORA allows EU supervisory authorities to designate the most systemically important ICT third-party providers, potentially including large cloud and AI model providers, for direct oversight, which is a live consideration when concentrating critical functions on one provider.
How does DORA interact with the EU AI Act for the same AI system?
The two regimes address different concerns and both can apply simultaneously; DORA covers the system's operational resilience as ICT infrastructure, while the EU AI Act addresses the AI system's risk classification and specific obligations based on its use case.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, helps EU financial institutions structure AI deployment and vendor decisions with DORA's ICT risk, incident reporting, and third-party oversight requirements built in from the start. This pairs with the EU AI Act, GDPR, and KVKK compliance checklist and with guidance on starting an AI pilot without breaking compliance.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.