Does DORA apply to AI vendors directly or only to financial entities?

DORA applies to the financial entity. The financial entity has obligations regarding the AI vendor relationship under Articles 28 to 30. If the European Supervisory Authorities designate the AI vendor as a critical ICT third-party service provider under Article 31, the vendor itself becomes subject to direct ESA oversight. The first round of designations is expected in 2026. Cloud providers and the largest AI vendors are the categories most likely to see designations.

How does DORA interact with the EU AI Act for financial entities?

The two regulations apply concurrently. DORA covers operational resilience and third-party risk. The EU AI Act covers AI-specific obligations for high-risk systems. A credit scoring system operated by a bank using a third-party AI service falls under both regimes. The DORA register entry covers the third-party relationship. The EU AI Act high-risk classification under Annex III covers the algorithmic obligations including Article 12 record-keeping. Both regimes require operational records at the AI request boundary, which can be produced from a single per-request audit trail.

What is the 4-hour notification window for ICT incidents?

DORA Article 19(4) requires financial entities to submit an initial notification of a major ICT incident to the competent authority within 4 hours of classification as major. Classification can take up to 24 hours under the implementing standard. The 4-hour clock starts from classification, not from incident onset. Financial entities should design their incident response to support the classification decision within hours of detection and to produce the initial notification immediately after classification. AI integrations that lack prompt-level visibility extend the detection window and compress the response window.

Are AI inference services automatically critical functions under DORA?

DORA Article 3(22) defines critical or important functions as functions whose disruption would materially impair the financial entity's compliance with regulatory obligations, financial performance, or soundness or continuity of services. Whether a specific AI inference workload is critical depends on the function the workload supports. AI inference for customer service summarization is typically not critical. AI inference for transaction risk scoring on payment authorization may be critical. The classification is the financial entity's responsibility under Article 8, with the criteria documented and the assessment kept current.

What records does a DORA inspection actually request?

Competent authority inspections typically request the register of information, the ICT risk management framework documentation, the business impact analysis for the function under review, the contract with the ICT third-party service provider, the substitutability assessment, the exit strategy with the most recent test results, and the operational logs for the relevant period. For AI usage, the operational logs are the prompt-level records that show who used the AI service, for what purpose, and under what policy. The inspection runs over weeks. Inability to produce the records during the inspection is itself a finding.

DORA Third-Party Risk for AI: What ICT Third-Party Providers Have to Show

The EU Digital Operational Resilience Act (Regulation 2022/2554) took effect on January 17, 2025. DORA applies to credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central counterparties, trading venues, trade repositories, managers of alternative investment funds, insurance and reinsurance undertakings, and several other categories of financial entity. The regulation treats AI inference vendors as ICT third-party service providers under Article 3(19). Financial entities have to register the relationship, monitor concentration risk, prove an exit strategy works, and submit incident reports through national competent authorities to the European Supervisory Authorities.

I want to walk through what DORA requires from financial entities using AI vendors, how the AI inference relationship fits the third-party framework, and what evidence the joint ESAs expect during a thematic review.

How DORA classifies AI vendors

DORA defines an ICT service in Article 3(21) as "digital and data services provided through ICT systems to one or more internal or external users." AI inference fits the definition. The financial entity submits a prompt over an HTTPS endpoint and receives a response generated by the vendor's model. The service is digital, runs on ICT systems, and serves users inside the financial entity.

Article 3(19) defines an ICT third-party service provider as an undertaking providing ICT services. OpenAI, Anthropic, Microsoft, AWS, Google, Mistral, Cohere, and the long tail of model vendors fit the definition. The financial entity that buys their inference services has the third-party provider obligations under Articles 28 to 30 of DORA.

The classification does not depend on the vendor's primary product line. Microsoft is a cloud provider that also offers AI inference. AWS is a cloud provider that also offers AI inference. Both relationships are ICT third-party service provider relationships. The financial entity registers each AI service as a separate contractual arrangement when the service is operationally distinct from the underlying cloud platform.

What goes into the register of information

DORA Article 28(3) requires the financial entity to maintain and update a register of information for all contractual arrangements on the use of ICT services provided by third-party providers. The Joint ESA Implementing Technical Standard specifies the data points.

