Does DORA apply to non-EU banks operating in the EU?

DORA applies to financial entities providing services in the EU. Non-EU banks with EU operations are in scope for the EU operations.

Is AI inference an ICT service under DORA?

Yes. The Joint ESAs guidance treats AI inference, including LLM API calls, as ICT services. The third-party arrangements include them in the Register of Information.

What is the difference between DORA and the EU AI Act?

DORA covers ICT risk for financial entities. The AI Act covers AI risk across all sectors with horizontal obligations. Financial entities subject to both face stacking obligations. The audit-trail and register obligations have substantial overlap.

How do exit-strategy tests work in practice?

The financial entity has to demonstrate the capability to migrate the function away from the provider within a defined time horizon. The test typically involves running production traffic against the alternative provider for a defined period to evidence the cutover works. A gateway makes the test operational because the cutover is a routing change.

What is a critical or important function?

DORA defines "critical or important function" in Article 3(22) as a function whose disruption would materially impair the entity's financial performance, soundness, or continuity of services. AI in fraud detection, KYC processing, trading-decision support, and core customer-service workflows typically qualifies.

DORA and AI: what EU financial entities have to map by January 2027

The EU Digital Operational Resilience Act (Regulation 2022/2554) took effect January 17, 2025. The Act regulates information and communication technology (ICT) risk at financial entities operating in the EU: credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, central counterparties, and a long list of others. DORA does not single out AI in its text. AI walks straight into the scope anyway because LLM vendors are ICT third-party service providers and AI inference is an ICT service.

By January 2027, the practical AI-related obligations are clear: a Register of Information covering every ICT third-party arrangement (including AI vendors), exit-strategy planning for material providers, concentration-risk management when multiple critical functions depend on the same vendor, and an audit trail that holds up under supervisory review. The European Supervisory Authorities (ESMA, EBA, EIOPA) have been issuing implementing technical standards that make the obligations specific.

I want to walk through what DORA expects from an AI program, where the gap is in current financial-services AI deployments, and the architecture that produces the artifacts the supervisor will ask for.

How DORA frames ICT third parties

DORA's third-party regime sits in Chapter V. Three obligations matter for AI.

The Register of Information. Article 28 requires every financial entity to maintain a register of all ICT third-party arrangements. The register is structured around the function the provider supports. LLM vendors providing inference for customer-service automation, fraud detection, document processing, or trading-decision support are ICT third parties under this definition. The register is reported to the competent authority annually.

Exit strategy obligation. Article 28(8) requires financial entities to have a documented exit strategy for arrangements supporting critical or important functions. The strategy has to be testable. Cutting over from OpenAI to Anthropic, or from one Bedrock model family to another, has to be planned, documented, and exercisable.

Concentration risk. Article 29 obliges financial entities to manage risk from over-reliance on individual ICT third parties. If 80% of the entity's AI inference runs on one provider, the concentration is a risk the entity has to evidence it managed. The supervisor expects diversification plans.

Audit trail. Article 9 obliges resilience of ICT systems, which includes the operational records that let the entity reconstruct what happened during an incident or during routine supervisory review. For AI, that means per-decision audit records of AI-influenced actions.

The gap in a typical financial-services AI deployment

A representative EU bank has AI touching five surfaces:

Customer-service chatbot calling an LLM through a SaaS vendor's API.
Fraud detection scoring transactions with a model hosted on AWS Bedrock.
KYC document processing using a vendor's OCR-plus-LLM pipeline.
Trading-desk research assistant calling OpenAI through Azure.
Internal copilot for employees, hosted by Microsoft.

For each, DORA's third-party register requires entries: the service description, the data flowing through it, the criticality classification, the exit plan. Most banks have started this work but few have completed it for AI specifically because the AI usage is distributed across business units and the ICT central register has historically focused on infrastructure providers.

