AI and DORA: Operational Resilience for Financial Entities

DORA makes operational resilience a supervised obligation for financial entities, and AI systems sit squarely inside it. Model providers are ICT third-party service providers with contractual and register duties attached, which surprises teams who procured them informally. This guide covers the position, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

How does DORA reach AI systems?

As ICT assets and ICT third-party services, with all the attached machinery.

Requirement	What it means for AI
ICT risk management	AI failure modes in the framework
Third-party provider oversight	Model providers assessed and monitored
Register of information	AI service contracts recorded and reported
Contractual provisions	Prescribed clauses in AI contracts
Resilience testing	AI-dependent processes tested
Incident reporting	AI incidents in scope, on timelines

What does the register of information require?

Maintaining and reporting information about contractual arrangements with ICT third-party service providers, including service descriptions, criticality assessment, and the entities involved.

AI service contracts belong in it. Organisations that procured model access through a corporate card, or as part of a bundled cloud arrangement, frequently find those contracts were never registered, and reconstructing the detail afterwards is tedious.

What contractual provisions are required?

Prescribed elements including service descriptions, data processing locations, access and audit rights, exit strategies, and incident notification, with additional requirements where the service supports critical or important functions.

The exit strategy requirement bites hardest for AI. A financial entity dependent on a specific model provider needs a documented, tested path to moving off it — which affects architecture, not just paperwork. See what is a fallback chain.

What does resilience testing involve?

A testing programme proportionate to risk, covering systems supporting critical or important functions, with advanced testing for some entities.

Processes depending on AI systems need including. Testing what happens when a model provider is unavailable, degraded, or returning materially different output is a resilience question with an answer that should be rehearsed rather than theorised.

What evidence do you need?

Register entries for AI service contracts, criticality assessments, contract evidence containing the prescribed provisions, testing results covering AI-dependent processes, exit strategy documentation, and incident records with timelines.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes provider abstraction and fallback design into architecture. An exit strategy that exists on paper and has never been tested is not an exit strategy, and the testing requirement makes that visible.

The practical pattern is an abstraction layer over model providers with at least one tested alternative path, plus evaluation confirming the alternative produces acceptable quality. That is engineering work with a regulatory driver, and it improves resilience regardless.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Procuring model access outside the contracting process. Treating exit strategies as documentation. Testing availability without testing degraded quality. And excluding AI processes from the resilience testing programme.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this interact with other regimes?

It overlaps with information security management practice and with the broader EU cybersecurity regime, and it stacks with AI Act obligations where a system falls within their scope.

One evidence base — supplier assessments, testing results, incident records, contractual provisions — serves all of them with different reporting. Separate programmes produce duplicated effort and inconsistent answers. See AI and NIS2 directive.

What should you do first?

Check whether every AI service your organisation uses appears in the register and has the prescribed contractual provisions. Informally procured access is the usual gap.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: provider abstraction with a tested alternative path so exit strategies are real, AI-dependent processes included in resilience testing, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and NIS2 directive.