DORA and Your AI Stack: What Financial Firms Need to Know

Your compliance team just finished the DORA ICT third-party register. They’ve catalogued every cloud provider, every SaaS platform, every outsourced IT service. Months of work. Hundreds of contracts reviewed. The register is thorough, professional, and almost certainly incomplete.

Did they include ChatGPT? What about Copilot? The AI coding assistant your developers adopted six months ago? The summarization tool your analysts paste client data into every afternoon?

If the answer is “no” — or worse, “I’m not sure” — you have a problem. Because the Digital Operational Resilience Act doesn’t care whether your procurement team signed the contract. It cares whether an ICT service processes your data. And every AI tool your people use does exactly that.

The risk you’re already running

Here’s what makes AI tools different from your other third-party ICT services: the data flows are invisible. Nobody fills out a procurement form before pasting a client’s portfolio summary into an AI chatbot. Nobody runs a vendor risk assessment before asking an AI to draft a regulatory filing. But every one of those interactions sends regulated data to a third-party service — usually one hosted in the United States.

That creates two problems at once. First, you’ve got an unregistered ICT third-party dependency — a gap in your DORA register that a supervisor will find. Second, you’ve got regulated financial data sitting on US servers, where the CLOUD Act gives US authorities legal access regardless of where the server is physically located. The CLOUD Act doesn’t require a search warrant in the traditional sense — and the data subject (your firm, your client) may never be notified.

This isn’t a hypothetical future concern. DORA has been in force since January 17, 2025. Supervisory reviews are happening now.

Nobody fills out a procurement form before pasting client data into an AI chatbot. But every one of those interactions creates an unregistered ICT dependency.

What DORA actually is

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — is the EU’s answer to a simple question: what happens when the technology financial firms depend on fails, gets hacked, or gets compromised?

Before DORA, every EU member state had its own patchwork of IT risk rules for financial firms. Some were thorough. Many weren’t. DORA replaces all of that with a single, directly applicable regulation across the entire EU.

The regulation was signed on December 14, 2022, published in the Official Journal on December 27, 2022, entered into force on January 16, 2023, and became fully applicable on January 17, 2025. There’s no transition period left. If you’re a regulated financial entity in the EU, you’re subject to DORA right now.

And the scope is enormous — roughly 22,000 financial entities across the EU fall under its requirements. Unlike a directive, which each member state transposes into national law (often differently), DORA is a regulation — it applies directly, uniformly, across all 27 EU member states. A bank in Dublin has the same obligations as an insurer in Frankfurt or a crypto exchange in Paris.

Who’s covered: all 20 entity types

One of the things that catches people off guard about DORA is its breadth. Article 2 lists 20 categories of regulated entities. This isn’t just banks:

1. Credit institutions
2. Payment institutions
3. Account information service providers
4. Electronic money institutions
5. Investment firms
6. Crypto-asset service providers and issuers of asset-referenced tokens
7. Central securities depositories
8. Central counterparties
9. Trading venues
10. Trade repositories
11. Managers of alternative investment funds (AIFMs)
12. Management companies (UCITS)
13. Data reporting service providers
14. Insurance and reinsurance undertakings
15. Insurance intermediaries, reinsurance intermediaries, and ancillary insurance intermediaries
16. Institutions for occupational retirement provision
17. Credit rating agencies
18. Administrators of critical benchmarks
19. Crowdfunding service providers
20. Securitisation repositories

If your organization falls into any of these categories — or if you’re an ICT third-party service provider to any of them — DORA applies to you. And that last point matters: DORA explicitly brings critical ICT third-party service providers under direct regulatory oversight.

Notice what’s on this list. It’s not just the big banks. Payment processors, crypto platforms, crowdfunding services, pension funds, credit rating agencies — DORA captures the entire financial ecosystem. If your organization touches money, insurance, pensions, or financial data in any structured way, you’re almost certainly in scope.

Roughly 22,000 financial entities across the EU fall under DORA — and the regulation applies directly and uniformly across all 27 member states.

Article 28: where AI tools become a compliance problem

The heart of the AI issue sits in Articles 28 through 30 of DORA, which lay out requirements for managing ICT third-party risk. Article 28 is the one your CCO needs to read carefully.

Here’s what it requires:

A complete register of all ICT third-party arrangements. Not just the ones your procurement team knows about. Every ICT service your firm relies on — including the AI tools your employees adopted on their own — must be documented. Article 28(3) requires financial entities to maintain and update a register of information on all contractual arrangements with ICT third-party service providers.

Risk assessment before contracting. Article 28(4) says firms must identify and assess all relevant risks before entering an ICT third-party arrangement. That includes assessing whether the arrangement creates concentration risk (too many critical services from one provider) and whether the provider’s jurisdiction creates legal conflicts.

Contractual requirements. Article 30 specifies mandatory contract terms including data location, security measures, audit rights, incident notification, and — critically — exit strategies. Most AI tool terms of service don’t meet these requirements. They weren’t written with Article 30 in mind, and retrofitting consumer-grade SaaS agreements into DORA-compliant contracts is harder than it sounds.

Now here’s where it gets specifically uncomfortable for US-hosted AI tools: Article 28(1)(a) requires that financial entities using ICT services “remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law.” If you’re subject to GDPR (and you are, if you’re a financial entity in the EU), using an AI tool whose parent company is subject to the CLOUD Act creates a direct jurisdictional conflict. The CLOUD Act compels disclosure. The GDPR restricts it. You can’t remain “fully responsible for compliance” with both at the same time.

