EU AI Act + DORA ICT Third-Party Risk: AI Model Governance for Dual-Regulated Firms

Post #1578 in the sota.io EU Cyber Compliance Series

If you run a FinTech or InsurTech platform and you're buying AI capabilities from a third-party vendor — a credit-scoring model, a fraud detection engine, an underwriting algorithm — you face a compliance problem that neither regulation alone was designed for. DORA treats your AI vendor as an ICT third-party service provider and requires specific contractual, concentration-risk, and oversight controls. The EU AI Act simultaneously classifies many of those same AI capabilities as high-risk systems and assigns you formal importer or deployer obligations. As of 2 August 2026, both frameworks are enforceable, and the obligations overlap in ways that require a unified governance approach rather than two separate compliance tracks.

This is the second post in the EU AI Act + DORA Intersection series. Part 1 mapped the broad dual-compliance landscape. This post focuses specifically on the ICT third-party risk dimension: how DORA Art.28–31 applies when your third-party is an AI model vendor, and what that means for your Art.25/26 obligations under the EU AI Act.

Understanding the Dual-Regulated Third-Party Problem

The core tension is that DORA and the EU AI Act approach third-party AI vendors from opposite angles.

DORA's perspective is operational resilience. It asks: does your dependency on this ICT vendor threaten your firm's ability to function? The focus is on concentration risk, contractual protection, and the vendor's own resilience posture. DORA does not care whether the vendor's product is an AI system, a database, or a message queue. What matters is the criticality of the function it supports.

The EU AI Act's perspective is risk to people. It asks: does this AI system make or influence decisions that affect individuals' rights, access to services, or safety? The focus is on whether the system is high-risk under Annex III, and if so, who bears responsibility for its conformity. Under Art.16, the provider (typically the AI vendor) carries the primary obligations. But under Art.25, the importer who places the system on the EU market also carries formal obligations — and under Art.26, the deployer who puts the system into operation does too.

When you license a credit-scoring model from a US AI vendor and deploy it to assess EU borrowers, you are simultaneously:

• An importer under EU AI Act Art.25 (placing the system on the EU market)
• A deployer under EU AI Act Art.26 (operating the system)
• A financial entity under DORA with ICT third-party risk obligations toward the vendor (Art.28-31)

All three roles activate simultaneously, and the controls they require significantly overlap.

DORA ICT Third-Party Risk: What Art.28–31 Requires

DORA's ICT third-party risk framework applies to any financial entity regulated under its scope — banks, investment firms, insurance companies, payment institutions, crypto-asset service providers under MiCA, and others. For these entities, reliance on any external provider for ICT services triggers the obligations in Chapter V of DORA.

Art.28: General Principles

Art.28 establishes the baseline governance requirements. Financial entities must:

• Maintain a policy on ICT third-party risk as part of their overall ICT risk management framework
• Identify all ICT third-party dependencies and classify them by criticality
• Ensure that arrangements with ICT third-party service providers are subject to ongoing monitoring
• Not use third-party providers in ways that increase their operational risk beyond acceptable limits

For AI model vendors, this means the AI vendor relationship cannot be treated as a simple software procurement. It must be managed as a structured ICT dependency with documented risk assessment, periodic review, and escalation procedures.

The practical implication: if you're buying an AI credit-scoring model as a SaaS API call, your ICT risk team needs to assess what happens if that API becomes unavailable, is retrained without notice, or produces systematically biased outputs. All three scenarios represent ICT operational risk under DORA's framework.

Art.29: ICT Concentration Risk

Art.29 requires financial entities to assess ICT concentration risk — the risk that too many critical functions depend on a single provider or a small number of providers. For AI vendors, this creates a specific problem.

The AI model market has significant concentration. A small number of providers — major cloud platforms with AI services, specialised AI model companies, and foundational model providers — supply capabilities to a large share of the financial sector. If your credit-scoring, fraud detection, and customer communication systems all rely on models from the same underlying provider (directly or via integrations), your concentration risk profile is substantial.

DORA does not set a hard numerical limit on concentration, but it requires you to assess whether concentration is acceptable and document that assessment. The European Supervisory Authorities have signalled that high concentration in AI model sourcing will attract scrutiny. Your Art.29 assessment should explicitly address:

