The Digital Operational Resilience Act never mentions artificial intelligence. A full-text search of Regulation (EU) 2022/2554 returns no instance of artificial intelligence, machine learning or automated decision, and no word-boundary match for AI at all. The nearest thing is a recital phrase about electronic and algorithmic trading. Regulation (EU) 2022/2554 is technology-neutral by construction, and that is exactly why an EU financial entity buying a language model API has a filing obligation.
DORA compliance for an AI vendor is built decision by decision rather than by summarising the Regulation. Below is the sequence a compliance team actually works through between signing an AI contract and submitting a register entry that will not be rejected, in the order those decisions arrive. Three of them have no good answer, and this page says which three.
| # | Decision | Where it is decided | Difficulty |
| 1 | Is this an ICT service? | Article 3(21) | Settled |
| 2 | Is the provider an ICT third-party service provider? | Article 3(19) | Settled |
| 3 | Which Annex III service code? | ITS (EU) 2024/2956, Annex III | No answer exists |
| 4 | Does it support a critical or important function? | Article 3(22) | Judgment |
| 5 | Who sits beneath the vendor, and how do you rank them? | Articles 3(18), 29(2) | Contested |
| 6 | Do the contract terms exist? | Article 30(2), 30(3) | Negotiable |
| 7 | Can the vendor meet a four-hour clock? | Article 19, DR (EU) 2025/301 | Usually not |
| 8 | Is anyone above you designated? | Article 31 | Asymmetric |
Decision one and two: the definitions settle quickly, and that is the point
Two definitions carry the whole analysis. Article 3, point (21):
“ICT services” means digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services which includes the provision of technical support via software or firmware updates by the hardware provider, excluding traditional analogue telephone services
And Article 3, point (19), the shortest definition in the Regulation:
“ICT third-party service provider” means an undertaking providing ICT services
Take a hosted model endpoint through the first definition. Digital service, delivered through ICT systems, provided to external users, available on an ongoing basis. Four elements, four matches, and the provider is an ICT third-party service provider under point (19). There is no size filter, no materiality threshold, no authorisation test and no sectoral filter anywhere in either definition, and the only express exclusion in the whole of point (21) is traditional analogue telephone services.
Only one element does real filtering, and it is ongoing basis. Take a consultancy that trains a model, hands over the weights and leaves: arguably not an ongoing service. A running endpoint plainly is. Procurement policy should name that boundary, because the ongoing-basis test is the only place in either definition where a genuine argument can be had.
Joint question and answer 2024_7290, finalised in November 2025, supplies the general method the ESAs apply: a service falling within Article 3(21) is an ICT service, while business processes “without a prevailing ICT component” are not. For an AI vendor the ICT component is not merely prevailing, it is the entire product.
DORA settles decisions one and two inside an afternoon. Then the procedure hits a wall.
Decision three: Annex III runs S01 to S19 and none of them is artificial intelligence
The first place AI breaks the framework. EBA question and answer 2025_7309, status final, confirms that a provider is classified “according to the type of service they provide, using the typology of services laid out in Annex III of Regulation (EU) 2024/2956.” That annex, in Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, states its own range: when referring to a type of ICT service in the register templates, only the identifier from S01 to S19 shall be reported.
Here are all nineteen. Read them looking for a model.
| Code | Type of ICT service |
| S01 | ICT project management |
| S02 | ICT development |
| S03 | ICT help desk and first level support |
| S04 | ICT security management services |
| S05 | Provision of data |
| S06 | Data analysis |
| S07 | ICT, facilities and hosting services, excluding cloud |
| S08 | Computation |
| S09 | Non-cloud data storage |
| S10 | Telecom carrier |
| S11 | Network infrastructure |
| S12 | Hardware and physical devices |
| S13 | Software licencing, excluding SaaS |
| S14 | ICT operation management, including maintenance |
| S15 | ICT consulting |
| S16 | ICT risk management |
| S17 | Cloud services: IaaS |
| S18 | Cloud services: PaaS |
| S19 | Cloud services: SaaS |
Artificial intelligence, machine learning, model, inference and generative appear nowhere in the list. Foundation model providers have to be filed under a code written for a different technology, and the choice propagates into the supervisory data the ESAs use to assess criticality.
There is, however, one decision rule hiding in the descriptions, and it is worth more than any amount of general advice. S08 Computation is defined as the provision of digital processing capabilities including data computation, expressly excluding computation performed in the context of a cloud environment. So a model served from a cloud environment cannot be filed under S08. The arrangement falls instead to S17, S18 or S19 according to how the service is delivered, which for a managed model API is ordinarily S19. S08 is left for computation outside a cloud environment, which in practice means dedicated on-premises or bare-metal inference.
A workable ordering survives that exclusion. A managed model API delivered as a service: S19. A model you deploy onto a platform you rent: S18. Inference on infrastructure you provision: S17. Self-hosted inference on your own or dedicated hardware: S08. A subscription to a data feed used to build or ground a model: S05. Analytical support wrapped around a model rather than the model itself: S06.
DORA publishes no official mapping of that kind, so the honest thing to record is the reasoning rather than the answer. Write down the code you chose and why you chose it, because the code is contestable and the reasoning is what defends it.
One detail confirms the typology could have been widened and was not. Between the ESAs’ draft and the adopted text, S07 gained payment-processing activities and operating payment infrastructures. The Commission was willing to extend a service category during adoption, and extended that one. Artificial intelligence stayed unnamed.
Decision four: critical or important is where the obligations multiply
Article 3(22) defines a critical or important function as one whose disruption would materially impair the financial entity’s financial performance, or the soundness or continuity of its services and activities, or whose failed performance would materially impair continuing compliance with the conditions of its authorisation or with other obligations under financial services law.
DORA makes an error in either direction expensive. Mark it critical and Article 30(3) adds six contract terms, threat-led testing participation and heavier due diligence. Mark it not critical and every one of those falls away, along with the obligation to inform the competent authority in advance of the arrangement.
Note what does not change with the answer. Article 28(3) requires the register to cover all contractual arrangements on the use of ICT services, not only critical ones, with those supporting critical or important functions distinguished inside it. Pilot deployment of a chatbot in a non-critical process still produces a DORA register entry. The classification changes the obligations, not the filing.
Decision five: ranking the chain beneath the vendor
The second place AI breaks the framework. An AI vendor rarely owns its infrastructure. The model runs on a hyperscaler, the weights may come from a third party, and inference may be brokered, so the register has to represent a chain rather than a relationship.
Article 3(18) defines ICT third-party risk to include risk arising from services provided by a provider “or by subcontractors of the latter.” Article 29(2) then applies where a contract permits further subcontracting of a critical or important service: the entity weighs benefits and risks, considers insolvency law and constraints on urgent recovery of its data, considers Union data protection rules and enforceability where the subcontractor sits in a third country, and assesses “whether and how potentially long or complex chains of subcontracting may impact their ability to fully monitor the contracted functions and the ability of the competent authority to effectively supervise the financial entity.”
The level 2 history explains why practitioners find this section thin. The ESAs submitted a draft technical standard on subcontracting on 17 July 2024. The Commission rejected it on 21 January 2025. The ESAs’ opinion JC 2025 06 records the reason: Article 5 of the draft, on conditions relating to the chain of ICT subcontractors, went “beyond the empowerment given to the ESAs by Article 30(5) of DORA,” with the provisions on monitoring the subcontracting chain specifically outside the mandate, so that article and its recital were removed. Delegated Regulation (EU) 2025/532 was adopted on 24 March 2025 without them.
The ESAs pointed to where the duty went in the same opinion: financial entities remain expected to follow Article 29(2) and Article 3(6) of the implementing standard on the register. Chain monitoring survived and changed address. The duty now sits in a Level 1 assessment obligation and in the register’s supply-chain ranking fields rather than in a technical standard, which is why anyone searching the RTS for it finds nothing.
DORA filings also fail here, and fail mechanically. The ESAs’ published observations on the first collection show that the errors causing outright rejection were structural rather than substantive: foreign key constraint violations, missing primary keys, wrong filing indicators, files not matching the entity identifier. Wrong or missing legal entity identifiers recurred alongside them. In the 2024 dry run, across roughly a thousand participating entities, 93.5 per cent of submissions contained at least one error and only 6.5 per cent passed all 116 data quality checks. Broken links between provider tables are the single most common failure, and an AI arrangement with a model host underneath it is precisely the shape that breaks them.
Concentration data shows why supervisors read those fields carefully. ESMA’s risk analysis of February 2026, across 728 entities in 19 countries, found Microsoft the top AI provider for almost half of respondents, ahead of OpenAI at 20 per cent and Amazon Web Services at 8 per cent. Forty-one per cent rely on a single commercial cloud provider, 62 per cent exclusively on commercial cloud, and only around 8 per cent of named providers are domiciled in the EU. Sixty-nine per cent identified a secondary provider and 41 per cent a tertiary one, which is the chain appearing in supervisory data.
Decision six: nine contract terms, or fifteen
DORA sets nine mandatory terms for every ICT contractual arrangement at Article 30(2). A complete description of the functions and services, stating whether subcontracting of a critical or important service is permitted and on what conditions. The locations, by region or country, where services are provided and data processed including storage, with advance notice of any change. Provisions on availability, authenticity, integrity and confidentiality. Access, recovery and return of data on insolvency or termination. Service level descriptions. Assistance during an ICT incident at no additional cost or at a cost fixed in advance. Full cooperation with competent authorities. Termination rights and minimum notice periods. And conditions for participating in the entity’s security awareness and resilience training.
Article 30(3) adds six more where the service supports a critical or important function. Full service levels with precise quantitative and qualitative targets. Notification of any development that might materially affect the provider’s ability to deliver. Contingency plans and security measures. Participation in the entity’s threat-led penetration testing. Rights of monitoring including, at point (e)(i), “unrestricted rights of access, inspection and audit” whose exercise is “not impeded or limited by other contractual arrangements or implementation policies.” And exit strategies, which the text sets out as:
exit strategies, in particular the establishment of a mandatory adequate transition period: (i) during which the ICT third-party service provider will continue providing the respective functions, or ICT services, with a view to reducing the risk of disruption at the financial entity or to ensure its effective resolution and restructuring; (ii) allowing the financial entity to migrate to another ICT third-party service provider or change to in-house solutions consistent with the complexity of the service provided.
Two of these are hard to obtain from an AI vendor and easy to overlook. Testing participation under 30(3)(d) contractually obliges a model provider to take part in a red team exercise it probably has not contemplated, with Article 26(4) pooled testing the realistic route for a provider serving many entities. And the exit strategy has to be real: a transition period during which the model keeps answering while you move, which for a service with no portable equivalent is a commercial negotiation rather than a drafting exercise.
Article 28(1)(a) is the reason none of this can be pushed onto the vendor. Under DORA a financial entity with contractual arrangements for ICT services “shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law.” Buying the service moves the work, not the liability.
Decision seven: a four-hour clock the vendor has to serve
DORA classifies incidents by effect rather than by technology. Article 3(10) defines a major ICT-related incident as one with “a high adverse impact on the network and information systems that support critical or important functions,” and the criteria in Article 18(1) reach clients and transactions affected, duration and downtime, geographical spread, data losses touching availability, authenticity, integrity or confidentiality, criticality of the services affected, and economic impact. Thresholds sit in Delegated Regulation (EU) 2024/1772.
Delegated Regulation (EU) 2025/301 then sets the clock. Initial notification comes as early as possible and in any case within four hours from classifying the incident as major, and no later than 24 hours from the moment the entity became aware of it. Intermediate reporting follows within 72 hours of that notification, even where nothing has changed. Final reporting comes no later than one month afterwards. The four-hour and twenty-four-hour limits run from different triggers, classification and awareness, which is where firms are caught out.
Applying this to AI, on a reading of the text rather than any regulator statement: a model endpoint outage degrading a customer-facing service is assessed like any other outage. A model producing silently degraded output with no outage is harder, but the integrity limb of Article 18(1)(d) reaches it, and detection rather than legal coverage is the obstacle, which pushes the problem back into the Article 17 incident management process.
The first supervisory data arrived on 3 June 2026 in the ESAs’ first annual report on major ICT-related incidents. The report records 3,383 major incidents, around a third of them with cross-border impact, and two findings that should reorder an AI risk register. System failures and external events were the main drivers, which the ESAs tied directly to third-party risk management and coordination with service providers during response. And only 10 per cent of reported incidents related to cybersecurity. The dominant failure mode under DORA is a third party’s system not working, which is the shape of a model outage.
So the practical question at decision seven is not whether you can meet the clock. The live question is whether your vendor’s notification obligation, as drafted, delivers the facts inside four hours of classification. Contracts that do not are a compliance defect rather than a commercial inconvenience.
Decision eight: check who above you is designated, and notice who is not
The third place AI breaks the framework. On 18 November 2025 the European Supervisory Authorities designated the first critical ICT third-party service providers under Article 31(9), which requires the ESAs to establish, publish and update the list yearly. Nineteen were designated and the European Banking Authority was appointed Lead Overseer for every one. The published list, reproduced exactly as it appears including its own irregular capitalisation, is:
Accenture plc; Amazon web Services EMEA Sarl; Bloomberg L.P.; Capgemini SE; Colt Technology Services; Deutsche Telekom AG; Equinix (EMEA) B.V.; Fidelity National Information Services, Inc.; Google Cloud EMEA Limited; International Business Machine Corporation; InterXion HeadQuarters B.V.; Kyndryl Inc.; LSEG Data and Risk Limited; Microsoft Ireland Operations Limited; NTT DATA Inc.; Oracle Nederland B.V.; Orange SA; SAP SE; Tata Consultancy Services Limited.
No pure-play AI company and no foundation model provider is on it. The hyperscalers that host models are designated; the model layer is not. AI exposure in EU financial services is captured indirectly, through the infrastructure beneath it, so the supervisory relationship runs to the party renting the compute rather than the party that trained the weights. Set that beside ESMA’s finding that OpenAI is the direct AI provider for a fifth of surveyed entities and the asymmetry is hard to defend for long.
Check any list you are shown against that PDF. One page ranking prominently for this query publishes a list of designated providers that is largely invented, naming firms that are not on it and omitting ten that are, and a second page has already repeated one of its errors.
DORA sets cumulative designation criteria at Article 31(2): systemic impact of a large-scale failure, the systemic character of the reliant entities, reliance in relation to critical or important functions “irrespective of whether financial entities rely on those services directly or indirectly, through subcontracting arrangements,” and degree of substitutability including “the lack of real alternatives, even partial.” Oversight is not nominal. Article 35(1)(d) lets a Lead Overseer recommend on security processes, on terms preventing “the generation of single points of failure,” on planned subcontracting, and at point (iv) on refraining from further subcontracting to a third-country subcontractor where the arrangement poses a clear and serious risk to Union financial stability. Fees under Delegated Regulation (EU) 2024/1505 are proportionate to turnover with a floor of 50,000 euro a year.
Supervisors have escalated their reading of the underlying risk. The European Systemic Risk Board raised systemic cyber risk to severe in June 2026, up from elevated in March, in a warning specifically about frontier artificial intelligence models. Germany’s BaFin had already said in guidance of 18 December 2025 that AI systems “must also be included within the existing ICT risk management framework.” And the ESAs’ statement of 31 July 2026 records that Lead Overseers have “initiated targeted engagement with relevant CTPPs” and begun “embedding AI-related risks into its Oversight Examination Methodology.” No 2026 update to the designation list had been published as at today.
The cadence nobody diarises
DORA does not stop at maintaining the register. The third subparagraph of Article 28(3) requires financial entities to report at least yearly to competent authorities on the number of new arrangements, the categories of ICT third-party service provider, the type of contractual arrangements, and the ICT services and functions being provided. Competent authorities then transmit to the ESAs, by 31 March in the steady state, with 30 April for the first cycle in 2025, and national deadlines run earlier so that supervisors can collect and validate first. The reference date is 31 December of the preceding year.
The yearly cadence turns the classification decision at step three into a recurring exposure rather than a one-off. Every year the S-code you chose for an AI vendor is refiled, and every year it feeds the criticality assessment that produced the list at step eight. Deloitte’s European DORA survey, a consultancy study rather than a regulator one, found 46 per cent of respondents naming the register as the single most challenging requirement, which given the above is not surprising.
Where the EU AI Act joins, and where it does not
DORA never mentions the AI Act, and a search of the adopted AI Act text for Regulation (EU) 2022/2554 returns nothing. Textually the two instruments are disconnected, which surprises most readers because commentary routinely implies a cross-reference.
The connection runs instead through clauses keyed to Union financial services law. Article 17(4) of the AI Act deems the quality management system obligation fulfilled, other than points (g), (h) and (i), for a financial institution complying with internal governance rules under that law. Article 26(5) deems deployer monitoring fulfilled on the same basis. Articles 18(3), 19(2), 26(6) and 72(3) absorb technical documentation, logs and post-market monitoring into the financial services file rather than deeming them satisfied. Article 9(10) is weaker than commentary suggests: risk management aspects “may be part of, or combined with” existing procedures, which deems nothing. And Article 74(6) makes the national financial supervisor the market surveillance authority for AI systems used by regulated financial institutions, so the body examining your ICT risk framework is also the body enforcing the AI Act against you.
One caution belongs on the record. Union financial services law is nowhere defined as including DORA, and DORA is never named in those clauses, so whether a DORA-compliant framework counts toward a deeming clause is interpretive rather than settled. The furthest any authority has gone is the ESAs describing the two as together providing “a solid foundation.”
A fraud detection model shows the disconnect most sharply. Annex III point 5(b) of the AI Act classifies creditworthiness evaluation as high risk “with the exception of AI systems used for the purpose of detecting financial fraud,” so a fraud model attracts few AI Act obligations. The same system is unambiguously an ICT service under DORA Article 3(21), and if it supports a critical or important function it attracts the full Article 30(3) contract regime, register entry, testing participation and incident reporting. Two European regimes, one system, opposite answers.
For completeness on outlook: DORA is not amended by the Digital Omnibus proposal, COM(2025) 837 of 19 November 2025. The proposal would route DORA incident reports through a single entry point alongside NIS2 and GDPR reports, and the European Central Bank recommended in Opinion CON/2026/9 of 10 March 2026 that DORA be excluded from that arrangement, warning that a DORA report “triggers time-critical processes.” No DORA enforcement action by any competent authority has been publicly identified.
The eight records that answer for the eight decisions
| Decision | Artefact | Also serves |
| ICT service determination | A written scope note applying Article 3(21) to the service | AI system inventory scope |
| Provider identification | Vendor record with legal entity identifier | Third-party risk register |
| Annex III code | The chosen code and the reasoning behind it | Nothing else, which is why it must be written down |
| Critical or important | Function criticality assessment under Article 3(22) | EU AI Act risk classification |
| Chain ranking | The chain from entity to vendor to model host, with identifiers | Concentration analysis |
| Contract terms | Executed clauses on location, audit, testing and exit | AI Act deployer duties |
| Incident readiness | Vendor notification terms tested against a four-hour clock | Incident response playbook |
| Designation check | A record of whether any upstream provider is designated | Board reporting |
Three of those eight are unusual in that no framework names the artefact. The Annex III reasoning, the chain ranking and the designation check all exist because the obligation exists, not because a template asks for them, which is exactly the kind of record that is missing when a supervisor asks.
Govern365.ai holds the mapping from a provision to the artefact that proves it, so the classification decision, the chain and the contract evidence stand as a record rather than being rebuilt each March. One control usually answers several regimes: the same vendor file supports a DORA register entry, an AI system inventory and an EU AI Act classification, and one third-party assessment answers both Article 28 due diligence and AI Act deployer duties. Our third-party AI risk management guide covers the vendor layer, foundation model vendor risk questions covers what sits beneath it, and the AI compliance evidence guide sets out the artefact types across regimes.
Three things to do before the next reference date. Sweep procurement and expense data for AI services that never went through vendor onboarding, because an unregistered arrangement is a filing gap rather than a policy gap. Write down the Annex III code and the reasoning for every AI provider, applying the cloud exclusion in S08 before anything else. And read the notification clause in every AI contract against the four-hour classification deadline, which is the term most often missing and the hardest to renegotiate after an incident.
Frequently asked questions
Does DORA apply to artificial intelligence?
The Digital Operational Resilience Act never mentions artificial intelligence. DORA applies to AI services because Article 3(21) defines ICT services as digital and data services provided through ICT systems to users on an ongoing basis, and Article 3(19) makes any undertaking providing such services an ICT third-party service provider.
Is an AI vendor an ICT third-party service provider under DORA?
On the text, yes. A language model API, an AI fraud detection service and a cloud-hosted model each satisfy every element of Article 3(21). Only the ongoing-basis requirement filters anything, and it may exclude a genuinely one-off engagement.
Do AI vendors go in the DORA register of information?
Yes. DORA requires at Article 28(3) a register of all contractual arrangements on the use of ICT services, not only those supporting critical or important functions, maintained at entity, sub-consolidated and consolidated levels.
Which Annex III code applies to an AI or LLM provider?
There is no AI code. Annex III of Implementing Regulation (EU) 2024/2956 runs from S01 to S19 and none of the nineteen refers to artificial intelligence, machine learning, models or inference. S08 Computation expressly excludes computation performed in a cloud environment, so a cloud-delivered model falls to S17, S18 or S19 according to delivery model, with S19 the ordinary answer for a managed model API. Record the reasoning, because the code is contestable.
Has any AI company been designated a critical ICT third-party service provider?
No. Nineteen providers were designated on 18 November 2025 and no pure-play AI or foundation model company is among them. The hyperscalers that host models are designated; the model providers are not.
Is an AI model outage a reportable incident under DORA?
An outage can be reportable. DORA classifies incidents by effect rather than by technology. If the AI service supports a critical or important function and the thresholds in Delegated Regulation (EU) 2024/1772 are crossed, the incident is major and reportable within four hours of classification and no later than twenty-four hours from awareness.
Does the DORA subcontracting technical standard cover monitoring of the AI supply chain?
Not directly. The Commission rejected the original draft because the chain-monitoring article exceeded the mandate in Article 30(5), and Delegated Regulation (EU) 2025/532 was adopted without it. Under DORA the duty survives through the Article 29(2) assessment and the register’s supply-chain fields.
When is the DORA register due?
DORA registers reach the ESAs by 31 March in the steady state, transmitted by competent authorities against a reference date of 31 December of the preceding year, with 30 April applying to the first cycle in 2025. National deadlines run earlier, because supervisors collect and validate before transmitting.
How do DORA and the EU AI Act interact for a bank?
Neither regulation cites the other. The AI Act deems certain obligations fulfilled, or absorbs them, where a financial institution complies with internal governance rules under Union financial services law, and Article 74(6) makes the national financial supervisor the market surveillance authority for AI systems used by regulated financial institutions
