DORA and AI: what financial institutions need to do now
DORA imposes strict ICT resilience rules on financial entities — here is what that means for AI deployments.
The Digital Operational Resilience Act entered full application in January 2025, and financial institutions across the EU are still catching up. Most of the attention has focused on DORA’s impact on traditional ICT systems — core banking, payment processing, cloud infrastructure. Far less attention has gone to what DORA and AI mean together, which is a problem because AI workloads introduce exactly the kind of concentration risk, third-party dependency, and opacity that DORA was written to address.
If your institution runs AI models — for fraud detection, credit scoring, customer service, or internal analytics — DORA applies to those workloads. Full stop.
What DORA actually requires
DORA is not a checklist regulation. It is a resilience framework built on five pillars: ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing. For AI workloads, the third-party risk management pillar is the one that bites hardest.
Article 28 requires financial entities to identify and assess all ICT third-party service providers, including sub-contractors. If your AI inference runs on a hyperscaler’s API, that provider is an ICT third-party under DORA. If that provider uses another company’s models, that is a sub-contractor. DORA requires you to map the entire chain, assess concentration risk, and maintain exit strategies.
Article 11 mandates business continuity and disaster recovery plans that cover all critical ICT services. If AI-powered fraud detection is critical — and it almost certainly is — you need a tested recovery plan that works even if your AI provider is unavailable.
Article 12 requires logging and monitoring of all ICT operations, with records that ensure integrity and confidentiality. AI inference events — prompts, completions, policy decisions — fall squarely within this scope.
The third-party concentration problem
Here is the uncomfortable reality: most financial institutions that have adopted AI are running it through one of three API providers. That is a textbook concentration risk under DORA. If your fraud detection, your customer service automation, and your internal document search all depend on the same provider’s API, a single outage — or a single contractual dispute — takes out all three.
DORA does not prohibit third-party AI services. It requires that you understand the dependency, test your resilience without it, and maintain credible exit strategies. For most institutions, the honest answer today is that no exit strategy exists. Switching AI providers is not like switching cloud regions. Model behaviour, prompt engineering, fine-tuning — none of it is portable.
The audit and logging requirement
DORA’s logging requirements go beyond traditional application logs. Article 12 specifies that records must support the “reconstruction of all activities” and ensure “integrity of the records.” For AI workloads, this means every inference request needs a tamper-evident audit trail that captures who asked, what was asked, what policy governed the request, and what the model returned.
Financial institutions that run AI through external APIs rarely have this level of logging. The provider logs on their side; you log on yours. Neither log is independently verifiable, and neither captures the full picture. This is a DORA compliance gap that most institutions have not yet addressed.
What to do now
First, map your AI dependencies the same way you map your ICT third-party providers. Include model providers, embedding services, vector database hosts, and any fine-tuning pipelines.
Second, assess concentration risk. If more than one critical function depends on the same AI provider, you have a DORA finding.
Third, build auditable logging into your AI inference pipeline — not after the fact, but at the gateway layer where every request is authenticated and recorded before the model processes it.
Fourth, test your resilience. Can your critical AI functions survive the loss of your primary provider for 72 hours? If not, your business continuity plan has a gap.
Where Operayde fits
Operayde addresses DORA AI compliance structurally. The appliance runs on-premise, eliminating third-party concentration risk for inference workloads. Every request passes through a gateway that emits Merkle-signed audit events, satisfying Article 12’s integrity requirements. Open-weight models run locally, so exit strategies are credible — you are not locked into a proprietary API. And because the appliance is managed as a fleet, continuity and patching happen continuously without exposing data to external networks.