A compliance officer at an insurer is updating the register of information that DORA asks for. The core system is in it, the cloud provider, the CRM, the party that hosts the policy administration. ChatGPT is not, because nobody signed a contract for it. One floor down, three underwriters use it every day to compare policy conditions.
That gap is what this piece is about. DORA asks for the management of ICT risk and of the ICT services that third parties provide. An AI service that employees use is such a service, whether it was procured or found. It belongs in the risk picture, and the question is not whether it belongs there but how much weight it carries and what you record about it. What AI governance means for a supervised firm more broadly is in AI governance for financial services; this piece covers the DORA side.
What does DORA actually ask?
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, DNB and the AFM supervise it. The regulation is about digital resilience, and it does not mention AI separately.
What it does ask, in plain words: a framework to manage ICT risk, with the management body ultimately responsible; reporting ICT incidents; testing resilience; managing the risk of ICT services that third parties provide, with a register of the contractual arrangements with those parties; and sharing threat information. Which requirements apply and how heavily differs per type of entity and per size. The regulation allows for proportionality, and the exact application is a matter for the firm's own compliance and risk functions.
Two of those parts matter for this piece: ICT risk management and the management of third parties. That is where daily AI use lands.
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. That it runs in a browser and that nobody raised a purchase order for it does not make it any less an ICT service. It does make one other difference: there is no contract, so no agreements on availability, data, security, subcontractors or termination. The risk is there; the management is missing.
That is the distinction that makes the third-party register awkward. That register describes contracts. A service without a contract does not fit in it, and so disappears from view while it is the least managed risk. How you keep the two lists side by side without duplicating work is in 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 not on the tool but on the use. The same chatbot that rewrites a memo supports no important function; if it sits in the underwriting process or in claims handling, that becomes a different conversation. What a tool carries in risk and what the use adds to it is in how to assess the risk of an AI tool.
Where does which AI use land?
| 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 falls under that contract, which data it may 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 heavier 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 and factually out of date.
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 moment. 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 is critical or important, and which subcontractors the vendor uses. Whether a data processing agreement has to sit underneath, and why free accounts rarely have one, is in do you need a data processing agreement for an AI tool.
The decision should know four values: allowed, limited use with a condition, no decision yet, not allowed. For a supervised firm, "no decision yet" is not a weakness in the register. It is the honest status of a service that has been noticed and not yet assessed, and it beats a service that is missing.
How do you know which services exist?
A bank asks all departments, when introducing DORA, which ICT services they use. The register then counts forty vendors. When the organisation looks for the first time at which AI domains are opened from the browser, nine AI services come 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. No incident. It shows that a survey describes what the departments knew, and that use goes further than that.
That observation need not be surveillance of people. What you need is which domain was opened, how often, and whether a decision about it exists. Who did it is irrelevant for the risk picture, and very much a question for the works council and the DPO. Which data you really need for that is in which data do you really need to measure AI use.
BeeSensible notices 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. The catalogue keeps, per tool, the vendor, the country, the hosting region, the training policy and whether a data processing agreement is available; the organisation sets the status itself in the AI Tools module. BeeSensible does not fill the DORA register; it shows which services are not yet in it.
