Start with the tools your teams already use: a fraud model, an AML assistant, a credit scoring engine, a customer chatbot, a document analysis tool for onboarding. If one of them supports a critical or important financial function, DORA cares about it. Not because DORA is an AI regulation. Because DORA is about the technology that keeps financial services running. An AI system is part of that technology when it processes decisions, depends on a cloud provider, calls an external model or can fail in a way that affects customers.
Start with the AI systems people actually use
- Fraud detection: the model can wrongly block card payments or let suspicious payments pass.
- AML and sanctions screening: the assistant can miss alerts, create false positives or slow down case review.
- Credit scoring and underwriting: the model can affect who gets credit, at what price and under what limit.
- Customer chatbots: the tool can give wrong answers, expose data or fail during a peak support period.
- Internal search and document analysis: the system can surface wrong evidence or depend on a supplier the register does not show.
These are not abstract AI risks. They are operating risks. A model can be unavailable, a provider can change a service, an integration can leak data, an automated decision can affect too many customers before anyone notices. That is why the same AI system can matter for model risk, the AI Act and DORA at the same time.
A critical provider is a supplier supervisors watch directly
On 18 November 2025, European supervisors named nineteen critical ICT third-party providers under DORA. In plain language, these are technology suppliers whose failure could create risk for many financial firms at once. Three names matter immediately for AI: Amazon Web Services EMEA, Google Cloud EMEA and Microsoft Ireland Operations.
Many financial AI systems run on these clouds through services such as Bedrock, Azure OpenAI Service and Vertex AI. Since January 2026, these providers have direct supervisors with powers to request information, investigate, inspect and issue recommendations. That does not make every AI use case high-risk. It does mean your AI dependencies are now easier for supervisors to follow.
DORA applies because AI is part of the service
DORA does not need to say AI for AI to be in scope. The test is simpler: does the system support a business function that depends on technology? If yes, the system, its data flows, its hosting provider and its external APIs can all become part of the DORA perimeter.
Take a credit scoring model. The model is not just a file. It depends on data, an application, monitoring, access rights, an inference endpoint and often a cloud or model provider. If that chain fails and customers are affected, the issue is not only an AI quality problem. It can become an ICT incident under DORA.
Three obligations become very concrete
- Inventory: Article 8 means the AI system should appear with its owner, function, data dependencies, model dependencies and providers.
- Incidents: Article 19 means an AI failure can be reportable if the impact is high enough, whatever the technical cause.
- Third parties: Article 28 means the register of information should show the cloud provider, the model provider and the service chain where they support a critical or important function.
This is where many registers are weak. They list the application, but not the model service behind it. They list the cloud contract, but not the AI component used through that cloud. They list the business owner, but not the incident threshold that would turn an AI failure into a DORA report.
The AI Act adds another layer
Some financial AI systems are also high-risk under Annex III of the EU AI Act. Creditworthiness and credit scoring are the clearest examples. Fraud detection is excluded from that high-risk category, but it can still be in DORA if it supports a critical or important function.
Article 9(10) of the AI Act lets firms combine the AI Act risk process with existing EU risk management frameworks. The EBA made the same point in its November 2025 AI Act analysis. In practice, the AI Act file and the DORA file should not tell two different stories about the same system.
What to do next
- Pick the AI systems that affect customers, transactions, onboarding, compliance or risk decisions.
- For each system, write down the business function, owner, data sources, model provider, cloud provider and fallback plan.
- Check whether the same system appears in the DORA register of information. If it does not, add it or explain why it is out of scope.
- Define the incident trigger in plain numbers: customers affected, transactions affected, downtime, economic impact and data impact.
- For high-risk AI Act systems, make sure the AI Act documentation and the DORA controls use the same owner, scope and evidence.
For each important AI system, the test is practical: where is it in the register, who owns the risk, which supplier does it depend on, and what happens when it fails?
References
- Regulation (EU) 2022/2554 (DORA), eur-lex.europa.eu/eli/reg/2022/2554/oj.
- Commission Implementing Regulation (EU) 2024/2956 (ITS on the register of information).
- ESAs, List of designated Critical ICT Third-Party Providers, 18 November 2025, esma.europa.eu.
- EBA, AI Act mapping exercise, letter from José Manuel Campa, 21 November 2025.
- Regulation (EU) 2024/1689 (AI Act), Article 9(10), Annex III, eur-lex.europa.eu.