The supervisory framework: who’s watching

DORA doesn’t just set rules — it creates enforcement machinery. Three European Supervisory Authorities share oversight:

• EBA (European Banking Authority) — credit institutions, payment firms
• EIOPA (European Insurance and Occupational Pensions Authority) — insurers, pension funds
• ESMA (European Securities and Markets Authority) — investment firms, trading venues, crypto providers

Together, these ESAs can designate ICT third-party service providers as “critical” under Article 31. Once designated, a critical provider falls under direct ESA oversight — including on-site inspections, recommendations, and the power to require changes. The ESAs can even issue penalties if a critical provider doesn’t cooperate.

This designation mechanism is new territory. Traditional financial regulation focuses on the regulated entity itself. DORA extends the supervisory perimeter to the technology providers those entities depend on. It’s a recognition that in 2025, operational risk and technology risk are the same thing.

Think about what this means for the major AI providers. If OpenAI or Microsoft becomes critical to enough financial entities — and given how rapidly AI adoption is growing in finance, that threshold is approaching fast — the ESAs could designate them as critical ICT third-party providers. That would subject them to direct European supervisory oversight, creating yet another layer of regulatory complexity on top of the existing CLOUD Act jurisdictional conflict.

And here’s the part that should worry compliance teams: the ESAs don’t need the AI provider’s consent to designate them as critical. The designation is based on systemic importance — how many financial entities depend on them, how substitutable the service is, what the impact of failure would be. The provider can object, but the ESAs make the final call.

Concentration risk

DORA explicitly addresses concentration risk in Article 29. If too many financial entities depend on the same ICT provider, a single failure could threaten financial stability. Supervisors are required to monitor this.

Consider the current AI market: a handful of US companies — OpenAI, Google, Microsoft, Anthropic — provide the large language models that most AI tools rely on. Even “independent” AI products often use these providers’ APIs under the hood. If your firm uses three different AI tools but they all run on OpenAI’s models, you don’t have three providers — you have one, and a concentration risk problem.

Exit strategies

Article 28(8) requires that firms have exit strategies for every ICT third-party arrangement. You need to be able to transition away from any provider without disrupting your operations.

For AI tools, this means asking uncomfortable questions. If your analysts have built workflows around a specific AI tool, can you switch to an alternative? How quickly? What happens to the data you’ve already sent to the provider? Do you even have the contractual right to demand deletion?

Most AI providers’ standard terms don’t address any of this. Try finding an exit strategy clause in ChatGPT’s terms of service. Try finding an audit rights provision. Try finding a contractual commitment to data location. These aren’t oversights — they’re reflections of a consumer-oriented service model that wasn’t designed for regulated financial entities. But DORA doesn’t care what the service was designed for. It cares what it’s being used for.

If three AI tools all run on the same underlying model provider, you do not have three providers. You have one — and a concentration risk problem.

What to do now

Here’s the practical compliance checklist. Start with the quickest wins:

1. Inventory every AI tool in your organization. Don’t just ask department heads — check browser extensions, app store installations, expense reports for AI subscriptions. Shadow AI is the biggest gap in most DORA registers. Every tool that processes data on your behalf is an ICT third-party service provider.

2. Add AI tools to your ICT third-party register. For each one, document the provider’s jurisdiction, what data it processes, which business functions depend on it, and whether the contractual terms meet Article 30 requirements. Most won’t.

3. Map the jurisdictional exposure. For every US-headquartered AI provider, document that the CLOUD Act creates a legal mechanism for US authorities to access your data — even if the data is stored in the EU. This is the conflict that Article 28(1)(a) will force you to address. Our CLOUD Act deep dive walks through exactly how this works.

4. Assess concentration risk. If multiple AI tools in your stack rely on the same underlying model provider, you have concentration risk under Article 29. Document it. Your supervisor will ask about it.

5. Review — or create — exit strategies. For every AI tool in your register, document how you’d transition to an alternative. What’s the timeline? What data needs to be migrated or deleted? Can the provider contractually commit to data destruction? Article 28(8) requires this.

6. Evaluate EU-sovereign AI alternatives. The simplest way to resolve the Article 28 jurisdictional conflict is to use AI tools that aren’t subject to the CLOUD Act. That means providers headquartered in the EU, with no US parent company, running on EU infrastructure. LumaVista runs open-source models on dedicated EU GPU servers — no US entity in the corporate chain, no CLOUD Act exposure, and the kind of data location certainty that makes your DORA register straightforward. Data sovereignty — not just residency — is what separates a compliant AI stack from a convenient one.

7. Brief your board. DORA’s Article 5 makes the management body directly responsible for ICT risk management. Your board members are personally accountable for understanding and approving the firm’s ICT third-party risk framework. If AI tools create unresolved compliance gaps, the board needs to know.

8. Don’t wait for enforcement. DORA has been fully applicable since January 17, 2025. The ESAs have been conducting supervisory reviews. The first enforcement actions will establish precedent — and you don’t want to be the precedent. Act now, while you still have the luxury of choosing your approach rather than scrambling to respond to a supervisory finding.

The firms that take DORA’s ICT third-party requirements seriously now — especially for AI tools — won’t just avoid regulatory trouble. They’ll build AI workflows they can actually trust, on infrastructure they actually control, with data flows they can actually explain to a supervisor. That’s not just compliance. That’s operational resilience. Which is, after all, exactly what DORA was designed to ensure.