assurance · Level 3
AI governance: risk registers, evidence and human accountability
Govern an AI system without being an engineer: find and score its hazards, prove its controls, decide who may accept and who may stop, and check the register with a small tested script.

Start with the essentials
The short answer
An AI risk register is a living record of what could go wrong with one AI system: how likely and serious each hazard is, which controls reduce it, what evidence shows those controls work, who owns each risk and who accepted what remains. It supports human accountability. It does not prove compliance, and it does not replace legal, data protection or security advice.
What you will learn
- You will be able to explain what an AI risk register is and is not, and how it fits your existing risk management.
- You will be able to identify hazards across an AI system's lifecycle, from data and prompts to suppliers, drift and end of life.
- You will be able to score likelihood and impact on a written scale, and judge residual risk against a stated appetite.
- You will be able to assign owners, approvers and the right to stop a system, and design human oversight that is more than a rubber stamp.
- You will have built and tested a script that finds missing owners, missing evidence, unapproved risks, bad scores and overdue reviews.
- You will be able to set incident, change and review triggers and write a one-page decision record.
Who it is for
People in UK councils, NHS-adjacent bodies, financial services, defence and critical-infrastructure suppliers, procurement, risk and compliance teams who must govern an AI system they did not build. No machine learning knowledge is needed. The coding chapter needs Python and the ability to run a script from a terminal; the rest needs only a pen or a spreadsheet.
Before you start
- A plain-English idea of how AI chatbots work and why they can be confidently wrong, as in What is AI?. For the coding chapter, enough Python to run a script from a terminal, as in Python: from first script to a useful automation. Privacy and data minimisation in AI applications covers DPIAs and personal data, which this workbook links to but does not repeat.
Read a sample · Chapter 05 of 06
Check your register with code
Registers decay quietly. A small script can check their form, never their truth.
Save this as register.csv in a new folder (plain UTF-8 text): Sampleford's register, with mistakes planted. The PDF wraps long rows; your file needs exactly eight lines, so rejoin any row that copies in pieces. Use a text editor: a spreadsheet can alter dates and separators. In controls and evidence, semicolons separate items; the first evidence item supports the first control. Owners are posts; a real register also names the holder.
id,hazard,stage,likelihood,impact,controls,evidence,owner,residual,review,status,approver
R01,Draft promises a wrong repair date,model,5,3,Officer checks each draft;Dates from policy table,QA sample Sep;Test TP-2,Repairs Manager,6,2026-12-01,open,
R02,Hidden instructions in a tenant message,prompts,3,3,No send or edit rights;Officer checks each draft,Access review AR-7;QA sample Sep,Digital Services Manager,6,2026-11-15,open,
R03,Dangerous defect not flagged urgent,use,3,5,Keyword triage first;Officer checks each draft,Test TT-3;QA sample Sep,Repairs Manager,10,2026-10-15,open,Director of Housing
R04,Drafts sent unchanged without reading,use,4,4,Monthly sample;Unchanged rate to board,TBC,Customer Services Manager,9,2026-10-01,open,
R05,Supplier changes model without notice,supplier,3,3,Notice clause;Regression test,Contract s4;Test TP-2,,6,2026-08-31,open,
R02,Policy knowledge out of date,drift,3,6,Owner signs off updates,Change log CL-12,Repairs Manager,6,2026-10-30,open,
R06,Supplier outage,supplier,3,2,Manual templates,Test BC-2,Digital Services Manager,4,2026-06-30,closed,The checker uses only Python's standard library and changes nothing. Save it as check_register.py beside the register.
"""check_register.py: check the form of an AI risk register. It only reads."""
import csv
import sys
from datetime import date
APPETITE = 8 # invented: a residual score above 8 needs a named approver
TODAY = date(2026, 9, 26) # fixed so the output repeats; use date.today() for real
COLUMNS = ["id", "hazard", "stage", "likelihood", "impact", "controls", "evidence",
"owner", "residual", "review", "status", "approver"]
def items(cell):
"""Split 'a;b' into items; blanks and placeholders such as TBC do not count."""
parts = [p.strip() for p in cell.split(";")]
return [p for p in parts if p.lower() not in ("", "tbc", "none")]
def check(rows):
problems, seen = [], set()
for row in rows:
rid = row["id"]
if None in row or None in row.values(): # extra or missing values
problems.append((rid, "wrong number of values"))
continue
if rid in seen:
problems.append((rid, "duplicate id"))
seen.add(rid)
try:
lik, imp = int(row["likelihood"]), int(row["impact"])
res, due = int(row["residual"]), date.fromisoformat(row["review"])
except ValueError:
problems.append((rid, "unreadable score or date"))
continue
# scores 1 to 5; residual cannot exceed inherent (likelihood x impact)
if not (1 <= lik <= 5 and 1 <= imp <= 5 and 1 <= res <= lik * imp):
problems.append((rid, "score out of range"))
if not row["owner"].strip():
problems.append((rid, "no owner"))
if len(items(row["evidence"])) < len(items(row["controls"])):
problems.append((rid, "a control has no evidence"))
if res > APPETITE and not row["approver"].strip():
problems.append((rid, f"residual {res} above appetite, no approver"))
if row["status"] == "open" and due < TODAY:
problems.append((rid, f"review overdue since {due}"))
return problems
if __name__ == "__main__":
with open(sys.argv[1], newline="", encoding="utf-8-sig") as f:
reader = csv.DictReader(f)
if reader.fieldnames != COLUMNS:
sys.exit("First line must be: " + ",".join(COLUMNS))
rows = list(reader)
problems = check(rows)
for rid, message in problems:
print(f"{rid}: {message}")
print(f"{len(rows)} risks checked, {len(problems)} problem(s)")
sys.exit(1 if problems else 0)Run it from that folder (python3 on macOS and Linux). TODAY is fixed, so your output should match.
python check_register.py register.csv
R04: a control has no evidence
R04: residual 9 above appetite, no approver
R05: no owner
R05: review overdue since 2026-08-31
R02: duplicate id
R02: score out of range
7 risks checked, 6 problem(s)R03 is above appetite but names an approver; R06 is overdue but closed. The script exits with code 1 when it finds problems, so a scheduled job could flag them. A wrong header stops it; a split row or stray comma shows as a wrong number of values.
Now test the checker: each mistake, planted in a clean row, must give exactly one problem. Save this as test_check_register.py and run python -m unittest.
"""test_check_register.py: a clean row passes; each planted mistake is caught."""
import unittest
from check_register import check
CLEAN = {"id": "T1", "likelihood": "3", "impact": "3", "residual": "6",
"owner": "Owner", "controls": "Check", "evidence": "Log", "approver": "",
"review": "2026-12-01", "status": "open"}
MISTAKES = {"impact": "7", "owner": "", "evidence": "TBC", "residual": "9",
"review": "2026-09-01", "status": None} # None: missing value
class CheckTests(unittest.TestCase):
def test_clean_row_passes(self):
self.assertEqual(check([CLEAN]), [])
def test_each_mistake_is_caught(self):
for field, bad in MISTAKES.items():
with self.subTest(field=field):
self.assertEqual(len(check([dict(CLEAN, **{field: bad})])), 1)
self.assertEqual(check([CLEAN, CLEAN]), [("T1", "duplicate id")])
if __name__ == "__main__":
unittest.main()python -m unittest
..
----------------------------------------------------------------------
Ran 2 tests in 0.000s
OKTwo dots, two passes; your time will differ.
Try it yourself · Activity 05
25 minRun it, fix it, add a rule
Find the mistakes by eye, then by script, then fix them properly.
- Read
register.csvand list the mistakes. Run the checker and tests, and compare. - Fix R04 (evidence, approver), R05 (owner; review date only after reviewing) and the second R02 (renumber R07, re-score impact). Rerun.
- Add a rule: owners cannot approve their own risk. Test it by making R03's approver
Repairs Manager.
What can the script never see?
Worked answer
Sample fixes: R04 evidence Sample report Sep;Board paper BP-9, approver Director of Housing; R05 owner Digital Services Manager, review 2026-10-31; the drift row becomes R07, impact 3. Output: 7 risks checked, 0 problem(s). The rule, before the overdue check: if row["approver"].strip() and row["approver"].strip() == row["owner"].strip(): then, indented, problems.append((rid, "owner cannot approve own risk")). With R03 changed: R03: owner cannot approve own risk and 7 risks checked, 1 problem(s). No script sees whether test TT-3 still reflects the live system.
Keep learning
The complete workbook
This workbook is for people in UK public bodies and regulated organisations who must govern an AI system without being machine learning engineers. Using an invented council's AI assistant, you will map hazards across the lifecycle, score and evidence them, assign owners and the right to stop, make human oversight real and check the register with a small tested Python script. It maps the method to NIST, UK government, NCSC, ICO, ISO/IEC 42001 and EU AI Act sources.
- 01What a risk register is, and is notIn the workbook · 1 exercise
First agree what a register is for, and what it cannot do.
- 02Find the hazards across the lifecycleIn the workbook · 1 exercise
A hazard is something that could cause harm. Look at every stage, not only the model.
- 03Score, control and evidenceIn the workbook · 1 exercise
Scores rank risks, but only with a written scale and proved controls.
- 04Owners, decision rights and real oversightIn the workbook · 1 exercise
Registers fail when nobody may clearly decide, or when human review exists only on paper.
- 05Check your register with codeRead here · 1 exercise
Registers decay quietly. A small script can check their form, never their truth.
- 06Triggers, decisions and the frameworksIn the workbook · 1 exercise
A register earns its keep when something breaks, changes or needs a decision.
Also inside: a 10-point checklist, a glossary of 12 terms and 10 questions and answers to test yourself. 6 hands-on exercises, each with a worked answer at the back where the workbook gives one.
No login, no card, no account. Before the download we ask you to follow Mickai (two quick links). Free to download and use for personal learning, study groups and inside your own team. Please do not resell the workbooks or republish them as your own. Link people to trust-agent.ai instead.
Test yourself
Questions and answers
Does keeping an AI risk register make us compliant?
No. A register records risks, controls, evidence and decisions, which helps you show accountability. Whether you comply with a law is a legal judgement, and conformity to a standard is assessed against that standard's own requirements. This workbook is general education, not legal advice. Involve your legal team, your data protection officer and your security team.
Do I need to understand machine learning to govern an AI system?
No. You need to understand the system's purpose, the people it affects, what can go wrong and what evidence shows the controls work. Ask technical staff and suppliers for that evidence in plain words. The ICO says senior management cannot delegate these issues to data scientists or engineering teams, so accountability stays with the organisation.
How is an AI risk register different from a DPIA?
A data protection impact assessment covers risks to people from processing personal data; the ICO says it is legally required where processing is likely to result in high risk, as most AI use is. A risk register covers every risk to the service, including security, supplier, quality and operational risks. They overlap, so each should refer to the other, and your DPO should see both. The privacy workbook in this library covers DPIAs.
Which framework should we follow?
Start with your organisation's existing risk management method, and use the AI sources to fill gaps. NIST's AI RMF gives a structure; DSIT and the AI Playbook give UK public sector context; the NCSC covers security; the ICO covers personal data. ISO/IEC 42001 is a paid management system standard. None of them is a checklist that makes a system safe.
Does the EU AI Act apply to UK organisations?
It can. Article 2 covers providers placing AI on the EU market and providers and deployers outside the EU where the system's output is used in the EU. Whether it applies to you is a question for legal advice. Its dates are in flux: on 26 September 2026 the Commission said high-risk rules now apply from 2 December 2027 or 2 August 2028.
What likelihood and impact scale should we use?
Your organisation's own, if it has one, so that AI risks can be compared with others. If not, a 1 to 5 scale for each, with every step described in plain words and, for likelihood, a frequency. Write the scale down. Scores are ranked judgements, not measurements, so record the reasoning behind each.
What counts as evidence for a control?
Something dated that shows the control operating: a test result, a sample of real outputs checked against the source, an access review, a signed contract clause, a training record. A policy saying a check should happen is not evidence that it does. 'TBC' is not evidence. Evidence should be current enough to reflect the live system.
Is having a human in the loop enough?
Only if the human input is meaningful. The ICO warns about automation bias, and its tests for decisions about people make a good yardstick for any review: a rubber stamp does not count; reviewers need the authority and competence to go against the output without fear of penalty, training, and all the relevant information. They also need time. Measure it, for example with the share of outputs sent unchanged and tests with planted errors.
Who should be able to switch the AI off?
More people than can switch it back on. Name the posts that may pause the system at once, write down how, and say what staff do instead. Restarting should need the owner and specialist advice. NIST asks for mechanisms and assigned responsibilities to disengage or deactivate a system that is not behaving as intended.
How often should we review the register?
On a set schedule and after triggers. NIST asks organisations to decide the frequency of periodic review. The invented Sampleford rule is monthly for risks above appetite and quarterly for the rest, plus an immediate review after an incident, a supplier or model change, a new data source or use, or a worrying metric.
When you have finished
Get your certificate of completion
Type your name and download a certificate for this workbook as a PDF, ready to print or to add to LinkedIn. It is made on your own device, so your name is never sent to us. It is a self-declared certificate, not an accredited qualification.
Learn the language
Key terms
- AI governance
- The laws, policies, institutions, norms and internal processes that set out how decisions about AI are made.
- AI assurance
- Measuring, evaluating and communicating whether an AI system is trustworthy (DSIT's description).
- Risk register
- A living record of a system's risks, with scores, controls, evidence, owners, decisions and review dates.
- Hazard
- Something that could cause harm, such as a wrong reply or a data leak.
- Inherent risk
- The risk score before any controls are applied.
- Residual risk
- The risk remaining after treatment, that is, with controls working.
6 of the workbook's 12 terms. The complete glossary is in the workbook.
Follow the evidence
Sources and checks
Facts last checked: .
Examples in this workbook were run on: Python 3.12.10 on Windows 11; also Python 3.13.5 and 3.14.7 on Linux (standard library only) (2026-09-26).
These workbooks use AI assistance. See how the workbooks are made.
- Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (January 2023)National Institute of Standards and Technology (NIST)
- AI Risk Management Framework (page noting that AI RMF 1.0 is being revised; read 26 September 2026)National Institute of Standards and Technology (NIST)
- Introduction to AI assurance (12 February 2024)Department for Science, Innovation and Technology (GOV.UK)
- Artificial Intelligence Playbook for the UK Government (10 February 2025)Government Digital Service (GOV.UK)
- The Orange Book: Management of Risk, Principles and ConceptsGovernment Finance Function and HM Treasury (GOV.UK)
- Machine learning principles (version 2.0, 22 May 2024)National Cyber Security Centre (NCSC)
- Prompt injection is not SQL injection (it may be worse) (blog, 8 December 2025)National Cyber Security Centre (NCSC)
- What are the accountability and governance implications of AI? (under review after the Data (Use and Access) Act)Information Commissioner's Office (ICO)
- How do we ensure individual rights in our AI systems? (human oversight and automation bias)Information Commissioner's Office (ICO)
- ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system (public description only)International Organization for Standardization (ISO)
- AI Act: regulatory framework for AI (read 26 September 2026)European Commission
- AI Omnibus enters into force (27 July 2026)European Commission
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Articles 2 and 14EUR-Lex (Publications Office of the European Union)
- Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI), amending Article 113 of Regulation (EU) 2024/1689EUR-Lex (Publications Office of the European Union)
Created by Mickarle Wagstaff-Irons - Micky Irons with the Mickai team. Published by Mickai LTD. Last updated 26 September 2026.
NextKeep going
Where to go next
Recommended for you
Privacy and data minimisation in AI applications
Keep personal data under control in an AI feature: UK GDPR principles, DPIAs, roles and transfers, and a redaction pipeline you run and test to see what it misses.
Recommended for you
How to evaluate a new frontier model the day it lands
A ten-step method for judging a new model: primary sources, licence, architecture, hardware, benchmarks, your own tests, safety, jurisdiction and a decision record.
Recommended for you
Open model licences, datasets and deployment obligations
Decide whether you may use, host and redistribute an 'open' model or dataset: licence families, dataset rights, model cards, AI-BOMs, hash checks and a checklist tool.