What belongs in an AI register?

Ask a chief operating officer how many AI systems the company runs and you will usually get an answer about licences. So many seats on a chat assistant, and a pilot in the contact centre. The count rarely includes a screening feature inside the recruitment software, or a summariser a vendor switched on in the CRM during a routine update. Those features shape decisions about people too.

The National AI Centre puts the fix in plain terms. Its guidance for organisations starting out asks them to create and maintain an AI register that documents every AI system and how the organisation uses it. The register covers systems built in-house and systems bought from someone else. It also covers AI embedded in other systems, and the guidance names human resources and customer engagement tools as examples.

One row per use

The guidance makes a point that changes how the register should look. The same tool can create different risks depending on how you use it. Its example compares AI drafting marketing emails with AI assessing job applications. A register with one row per product hides that difference. A register with one row per use shows it.

A second example in the guidance makes the same point about context. A chatbot that answers simple questions during business hours, while a staff member can watch it, is a low-risk use. The risk expands when that chatbot runs around the clock without human oversight and takes on harder questions. That is one product and two rows.

So I build the register around uses. "Chat assistant, enterprise licence" is a procurement entry. "Recruiters use the assistant to summarise CVs before shortlisting" is a use, and it affects candidates who will never see the summary. The second row tells a risk owner where to look, and it tells a team lead what they are answerable for.

Writing uses also flushes out the work nobody thought of as AI. A finance team that "doesn't use AI" may run invoice matching through a tool that scores every exception. A service team may have a chatbot answering after hours. Each of those is a row.

What each row should hold

The guidance spreads its essential practices across six headings, and most of them need a column. I keep the row short enough that a team lead can fill it in without a consultant. These are the fields I would start with.

1. The use, written as a sentence with a verb and a person in it.
2. The system and the supplier, including the case where AI sits inside a product you bought for another job.
3. The person accountable for this use. The guidance asks for a senior leader as the overall owner first, and then a specific accountable person for every AI system as governance matures.
4. The people affected. The guidance asks for a stakeholder impact assessment and tells organisations to pay particular attention to vulnerable or marginalised groups.
5. The result of the risk screen, so anyone can see whether the use needs extra governance attention.
6. What you tell people. The guidance asks organisations to disclose AI use, especially where AI makes or influences decisions about them.
7. How you test the use before launch and monitor it after it goes live.
8. Where a person can pause, override, roll back or shut it down, and who that person is.
9. The date of the next review.

Nine fields sounds like a lot. Most rows are quick once the team knows the use. The slow rows are the ones where nobody can name the accountable person, and those are the rows you most need to find.

Finding what is already running

The hard part is the first pass. Teams rarely know everything their vendors have switched on, and staff who use a personal account at work are unlikely to volunteer it to a governance survey. I would start with the money. Expense claims and card statements show which AI subscriptions people pay for. Procurement can list the contracts renewed in the past year and flag the ones where the vendor now advertises AI features.

Then ask each team a narrower question than "do you use AI?". Ask which tasks a tool now drafts, scores, sorts or answers for them. People describe their work more accurately than their software. A team that says it does not use AI may still tell you the CRM drafts its customer emails.

You do not need a perfect inventory before you begin. The guidance says organisations do not need to do everything at once, and it asks them to adapt each practice to their size and risk profile. Twenty honest rows give a risk owner more to work with than a policy that assumes there are none.

Give the first pass a single owner and a deadline a few weeks out. Teams will happily debate column headings for a quarter. The useful version arrives when someone has to send the sheet to the senior owner by a date, with the gaps marked as gaps.

Keeping it alive

Registers tend to die quietly. One person in risk builds a spreadsheet and circulates it once. The business keeps buying software, and the sheet goes stale by the next quarter.

Attach updates to processes that already run. Make a register entry part of procurement and part of change requests, so no AI feature arrives without a row. Tie each review date to something with consequences, such as a contract renewal or a quarterly risk report. The guidance also asks organisations to keep clear records of the actions they take under each practice, because good documentation supports audits and reviews. A live register is most of that record.

Monitoring belongs in the row as well. The guidance warns that an AI system that worked well last month might start giving different answers after it is trained on more data. A use that was low risk at launch can drift. The review date forces someone to look again, and the row tells them what they are looking for.

Contestability belongs nearby. The guidance asks organisations to set up channels for people to report problems with AI decisions or challenge them. If a candidate or a customer complains, the register should tell you within a minute which use was involved and who owns it.

Who should own it

The register needs an owner with authority. The guidance is direct about the first step: assign a senior leader as the overall AI governance owner, with enough authority and understanding of AI to oversee all AI use in the organisation. That person owns the register as a whole. Each row still needs its own accountable person close to the work. The board question about what accountability requires once a model can act only has an answer when those names exist.

If your organisation already works from a framework such as NIST's, the register is where that framework touches daily work. What the NIST AI Risk Management Framework is for covers how to use it as a set of questions. The register is where you write down the answers for each use.

What to do this month

1. Name the senior owner, and make the register a standing item in a risk meeting you already hold.
2. Pull AI subscriptions from expenses and AI features from vendor contracts, and turn each one into a use with a verb and a person in it.
3. Fill in the accountable person and the people affected for every use before you worry about the other columns.
4. Add a register entry to procurement and change requests so the list grows with the business.

The leadership day of our AI governance workshop covers ownership and intake for AI use cases, and the register is where both land. If you finish the month with a named person beside every use, the rest of your governance has something to hang on.