At a housing association the managing director asks the management team who actually maintains the AI register. There is a pause, and then everyone looks at the data protection officer. She says she is happy to review the register, but she has no way of knowing which tools the lettings department started using this month.
She is right twice over. The AI register is the organisation's responsibility, with the board as the final responsible party. Below that it only works in layers: one owner of the register as a whole, an owner per row in the business, IT for the observation, procurement for the contracts, and the DPO as adviser and reviewer. What belongs in the register is covered in an AI register: what it is and what you record in it. This piece is about who carries which part.
Why does the law not name anyone?
Because no law prescribes an AI register in a fixed form, and so no law says who keeps it. The GDPR places accountability with the controller, and that is the organisation. The AI Act addresses Article 4 to providers and deployers, and again that is the employer as a whole, not a department. What the AI Act does require is covered in is an AI register mandatory.
So the split has to come from inside: what is used, for what, under which contract, and whether that is acceptable are four kinds of knowledge that sit with four kinds of people.
Why is "the DPO will handle it" not an answer?
It sounds sensible, and it fails for two reasons.
The first is legal. Article 39 of the GDPR gives the data protection officer an advisory and supervisory task, and Article 38 requires that they can perform it independently, without instructions on the outcome and without duties that lead to a conflict of interests. Making the DPO the owner of the register asks them to supervise their own work. The same argument applies to AI literacy, and it is worked out in who is responsible for AI literacy.
The second is practical, and it is what the DPO at the housing association said. She does not see which tools lettings opens. A register that sits with one person describes what that person knows, and after a quarter that is not enough. Not every organisation has a DPO either; whether one is required depends on what you are and what you process.
Who carries what?
| Role | Task in the register | What is missing when this role drops out |
|---|---|---|
| Board or executive team | Appoints the owner, adopts the policy, carries the final responsibility | Nobody to settle it when two departments want different things |
| Owner of the register (CISO, privacy or compliance team) | The format, the fields, the review rhythm, the link to the record of processing | A register filled in differently per department and complete nowhere |
| Owner per row (the business) | Purpose, data, form of use, and the review of their own row | Rows that stay exactly as they were recorded a year ago |
| IT or the administrator | The observation: which tools are opened. Puts a new tool on no decision yet and brings the decision to the moment of work | A register that only knows what someone reported |
| Procurement or contract management | Account type, data processing agreement, terms and changes to them | A tool marked allowed while the business licence was never signed |
| Data protection officer | Advises on assessments, checks that the register matches the processing, flags what is missing | Nobody who independently says a decision is wrong |
Two rows deserve a note. The owner per row is the one most often left empty, because "IT" or "the CISO" is easier to write. But only the department that uses the tool can say what for and with which data, the two fields where the risk lives. A transcription tool for internal meetings and the same tool for conversations with tenants are two rows with two owners.
The IT row is the other side. IT decides nothing about a tool, but is the only one who can see that the tool exists. A newly observed tool goes on no decision yet, and there IT's task ends. How that split works at review time is covered in how do you keep an AI register up to date.
Who takes the decision per tool?
The organisation. The decision is one of four statuses: allowed, limited use, no decision yet, not allowed. The row owner proposes, based on purpose and data. Procurement supplies the account type and the contract. The DPO advises. The owner of the register records the decision, with a date and a name. For a tool that makes decisions about tenants or employees, the board signs off itself.
What never takes the decision: a risk score, a vendor or a tool. A score is advice. Every tool starts on no decision yet and stays there until someone with a name makes it something else.
What does that look like at the housing association?
The management team splits it in one meeting. The CISO becomes owner of the register as a whole. IT delivers each quarter the list of AI services that were opened, in counts, without names. Procurement delivers per tool the account type and whether a data processing agreement is in place. The DPO reviews every six months whether the register still matches the record of processing.
IT's first list shows why that was needed. Copilot is allowed and is in the register. Alongside Copilot, Perplexity, ChatGPT and a transcription tool turn out to be in use, and two of them appear nowhere. That is not an incident: nothing had been decided about those tools, so nobody broke a rule. They go on no decision yet, and the CISO goes looking for an owner in lettings and in communications. That conversation is the register doing its job.
BeeSensible supports exactly that split. The extension reports only the domain of an opened AI tool, at most once per day per device, without a user id and without content, and matches it against a catalogue of 865 assessed tools. An administrator sees which tools have no decision yet and records the decision the organisation has taken; the product decides nothing itself. More on how that works is on the AI tools page.
