Who Does DORA Apply To, and Does It Reach Your AI Vendor?

Yes, if you're a bank, insurer, investment firm, payment institution, or crypto-asset service provider operating in the EU, and yes, your AI vendor is pulled in with you. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, became fully enforceable on January 17, 2025, and it covers roughly 20 categories of financial entities according to the EIOPA's own scope definition. The regulation doesn't stop at your organization's walls. Article 28 extends obligations to any ICT third-party provider your firm relies on for a critical or important function, and an AI vendor supplying document processing, claims triage, or a customer-facing chat agent almost always qualifies.

This is the part most AI vendor contracts miss entirely. The vendor doesn't need to be a financial entity itself, or even based in the EU, to fall under DORA's reach. If your firm is in scope and the AI service touches a critical function, the contractual and oversight requirements attach to that vendor relationship whether or not the vendor's legal team has ever read the regulation. We've seen procurement teams assume DORA is a bank problem, then discover mid-negotiation that their AI vendor's standard terms have no incident notification clause, no subcontractor disclosure, and no exit provision. That gap is now a compliance finding waiting to happen.

The Five DORA Pillars, Translated for an AI Vendor Contract

DORA rests on five pillars, and each one changes shape when the "ICT service" in question is a model API or an agent rather than a traditional software license. ICT risk management asks who owns risk decisions when the model itself is a black box you don't control. Incident reporting asks whether your vendor will tell you, within DORA's tight timelines, that the underlying frontier model had a degraded output incident, not just an outage. Resilience testing asks whether you can actually simulate your AI vendor going dark, which is a very different exercise than testing a database failover. Information sharing asks whether your vendor participates in the threat-intelligence exchanges DORA encourages. And third-party risk management, the pillar most relevant here, asks you to map the full chain: your AI vendor, the frontier-model provider behind it, and any subprocessors in between.

The KPMG framing of this shift is worth reading precisely because it treats third-party risk management as the pillar under the most pressure, and AI vendors are the newest, least-mapped category in that chain. PwC makes a similar point in its own third-party risk management guidance: the compliance burden isn't new in kind, it's new in scale, because AI vendors introduce dependency layers (the model provider behind the wrapper) that traditional software vendors never had.

Concentration Risk and the Hosted-API Problem

Here's the uncomfortable arithmetic: if your "AI vendor" is a thin wrapper calling OpenAI's or Anthropic's hosted API, you don't have one vendor relationship, you have two, and the second one is invisible in most contracts. DORA's concentration-risk language exists precisely to catch this. Article 28 and the accompanying regulatory technical standards ask financial entities to assess whether reliance on a single ICT provider, or a small cluster of providers underneath a chain of vendors, creates a systemic single point of failure. Route your claims processing, your KYC checks, and your customer support through the same frontier-model API, even via three different vendor logos, and you've concentrated risk in exactly the way the regulation was written to surface.

This is where self-hosting stops being a preference and becomes a genuine risk mitigation. Running an open-source model on infrastructure your firm controls, with documented data flows and no third-party inference dependency, removes an entire tier of concentration risk from your Register of Information. It's also why Genta AI Solutions builds self-hosted, open-source model deployments for regulated clients with zero data retention: not as a compliance checkbox, but because the alternative genuinely creates the exposure DORA is asking firms to measure. This isn't a universal answer (self-hosting has its own operational cost and skill requirements), but for a firm that has already mapped its concentration risk and found it concentrated in a hosted API, it's the direct fix.

The Exit Strategy Clause Most AI Contracts Don't Have

Article 28 of the official DORA text requires a documented exit strategy for critical or important ICT services, and it requires that strategy to exist before the contract is signed, not drafted in a panic after a vendor fails. Read your current AI vendor agreement and ask a direct question: if this vendor disappeared tomorrow, or was acquired, or had its access to the underlying model revoked, what's the documented path to continuity? Most AI vendor contracts we've reviewed have no answer. They have a termination clause, which tells you how the relationship ends, but not an exit strategy, which tells you how your business keeps running.

A compliant exit strategy for an AI vendor needs a few things a standard SaaS contract doesn't: portability of your data and any fine-tuned artifacts, documented dependency on upstream model providers (so you know what breaks if the vendor's own vendor changes terms), and a realistic timeline for standing up an alternative, whether that's a competing vendor or an internal build. If your vendor can't answer where your fine-tuning data lives, who owns the resulting model weights, or what happens to your prompts and outputs if the contract ends, you don't have an exit strategy, you have a hope.

What Happens If Your AI Vendor Gets Designated a Critical ICT Third-Party Provider?

The European Supervisory Authorities (EBA, ESMA, and EIOPA) can designate an ICT provider as a Critical ICT Third-Party Provider (CTPP), placing it under direct EU oversight rather than oversight-by-proxy through each financial entity that uses it. The first CTPP designations happened in 2025, and frontier AI infrastructure providers are plausible future candidates given how concentrated the market already is. If your AI vendor, or the model provider it depends on, gets that designation, you don't get to relax. Direct ESA oversight of the vendor doesn't remove your own obligation to monitor that relationship, maintain your Register of Information, and keep your exit strategy current. It does mean the vendor faces its own regulatory examinations, incident disclosure requirements, and potential remediation orders, all of which can ripple into your service continuity with little warning.

