Until recently, discussions about AI in financial services regulation focused primarily on the EU AI Act and its classification framework. DORA was treated as a separate concern, addressing ICT risk and operational resilience without specific reference to artificial intelligence.
That separation no longer holds.
In June 2026, the European Supervisory Authorities published their first annual report on major ICT-related incidents under DORA. Alongside the statistical findings, the ESAs included an explicit warning: the evolution of highly capable AI-driven tools should encourage financial entities to strengthen cybersecurity measures to maintain their resilience. The same month, Finanstilsynet's ROS 2026 dedicated attention to AI as both a threat amplifier and an internal governance challenge.
The supervisory consensus is forming rapidly. AI is not just a compliance topic under the EU AI Act. It is an ICT risk that falls squarely within the scope of DORA's operational resilience framework. Institutions that treat these as separate workstreams will find themselves explaining that choice to supervisors who see them as deeply connected.
AI as a threat amplifier
The first dimension of the supervisory concern is external. AI makes existing cyber threats faster, cheaper, and more effective.
Finanstilsynet's ROS 2026 states explicitly that generative and autonomous AI accelerates the discovery and exploitation of software vulnerabilities. Threat actors can use large language models to identify weaknesses in code, generate novel exploitation techniques, and automate reconnaissance at a scale that was previously impractical. Social engineering attacks become more convincing when AI generates personalised, contextually appropriate phishing messages. Deepfake technology enables voice and video impersonation that can bypass identity verification procedures.
None of this requires the threat actor to have exceptional technical skill. AI tools lower the barrier to entry for sophisticated attacks while simultaneously increasing the pace at which they can be conducted. The asymmetry between attacker capability and defender preparedness is widening.
For DORA purposes, this shifts what supervisors expect from your ICT risk assessment. Article 6(1) requires financial entities to have a sound, comprehensive, and well-documented ICT risk management framework. That framework must identify, classify, and adequately document ICT risks. If your risk register describes the cyber threat landscape without accounting for AI-accelerated attack vectors, it no longer reflects the environment your institution actually operates in.
The ESAs' incident report found that cybersecurity incidents accounted for approximately 10% of the 3,383 major incidents reported across the EU in 2025. While that figure covers all causes including non-AI-related attacks, the ESAs' explicit reference to AI tools as a factor indicates that this percentage is expected to grow unless institutions adapt their defences.
AI as an internal ICT risk
The second dimension is internal and arguably more urgent for most institutions. AI tools adopted within your organisation create ICT risks that must be identified, governed, and managed under your DORA framework.
Finanstilsynet identifies unauthorised AI adoption as a specific governance concern. The pattern is familiar to anyone working in financial services technology: a business unit discovers a generative AI tool that improves productivity. They begin using it. The tool processes client data, generates outputs used in decision-making, or connects to internal systems. None of this goes through ICT risk assessment, procurement review, or third-party due diligence.
Under DORA, any ICT service that supports business functions is within scope of the risk management framework. That includes AI tools, whether they are operated internally, consumed as a cloud service, or embedded within a third-party product. The question is not whether an AI tool is labelled as "ICT" by the team using it. The question is whether it creates risks to the confidentiality, integrity, or availability of your information and systems.
Three specific scenarios illustrate where this creates DORA compliance exposure:
AI tools processing sensitive data. If an employee pastes client information into a generative AI service, that service is now processing personal and potentially confidential data. Under DORA Article 28, ICT services provided by third parties must be governed by contractual arrangements that address data protection, security, and the entity's right to audit. If no contract exists because no one in procurement knows the tool is being used, that is a governance failure with both DORA and GDPR implications. AI embedded in vendor products. Many ICT third-party providers are integrating AI capabilities into their existing services. Your core banking system may now use machine learning for fraud detection. Your communications platform may route requests through an AI model. These capabilities change the risk profile of services you have already assessed. If your Register of Information and risk assessments do not reflect AI components within vendor products, your documentation no longer matches reality. AI tools used in ICT operations. Development teams increasingly use AI coding assistants, automated testing tools, and AI-driven monitoring. These tools interact with your codebase, infrastructure, and production systems. A misconfigured AI tool with write access to production represents a risk that should be identified and managed like any other privileged system access.Where DORA's requirements apply to AI
DORA does not contain the word "artificial intelligence." It does not need to. The regulation is technology-neutral and applies to all ICT risks regardless of the underlying technology. Several articles become directly relevant when AI is in scope.
Article 5 (Governance) requires the management body to bear ultimate responsibility for the ICT risk management framework. If AI tools create risks that the board is unaware of, governance obligations are not being met. Supervisors will ask whether AI usage has been reported to the board, whether policies exist for AI adoption, and whether the institution has visibility into which AI tools are deployed. Articles 6 through 16 (ICT risk management) require identification, protection, detection, response, and recovery capabilities across all ICT systems. AI tools that interact with data or systems must be included in asset inventories, covered by access controls, monitored for anomalies, and subject to incident response procedures. Article 28 (Third-party risk) applies to any AI service consumed from an external provider. That includes standalone AI platforms, AI features embedded in existing vendor products, and AI APIs integrated into internal workflows. Each requires assessment, contractual coverage, and ongoing monitoring. Articles 17 through 23 (Incident reporting) apply when an AI-related disruption meets the criteria for a major incident. An AI system that produces erroneous outputs affecting client transactions, an AI-driven security tool that generates false negatives allowing a breach to proceed, or an AI provider outage that disrupts a critical function — all of these may trigger reporting obligations.What supervisors will ask
Based on the signals from the ESAs and Finanstilsynet, a set of supervisory expectations is becoming clear. Institutions should be prepared to answer the following questions during their next interaction with their NCA:
- What AI tools does your institution use, and who authorised their deployment?
- Are AI services reflected in your Register of Information?
- How does your ICT risk assessment account for AI-specific threats?
- What governance policies exist for new AI adoption?
If you cannot answer these comprehensively, you have a visibility gap. An AI asset inventory, documenting which tools are in use, what data they access, who approved them, and what controls are in place, is the foundation for everything else.
An institution that has no process for evaluating and approving AI tools before deployment cannot claim effective ICT risk governance. The policy does not need to be prohibitive. It needs to ensure that AI tools receive the same risk assessment, security review, and contractual coverage as any other ICT service.
Practical steps for 2026
The convergence between AI risk and DORA compliance creates work, but it is manageable work if approached systematically.
Start with visibility. Conduct an inventory of AI tools in use across the institution. Include tools used by individuals, teams, and those embedded in vendor products. This does not require perfection on day one. It requires a process that surfaces what is currently invisible. Integrate AI into your ICT risk framework. Update your risk register to include AI-specific risks: data leakage through AI services, dependency on AI providers, model errors affecting business decisions, and AI-accelerated cyber threats. Assess each against your existing risk appetite and determine whether current controls are adequate. Update your Register of Information. If AI services from third-party providers are not currently captured, add them. Review existing vendor arrangements for AI components that may have been introduced since your last assessment. Establish governance for new AI adoption. Create a process that requires AI tools to be evaluated through your ICT risk assessment before deployment. This process should be lightweight enough that teams use it rather than work around it, but rigorous enough to identify genuine risks before they materialise. Brief your board. The management body needs to understand that AI has become a supervisory concern under DORA. Present the findings from the ESAs' incident report and your NCA's publications. Ensure that AI risk is visible in the board's ICT risk reporting, and that decisions about AI governance are documented in board minutes.The regulatory direction is clear
Six months ago, treating AI as primarily an EU AI Act concern was defensible. Today, after the ESAs and multiple NCAs have explicitly connected AI to ICT operational resilience, that position is no longer tenable.
AI is an ICT risk. It falls within DORA's scope. Supervisors are asking about it. The institutions that act on these signals now will be in a significantly stronger position when those questions arrive formally. The institutions that wait for specific AI provisions within DORA's technical standards will find themselves explaining to supervisors why publicly available guidance was not sufficient to prompt action.
The ESAs' message is measured but unambiguous: the evolution of AI tools should encourage financial entities to strengthen cybersecurity measures. In regulatory language, "should encourage" is as close to a directive as a first annual report gets. The second report will expect progress.