How to Build an AI Risk Register for a Small Business (With Template)

A fifty-page AI policy that nobody reads protects nothing. A one-page risk register that four people have actually looked at protects quite a lot, and it takes an afternoon.

This is the format we use with clients, why each column exists, and what tends to go in it. It works whether or not you are in scope of any particular regulation, because the point is not compliance. The point is that somebody has thought about what could go wrong before it does.

This article is part of our guide to the EU AI Act for UK businesses.

Why a register rather than a policy

A policy says what people should do. A register says what could go wrong, how likely it is, how bad it would be, and who is dealing with it.

Policies are written to be shown to someone. Registers are written to be used. If you only have the appetite for one document, make it the register, because the policy can be derived from it later and the reverse is not true. When you do want the policy, writing an AI use policy for a small business has a template.

The columns

Seven, and no more. Every extra column halves the chance the register is ever updated.

Column	What goes in it
What	The AI system, named plainly. "ChatGPT, used by the marketing team", not "generative content capability"
What could go wrong	One concrete sentence, describing an event rather than a category
How likely	Low, medium, high. Resist numeric scores, they invent precision you do not have
How bad	Low, medium, high. Judge by worst realistic outcome, not worst conceivable
What we do about it	The actual control. Something a person does or a setting that is switched on
Who owns it	A person's name. Not a department
Last reviewed	A date

That is it. If a column does not change a decision, it does not belong.

What usually goes in it

The same handful of entries appear in nearly every SME register, and they are rarely the ones people expect. Here is a filled-in example for a professional services firm of around sixty people.

Staff paste client information into public AI tools. Likelihood high, impact high. Control: approved tool with business terms and training switched off, plus a rule on what can never go in, plus training with real examples. Owner: operations director.

This is the most common real incident in UK SMEs and it does not appear in most vendor-authored templates, because no product fixes it.

Generated content contains something untrue about our services. Likelihood medium, impact medium. Control: named human sign-off before anything is published. Owner: marketing manager.

Chatbot tells a customer something we then have to honour. Likelihood low, impact high. Control: bot restricted to published information, escalates on anything about price or terms, transcripts reviewed weekly. Owner: customer service lead.

AI-assisted shortlisting disadvantages a protected group. Likelihood medium, impact high. Control: human reviews every rejection, criteria documented, outcomes checked quarterly against protected characteristics. Owner: HR lead.

Under UK law this is the one most likely to produce a genuinely expensive problem. See AI regulation in the UK.

A supplier changes their AI terms and our data is used for training. Likelihood medium, impact medium. Control: annual terms review on the three tools that matter, business tier where available. Owner: whoever owns supplier relationships.

We become dependent on one AI supplier. Likelihood medium, impact medium. Control: exports kept in a format we control, no process built where only one vendor's output works. Owner: operations director.

Nobody can explain how a decision was reached. Likelihood medium, impact medium. Control: for any decision affecting an individual, record the inputs and the reasoning at the time. Owner: department head.

Seven entries. Most SME registers land between five and twelve.

How to actually build it

Get four people in a room for ninety minutes. Someone from operations, someone who uses the tools daily, someone who owns customer relationships, and whoever makes decisions. Daily users matter most; they know what is really happening.

Start by listing tools, not risks. Including the ones nobody approved. Ask "what are you actually using" and make it clear this is not a disciplinary conversation, because the shadow tools are the ones carrying the risk. See shadow AI.

For each tool, ask what the worst plausible Tuesday looks like. Plausible, not catastrophic. You want the thing that could genuinely happen this month.

Write the control before scoring. Scoring first leads to arguing about whether something is medium or high. Writing the control first usually reveals that the score does not matter, because the fix is cheap either way.

Name owners in the room. An owner assigned in their absence is not an owner.

Diarise the review. Twice a year, thirty minutes. Put it in the calendar before anyone leaves the room.

The template

Copy this into a document or a spreadsheet and fill it in.

AI RISK REGISTER
Business:                         Last full review:
Reviewed by:                      Next review due:

# | What (system + who uses it) | What could go wrong | Likely | Impact | Control | Owner | Reviewed
1 |                             |                     |        |        |         |       |
2 |                             |                     |        |        |         |       |
3 |                             |                     |        |        |         |       |

SYSTEMS CONSIDERED AND JUDGED LOW RISK
(list them, so it is clear they were considered rather than missed)

DECISIONS TAKEN
- EU AI Act scope assessed on [date]. Conclusion: [in/out], because [reason].
- Approved tools: [list]. Tools not approved: [list].

The last two sections matter more than they look. Recording what you considered and rejected is what distinguishes a business that made a decision from one that never asked.

Key Takeaways

• A one-page register that gets used beats a long policy that does not. Seven columns, no more.
• Use low, medium and high rather than numeric scores. Numbers imply precision you do not have.
• The most common real risk in a UK SME is staff pasting confidential information into public tools. No product fixes it, which is why vendor templates omit it.
• Write the control before scoring the risk. It usually makes the argument about scoring irrelevant.
• Record what you considered and judged low risk. Evidence of a deliberate decision is most of the value.

Frequently Asked Questions

How long should this take to produce?

Ninety minutes for the first version with the right four people in the room, plus an hour to write it up. If it is taking days, the scope has drifted into policy writing.

Do we need this if we are out of scope of the EU AI Act?

Yes, and arguably more so, because there is no external framework prompting you. UK GDPR, discrimination law and consumer protection all apply regardless, and the operational risks are identical either way.

Who should own the register overall?

Whoever owns operational risk generally. In a business under a hundred people that is usually the operations director or the owner. Giving it to IT is a common mistake, because most of the entries are about human behaviour rather than technology.

What if a risk has no good control?

Write that down. An honest "no effective control, accepted by [name] on [date]" is a legitimate entry and far more useful than inventing a control that nobody performs. It also makes the risk visible at the next review, which is when someone usually thinks of a fix.

---

Want help building a register that fits your business rather than a template that fits nobody? Talk to Halo Technology Lab. Our strategy and scoping service includes the workshop above.