How to Build an AI Risk Register for a Small Business
Last updated:
Why a register beats a policy on its own
Most small businesses that have done anything about AI risk have written a policy. The policy says staff must not paste customer data into public tools, must check outputs, must ask before buying anything. It is signed, filed and forgotten.
A policy says what should happen. A risk register says what could actually go wrong in your business, with your tools, and what is stopping it. It is the difference between a rule about driving carefully and knowing which of your vans has worn brakes.
You need both. If you do not yet have the policy, our guide to writing an AI policy is the place to start. This post is the register that sits beside it.
The columns that earn their place
Resist the enterprise template with thirty columns. Nobody at a 25-person firm maintains it. These eight are enough:
| Column | What goes in it |
|---|---|
| AI use | The specific use, not the tool. 'Drafting quote emails in the sales inbox' rather than 'Copilot'. |
| Risk | One concrete failure, in a sentence. One row per risk, so a use may have several rows. |
| Likelihood (1-3) | Rare, possible, likely. Three points is enough to force a decision. |
| Impact (1-3) | Annoying, costly, serious. Define each in money or harm terms once, at the top. |
| Score | Likelihood times impact. Anything 6 or above gets attention this quarter. |
| Control | What currently prevents or catches it. 'None' is an honest and useful answer. |
| Owner | One named person, not a department. |
| Next review | A date. |
We use a three-point scale on purpose. Five-point scales invite endless debate about whether something is a 3 or a 4, and that debate is where registers go to die.
The risks small businesses actually face
Generic AI risk lists are full of existential concerns and algorithmic discrimination at national scale. Those matter, but a typical small firm's real exposure is more mundane. These categories cover most of what we see:
- Data leakage. Client or personal data pasted into a tool whose terms allow retention or training, or a staff member using a personal account.
- Confident wrong output. A drafted email quoting the wrong price, a summarised contract missing a clause, an extracted invoice total with a transposed digit.
- Unreviewed automation. Output that reaches a customer or a ledger with no human in between.
- Vendor dependency. A tool the business now relies on changes price, changes behaviour after a model update or shuts down.
- Unfair decisions. AI involved in hiring, lending, pricing or access to services, where a pattern of bad outcomes could hurt people and break the law.
- Shadow tools. AI in use that nobody approved and nobody knows about. Our piece on shadow AI at work covers how to find it without a witch hunt.
- Intellectual property. Generated text or images used commercially where rights are unclear.
Three worked rows from an illustrative accountancy practice
Take a 20-person accountancy practice. It uses a general AI assistant for drafting, an extraction tool that reads receipts into its bookkeeping software, and a transcription tool in client meetings. Three rows from its register might read like this:
| Use | Risk | L | I | Score | Control | Owner |
|---|---|---|---|---|---|---|
| Receipt extraction | Wrong VAT amount posted to a client's return | 2 | 3 | 6 | Human review of items over a threshold; monthly sample check | Bookkeeping lead |
| Drafting client emails | Client financial details entered into a personal AI account | 2 | 3 | 6 | Business accounts only; SSO; policy training | Practice manager |
| Meeting transcription | Recording without client consent | 1 | 2 | 2 | Consent line in engagement letter; verbal check at start | Partner |
Notice the first row's control. It is specific enough that someone could check it is actually happening. 'Staff check outputs' would not be. Vague controls are the most common weakness in registers we review, because they look reassuring and prevent nothing.
How to fill it in without a week of workshops
- List every AI use. Ask each team lead for five minutes, and check expense claims and software invoices for tools nobody mentioned.
- For each use, ask one question: what is the worst realistic thing that happens if this output is wrong, leaks or stops?
- Write that as a risk row. Add a second row only if there is a genuinely different failure.
- Score quickly. If two people disagree by more than one point, take the higher score and move on.
- Write the control that exists today, not the one you intend to add.
- For anything scoring 6 or more with a weak control, write one action with a date.
An owner and an operations lead can produce a first version in an afternoon. It will be imperfect, and an imperfect register that exists is worth more than a thorough one scheduled for next quarter.
Keeping it alive
Registers fail by going stale. Three habits prevent that. Review it quarterly in an existing management meeting rather than a new one. Add a row before any new AI tool goes live, as a condition of purchase. And revisit a row whenever something goes wrong, even a near miss, because incidents are the best evidence you will get about likelihood.
If you use AI in hiring, credit or insurance decisions and have EU exposure, the register also becomes the starting point for the documentation the EU AI Act's high-risk rules expect. It will not be sufficient on its own, but it is the right foundation.
When a register is overkill, and when it is not enough
A five-person business using one AI writing assistant does not need a register. A paragraph in the policy covering data and review is proportionate.
At the other end, if AI makes or heavily shapes decisions about people, or your automated systems post transactions without review, a spreadsheet register is necessary but not sufficient. You will want proper logging, evaluation against real cases and monitoring. That is engineering work, and it is the kind of thing we build at SpiderHunts as part of AI integration projects, so the controls in the register are enforced in code rather than hoped for.
Frequently asked questions
What is an AI risk register?
How often should an AI risk register be reviewed?
Can we add AI risks to our existing risk register?
Who should own the AI risk register?
Want a second pair of eyes on your AI risks?
Share your draft register, however rough. We will point out the risks we see most often in businesses your size and the controls that are cheap to put in place.
Related services
What we build for problems like this one