DORA + AI: What EU Banks Need to Map Before the January 2027 ICT Third-Party Register Deadline

The Digital Operational Resilience Act (DORA) took effect for EU financial institutions on January 17, 2025. The regulation requires banks, investment firms, payment service providers, and a long list of related entities to maintain operational resilience against ICT disruption, including the disruption that comes from third-party dependencies. The consolidated ICT third-party register, which forces every covered firm to maintain a structured list of every ICT dependency it relies on, expanded its scope in 2026 and goes live in its full form in January 2027.

LLM providers are ICT third parties. At scale, they meet the criteria for critical ICT third-party services. A bank that runs production inference through OpenAI, Anthropic, and Bedrock simultaneously now has three critical dependencies to register, monitor, and document exit strategies for.

I want to walk through the parts of DORA that directly affect AI deployment at EU banks, the deadlines, the artifacts the register requires, and the architectural choices that make the artifacts producible.

The ICT third-party register

The register is the central operational artifact under DORA Article 28. Each covered firm maintains a structured list of every ICT third-party arrangement. For each entry: the supplier identification, the function performed, the criticality assessment, the data category processed, the location where data is processed, the contractual terms, and the resilience evidence.

The register has to be machine-readable in a format the EBA, ESMA, and EIOPA have published as the harmonized template. It has to be available to the supervisor on demand. It is updated when arrangements change.

An LLM provider used for production inference at meaningful volume meets the threshold for an entry in the register. The data category includes any classified information that flows through prompts. The function performed includes whatever the model decides on behalf of the bank.

The criticality assessment

DORA Article 30 requires a documented criticality assessment per ICT third-party arrangement. The assessment considers the function's importance to the firm's operations, the substitutability of the provider, the concentration risk, and the data sensitivity.

For AI inference, the criticality assessment runs as follows. If the bank uses the provider for a customer-facing decision (credit scoring, fraud detection, claim adjudication), the provider is at minimum important to operations. If the bank has not architected a fallback to an alternative provider, the substitutability score is low. If the bank uses the same provider for multiple high-value workflows, concentration risk is elevated.

A bank that runs production credit scoring through a single LLM provider with no failover has built a critical dependency without registering it. DORA holds the bank's senior management responsible for that gap.

The exit strategy requirement

Article 28(8) requires the firm to maintain a documented exit strategy for each critical ICT third-party arrangement. The strategy has to cover the situations that would trigger an exit (service degradation, regulatory action against the provider, contractual termination), the alternatives the firm would switch to, the operational steps to switch, and the timeline to complete the switch without losing service continuity.

For an LLM provider, the exit strategy has practical complexity. Switching from one provider to another requires real engineering work. Prompts engineered for one model often degrade on another. Fine-tuned variants stay tied to the provider that produced them. Vector embeddings produced by one provider are incompatible with another's index.

The architectural choice that simplifies the exit strategy is model-agnostic inference routing. If the bank's production stack routes through an inference layer that supports multiple providers behind a uniform interface, the exit strategy reduces to a routing change. If every workflow is hardcoded to a specific provider's API, the exit strategy is a full rewrite per workflow.

The concentration risk test

Article 29 requires firms to monitor concentration risk at the financial-sector level. If a meaningful share of EU banks routes inference through a single provider, the provider becomes a systemic dependency. The European Supervisory Authorities (ESAs) can designate a third party as critical ICT third-party service provider (CTPP) under the Oversight Framework, which subjects the provider to direct supervisory examination.

For LLM providers, this is a near-term reality. A small number of providers serve most of the European banking sector's inference. The supervisory designation conversation is already underway in industry working groups. Banks that depend on a single CTPP carry concentration risk that the register has to reflect.

The architectural hedge against concentration risk is the same as the exit strategy hedge: route through a model-agnostic layer that can switch providers without rewriting workflows.

What the supervisor will ask for during examination

Beyond the register itself, the supervisor will ask for evidence that the controls described in the register are actually enforced. For AI inference, the questions follow a pattern.

Which prompts did this AI system process for credit decisions during the audit window? Identity of the requesters? Data classifications in the prompts? Model responses returned? Policy version applied? Override decisions? Exception handling?

The answers come from a per-decision audit record at the inference layer. Application logs do not contain the prompt content with the level of detail the supervisor's question presumes. The model provider's logs are owned by the provider and subject to the provider's retention. The bank needs its own record, written before the response returns to the application, retained for the bank's regulatory window.

DORA does not specify the format of this evidence. It specifies the questions the firm has to be able to answer. The format is the firm's choice, but the format has to make the answers producible on demand.

The 2027 deadline

The full ICT third-party register, in its expanded form covering AI inference dependencies, goes live in January 2027. EU banks have approximately seven months from now to assemble the register, complete the criticality assessments, document the exit strategies, and stand up the evidence layer that makes the register operationally meaningful.

The work splits into three streams.

Inventory stream: enumerate every AI inference dependency in production, including dependencies introduced by SaaS vendors that embed LLM calls under the hood. The bank owns the dependency regardless of where the inference physically runs.

Contractual stream: revise vendor contracts to include DORA-compliant terms (audit rights, exit assistance, data location commitments, service level continuity). Most LLM provider contracts as currently written do not include all of these.

Evidence stream: stand up the per-decision audit record at the inference layer. The record is what makes the register operationally enforceable rather than a documentation exercise.

Compliance gap

EU banks that have an AI governance program at the policy level typically do not yet have the evidence layer DORA assumes. The procurement record exists. The vendor due diligence is complete. The application logs are retained. The piece missing is the per-decision record at the inference layer that ties the AI output back to the identity of the requester and the policy that was applied.

The architectural fix is an inline enforcement layer at the AI request boundary that produces the record per request, signs it for tamper-evidence, retains it for the regulatory window, and supports multiple providers behind a uniform interface so the exit strategy is routable.

DeepInspect

This is what DeepInspect produces for banks. DeepInspect sits inline between authenticated users and agents and any HTTP-based LLM endpoint. The per-decision audit record satisfies the supervisor's evidence questions. The model-agnostic property makes the exit strategy a routing change rather than a workflow rewrite. The identity-bound policy enforcement satisfies the substitutive controls the supervisor expects to see described in the register.

If you are at an EU bank preparing for the January 2027 register deadline and need the inference-layer evidence to make the register operationally credible, let's talk today.