DORA and AI Inference: What EU Financial Services Need to Know
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) became fully applicable on January 17, 2025. It applies to banks, insurance companies, investment firms, payment processors, crypto-asset service providers, and their critical ICT service providers. If your organization uses AI APIs for any customer-facing function, DORA directly affects how you choose and manage those providers.
This is not a future concern. DORA is active law, and supervisory authorities are already conducting assessments.
What DORA requires for AI service dependencies
DORA introduces five pillars of operational resilience. Three of them directly affect AI inference providers.
ICT risk management (Articles 5-16)
Every financial entity must identify, classify, and manage ICT risks. For AI inference, this means:
- Document all AI API dependencies. Every model, every endpoint, every provider. If your fraud detection system calls an inference API, that API is an ICT service dependency.
- Assess concentration risk. Over-reliance on a single AI provider is a risk that must be documented and mitigated. If your only inference provider goes down or changes terms, what happens?
- Maintain business continuity plans. What is your fallback if your AI provider is unavailable for 4 hours? 24 hours? A week?
Third-party risk management (Articles 28-44)
This is where DORA gets specific. For every ICT third-party service provider, you need:
- Due diligence before engagement. Assess the provider's security posture, data handling practices, jurisdiction, and subprocessor chain.
- Contractual requirements. Your agreement must include audit rights, data location guarantees, incident notification timelines, and subprocessor disclosure. Standard US provider terms rarely include these.
- Exit strategies. You must have a documented plan for migrating away from any ICT provider within a reasonable timeframe. The ECB Guide on Cloud Outsourcing (published July 15, 2025) sets a 12-month maximum exit timeline.
Incident reporting (Articles 17-23)
Major ICT incidents must be reported to your supervisory authority within defined timeframes. If your AI provider has a data breach that affects your customers, you need to know about it fast enough to meet these obligations.
Why US AI providers create DORA compliance problems
In November 2025, the EU designated AWS, Microsoft Azure, and Google Cloud as critical ICT service providers under DORA. These designations require the providers to establish EU subsidiaries and submit to direct EU supervisory oversight. This is unprecedented: the EU is asserting jurisdiction over US tech companies because of their systemic importance to EU financial services.
But designation does not solve the underlying problems for AI inference:
Jurisdiction conflict remains unresolved. The US CLOUD Act still allows US authorities to compel data disclosure from any US company, regardless of EU subsidiary structure. The Schrems II ruling (July 2020) invalidated the EU-US Privacy Shield because of exactly this conflict. The current EU-US Data Privacy Framework, upheld by the EU General Court in September 2025, relies on an executive order that critics argue cannot override FISA Section 702 surveillance authority. This framework could be invalidated in a future "Schrems III" challenge.
Subprocessor opacity is structural. When you send a prompt to a US AI provider, your data may pass through monitoring, logging, abuse detection, and content filtering systems that are not disclosed in the standard terms. EDPB Opinion 22/2024 requires controllers to have real-time visibility into every processor and subprocessor. Try requesting a complete subprocessor list from OpenAI that includes their internal monitoring infrastructure.
Audit rights are effectively absent. DORA Article 28 requires contractual audit rights. Standard US AI provider terms do not grant on-site audit rights, and most do not even offer SOC 2 reports that cover AI-specific data handling.
Concentration risk is systemic. If you use a single US AI provider for multiple functions (chat, embeddings, classification, code generation), you have a single point of failure in a single jurisdiction. DORA specifically requires managing this.
What DORA-compliant AI inference looks like
Based on the regulatory requirements, a DORA-compliant AI inference setup needs:
1. EU jurisdiction throughout the data path. The inference provider, its data centers, and its subprocessors should all be EU-incorporated entities. This eliminates CLOUD Act exposure and Schrems II transfer risk.
2. Multi-provider architecture. Concentration risk requires that you are not dependent on any single provider. Automatic failover across multiple providers is the practical solution.
3. Zero or minimal data retention. Every byte of data your provider stores is data at risk in a breach. Zero Data Retention (where prompts and completions are not stored after processing) minimizes the impact of any security incident.
4. Contractual transparency. Published subprocessor lists, available DPA, defined incident notification process, audit rights.
5. Documented exit capability. A realistic plan for migrating to an alternative provider within 12 months.
How ozeye addresses each DORA requirement
| DORA Requirement | How ozeye addresses it |
|---|---|
| ICT dependency documentation | Published API documentation, subprocessor list, and provider details |
| Concentration risk | Automatic multi-provider routing across Mistral, Scaleway, and OVHcloud with failover |
| Business continuity | If one provider fails, requests automatically route to alternatives |
| Third-party due diligence | All providers EU-incorporated, ZDR enabled, DPA available |
| Contractual audit rights | Transparent terms, defined breach notification process |
| Exit strategy | OpenAI-compatible API; migration is changing a base URL |
| Incident reporting support | Audit trail with provider, model, latency, and cost metadata (never content) per request |
| Data minimization | Zero Data Retention across all providers |
The multi-provider routing is not just a technical feature. It is a direct response to DORA's concentration risk requirements. When your inference automatically fails over from Mistral to Scaleway to OVHcloud, you have eliminated the single-provider dependency that DORA Article 29 flags as a risk factor.
Practical steps for compliance
If you are in EU financial services and using AI APIs today, here is what to do:
1. Inventory your AI dependencies. List every AI API endpoint, model, and provider your organization uses. Include internal tools, not just customer-facing systems. If a developer is using GitHub Copilot with customer code, that counts.
2. Classify by DORA criticality. Any AI function that touches customer data, influences financial decisions, or supports a critical business process is an ICT service under DORA. Credit scoring, fraud detection, KYC document processing, claims assessment, customer support chatbots: all in scope.
3. Evaluate provider compliance. For each provider, document: incorporation jurisdiction, data center locations, subprocessor list, DPA availability, data retention policy, audit rights, and exit feasibility.
4. Migrate high-risk workloads first. Start with the AI functions that process the most sensitive data or support the most critical decisions. Moving from a US provider to an EU-native alternative like ozeye is a base URL change, not a rewrite.
5. Document everything. DORA compliance is not just about doing the right thing. It is about proving you did the right thing. Maintain records of provider assessments, risk evaluations, and the rationale for your choices.
The timeline is now
DORA has been enforceable since January 2025. The supervisory authorities are not waiting. The ECB's Guide on Cloud Outsourcing added concrete timelines in July 2025. The critical ICT provider designations in November 2025 signaled that EU regulators are serious about oversight.
Every month you operate AI workloads on non-compliant infrastructure, the compliance gap widens. The migration itself is straightforward. The regulatory exposure of not migrating is not.