A privacy officer receives a spreadsheet from the head of operations. It is titled "AI register" and has four rows: Copilot, ChatGPT, DeepL and a meeting transcription tool. The same week, someone asks the service desk whether the organisation can take over his subscription to a presentation tool with AI in it, because he has been paying for it himself. That tool appears nowhere.
That is the AI register in one picture: a list of what the organisation knows, next to a reality that is larger. This piece covers what belongs on that list, how it relates to the GDPR record of processing, and why it is never right without a second source.
What do organisations mean by an AI register?
Usually this: an overview of the AI tools and AI applications in use across the organisation, with one row per application saying who is responsible, what it is used for, which data goes in and what the organisation has decided about it. It is an internal working document. It lives as a spreadsheet, as a tab in the record of processing, as a list in a GRC tool or as a module in a product.
The form matters less than the question the register answers: do we know which AI is used here, and have we formed a view on it? An organisation that cannot answer those two cannot explain its policy to employees, cannot sign a data processing agreement for the right tool, and has no answer when a regulator or auditor asks.
One misunderstanding to clear up first: the AI Act does not tell every organisation to keep one universal AI register in a fixed form. There are registration and documentation duties, and they depend on your role and on the systems you deploy. How that works is set out in is an AI register mandatory under the EU AI Act. This piece is about the register organisations keep because otherwise they do not know what is going on.
Tool, application or use case: what is a row about?
Most registers start at tool level, because that is easiest: Copilot, ChatGPT, DeepL. There is a problem with that. A tool says little about risk. Copilot for an internal memo and Copilot for summarising a job interview are the same tool and two very different situations.
So it helps to keep three layers apart.
The tool is the vendor's product: Microsoft 365 Copilot, ChatGPT Team, DeepL Pro. At this layer you record who the vendor is, where data is processed, whether the vendor trains on your data and which agreement sits underneath.
The application is how the organisation has set up that tool for a specific purpose: Copilot in Teams for meeting notes in HR, DeepL for customer correspondence at the service desk. This layer holds the owner, the purpose and the data that goes in. It is where the risk lives, and it is the layer most registers skip.
The use case is the concrete task: summarising a job interview, answering a complaint in English. There are too many use cases to record one by one. They belong in the policy, as examples of what is and is not fine, not in the register.
A workable rule: one row per application, with the tool as a property of that row. One tool then appears several times, and that is exactly right.
Which fields belong in it?
There is no prescribed format. These are the fields that do the work in practice, with the reason for each.
| Field | What you record | Why |
|---|---|---|
| Vendor | Name, country of establishment, where processing takes place, whether it trains on your data | Determines which agreement is needed and which supervisory regime applies |
| Purpose | What the application is used for, in one sentence | Without a purpose there is no assessment and no purpose limitation under the GDPR |
| Owner | The role responsible for the application, not IT | Someone has to answer the questions and drive the review |
| Risk assessment | The outcome, the date and who did it; where personal data is involved, a link to the DPIA | Makes the decision traceable |
| Data use | Which categories of data go in, and which explicitly do not | This is where a memo and a job interview differ |
| Decision | Allowed, limited use, no decision yet, not allowed, plus the condition attached to limited use | This is what employees need to be able to look up |
| Date of assessment | When the decision was taken | An undated decision cannot be defended |
| Review | When the decision is looked at again, and which event brings that forward | Vendor terms change; the decision has to follow |
Two fields deserve a note. The decision should have four values, not two. Between allowed and not allowed sit "limited use" (only with this data, only for this purpose) and "no decision yet". The last one is not a gap in the register, it is an honest status. A tool that has been noticed but not yet assessed is in the register that way, which beats it being absent.
The review is the field most often left empty, and the field that keeps the register alive. Vendors change their terms, a free account becomes a business account, a tool gains a feature that reads documents. A decision from a year ago says nothing about any of that. Set an interval, and write down which events force an earlier review: changed terms, an incident at the vendor, a new kind of data going in.
What to ask the vendor in order to fill the fields is in approving an AI tool: what to ask the vendor. Whether a data processing agreement has to sit underneath is in do you need a data processing agreement for an AI tool.
How does it relate to the GDPR record of processing?
They look alike, and so they often get merged. That goes wrong, because they answer different questions.
The record of processing activities under Article 30 GDPR describes processing of personal data: the purpose, the categories of data subjects and data, the recipients, the retention period and the security measures. It is about data, not about technology. Payroll is in it whether or not AI is involved.
An AI register describes AI systems and what the organisation does with them. A translation tool for public product descriptions belongs in it even though no personal data goes in. A tool with no decision yet belongs in it. It is about the deployment of a technology, not about a processing operation.
The two touch at one point: an AI application that processes personal data. In the record of processing, that application is a processing operation with a recipient (the vendor); in the AI register it is a row with a vendor and a data use. Put a cross-reference in each. More is not needed, and less is wrong: merge the two and you get a register where half the rows cannot fill in the other half's fields.
What does a register show, and what does it not?
This is where the head of operations' spreadsheet breaks down. A register is filled in by people who know about a tool. So it describes what the organisation knows. What is used is a different set, and it is larger.
A municipality has allowed Microsoft 365 Copilot, with a restriction on documents from social services. The register has six rows. An inventory in spring finds Perplexity and ChatGPT in use alongside Copilot, plus three specialised tools: a transcription tool for council meetings, a tool that rewrites policy documents into plain language, and an image generator used by the communications team. Two of those appear nowhere.
That is not an incident. Nobody did anything they were not allowed to, because nothing had been decided about those two tools. What it does show is what a one-off inventory is: a photograph of one moment, taken by asking. Someone who does not know their tool is AI does not report it. Someone paying for it privately does not report it. And someone who started using it last week was not using it yet when the inventory ran. Why that is structural and cannot be fixed by inventorying more often is in why an AI tool catalog ages the moment you print it.
So the register needs a second source: which AI tools are actually being opened in the organisation. Not who, not what is typed into them, only which tools. The difference between that list and the register is the backlog: tools that need a decision. What that set of unregistered tools is, and what does and does not count, is in what is shadow AI.
BeeSensible connects a catalogue of 865 AI tools, each with vendor, country, certifications, training policy and a risk score, to the use observed in the organisation: the extension reports only the domain of an opened AI tool, at most once per day per device, with no user id and no content. An administrator sees which tools still have no decision and records that decision; every tool starts at "no decision yet". More on how that works is on the AI tools page.