• Whether your AI model vendor is also relied upon by a significant portion of the financial sector
• What your fallback options are if the vendor ceases operations or degrades service
• Whether your use of foundation models (accessed via API) creates indirect concentration at the foundational model layer

Art.30: Key Contractual Provisions

Art.30 is where DORA's requirements become most operationally demanding for AI vendor relationships. It specifies minimum contractual provisions that must appear in every ICT third-party arrangement. For AI model vendors, these clauses interact directly with EU AI Act requirements in ways that can create contract negotiation friction.

DORA Art.30 requires that ICT third-party contracts include, at minimum:

• Full description of the services, including whether subcontractors are used and where data is processed
• Locations where services are provided and where data is stored and processed
• Provisions on availability, authenticity, integrity, and confidentiality of data
• Provisions on data access and recovery in the event of the provider's insolvency
• Descriptions of service levels, including quantitative and qualitative metrics
• Relevant provisions enabling the financial entity to terminate the arrangement
• Provisions on cooperation with the financial entity's competent authority
• Termination rights — including the right to exit if the provider undergoes changes in control or fails to comply with applicable law
• Provisions on participation in audits

For AI vendors specifically, Art.30 creates requirements that most SaaS AI vendors have not designed their contracts to satisfy:

Model change notification: DORA requires you to define service level metrics with quantitative targets. If the vendor retrains their model, you have no contractual protection unless you explicitly negotiated model-change notification periods and performance metric maintenance obligations. Standard AI vendor contracts often reserve the right to update models without notice.

