EU AI Act and DORA: Managing AI System Risk in Financial Services

Financial services firms are adopting AI at a significant pace. Credit scoring models, fraud detection systems, algorithmic trading engines, customer service automation, anti-money laundering screening tools — AI is embedded in how modern financial entities operate. Regulators have noticed.

Two major EU regulations now apply to AI systems used by financial entities: the EU AI Act and DORA. They approach the same technology from different angles. Understanding how they interact will save you from duplicating compliance work and from missing the gaps where each regulation goes beyond the other.

What the EU AI Act Requires

The AI Act applies to providers and deployers of AI systems in the EU. If your organisation uses an AI system, even one you did not build, you are a deployer and you have obligations.

The Act classifies AI systems by risk level. Unacceptable risk systems are banned outright. High-risk systems face significant obligations. Limited-risk and minimal-risk systems have lighter requirements.

Most AI systems used in financial services fall into the high-risk category. The AI Act explicitly lists systems that evaluate creditworthiness, determine access to financial services, or influence decisions about insurance or credit as high risk. If your AI system affects whether a person gets a loan, an account, or insurance coverage, it is almost certainly high risk.

High-risk AI systems require a conformity assessment before deployment. They need human oversight mechanisms, transparency documentation, and registration in the EU AI database managed by the European Commission.

The AI Act is being phased in. Rules banning unacceptable-risk systems applied from February 2025. Obligations for high-risk systems apply from August 2026. That timeline is closer than it looks.

What DORA Requires for AI Systems

DORA does not mention AI explicitly. It does not need to.

AI systems are ICT systems under DORA's definition. If your credit scoring model runs on ICT infrastructure, it is an ICT asset. If your fraud detection system goes down, that is an ICT incident. The same framework that governs your data centres and your cloud services governs your AI systems too.

DORA's ICT risk management framework, set out in Articles 6 to 14, applies to AI systems just as it applies to any other digital system. That means AI systems should appear in your ICT asset register. They should be covered by your ICT risk assessment. They should be included in your business continuity plans. Where appropriate, they should be subject to resilience testing.

The practical implication is straightforward. If an AI system is critical to a service or a process your organisation depends on, it should be treated with the same rigour as any other critical ICT system.

Where the Two Regulations Overlap

There are three areas where DORA and the AI Act create overlapping obligations. Recognising these overlaps is where you can save real effort.

Risk assessment. The AI Act requires a risk assessment before deploying a high-risk AI system. DORA requires ICT risk assessments covering all systems, including AI. These do not need to be two separate documents. One thorough risk assessment, documented with both frameworks in mind, can provide evidence for both. The key is making sure the documentation explicitly addresses the AI Act's specific requirements alongside DORA's. Third-party AI providers. Many financial entities use AI systems built and operated by third-party providers. Under DORA, those providers are ICT third-party service providers. They must be in your third-party risk management programme, with appropriate contractual arrangements. Under the AI Act, the provider has its own obligations as an AI system provider, but you as the deployer still have oversight obligations. Your third-party register should capture the AI Act status of each AI provider alongside the DORA contractual requirements. Knowing whether your vendor has completed a conformity assessment is now a procurement question, not just a technical one. Incident reporting. If a high-risk AI system causes a significant disruption to your operations, that is a DORA ICT incident. Depending on severity, it may trigger the major incident reporting requirements under DORA's Article 19. The AI Act also requires providers to report serious incidents involving high-risk AI systems to market surveillance authorities. These are different reporting channels with different timelines and different recipients. Know which obligation applies to which type of incident, and be clear about who in your organisation owns each reporting pathway.

Where the AI Act Goes Beyond DORA

There are three areas where the AI Act creates specific obligations that DORA does not address.

Conformity assessments. High-risk AI systems need a documented conformity assessment before they are deployed. This is an AI Act requirement with no direct DORA equivalent. The assessment demonstrates that the system meets the Act's requirements for accuracy, robustness, cybersecurity, and transparency. If you deploy a high-risk AI system, you need this documented evidence on file before the system goes live. Human oversight requirements. The AI Act requires that high-risk AI systems be designed and deployed in a way that allows a human to monitor, understand, and if necessary override the system. DORA has no equivalent prescription. For automated credit decisions or trading systems, this means building in meaningful override capability. A nominal human in the loop who cannot in practice understand or reverse a decision does not satisfy the requirement. The oversight must be real. EU AI database registration. Deployers of certain high-risk AI systems must register them in the EU-wide AI database. This is an administrative obligation with no parallel in DORA. It applies to deployers who are public bodies and to deployers of the specific AI systems listed in Annex III of the Act. Check whether any of your systems fall within scope.

Practical Steps for Managing AI Systems Under Both Frameworks

There is a logical sequence for getting this under control.

First, inventory your AI systems. List every AI system your organisation uses, whether built internally or sourced from a third party. For each one, determine whether it is high risk under the AI Act. If you are unsure, the AI Act's Annex III provides the specific categories. Financial services use cases are clearly listed. Second, add AI systems to your ICT asset register. Each AI system should be registered as an ICT asset. Connect it to the relevant CIF function or business process it supports. This links the AI Act compliance work directly into your DORA risk management framework. Third, classify AI system providers in your third-party register. Note whether each provider is an AI system provider under the Act, what risk classification their system carries, and what evidence you hold of their AI Act compliance. A provider who cannot demonstrate conformity assessment completion for a high-risk system is a third-party risk you need to manage. Fourth, document the risk assessment for each high-risk AI system carefully. Structure the documentation to satisfy DORA's risk assessment requirements and the AI Act's conformity assessment requirements at the same time. This is possible with a thoughtful template. It is much harder if you treat them as separate exercises. Fifth, check your incident response process covers AI system failures. Your incident classification criteria should be explicit about what constitutes an AI-related ICT incident. Your major incident reporting checklist should include a check for AI Act serious incident reporting obligations.

DORA GRC includes a dedicated EU AI Act module where you can register AI systems, track their risk classification, link them to ICT assets and providers, and manage compliance across both DORA and the AI Act in the same system. AI system incidents feed into the main incident register so reporting timelines are tracked in one place.

The Bottom Line

The EU AI Act and DORA were designed by different regulators with different primary goals. For financial entities using AI systems, the practical overlap is significant.

An AI system that goes down is an ICT incident. An AI system sourced from a third party is a third-party risk. The compliance work you are already doing under DORA is a reasonable foundation for AI Act readiness.

The gaps are real. Conformity assessments, human oversight requirements, and database registration go beyond anything DORA asks for. But they are specific and addressable. Starting from a solid DORA framework puts you in a much stronger position than starting from scratch.

For a full picture of which EU regulations apply to your organisation, see EU CRA, NIS2, DORA, EU AI Act: Which Regulation Applies to You?