A firm buys an AI service. Procurement runs its checks, security reviews the vendor, the model goes into a process, and everyone moves on. Some months later the same firm is asked for its register of information and discovers that the service it treated as a software subscription is, under the Digital Operational Resilience Act, an ICT third-party dependency in a financial process — with contractual provisions it probably does not have and an exit strategy nobody has written.
DORA is not an AI regulation, and that is exactly why it catches people. It never mentions your model as a model. It regulates dependency.
1. The reframing that does the work
Under DORA a model in a financial process is not a feature. It is ICT that a business function depends on.
Once that sentence is accepted, four things follow without any further argument, because they are what the regulation already says about ICT: the model belongs in the risk framework and the asset register, its failures are ICT incidents, the business path that runs through it belongs in the resilience testing programme, and the party supplying it is a third party with all the obligations that carries.
Nothing in that list is new to a financial firm. What is new is which things are inside it. Most DORA gaps involving AI are not failures to meet a requirement — they are failures to notice that a requirement now reaches something nobody had classified as ICT.
2. Where AI concentrates the risk: third parties
This is the pillar that AI changes most, and the reason is structural rather than technical.
An organisation's AI capability is rarely spread across many suppliers. It tends to sit with a small number of model providers, often reached through a handful of platforms, and frequently the same ones the rest of the market is using. Concentration is the thing DORA's third-party regime is built to surface, and AI produces it almost by default.
Four things are worth checking before anyone asks for them:
- Is the register of information current? If AI services entered through product budgets rather than procurement, some of them will not be in it.
- Are the required contractual provisions actually in the contract? A standard SaaS agreement signed before anyone thought of the vendor as ICT usually does not carry them.
- Is there an exit strategy that has been thought through? Not a clause — a plan. Switching model providers is not like switching hosting, and the honest version of the plan often reveals a longer dependency than expected.
- Is the concentration understood? Including the concentration you inherit: two suppliers that both sit on the same underlying model are one dependency wearing two names.
3. An AI failure is an incident, and looks like nothing
The incident regime assumes something breaks. Models mostly do not break; they degrade.
A model whose accuracy drifts, whose upstream data changes shape, or which starts producing subtly different outputs after a provider updates it, produces no outage, no alert and no ticket. The system is up. It is simply wrong more often than it was, and the first signal is usually downstream — in the exceptions queue, in complaints, in a reconciliation that stops reconciling.
Two questions follow from that, and both are worth answering in advance rather than during. Would your monitoring recognise this class of failure as an incident at all? And when classification is applied, does the root-cause analysis reach the model, or does it stop at the service that called it?
DORA carries classification thresholds and reporting windows. What they are is a matter for the regulation and your counsel; whether your incident process can see an AI degradation in time to apply them is a matter for you, and it is the part we find missing.
4. Testing the path, not the model
The resilience testing programme has to cover the AI-dependent path, and the interesting test is not accuracy.
It is degraded mode. What does the business process do when the model is unavailable, slow, or returning results that fail a sanity check? A path that has no answer beyond "it stops" is a documented dependency with an undocumented consequence, and the time to discover that is in a test rather than in an incident.
5. What an engagement examines against DORA
The work is an audit, not a readiness assessment — DORA is regulation, and there is no certificate to prepare you for.
In practice it traces the four questions above through evidence: what is in the register and what is missing from it, which contracts carry the provisions and which do not, whether the incident process would recognise a model degradation, and whether the AI-dependent path has been tested in a degraded state. The output is findings against named obligations, ranked, with what to fix first.
The full scope — the five pillars and what an AI dependency adds under each — is set out on the DORA framework page.
Three questions worth asking this week
Which AI services are in the register of information, and which entered through a product budget? The second list is usually the longer one and nobody owns it.
If the model degraded rather than failed, what would tell us? Name the alert. If the answer is a person noticing something looks off, that is the finding.
What is the exit strategy for our largest AI dependency? Not the clause. The plan, with a timescale someone believes.
Frequently asked questions
- Does DORA apply to AI?
- DORA does not regulate AI as such. It regulates ICT that financial entities depend on, and a model sitting in a financial process is ICT you depend on — which brings it inside the ICT risk framework, the incident regime, the resilience testing programme and the third-party rules.
- Is our AI vendor an ICT third-party provider under DORA?
- If a financial process depends on the service, it is generally being relied on as ICT regardless of how it was bought or what the contract is called. The practical test is whether the register of information lists it and whether the contract carries the provisions DORA requires — many AI services entered organisations through product budgets and neither is true.
- Is a model degradation an ICT incident?
- It can be, and that is the difficulty: a model that drifts produces no outage and no alert. The question to answer before it happens is whether your monitoring would recognise the degradation as an incident at all, and whether root-cause analysis reaches the model rather than stopping at the service calling it.
- What does an iDharma DORA engagement cover?
- It is an audit, not a readiness assessment — there is no certificate to prepare for. It traces the register of information, the contractual provisions, the incident process and the resilience testing of the AI-dependent path, and returns findings against named obligations, ranked by what to fix first.