The per-decision audit record is the second gap. The bank's loan origination system records "AI tool returned a flag at 14:32." The supervisor will ask which model, which version, which prompt, which response, which natural person reviewed the result, what policy version governed the decision. The application's log does not contain those fields because the application was not the resolver of those fields.

The third gap is the exit-strategy test. The bank cannot exercise an exit from OpenAI to Anthropic on the customer-service chatbot if the application logic is wedded to OpenAI's API shape. The exit becomes a multi-month migration project, not a tested capability.

The architectural shape DORA implies for AI

Three architectural pieces line up with the DORA obligations.

A central control point for AI traffic. Every AI request from the bank to any model provider flows through a gateway. The gateway is the place the register evidence comes from: which model was called, by which application, on whose behalf, with what data classification. The register stays accurate because the source of truth is the gateway's traffic, not a manually maintained spreadsheet.

Provider abstraction at the request layer. Applications point their AI clients at the gateway URL. The gateway routes to OpenAI, Anthropic, Bedrock, Azure, or any other provider. Switching providers is a routing change at the gateway, not a code change at every application. The exit strategy becomes a tested capability rather than a paper plan.

Per-decision audit log. The gateway writes a record for every AI request with the principal, model, endpoint, redacted prompt, response treatment, policy version, decision outcome, and timestamp. The log is append-only and signed. Retention follows the longest applicable obligation, which for EU banks runs years.

Concentration risk and the routing layer

DORA's concentration-risk obligation maps directly to gateway routing. The gateway can route a percentage of traffic across providers based on policy, evidence the diversification, and demonstrate the routing actually works. The supervisor's review can examine the routing policy and the realized traffic split as two artifacts of the same control.

Without the gateway, concentration-risk management is a procurement exercise: the entity has contracts with multiple providers but the live traffic still runs on one. The gateway closes the gap between procurement and runtime.

The Critical ICT Third-Party regime

DORA's Chapter V, Section II creates the Critical ICT Third-Party Provider (CTPP) regime. The European Supervisory Authorities can designate a provider as critical based on the share of the EU financial sector that depends on it. Designated providers come under direct supervision by a Lead Overseer.

For AI, the candidates for CTPP designation are obvious: the largest model providers and the largest cloud providers running the inference. Financial entities still carry their own obligations regardless of the provider's designation. The CTPP regime adds a supervisory channel; it does not displace the entity's audit-trail obligation.

DORA and the EU AI Act intersection

For a financial entity also subject to the EU AI Act, the obligations stack. AI Act Article 26 places deployer obligations on the entity. DORA Articles 9 and 28 add ICT resilience and third-party obligations. The audit artifacts overlap substantially: the per-decision record satisfies both Article 12 logging and DORA Article 9 resilience.

The architectural pattern that satisfies both at the same time is the policy gateway with the audit log at the request boundary. One control plane, two regulatory regimes.

Penalties and enforcement

DORA penalties are set by member states. Several member states have published framework levels reaching €5,000,000 for ICT-third-party obligations and €1,000,000 per day for ongoing non-compliance. Supervisors also have intervention powers under Article 50 to require risk mitigation plans, restrict activities, or impose ad-hoc audits.

The financial exposure scales with the entity's size and the materiality of the function the AI supports. For a bank running fraud detection on tens of millions of transactions per day, the supervisor's intervention authority is the immediate concern, not the headline penalty.

DeepInspect

DeepInspect is the policy gateway in the AI request path. The deployment pattern for an EU financial entity is a proxy or sidecar that terminates AI calls regardless of provider. Identity resolves at the gateway. Policy evaluates at the gateway. The per-decision audit log writes to an append-only signed store. Routing across providers is configurable at the gateway, which makes exit-strategy testing operational rather than theoretical.

For an entity working through the January 2027 register completion plus the broader DORA obligations, DeepInspect produces the register evidence, the exit-strategy capability, the concentration-risk control point, and the audit trail from a single architecture.

If you are a financial entity working through DORA's AI scope, let's talk today about mapping the architecture.