DORA and AI: What Financial Services Need to Know About Third-Party AI Risk

DORA Article 3(19) defines an ICT service as "digital and data services provided through ICT systems to one or more internal or external users." AI services — whether foundation model APIs, embedded AI features in SaaS products, or AI-specific tooling — fall unambiguously within this definition. There is no AI-specific carve-out.

The consequence is that every AI vendor a financial entity uses must be treated as an ICT third-party service provider (ICT TPP) for DORA purposes. This triggers three concrete obligations.

**First**, the vendor must be entered in the financial entity's Register of Information under Article 28(3), with all the metadata that RTS on the Register requires: legal identity, function supported, criticality assessment, service dependency mapping, sub-contracting chain, exit strategy, and continuity arrangements.

**Second**, the underlying contract must comply with Article 30's mandatory contractual provisions: service description, data processing locations, service level requirements, monitoring and audit rights, cooperation with competent authorities, incident notification, exit assistance, and — for critical or important functions — additional security and testing requirements.

**Third**, if the AI service supports a critical or important function (defined in Article 3(22) as one whose disruption would materially impair financial performance, continuity, or regulatory compliance), enhanced due diligence, threat-led penetration testing scope inclusion, and formal risk assessment before contracting are required.

The definition of "critical or important function" is where most financial entities have compressed their AI deployment. Customer-facing chatbots, credit decisioning models, transaction monitoring AI, and market-facing pricing algorithms are almost always in scope. Internal productivity tools (copilots, drafting assistants) are usually not, though the boundary is context-dependent and has been the subject of live supervisory debate throughout 2026.

DORA's most consequential third-party mechanism is the Critical ICT Third-Party Provider (CTPP) designation under Article 31. CTPPs are subject to direct oversight by the European Supervisory Authorities (EBA, EIOPA, and ESMA acting jointly through the Oversight Framework), including on-site inspections, remediation orders, and — for non-EU CTPPs — a requirement to establish a subsidiary in the Union within 12 months of designation.

The first CTPP designations were published on 13 February 2026. Nineteen providers were designated in the first tranche, including AWS, Microsoft, Google Cloud, IBM, Oracle, SAP, Salesforce, Broadcom (VMware), and — notably — OpenAI and Anthropic. This was the first regulatory recognition anywhere in the world that foundation model providers meet the systemic-importance threshold for direct supervision of a critical financial infrastructure category.

For financial entities, CTPP designation of their AI vendors is a mixed signal. On one hand, the designated provider is subject to direct oversight, which reduces certain categories of due diligence burden — the financial entity does not need to independently verify what the ESAs have already verified. On the other hand, CTPP designation confirms that the provider is systemically important to the financial sector, which increases concentration risk. DORA Article 29 explicitly requires financial entities to assess and mitigate concentration risk arising from their ICT third-party dependencies.

The 2026 practical response to the OpenAI and Anthropic CTPP designations has been the emergence of "multi-model" architectures at large financial institutions, with credit decisioning, fraud detection, and customer service functions provisioned across at least two of {OpenAI, Anthropic, Mistral, Google} to reduce single-provider dependency. This is a direct DORA-driven architectural pattern that would not have emerged from AI-quality considerations alone.

The AI Act does not replace DORA for financial entities — it overlays additional obligations that address different risk dimensions. The overlay operates in four specific areas.

**Article 26 deployer obligations.** Financial entities using any AI system in a professional capacity are AI Act deployers. This carries obligations DORA does not: ensuring human oversight of AI system output, monitoring for anomalies including drift, maintaining automatically generated logs for at least six months, and — for high-risk uses under Annex III — conducting a fundamental rights impact assessment. Credit scoring and life/health insurance underwriting are named in Annex III, so most retail-focused financial entities have direct high-risk deployer obligations from 2 December 2026.

**Article 50 transparency to customers.** When customers interact with AI systems — including chatbots that make regulated communications — they must be informed. This is more granular than DORA's operational disclosure requirements and reaches into product design in ways DORA does not.

