A compliance officer at an insurer is updating the register of information that DORA requires. It lists the core system, the cloud provider, the CRM and the company that hosts the policy administration system. ChatGPT is not in it, because nobody signed a contract for it. One floor down, three underwriters use it every day to compare policy wordings.
This piece is about that gap. DORA requires firms to manage ICT risk and the ICT services that third parties provide. An AI service that employees use is one of those services, whether it was procured or simply found. So the question is not whether it belongs in your ICT risk management, but how much weight it carries and what you record about it. What AI governance means more broadly for a regulated firm is covered in AI governance for financial services; this piece deals with the DORA side.
What does DORA actually require?
DORA, the Digital Operational Resilience Act, is an EU regulation that has applied since January 2025 to banks, insurers, investment firms, payment institutions and a range of other financial entities. In the Netherlands it is supervised by DNB, the Dutch central bank, and the AFM, the Dutch financial markets regulator. The regulation is about digital resilience and does not mention AI specifically.
What it does require, in plain terms: a framework for managing ICT risk, with ultimate responsibility resting with the management body; reporting ICT incidents; testing resilience; managing the risk of ICT services provided by third parties, with a register of the contractual arrangements with them; and sharing threat information. Which requirements apply, and how strictly, depends on the type and size of the entity. The regulation allows for proportionality, and exactly how it applies is a matter for the firm's own compliance and risk functions.
Two of those parts matter here: ICT risk management and third-party risk management. That is where everyday AI use comes in.
Is an AI chatbot a third-party ICT service?
Yes. It is software that an external party provides and that employees use for their work. The fact that it runs in a browser and nobody raised a purchase order for it does not make it any less an ICT service. It does make one difference: there is no contract, so nothing has been agreed on availability, data, security, subcontractors or termination. The risk is there; the management is not.
This is what makes the third-party register awkward. It describes contracts. A service without a contract does not fit, so it drops out of view, even though it is the least managed risk. How to keep the two lists side by side without duplicating work is covered in our article on the AI register and the third-party register.
The second question is how much weight the service carries. DORA distinguishes between ICT services that support a critical or important function and the rest. That depends on the use, not on the tool. A chatbot that rewrites a memo supports no important function; once the same chatbot is part of the underwriting process or claims handling, it is a different conversation. The risk a tool brings and what the use adds to it are covered in our guide on how to assess the risk of an AI tool.
Where does each type of AI use fit?
| Type of AI use | Where it falls in DORA terms | What you record about it |
|---|---|---|
| Microsoft 365 Copilot under the existing Microsoft contract | Third-party ICT service, already in the register | That Copilot is covered by that contract, which data it can reach, the decision |
| AI feature inside the advice software or the CRM | Falls under that vendor's contract | Whether the contract covers that feature, whether data goes to a subcontractor |
| ChatGPT or Perplexity on a free account | ICT service without a contract: an unmanaged risk | Assessment, decision, condition and the alternative that has a contract |
| Transcription tool a team found on its own | ICT service without a contract, holding recordings of client meetings | Decision, and if allowed: contract, data processing agreement, processing location |
| AI in the underwriting or claims process | May support a critical or important function | The more thorough assessment, including exit and continuity |
The second row is the one most often forgotten. A vendor switches on an AI feature in software that has been in the register for years, and the contract says nothing about it. The register is then formally in order but out of date in practice.
What do you record?
The fields largely match an ordinary AI register: vendor and country, purpose, owner, which data goes in, the risk assessment, the decision with its condition, the date and the review date. DORA adds three that are optional for an ordinary register: whether there is a contract and what it covers, which function the service supports and whether that function is critical or important, and which subcontractors the vendor uses. Whether you need a data processing agreement, and why free accounts rarely come with one, is covered in our article on data processing agreements for AI tools.
The decision field should have four values: allowed, limited use with a condition, no decision yet and not allowed. For a regulated firm, "No decision yet" is not a weakness in the register. It is the honest status of a service that has been spotted but not yet assessed, and it is better than a service that is missing altogether.
How do you know which services exist?
When implementing DORA, a bank asks every department which ICT services it uses. The register ends up with forty vendors. When the bank first looks at which AI domains are opened in the browser, nine AI services turn up, six of which appear in no contract: two chatbots, a transcription tool, a translation service, a PDF summariser and a browser extension that rewrites emails. That is not an incident. It shows that a survey describes what the departments knew about, and that actual use goes further.
Observing this does not have to mean monitoring people. What you need is which domain was opened, how often and whether there is a decision about it. Who opened it is irrelevant to the risk assessment, and very much a matter for the works council and the DPO. Which data you actually need for this is covered in our article on the data you really need to measure AI use.
BeeSensible detects when someone opens an AI tool and sends only the domain, at most once a day per device, with no user ID and no page content. For each tool, the catalogue holds the vendor, the country, the hosting region, the training policy and whether a data processing agreement is available; the organisation records the decision itself from the Inbox. BeeSensible does not fill in the DORA register; it shows which services are not yet in it.
