What DORA's register of ICT third-party arrangements requires for AI deployments — how to classify entries, common mistakes, what regulators ask, and what institutions should weigh.
DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — requires regulated European financial services firms to maintain a register of all contractual arrangements with ICT third-party service providers. Article 28 sets the obligation. Commission Implementing Regulation (EU) 2024/2956 sets the data fields. The register is one of the first documents a competent authority asks for when it reviews an institution's ICT risk management. It frames the rest of the regulatory conversation.
When AI enters the ICT stack, the register has to be updated. Public guidance on how to do that is thin. This article covers what DORA requires, how AI deployments map onto the register, what "critical or important function" means in practice, what regulators ask when reviewing AI entries, and the most common mistakes.
Article 28(3) requires a continuously maintained register, made available to the competent authority on request. Commission Implementing Regulation (EU) 2024/2956 sets out the data fields — provider, contractual terms, location of data processing, sub-processors, classification flags. Each ICT service is a separate entry.
The register distinguishes between ICT services supporting "critical or important functions" of the institution and other ICT services. This classification — the institution's own assessment under its broader risk-management framework and the EBA Guidelines on Outsourcing where they continue to apply — drives the obligations under Article 30 (key contractual clauses, exit strategies, audit rights, sub-processor consent). Under-classification risks a regulator finding; over-classification inflates contractual and oversight cost.
AI deployments take several shapes, each with different register treatment:
Hosted AI API providers (OpenAI, Anthropic, Google, Cohere, Mistral's hosted endpoints, equivalents). The provider is an ICT third party; a register entry is required regardless of volume. Pilot deployments are not exempt — the moment production-equivalent data leaves the perimeter, the obligation applies.
Enterprise-tier API arrangements (Azure OpenAI in-tenant, Bedrock private, Anthropic enterprise tier). Still ICT third-party arrangements, but the exposure profile is materially stronger than the public tier. The register entry should document the distinction.
Self-hosted open-weight models (Llama, Mistral, DeepSeek, Qwen running on the institution's own infrastructure). This is where institutions most commonly get the register wrong. The model provider — Meta, Mistral AI, DeepSeek, Alibaba — is typically not an ICT third party in DORA's sense; the institution downloaded the weights and operates the model itself. The register entry is for the infrastructure provider, not the model provider.
Vendor-built AI applications running on third-party infrastructure. This is a two-level arrangement — the partner is the primary ICT third party, the underlying hyperscaler is a sub-processor. Both belong in the register and the relationship must be documented.
The classification is older than DORA — it comes out of the EBA Guidelines on Outsourcing and the institution's own risk framework. When AI is the technology under classification, three patterns emerge.
AI in customer-facing regulated outcomes is almost always critical. Complaints handling, credit decisioning (EU AI Act Annex III high-risk), AML alert triage, fraud detection in customer journeys, KYC and onboarding. The institution's regulatory standing depends on the function operating correctly; the AI supporting it inherits that criticality.
AI in financial-crime detection is treated as critical by most national regulators. AML, sanctions screening, fraud — even where AI is a triage layer behind human review — falls within the perimeter where regulators expect documented oversight.
AI in internal productivity is usually not critical. Research summarisation, internal memos, non-customer-facing analytics. The arrangement is still registered as an ICT third party, but contractual and oversight obligations are lighter.
The classification has three consequences: the depth of contractual clauses under Article 30, the granularity of the register fields, and the level of regulator scrutiny the entry will receive. The institution that documents the classification rationale alongside the register entry makes the regulator's review easier and reduces the risk of a finding that the classification is unsupported.
When a competent authority — BaFin, FINMA, the FCA where it applies, the national authorities across the EU — reviews the DORA register, four questions come up consistently on AI entries. As covered in the regulator-review piece, the register frames everything that follows.
The institution that prepares for these questions before they are asked spends less time in the review and produces fewer findings.
Four mistakes come up repeatedly across the institutions we work with.
Treating open-weight model providers as ICT third parties. Meta, Mistral AI, DeepSeek, Alibaba are not typically providing an ongoing ICT service when an institution downloads their weights and runs them locally. The correct register entry is for the infrastructure on which the model runs, not the model provider. Where the institution has a separate commercial agreement with the model provider (some open-weight commercial licences include this), that agreement can be registered — but the weights themselves are not the ICT service.
Missing the sub-processor chain. When the AI partner runs on a hyperscaler, omitting the hyperscaler from the register is a common error. The contractual perimeter is with the partner, but the ICT third-party risk perimeter extends to the sub-processor. DORA expects both.
Failing to register pilots. Pilots that involve real data flows — even at low volume — are within DORA's perimeter. Treating them as "out of scope until production" creates an unregistered arrangement when the pilot scales. Register from the start; classify as non-critical at pilot scale and reclassify if scope expands.
Not updating when deployment scope expands. An AI deployment registered as non-critical may scale into a critical function over six to twelve months — the same AI now handling regulated customer-facing decisions. Institutions where the AI deployment is owned by IT but the register is owned by ICT risk see the operational change without the register update.
Four factors should drive the decision.
Use-case scope, not technology category. The same model can support a critical function in one deployment and a non-critical function in another. An LLM used in AML triage is critical; the same LLM summarising weekly research is not. Classification follows the use case.
Data flows and PII content. Where customer, transactional, or other regulated content leaves the institution's perimeter — even briefly — the arrangement is treated more conservatively. The register entry should document where data is processed, retention, and which sub-processors see it.
Failure-mode impact. What breaks if the AI is unavailable for an hour, a day, or a week? An AI in AML triage produces a manageable queue; an AI in real-time fraud detection is a different category of operational impact. The risk-classification fields should reflect this honestly.
Exit feasibility within the regulatory timeframe. Can the institution stop using this provider, within the timeframe the regulator expects, without operational discontinuity? Where exit is tested rather than theoretical, the entry's risk posture is stronger.
DORA's register is one of the first documents regulators read when reviewing AI in a regulated financial institution. Each AI deployment maps onto the register differently — hosted API, enterprise-tier, self-hosted open-weight, vendor-built — and the classification under "critical or important function" depends on the use case rather than the technology category.
The most common mistakes are operational rather than technical, caused by gaps between the team owning the AI deployment and the team owning the register. Regulators across BaFin, FINMA, the FCA, and the EU national authorities converge on a consistent set of expectations: currency, completeness, exit feasibility, and sub-processor chain visibility.
The register does not determine whether an AI deployment is regulatorily acceptable. It frames the conversation. An institution with a current, accurate, well-classified register defends its AI position from a stronger documentary baseline than one retrofitting the register during a review.
If your institution is updating its DORA register to reflect AI deployments and wants to pressure-test the classification, the sub-processor chain, and the exit posture before the regulator does, we can help you work through it.
Related reading:
Stop renting generic models. Start building specialized AI that runs on your infrastructure, knows your business, and stays under your control.