**GPAI documentation pass-through.** Financial entities relying on GPAI-embedded SaaS products must obtain the Article 53 technical documentation for compliance evidence purposes. DORA's Article 28 register requires documentation of the ICT service; the AI Act requires additional documentation of the AI model within that service. In practice, financial entities are extending their DORA registers to include an "AI model" attribute alongside standard ICT service metadata.

**Article 26(5) fundamental rights impact assessment.** For high-risk deployments, a FRIA must be conducted before first use and updated when material changes occur. The EDPB and EBA published a joint template on 30 May 2026 that harmonises FRIA content with DORA risk assessment content, reducing but not eliminating duplication.

The net additional load from the AI Act overlay, above baseline DORA obligations, is estimated by the ECB's June 2026 SREP guidance at 15–25% of existing ICT third-party risk management effort for large banks, front-loaded into the second half of 2026.

Efficient compliance depends on identifying where the two regimes ask for the same evidence and combining the work. Four overlaps are meaningful.

**Vendor registers.** DORA's Article 28 Register of Information can accommodate AI Act model attributes without structural change. The EBA's revised RTS on the Register (in force from 1 April 2026) added optional fields for "AI system category," "GPAI model provider," and "Code of Practice signatory status." Financial entities using these fields satisfy both DORA registration and AI Act inventory obligations from a single source of truth.

**Incident reporting content.** DORA major incident reporting (Article 19) and AI Act serious incident reporting (Article 73) run on different timelines — DORA requires initial notification within 4 hours of classification, AI Act within 15 days of detection — but the content required for the reports overlaps substantially. Root cause, affected systems, containment measures, and impact assessment appear in both. Incident response playbooks that generate a single evidence base servable to both reporting streams reduce duplication.

**Audit rights.** DORA Article 30(3)(e) mandates audit rights for financial entities in ICT contracts. AI Act Article 26 gives deployers rights to demand documentation from providers. Contract clauses combining these into a single audit right — covering both DORA operational testing and AI Act documentation verification — are now standard in 2026 MSAs and reduce contract negotiation complexity.

**Concentration risk analysis.** DORA Article 29 concentration risk assessment and AI Act market monitoring both benefit from a unified view of which AI providers the entity depends on for critical functions. A single "critical AI provider map" satisfies both requirements and enables the multi-provider strategies that both regimes implicitly favour.

The efficient compliance posture combines these overlaps into a single evidence architecture rather than running parallel workstreams. Institutions that separated their AI Act and DORA programmes in Q1 2026 have been consistently re-merging them through Q2, and the ECB's June SREP guidance now explicitly recommends integrated programmes.

The single hardest DORA compliance problem for AI vendors is sub-contracting transparency, and the AI Act intensifies it rather than solving it.

DORA Article 29(2) requires financial entities to assess sub-contracting chains for ICT services supporting critical or important functions, with particular attention to sub-contractors located in third countries. The RTS on sub-contracting (published 24 July 2025, in force from 1 January 2026) requires the full sub-contracting chain to be documented in the Register and material changes to be notified 15 days in advance.

For AI vendors this is structurally difficult. A typical embedded-AI SaaS product involves: the SaaS vendor itself, one or more foundation model providers (often via an inference platform like Azure OpenAI or Amazon Bedrock), a cloud infrastructure provider hosting the model, a vector database provider for retrieval-augmented generation, and often a specialised fine-tuning or evaluation provider. Each layer is a sub-contractor, and each layer's own sub-contractors may be in scope depending on materiality assessment.

The AI Act adds the GPAI model as an additional data point that must be tracked through the chain. When a Layer 2 vendor swaps its embedded model — for example, moving from GPT-4o-mini to GPT-5.6-turbo — this is potentially a material change requiring both DORA sub-contracting notification and AI Act deployer notification. In practice, model swaps happen frequently and quietly, and enforcement of the notification obligation is uneven.

The practical response emerging in 2026 is contractual: financial entities are requiring named-provider clauses that lock the vendor into a specific foundation model provider for the contract term, with model version changes permitted but provider changes requiring formal amendment. This trades some vendor flexibility for chain stability, and is now standard in financial services AI procurement above roughly €500k annual contract value.