At an insurer, two spreadsheets sit side by side. One, the register of information, belongs to the risk function and lists the contractual arrangements with ICT third parties, as DORA requires. The other, the AI register, belongs to the DPO. Microsoft appears in both: in one with the contract date, the supported function and subcontractors, in the other as "Copilot, allowed, no client data in prompts". The country of establishment is in both, and wrong in one of them.
That is how one reality turns into two. The registers cover the same vendors but ask different questions: one asks what has been agreed, the other what is used and what has been decided. The answer is not one big register, but one place for each fact, a reference between the lists and a shared source for what is actually opened. Our guide to the AI register covers what it is and which fields belong in it; our article on AI and DORA explains why an AI service is a third-party ICT service under DORA.
What are the two registers about?
The register of information answers the regulator's question: which ICT third parties does this entity depend on, which functions do they support, how critical are those functions and what has been agreed in the contract if something goes wrong? It is a list of dependencies.
The AI register answers the questions that come from the workplace and the DPO: which AI tools do we use, which data goes in, what have we decided for each tool, on what condition and when do we review it? It is a list of decisions.
| Field | Register of information on ICT third parties | AI register |
|---|---|---|
| Vendor, country of establishment | Yes | Yes |
| Contract, term, subcontractors | Yes, the core | Only whether there is one |
| Supported function and whether it is critical or important | Yes, the core | Usually not |
| Which data goes in | Sometimes, in outline | Yes, per tool and per purpose |
| Decision with condition | No | Yes, the core |
| Review and trigger | Contractual milestone | Date plus triggering event |
| Allowed alternative | No | Yes |
| Tools without a contract | Do not fit | Belong in it, with no decision yet |
The last row matters most. A register of contractual arrangements has no room for a service with no arrangement. An AI register does, and must, because that service is precisely the least managed risk.
Where do they overlap, and where do they differ?
The overlap is in the vendor facts: who the vendor is, where it is established, where processing takes place, which subcontractors it uses and whether there is a contract and a data processing agreement. Those facts change when the vendor changes, not when the organisation decides something. So they belong in one place, and the other list refers to it.
What differs is the purpose of each list. The criticality of a function is a risk judgement about the entity; the decision per tool is a policy choice about use. The same vendor can provide a critical service (the policy administration system) and an AI feature the organisation decides on separately (the summariser inside that same application). Those are two rows, each in the register where it belongs, with a reference.
How do you avoid duplicate work?
Three working rules, and they are duller than a new system.
One owner per field. The risk function is the source for contract, function and criticality. The DPO or the CISO is the source for data use, decision and condition. The business owns each tool and answers the questions when it is reviewed. Our article on who is responsible for the AI register sets out who plays which role, and why "the DPO will handle it" does not work.
One procedure per new tool. An AI service that someone spots goes into the AI register with no decision yet. If it is allowed, procurement follows and it enters the register of information with a contract; the AI register then refers to that row. If it is not allowed, the decision and the alternative are recorded in the AI register and it never reaches the third-party register. Nobody enters a tool twice, and the path each tool took stays visible.
One review cycle. A changed contract, a new AI feature from an existing vendor, an incident or a new use triggers a review of both lists at once. Our article on keeping an AI register up to date lists those triggers and how to turn them into a routine.
What feeds the registers?
Both registers describe what the organisation knows. The question neither answers is what falls outside that knowledge.
An insurer has Microsoft in the register of information, with Copilot as the allowed AI, and the vendor of the claims software, which gained a summarising feature in an update. The AI register has four rows. When the organisation looks for the first time at which AI domains are opened in the browser, ChatGPT, Perplexity, a transcription tool and a browser extension that rewrites emails are added. Two of those have no decision yet and none has a contract. Nobody did anything wrong. It shows that a register you maintain describes what you knew, while a register fed by observed use describes what is there.
That observation needs no data about people. Which domain, how often, in which period and whether a decision exists: that is enough to see which row is missing from both lists. Our article on moving from shadow AI to an up-to-date AI register describes the step from observation to an accurate register.
BeeSensible links a catalogue of over 1,000 assessed AI tools to the use observed in the organisation, at domain level only and with no user ID. For each tool, the catalogue already holds the vendor, country, hosting region, training policy and whether a data processing agreement is available; the organisation records its own decision in the AI register. The register of information stays where it is; what BeeSensible adds is the list of services missing from it.
