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, set against a larger reality. This article covers what belongs on that list and how it relates to the GDPR record of processing activities.
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 might be a spreadsheet, a tab in the record of processing activities, a list in a GRC tool or 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 (DPA) 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. Our article on whether an AI register is mandatory under the EU AI Act explains how that works. This article 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 Business, 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 covers it.
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 specific 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 acceptable, 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 regulatory 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 but an honest status. A tool that has been noticed but not yet assessed goes into the register with that status, which is better than leaving it out.
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.
Our guide to approving an AI tool lists the questions for the vendor that help you fill in these fields, and our article on data processing agreements for AI tools explains whether you need a DPA.
How does it relate to the GDPR record of processing activities?
They look alike, and so they often get merged. That is a mistake, because they answer different questions.
The record of processing activities under Article 30 GDPR describes the 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 meet at one point: an AI application that processes personal data. In the record of processing activities, 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 in which half the rows have no use for the other half's columns.
What does a register show, and what does it not?
A register is filled in by people who know about a tool. So it describes what the organisation knows, and actual use is usually 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: nothing had been decided about those two tools. It does mean a register needs a second source, namely which AI tools are actually being opened. Our article on keeping an AI register current explains how to set up that source and keep the register up to date afterwards. Our explainer on shadow AI covers what does and does not count as unregistered use.
In BeeSensible, AI tools seen in the organisation that have no decision yet show up on their own, with no user ID and no content, alongside the AI register where you record the decision per tool. Every tool starts with the status "No decision yet".