The register covers identification of the third-party provider, the function supported, the criticality classification, the data category processed, the location of data storage and processing, the start date of the contract, the contract reference, and the substitutability assessment. For AI vendors, the register entries get specific. The function supported is "AI inference for customer service summarization" or "AI inference for transaction risk scoring," not "AI." The data category is mapped to the financial entity's data classification scheme, with personal data and confidential data flagged separately.

Financial entities submit the register annually to their national competent authority. The competent authority forwards the data to the European Supervisory Authorities for the EU-wide oversight regime. The ESAs use the register to identify critical ICT third-party service providers that get designated under Article 31 of DORA.

Concentration risk and critical providers

DORA Article 29 requires financial entities to assess concentration risk from ICT third-party arrangements. A high concentration on one vendor for a critical function triggers heightened oversight. The financial entity has to document the substitutability assessment under Article 30(2), demonstrating that the function can be migrated to another provider without unacceptable disruption.

AI inference is a structurally concentrated market. Foundation model capability sits with a small number of vendors. Substitutability between OpenAI and Anthropic for a specific workload requires the financial entity to run model comparison testing, validate output quality, retrain prompt templates, and adjust downstream processing. The substitutability assessment is operationally meaningful, not a paperwork exercise.

The ESAs designate the most material ICT third-party service providers as critical under Article 31. Designation brings the provider under direct ESA oversight including inspections, requests for information, and recommendations. The first round of designations is expected in 2026. Cloud providers and AI vendors are the categories most likely to see designations.

Exit strategies and the testing requirement

DORA Article 28(8) requires financial entities to maintain exit strategies for ICT third-party arrangements supporting critical or important functions. The exit strategy must be documented, kept current, and tested.

For AI vendors, the exit strategy answers what happens if the vendor terminates the service, suffers a major outage, or fails the criticality test. The strategy covers the alternative provider, the cutover procedure, the data migration path, and the operational continuity arrangement. The financial entity must demonstrate that the strategy works in practice. The Article 24 testing program covers ICT third-party exit scenarios alongside other resilience tests.

Most AI inference arrangements I see at financial entities have an exit strategy clause in the contract and no operational test. The clause specifies that the vendor will provide reasonable assistance with migration on contract termination. The operational test verifies that the migration actually happens in the timeline the strategy assumes. The two are different artifacts. DORA requires both.

Incident reporting and what AI incidents trigger

DORA Article 17 requires financial entities to report major ICT-related incidents to the competent authority. The classification of an incident as major follows criteria laid out in the Joint ESA Regulatory Technical Standard on classification. Geographic spread, duration, number of clients affected, data losses, reputational impact, and economic impact all factor in.

For AI vendors, incidents that trigger reporting include unavailability of the AI service during a critical operational window, unauthorized disclosure of customer data submitted through the AI service, model output that produces material financial harm to customers, and corruption of the AI vendor's underlying infrastructure that affects the financial entity's operations.

The initial notification is due within 4 hours of classification as a major incident under Article 19(4). The intermediate report is due within 72 hours. The final report is due within one month. Financial entities that operate AI integrations without prompt-level visibility cannot meet the 4-hour clock because they cannot tell whether the AI vendor's incident affected their own data flows.

The audit trail DORA actually expects

DORA Article 5 requires the management body of the financial entity to be ultimately responsible for the digital operational resilience strategy. Article 6 requires an ICT risk management framework. Article 9 requires identification, classification, and documentation of ICT-supported business functions. Article 13 requires logs sufficient to support the resilience program.

For AI usage, the operational records expected during a competent authority inspection include the AI vendor used per request, the workforce member or automated agent that initiated the request, the data category exposed, the policy that governed the decision, the outcome of the decision, and the timestamp. The records support the register entries, the concentration risk assessment, the exit strategy testing, and the incident reporting.

Application logs typically cover none of these dimensions in operational detail. The records that survive a DORA inspection are produced at the AI request boundary, not by the application that sent the request.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users and agents and any LLM endpoint. Per-route policies enforce which AI vendor receives which workload, with the register classification and BAA-equivalent contractual scope wired into the policy decision. Every request produces a signed audit record containing identity, role, data category, vendor selected, policy version, decision outcome, and timestamp.

The record set supports the DORA register of information directly. The vendor-selection data feeds the concentration risk assessment. The per-request records back the incident reports the 4-hour clock requires. The same records satisfy EU AI Act Article 12 for financial entities running high-risk AI under Annex III.

If you are running AI under DORA and your register of information depends on a quarterly survey of application teams, the data quality fails inspection. Book a demo today.