The practical implication for a buyer: build your vendor contract assuming a CTPP designation could happen mid-term, not as a hypothetical edge case. Ask what changes for you contractually if that designation occurs, and whether the vendor commits to passing through any resulting audit or reporting obligations rather than treating them as confidential.

DORA vs. the EU AI Act vs. NIST AI RMF: Which One Governs Your AI Vendor Contract?

All three, usually, and they're not interchangeable. DORA governs operational resilience and third-party risk for financial entities specifically, regardless of what the ICT service does. The EU AI Act governs the AI system itself, classified by risk level, and applies based on what the system does (a high-risk classification for AI used in credit scoring or insurance pricing, for instance) rather than who's buying it. NIST's AI Risk Management Framework, described on the NIST site, is voluntary in the US but increasingly used as the reference architecture US financial firms point to when a European counterparty or regulator asks how they manage AI risk. For a US-based fintech with EU customers, NIST AI RMF often becomes the internal governance skeleton, while DORA and the EU AI Act are the external obligations layered on top when EU financial entities are involved.

Our post on what the EU AI Act's high-risk deadline means for US and Singapore companies goes deeper on the Act's classification system specifically. The short version for a vendor contract: DORA asks "can this relationship survive an incident," the EU AI Act asks "is this system's risk level properly classified and controlled," and NIST AI RMF gives US firms a framework to answer both questions before an EU regulator asks. A single AI vendor contract for a regulated financial entity should reference all three, because a contract that only satisfies one leaves the other two as open findings. If you also operate in Singapore, the MAS AI risk management guidelines add a third-party AI provision built on the same idea.

A Practical Checklist: What to Ask an AI Vendor Before You Sign

Before signing, get direct answers to these, in writing, not in a sales deck:

• What underlying model or infrastructure does this service depend on, and is that dependency disclosed as a subprocessor in the contract?

• Does the contract include a documented exit strategy under Article 28, specifying data portability and a realistic transition timeline?

• What's the incident notification timeline, and does it meet DORA's reporting windows, not just the vendor's standard SLA?

• Where does our data physically reside, and does the vendor commit to zero retention on inference calls if we require it?

• If this vendor or its upstream provider is later designated a CTPP, what contractual obligations pass through to us?

• Can this vendor be replaced with a self-hosted alternative without a full rebuild, or is the switching cost effectively infinite?

This list overlaps with, but doesn't replace, the broader due-diligence process we walk through in what to ask an AI vendor before you sign the contract. That post covers the general vendor evaluation; this one is the DORA-specific layer for a regulated financial entity. If your team is also weighing whether a vendor's ISO 42001 certification actually covers this ground, our piece on what ISO 42001 certification actually proves about an AI vendor is the natural next read, and our broader look at how compliance changes AI agent deployment in financial services covers the operational side of this same decision.

If you're mapping this against your own vendor stack and wondering whether self-hosting makes more sense than renting a hosted model, that's precisely the diagnosis question our enterprise AI work starts with, before any build decision gets made. Genta AI Solutions runs that diagnosis for regulated clients specifically because the exit-strategy and concentration-risk math changes depending on what's actually running under the hood.

If you're working through this decision, this is exactly what our Discovery phase maps out, and we're happy to compare notes.

Frequently asked questions

Who does DORA actually apply to, only banks, or does it reach fintechs and their AI vendors too?

DORA covers roughly 20 categories of EU financial entities, including banks, insurers, investment firms, payment institutions, e-money institutions, and crypto-asset service providers, per the EIOPA's scope guidance. Their ICT third-party providers, including AI and LLM vendors, are pulled in through Article 28 obligations even if the vendor itself isn't a regulated financial entity.

What does DORA require when we hire an AI vendor or bring in a new ICT third party?

You need to assess the vendor's risk profile before signing, log the relationship in your Register of Information (including any subcontracting chain), and negotiate contractual terms covering incident reporting timelines, audit rights, and a documented exit strategy if the service supports a critical or important function.

Does using a hosted API like OpenAI or Anthropic instead of a self-hosted model create "concentration risk" under DORA?

It can. If multiple critical functions route through the same underlying model provider, even via different vendor wrappers, you've concentrated dependency in a way DORA's concentration-risk provisions are designed to surface. Self-hosting an open-source model removes that specific dependency layer, though it introduces its own operational responsibilities.

What's the difference between DORA and the EU AI Act for an AI vendor contract, do we need to comply with both?

Yes, typically both apply, and they cover different things. DORA governs operational resilience and third-party risk for financial entities regardless of what the service does; the EU AI Act governs the AI system's risk classification based on its function, such as credit scoring or insurance underwriting. A financial entity's AI vendor contract usually needs to satisfy both.

What exit strategy does DORA require if our AI vendor is later designated a Critical ICT Third-Party Provider?

Article 28 requires the exit strategy to exist before signing, regardless of later CTPP status. If a CTPP designation happens mid-contract, your existing exit plan should already cover data portability, a realistic transition timeline, and clarity on what obligations pass through from the vendor's own new regulatory oversight.