DORA doesn’t care that it’s AI

If you are shipping AI into a bank, an insurer, a payment institution, or anyone selling to one, there is a regulation that will reach your product before the EU AI Act does. It has applied since January 2025, most AI teams have never read it, and it does not care that your feature is AI.

The Digital Operational Resilience Act entered into force on 16 January 2023 and applies from 17 January 2025. It has five operative blocks: ICT risk management, incident reporting, resilience testing, ICT third-party risk, and direct EU oversight of providers designated as critical.

Nowhere in it will you find a chapter on artificial intelligence. That is precisely why it catches people out — and why it belongs in your AI use-case register alongside the AI Act, not after it.

Your model vendor is an ICT third-party provider

This is the thing to understand first, because everything else follows from it.

DORA’s definition of ICT services is intentionally wide — the regulation is explicit that it should be read broadly, covering digital and data services provided through ICT systems on an ongoing basis. An external model API delivered continuously over the internet sits comfortably inside that.

So the LLM provider your team integrated in a fortnight is, in all likelihood, an ICT third-party service provider to a regulated entity. That is not a technicality. It brings a set of obligations that have nothing to do with model quality and everything to do with dependency.

What Article 28 actually asks for

Article 28 sets the framework for third-party ICT risk, and it is where AI projects most often discover they have a problem. Four requirements matter most in practice.

A register of information. Every contractual arrangement for ICT services has to be recorded and reported to the competent authority. If your AI vendor was procured on a corporate card by a product team in a hurry, it is probably not in that register. Someone will eventually have to put it there, and answer why it wasn’t.

Concentration risk. Supervisors want to know how dependent you are on any one provider. The interesting version of this question for AI is not “how many vendors do you have” but “how many of them sit on the same underlying model, or the same three clouds?” Four vendors resting on one foundation model is one dependency wearing four coats.

Exit strategies. Documented, comprehensive, tested, and reviewed periodically. Not aspirational. “We would migrate to another provider” is not an exit strategy if nobody has tried it, the prompts are tuned to one model’s behaviour, and the evaluation set only exists as screenshots in a deck.

Contractual minimums. Audit rights, service levels, subcontracting terms, data location, termination rights. Standard AI vendor terms frequently do not include them, particularly at the startup end of the market.

The part that surprises product teams

Exit strategy is where AI is genuinely different from ordinary software, and where I’ve seen the most confident plans fall apart.

Swapping one database for another is a migration problem. Swapping one model for another is a behaviour problem. Your prompts encode assumptions about how a particular model responds. Your thresholds were tuned against its confidence distribution. Your users have formed expectations from months of a particular tone and failure mode. Move to a different provider and none of that transfers cleanly.

The practical consequence is that a credible AI exit strategy has to be built into the product, not written about it. That means an abstraction layer over the provider, an evaluation set you can re-run against a candidate replacement, prompts held as versioned artifacts rather than string literals, and a documented sense of what “equivalent quality” even means for your use case.

All of those are things you do at build time, cheaply, or retrofit later, expensively, under supervisory pressure.

Incident reporting changes what you log

DORA sets classification criteria for ICT-related incidents and reporting windows measured in hours rather than days for major ones.

That has a quiet product implication. If your AI feature degrades — the provider throttles you, quality drops after a model update, latency triples — can you tell? Quickly? And can you tell whether it crossed a threshold that makes it reportable?

Most AI features I have reviewed — including consumer fintech — were instrumented for product analytics and not for operational resilience. You knew how many people used it. You did not know it had been quietly worse for eleven days. Under DORA those are different questions with different consequences.

What to do before someone asks

• Find out whether you are in scope. If you sell to financial entities, your contracts probably already carry DORA clauses passed down to you. Read them before you sign the next one.
• Get your AI vendors into the register. The ones procured quickly by product teams are the ones that are missing.
• Test the exit, don’t describe it. Run your evaluation set against a second provider once. Whatever breaks is your real exit strategy, written down.
• Instrument for degradation, not just usage. Quality drift after a provider-side model update is invisible in a product analytics dashboard.
• Ask about concentration honestly. Count foundation models and clouds, not vendor logos.

DORA and the EU AI Act get discussed as if they were the same conversation. They aren’t. The AI Act asks whether your system is safe and fair, and whether a human is genuinely overseeing it. DORA asks whether your business keeps running when the thing you depend on stops working properly. An AI feature can pass the first and fail the second badly.

If you are building AI for financial services, the second question is arriving first — and it is being asked by procurement, in a spreadsheet, several weeks before anyone mentions risk tiers.