At an insurer, two spreadsheets sit side by side. One is called register of information and belongs to the risk function: the contractual arrangements with ICT third parties, as DORA asks. The other is called AI register and belongs to the DPO. Microsoft is in both. In one with contract date, supported function and subcontractors, in the other with "Copilot, allowed, no client data in prompts". The country of establishment is in both, and wrong in one of them.
That is how two realities grow out of one. The two registers cover the same vendors from a different question: one asks what has been agreed, the other what is used and decided. The answer is not one big register, but one place per fact, a reference between the lists, and a shared source for what is actually opened. What an AI register is in general and which fields belong in it is in AI register: what it is and what to record; why an AI service is a third-party ICT service under DORA is in AI and DORA.
What are the two registers about?
The register of information answers the supervisor's question: which ICT third parties does this entity depend on, which functions do they support, how critical are those functions, and what is contractually arranged if something goes wrong. It is a list of dependencies.
The AI register answers the question from the workplace and the DPO: which AI tools do we use, which data goes in, what have we decided per tool, under which condition, and when do we look at that again. 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 moment | Date plus event |
| Allowed alternative | No | Yes |
| Tools without a contract | Do not fit | Belong in it, on no decision yet |
The last row matters most. A register of contractual arrangements cannot hold a service with which there is no arrangement. An AI register can, and must, because that service is exactly the least managed risk.
Where do they overlap, and where not?
The overlap sits 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 does not overlap is the reason for 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) 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 agreements, 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 at review. Who carries which role, and why "the DPO will handle it" does not work, is in who is responsible for the AI register.
One route per new tool. An AI service that is noticed goes into the AI register on 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 sit in the AI register and it never reaches the third parties. Nobody enters a tool twice, and the path each tool took stays visible.
One rhythm for review. A changed contract, a new AI feature at an existing vendor, an incident or a new use are triggers for both lists at once. Which triggers those are and how you turn them into a rhythm is in how do you keep an AI register up to date.
Where does the source come from?
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 has had a summarising feature since an update. The AI register counts four rows. When the organisation looks for the first time at which AI domains are opened from the browser, ChatGPT, Perplexity, a transcription tool and a browser extension that rewrites emails join them. Two of those have no decision yet and none has a contract. Nobody did anything wrong. It shows that a register you update describes what you knew, and that 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. What the step from observing to a register that is right looks like is in from shadow AI to a current AI register.
BeeSensible links a catalogue of 865 assessed AI tools to the use observed in the organisation, at domain level only and with no user id. Per tool, the vendor, country, hosting region, training policy and whether a data processing agreement is available are already in the catalogue, and the organisation records the decision itself in the AI Tools module. The register of information stays where it is; what BeeSensible adds is the list of services missing from it.