Subprocessor and submodel chains: DORA requires disclosure of subcontractors. AI model vendors routinely rely on foundational models from third parties (which are themselves third parties under DORA's framework). Your contract must require that your vendor discloses its own supply chain, including foundational model dependencies.

Audit rights: DORA requires provisions enabling audits. For AI models, this creates questions about what an audit means — you need the right to audit not just the vendor's security controls but the model's conformity documentation, especially where the EU AI Act overlaps.

Art.31: Critical ICT Third-Party Service Providers

Art.31 establishes a designation framework under which the European Supervisory Authorities can classify ICT providers as critical to the financial sector. Critical ICT third-party service providers (CTPPs) become subject to a direct oversight framework with lead overseer designation and supervisory powers.

As of mid-2026, the ESAs have not yet formally designated AI model vendors as CTPPs under Art.31, but the oversight framework is operational and the criteria include market share across financial entities, systemic importance of supported functions, and substitutability. Large AI model providers with significant financial sector penetration are likely candidates for future designation.

For your compliance planning, Art.31 designation of a vendor you rely on would trigger additional obligations — including participation in mandatory testing programs led by the lead overseer, potential obligations to migrate away from the designated provider if remediation fails, and enhanced reporting requirements.

EU AI Act Obligations: Art.25 and Art.26 for AI Importers and Deployers

When a FinTech firm imports a high-risk AI system from a non-EU provider, Art.25 of the EU AI Act assigns formal obligations before the system can be placed on the EU market.

Art.25: Importer Obligations

An importer under the EU AI Act is any natural or legal person established in the EU who places on the market or puts into service a high-risk AI system that bears the name or trademark of a natural or legal person established outside the EU.

If you are a German FinTech and you are the entity that contracts with a US AI model vendor and deploys that vendor's credit-scoring model to EU customers, you are the importer. The Art.25 obligations are:

Verify provider compliance: Before placing the system on the market, you must verify that the provider has conducted the required conformity assessment, that the system bears a CE marking, that the provider has drawn up the required technical documentation, and that the system is accompanied by the information and instructions required for the deployer.

Keep a copy of conformity documentation: You must hold a copy of the EU declaration of conformity and ensure the technical documentation is available to market surveillance authorities on request.

Register in the EU AI Database: High-risk AI systems must be registered in the EU database under Art.49. As importer, you have registration obligations.

Due diligence on provider: If you have reason to believe the AI system does not conform with EU AI Act requirements, you must not place it on the market until it does conform. You have an obligation to investigate and, if necessary, withdraw the system.

The practical challenge: US AI vendors are not automatically EU AI Act compliant as of August 2026. Many have not completed conformity assessments, may not have technical documentation in the form required by Art.11, and may not have CE marking. As the importer, you cannot outsource this compliance gap to the vendor — you are liable under EU law for placing a non-conforming system on the EU market.

Art.26: Deployer Obligations

Even if you did not import the AI system (perhaps another entity in your group is the importer), if you put the high-risk AI system into operation — you run it, you feed it data, you use its outputs — you are a deployer under Art.26.

Deployer obligations include:

• Use the system in accordance with its intended purpose and the provider's instructions
• Assign human oversight to competent persons who have the necessary competence, training, and authority (Art.26 and Art.14 together define what human oversight means)
• Inform individuals who are subject to the system's decisions, including under Art.50 transparency obligations
• Conduct a fundamental rights impact assessment (Art.27) before deploying certain high-risk systems
• Monitor the system's operation and report serious incidents to market surveillance authorities under Art.73
• Keep logs of the system's operation to the extent required by technical capability

For FinTech deployers of credit-scoring AI, the Art.26 obligations mean you cannot simply run the vendor's model as a black box. You must have documented human oversight procedures, staff trained to interpret and challenge the model's outputs, and a process for handling cases where the model's outputs raise concerns.

The Convergence: Where DORA and EU AI Act Overlap

The obligations from DORA Art.28–31 and EU AI Act Art.25–26 do not just coexist — they create requirements that must be addressed together in your AI vendor governance.

Contract as the Convergence Point

DORA Art.30 requires contractual provisions that, when applied to AI model vendors, directly support your EU AI Act Art.25 importer obligations. Specifically:

The practical recommendation: design your AI vendor contract as a single instrument that satisfies both frameworks simultaneously. Your legal team should be working from a template that covers DORA Art.30 provisions and EU AI Act Art.25 importer provisions in a unified document.

Model Change Management

The most operationally complex overlap involves model updates. AI vendors update their models — for performance, for bias mitigation, to address discovered vulnerabilities. Under DORA, a material change to a critical ICT service may require reassessment of your concentration risk and ICT risk framework. Under the EU AI Act, a substantial modification to a high-risk AI system may trigger a new conformity assessment requirement at the provider level, which you as importer need to verify.

What counts as a substantial modification under the EU AI Act? The regulation and implementing acts provide guidance: changes that affect the system's intended purpose, changes that affect compliance with applicable requirements, changes that reduce performance beyond what was stated in the technical documentation.

What counts as a material change under DORA? The DORA implementing acts reference any change that affects the agreed service levels, the security characteristics of the service, or the ICT provider's ability to continue providing the service.

In practice: your AI vendor governance policy should require that the vendor notify you of all model updates and classify each update as requiring (a) no reassessment, (b) DORA-level reassessment, (c) EU AI Act-level reassessment, or (d) both. The classification criteria should be defined in your vendor contract.

Concentration Risk and the Foundation Model Layer

A significant governance gap exists at the foundational model layer. Most specialist AI model vendors — credit-scoring SaaS, fraud detection platforms, underwriting AI — build on top of foundational models from a small number of providers. Your direct vendor relationship covers the top layer, but your DORA Art.29 concentration risk assessment must look through to the foundational layer.

If three of your AI model vendors all rely on the same foundational model provider's API, your effective concentration risk is higher than your vendor diversification suggests. Mapping this requires asking your vendors for their own ICT dependency disclosures — the information DORA Art.30 entitles you to request.

For the EU AI Act dimension: if a foundational model provider updates their model and this flows through to your deployed high-risk AI system, this could constitute a substantial modification requiring your importer obligations to be re-verified, even though you had no direct relationship with the foundational model provider.

Practical Developer Checklist

For software teams building or integrating AI model capabilities at dual-regulated firms:

Vendor Assessment (Before Contract)

1. Identify whether the AI model falls under Annex III high-risk categories — check use case against the nine categories
2. Confirm the vendor has a published EU declaration of conformity or a timeline for producing one
3. Request the technical documentation summary — Art.11 requires it to exist; if the vendor cannot provide it, this is a red flag
4. Assess the vendor's foundational model dependencies for indirect concentration risk (Art.29)
5. Map data residency — does DORA Art.30 require EU data location? Does your data classification policy require it?

Contract Negotiation (Art.30 + Art.25 Alignment)

1. Include model change notification clauses with minimum notice periods (recommend 30 days for material changes)
2. Define "material change" in the contract to cover both DORA and EU AI Act substantial modification criteria
3. Include audit rights covering security controls AND conformity documentation
4. Include subcontractor and submodel disclosure obligations
5. Include exit provisions tied to regulatory non-compliance, not just service failure
6. Define termination data portability requirements for model outputs and training data contributions
7. Include cooperation with competent authority clauses (required by DORA Art.30; supported by AI Act Art.74)

Technical Integration (Art.26 Deployer Obligations)

1. Implement logging of model inputs and outputs at the integration layer (support Art.12 logging obligations)
2. Build model output confidence/uncertainty capture into your API integration — required for human oversight under Art.14
3. Implement an override mechanism — human operators must be able to disregard or modify model outputs (Art.14 human oversight)
4. Build a model output monitoring pipeline to detect distribution drift and performance degradation
5. Instrument your integration to detect when the model is being used outside its intended purpose (Art.26)
6. Document the system's deployment context as part of your conformity record (Art.25 importer obligation)

Ongoing Operations

1. Conduct annual review of your Art.29 concentration risk assessment for AI vendor dependencies
2. Maintain a register of all high-risk AI systems in operation, mapped to vendor relationships (Art.25 + DORA Art.28)
3. Run tabletop exercises covering AI model failure scenarios — what is your operational continuity plan if the vendor's API is unavailable?
4. Log and report serious incidents under Art.73 — integrate AI model incident classification into your DORA incident reporting process
5. Train human oversight staff on the specific model's capabilities and limitations — documented competency is required under Art.26
6. Review vendor conformity documentation annually — declarations of conformity must remain valid
7. Assess each model update against your dual-framework criteria and document the assessment outcome

Infrastructure and Jurisdiction Considerations

One dimension that connects both frameworks: where your AI model integration infrastructure runs.

Under DORA Art.30, you have the right to know where data is processed. If you are running your AI model integration layer on a US-headquartered cloud provider, your ICT dependency chain looks like:

1. Your application → 2. US cloud provider (ICT third party #1) → 3. AI model vendor (ICT third party #2) → 4. Foundational model provider (ICT third party #3, often the same as #1)

Every layer in this chain is subject to DORA's ICT third-party risk framework and potentially to US legal process under the CLOUD Act. If the data flowing through this chain includes borrower data used to make credit decisions, the jurisdictional exposure is significant.

Running your AI integration middleware on EU-native infrastructure (Hetzner Germany via sota.io, or similar EU-native PaaS) eliminates the CLOUD Act exposure at the infrastructure layer. It does not resolve the AI model vendor's own jurisdiction, but it ensures that your operational layer — the component you control — is not adding additional CLOUD Act exposure to the stack.

This matters for your Art.29 concentration risk assessment: EU-native infrastructure reduces the correlated risk that multiple layers of your AI stack are simultaneously reachable by the same legal jurisdiction.

Summary: Building a Unified AI Vendor Governance Framework

Dual-regulated firms cannot treat DORA and EU AI Act compliance as two separate workstreams when the subject is AI model vendor relationships. The obligations converge on the same questions: Who is your vendor? What do they do? What changes to what terms? What can you audit? What are your exit options?

The practical approach:

1. Unified vendor register — one register covering both DORA ICT third-party status and EU AI Act role (provider/importer/deployer) for each AI model vendor
2. Unified contract template — Art.30 contractual provisions drafted to simultaneously satisfy Art.25 importer verification requirements
3. Unified change management — a single process for assessing model updates against both DORA material-change criteria and EU AI Act substantial-modification criteria
4. Unified incident response — AI model failures assessed under both DORA incident classification (Art.17-19) and EU AI Act serious incident reporting (Art.73)
5. EU-native infrastructure — where you control the integration layer, run it on jurisdiction-clean infrastructure to avoid compounding your concentration and CLOUD Act exposure

The August 2026 deadline affects both frameworks for many dual-regulated firms. AI Act obligations for high-risk systems become fully enforceable, and the DORA oversight framework for ICT third-party providers is operational. Firms that have treated these as separate compliance programs should consolidate them around their AI vendor relationships now, while there is still time to negotiate contract updates and implement technical controls.

Part 3 of this series covers the DORA incident reporting + EU AI Act Art.73 serious incident overlap in detail.