DORA and AI: an assistant is an ICT dependency, not an experiment

DORA is about digital operational resilience in the financial sector. It does not mention artificial intelligence as a special case, and it does not need to. An AI service that supports a business process is an ICT service, and it lands in the same framework as everything else.

The responsibility does not move

Article 28(1) states that financial entities “shall manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework”, and point (a) removes the usual escape:

financial entities that have in place contractual arrangements for the use of ICT services to run their business operations shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law

Regulation (EU) 2022/2554, Article 28(1)(a)

Recital 64 says the same in plainer words: “A financial entity should at all times remain fully responsible for complying with its obligations set out in this Regulation.”

Article 28(1)(b) then makes the effort proportionate, taking into account “the nature, scale, complexity and importance of ICT-related dependencies”. A pilot with two users and a production workflow in credit operations are not treated alike.

What has to be in the contract

Article 30(2) lists the minimum contents of an arrangement on the use of ICT services. Point (b) is the one that catches AI services:

the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations

Regulation (EU) 2022/2554, Article 30(2)(b)

Point (a) requires a clear and complete description of the functions and services, and whether subcontracting is permitted. Point (c) covers availability, authenticity, integrity and confidentiality. Point (d) covers access, recovery and return of data if the provider fails.

Applied to a cloud AI service, those are not abstract. The location answer can depend on a deployment setting, subprocessing has to be described, and the exit path has to exist before it is needed.

The questions a supplier has to answer in writing

• Where is the service provided, and where is the data processed and stored?
• Who else processes it, and under what terms?
• What happens during an outage, and what is the recovery objective?
• Can the service be substituted, and how long would that take?
• What happens when the model version is retired?
• What notice is given before any of these change?

DORA is not an argument against cloud. It is an argument against dependencies nobody has written down.

What a local appliance changes, and what it does not

A local AI appliance does not remove operational risk. Hardware fails, software fails, and a model can be confidently wrong. Those risks move onto the entity's own register rather than disappearing from it.

What changes is the shape of the dependency. The processing location is the entity's own site and does not move with a console setting. There is no external inference endpoint whose availability sits outside the contract. The model version is fixed until somebody chooses to change it.

For a workflow that must keep running, those are the properties the register cares about. For everything else, a well-documented cloud service may be the better answer, and DORA is content with either as long as the entity can evidence the choice.