DORA AI Compliance for Banking: What the Operational Resilience Regime Requires from AI Systems
DORA took effect January 2025 across the EU financial sector and overlaps with the EU AI Act on the high-risk AI systems banks operate. The combined obligation includes operational resilience, third-party risk management, incident reporting, and per-decision audit records for AI-assisted financial decisions. This piece walks through what DORA actually requires of AI systems, how Article 6 and Annex III of the EU AI Act layer on top, and the architecture that satisfies both.
The Digital Operational Resilience Act took effect January 17, 2025 across the EU financial sector. The EU AI Act's high-risk system requirements take effect August 2, 2026 and apply to credit scoring, fraud detection, and other AI use cases banks routinely deploy. The combined regime requires per-decision audit records, ICT third-party risk management, incident notification within tight windows, and demonstrable operational resilience under disruption. Most bank AI deployments produce none of these as architectural outputs.
I want to walk through what DORA actually requires of AI systems, how the EU AI Act's high-risk provisions overlap, and the architecture that satisfies both regimes.
What DORA requires
DORA establishes a uniform regulatory framework for the management of ICT risk across the EU financial sector. The five pillars of DORA are ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information and intelligence sharing.
For AI systems used by financial entities, the pillars apply directly. ICT risk management requires that AI systems be inventoried, classified by criticality, and governed under the firm's ICT risk framework. Incident management requires that AI-related incidents (model failures, prompt injection events, unauthorized access, data leakage) be detected, classified, and reported to the competent authority within the DORA-defined timelines.
The third-party risk pillar is the one most relevant to bank AI deployments. AI services from OpenAI, Anthropic, Google, Microsoft, AWS, and the long tail of providers are ICT third-party service providers under DORA. Critical ICT third-party providers are subject to additional designation and oversight. Banks have to maintain a register of contractual arrangements, conduct risk assessments before contracting, and apply specific contractual provisions including audit rights, data location commitments, and exit strategy provisions.
The operational resilience testing pillar requires that critical ICT systems, which include AI systems supporting critical financial functions, undergo regular testing including threat-led penetration testing for the largest firms. The testing has to be evidenced and the results reported.
How the EU AI Act layers on top
The EU AI Act classifies certain financial AI use cases as high-risk under Article 6 and Annex III. The relevant Annex III categories for banking include creditworthiness assessment (Annex III point 5(b)) and risk assessment and pricing in relation to natural persons in the case of life and health insurance (point 5(c)). AI systems used for these purposes are high-risk regardless of which underlying technology powers them.
High-risk classification triggers obligations under Articles 8 through 17 (provider obligations including risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, and cybersecurity) and Article 26 (deployer obligations). For a bank deploying a third-party AI for credit scoring, both sets apply: the bank acts as the deployer and inherits Article 26 obligations, and may also act as the provider for AI systems it develops internally.
Article 12 of the EU AI Act is the record-keeping provision. High-risk AI systems must automatically record events over the lifetime of the system, with logs detailed enough to identify risk situations and support post-market monitoring. Article 19 specifies the minimum content of those logs: period of use, reference databases checked, input data, and identification of natural persons involved in result verification. The records have to be retained for at least six months and accessible to competent authorities on request.
The penalties under Article 99 reach €15 million or 3% of global annual turnover, whichever is higher, for high-risk non-compliance. For a major EU bank, the percentage tier dominates and reaches into the hundreds of millions of euros.
Where bank AI deployments are exposed
Bank AI deployments face exposure across the DORA pillars and the EU AI Act articles. The pattern repeats across many institutions I have seen.
The third-party AI service is not in the ICT third-party register, or is registered but without the DORA-required contractual provisions. The provider has not been classified for criticality. The contract lacks the audit-right, data-location, and exit-strategy provisions DORA requires.
The AI processing produces no per-request audit record. The bank's internal logs may show that the credit decision system was called for a specific loan application, but they do not show what specifically was sent to the LLM provider, what was returned, what data classification applied, or what policy governed the decision. Article 12 of the EU AI Act expects this record to exist automatically. The bank cannot produce it.
The natural person involved in the credit decision is not identified in the audit record. The AI request was made by a service account shared across the credit operations team. The Article 19 requirement that the log identify natural persons involved in result verification is unmet.
The incident detection time for AI-related events exceeds the DORA notification window. By the time a model drift, prompt injection, or unauthorized access incident surfaces through downstream effects, the DORA-required initial notification deadline (4 hours for major incidents) has passed.
The shadow AI surface is uninventoried. Cloud Radix's 78% employee unauthorized AI use figure applies to bank employees the same way it applies elsewhere. AI processing of customer data, market data, or pre-announcement earnings information outside the formal AI program creates exposure under DORA's ICT risk management pillar, the EU AI Act if the use case is high-risk, and MAR (market abuse regulation) for the pre-announcement data class.
The architecture that satisfies both regimes
The architecture that closes the gap has the same shape as the architecture for HIPAA in healthcare or Article 12 generally. The financial-services calibration adds specific data classes and incident response speed.
Inline inspection at the AI request boundary covers every AI request the bank's environment generates. The inspection includes detection for the data classes relevant to financial services: NPI (non-public information), MNPI (material non-public information), customer PII, payment data, model inputs for high-risk Annex III use cases. Detection accuracy matters because false negatives leak regulated data and false positives interrupt customer-facing operations.
Identity attribution names the verified natural person behind each request. For credit scoring and similar high-risk Annex III workflows, the natural person involved in result verification is a specific employee whose identity is in the audit record. For agent-based workflows, the agent identity (NIST Pillar 1) and the delegated authority context (Pillar 2) appear in the record.
Per-decision audit records satisfy both Article 12 and the DORA evidence expectations. The records contain timestamp, identity, data class, policy version, decision outcome, and tamper-evident signature. Retention runs at the longer of the EU AI Act six-month floor, DORA's record-keeping expectations, MiFID II record-keeping (typically five to seven years), and any other applicable financial regulation.
Incident detection at the request layer enables the DORA notification timeline. An anomaly in AI request patterns, an unauthorized AI service contacted from the bank's environment, or a prompt injection event detected by the inspection layer surfaces immediately rather than 247 days later. The DORA 4-hour initial notification window becomes operationally feasible.
Third-party risk management benefits from the same architecture because the inspection layer's audit records support the audit-right provisions DORA requires in contracts with ICT third-party providers. The bank can produce evidence of what its environment sent to which provider, when, and what the provider returned, independent of the provider's cooperation.
Where this connects to the broader EU regulatory stack
DORA and the EU AI Act do not stand alone for financial services. NIS2 applies broadly to large financial entities and adds incident notification and supply-chain security requirements that overlap with DORA. GDPR applies to customer data processing and adds Article 22 protections for automated decision-making that interact with AI credit decisions. MiFID II and IFD/IFR apply specific record-keeping and conduct rules to investment firms. The Sustainable Finance Disclosure Regulation adds ESG-related disclosure that may interact with AI-assisted ESG scoring.
The architecture that satisfies DORA and the EU AI Act produces records that contribute to GDPR Article 22, NIS2 supply-chain evidence, and MiFID II record-keeping. The infrastructure is shared. The vocabulary differs.
DeepInspect
This is the architecture DeepInspect was built to provide for financial-services AI compliance. DeepInspect sits inline between authenticated users, agents, and applications and any HTTP-based LLM endpoint. The inspection includes detection for NPI, MNPI, customer PII, payment data, and the data classes relevant to high-risk Annex III financial use cases.
Every decision produces a per-decision audit record containing identity, timestamp, data class, policy version, outcome, and a tamper-evident signature. The records support the EU AI Act Article 12 and Article 19 expectations, the DORA evidence and incident detection expectations, the MiFID II record-keeping timeline, and the audit-right provisions DORA requires in third-party contracts.
For bank CISOs, compliance officers, and operational resilience teams facing the August 2 EU AI Act enforcement date layered onto the in-force DORA regime, the inspection layer is the architectural component that produces the evidence each regime expects from the same infrastructure. Book a demo today.
Frequently asked questions
- How does DORA classify AI services from OpenAI or Anthropic?
AI services from external providers are ICT third-party service providers under DORA. The provider classification (critical or non-critical) depends on the service's role in supporting the bank's critical or important functions. AI services supporting credit decisions, fraud detection, or other high-risk Annex III functions typically qualify as supporting critical functions and trigger the heavier governance requirements. Banks have to maintain the register of contractual arrangements, complete the pre-contractual risk assessment, and ensure the contract includes the DORA-required provisions. Designation of providers as critical ICT third-party providers by the European Supervisory Authorities adds an additional layer of oversight directly on the provider, but does not relieve the bank of its own governance obligations.
- Does DORA require that AI providers be located in the EU?
DORA does not impose a blanket EU-residency requirement on ICT third-party providers. The contractual arrangements have to address data location and transfer, but providers outside the EU are permitted subject to the bank's risk assessment and the regulatory expectations on data transfer (which interact with GDPR for personal data). For AI providers based outside the EU, the contractual provisions typically have to include specific commitments around data residency for the bank's data, jurisdictional clarity for the contract, and exit-strategy provisions that allow the bank to transition off the provider if required by regulators.
- What is the DORA incident notification window for an AI-related event?
DORA defines incident classes based on severity. Major incidents require initial notification within 4 hours of detection, intermediate notification within 72 hours, and final notification within one month. The classification is based on the impact on clients, the financial impact, the geographical spread, the duration, and the criticality of the affected services. AI-related incidents that meet the major incident threshold (significant data leak, material model failure affecting customer decisions, prolonged service disruption) trigger the same windows. The operational requirement is that the bank can detect and classify the incident inside the timeline, which is where the request-layer inspection makes the difference.
- How do DORA and the EU AI Act interact when an AI service supports a high-risk function?
The two regimes operate concurrently. DORA addresses the operational resilience and third-party risk of the ICT service. The EU AI Act addresses the AI system's risk classification, conformity, and post-market monitoring. A bank deploying an AI for credit scoring faces DORA obligations on the AI provider as an ICT third-party and EU AI Act deployer obligations on the use of the AI for a high-risk Annex III purpose. The audit records and inventory the bank maintains have to satisfy both vocabularies. The infrastructure is the same; the documentation maps to two regulatory frames.
- Are there specific EBA or ECB guidelines for AI use that add to DORA?
The European Banking Authority and the European Central Bank have issued guidelines and opinions on AI use in banking that complement DORA. The EBA Discussion Paper on the use of machine learning for IRB models, the ECB's guide on internal models, and various supervisory expectations on model risk management apply to AI use in credit and market risk modeling. These do not replace DORA or the EU AI Act but add expectations on model documentation, validation, and ongoing monitoring. The architectural requirements (per-decision records, identity attribution, audit trail) align across the layers; the documentation requirements differ by regulator