Short answer. You manage AI vendor risk under DORA the same way you manage any ICT third-party risk: register the service, classify whether it supports a critical or important function, put DORA Article 30 clauses in the contract, and prove you can exit. An LLM API is an ICT service the moment it runs in production, so it belongs in the register of information under Article 28. This matters now because on 18 November 2025 the European Supervisory Authorities designated the first 19 Critical ICT Third-Party Providers, and the cloud platforms most AI vendors run on are on that list. Direct EU oversight of those 19 does not move the risk off the bank. The financial entity stays accountable for its own outsourcing.
DORA, Regulation (EU) 2022/2554, has applied to financial entities since 17 January 2025. It does not create a separate AI regime. It folds AI and large language models into the ICT third-party risk rules that already govern every cloud service, data feed, and SaaS contract a bank runs. So the question “how do we manage the OpenAI or Anthropic contract” has the same answer as “how do we manage the core banking host”: register it, classify it, contract for it, and test the exit.
In a working setup the work divides into four moves:
The failure pattern is a bank that adds an LLM API through an engineering team’s monthly card, treats it as a tool rather than an outsourced ICT service, and leaves it out of the register. When a supervisor asks for the register entry and the exit plan, there is none. That gap is exactly what a DORA examiner looks for, and it is the same gap that stalls an AI model before production because no one can prove the dependency is controlled.
The 18 November 2025 designation changed the shape of the problem. The ESAs named 19 Critical ICT Third-Party Providers, including the hyperscale cloud platforms, and those 19 move under direct EU oversight through 2026. Most AI vendors do not run their own compute. They sit on top of a designated provider, so an AI dependency is usually a hidden second dependency on a hyperscaler already flagged as systemic.
Oversight of the hyperscaler does not reduce the bank’s own obligations. DORA is explicit that the financial entity remains responsible for managing the risk from every ICT service it consumes, including sub-outsourcing chains and concentration. For a CEE bank running credit, fraud, or claims models, that means the AI vendor, the model it serves, and the cloud underneath all have to be visible, classified, and exit-tested before an audit, not during one.
An LLM API in production is an ICT service under DORA and belongs in the Article 28 register of information.
Yes, once it runs in production. DORA defines an ICT service broadly as digital and data services provided through ICT systems on an ongoing basis. A hosted model API called by a live banking workflow meets that definition, whether it is billed as a platform subscription or a per-token API. The billing line does not decide the classification. The function it supports does. A model that only powers an internal experiment sits lower on the register than one embedded in a customer-facing or decision-making process, but both are ICT services and both belong in the register of information.
The Article 28 register entry for an AI vendor carries the same fields as any ICT provider, plus the detail that makes AI risk auditable. Name the provider and the specific service, for example a named model API rather than “generative AI”. Record the function supported, the criticality classification, the data processing location, and the contract dates including renewal and termination. Capture sub-outsourcing: if the model vendor runs on a hyperscaler, that chain has to be documented, because Article 28 requires visibility of the providers behind your provider. An incomplete chain is a finding, not a formatting note.
Article 30 lists the mandatory provisions for arrangements supporting critical or important functions. For an AI vendor the ones that bite are audit and access rights so the bank or a supervisor can inspect the service, incident notification and cooperation so a model failure is reported and worked jointly, sub-processor transparency and controls on further sub-outsourcing, service levels with EU data residency where required, and a full exit strategy with transition support. A generic SaaS agreement rarely carries these, so AI vendor contracts signed before DORA usually need renegotiation before the function they support can be called compliant.
Treat the hyperscaler as a named dependency, not background infrastructure. Map which critical functions ultimately rest on a single designated provider, then define and test an exit path at least once a year. The test is the point. A bank that can describe a fallback but has never run it has documentation, not resilience. Where a single provider carries several critical functions, the concentration itself is the risk a supervisor will probe, and a rehearsed migration or a second-source design is the answer that holds up.
Ownership sits across the three lines of defense, not in procurement alone. The first line, the business and engineering teams that adopt the AI service, identifies the dependency and keeps the register entry current. The second line, risk and compliance, sets the classification rules, challenges them, and confirms the Article 30 clauses are in place. Internal audit forms the third line, and the management body stays accountable for the overall ICT risk framework. When AI vendor risk is owned only by the team that bought the tool, the register is incomplete by design, and that is the state DORA is written to prevent.
Managing AI vendor risk is a governance and integration problem before it is a legal one, which is why it belongs next to the production work, not in a separate compliance silo. Ableneo shipped 34 production AI projects in 2025, 94% of them using LLMs, across banking and insurance clients in the same regulated world as this question. That mix means the register entry, the criticality call, and the exit test get designed alongside the model, not bolted on after go-live. Our AI transformation work builds the third-party control into the delivery, and it connects directly to the sign-off question covered in who signs off on an AI system in a DORA audit.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.