What is an AI model register?

An AI model register is a single table recording every AI system an organisation runs, with one named owner per system, updated at every approval gate. It is the base record that tiering, approval, review, and incident response all refer to. An institution that cannot list its AI systems cannot govern them.

What fields should an AI model register contain?

The minimum set that survives an audit: a stable system identifier, named business owner and technical owner, a one-sentence purpose statement, a consequence tier, whether the system was built or bought, model and version including vendor identifiers, data sources with lawful basis where personal data applies, the human role of decides, reviews or is informed, an observable stopping condition, who is authorised to stop it, approval date and approver, a mandatory next review date, and incidents to date.

Who should own the AI model register?

One owner for the register itself, and for each entry a named business owner who accepts the output and a named technical owner accountable for operation. Both must be individuals rather than teams, because a team cannot be called to account for a decision.

AI Model Register Template

Last updated: 2026-08-14

An AI model register is a single table listing every AI system an organisation runs, with one named owner per system, updated at every approval gate. The minimum fields that survive an audit are a stable system identifier, named business and technical owners, a purpose statement, a consequence tier, the model and version, data sources with lawful basis, the human role, a stopping condition, who is authorised to stop it, approval and review dates, and incidents to date.

An institution that cannot list its AI systems cannot govern them. The register is the base record that every other governance activity refers to: tiering, approval, review, and incident response all read from it and write back to it.

The template

One table, one owner, updated at every gate. Fields below are the minimum that survives an audit.

Field	Purpose
System ID	Stable identifier used across all other systems
Business owner	Named individual who accepts the output, not a team
Technical owner	Named individual accountable for operation
Purpose statement	One sentence on the decision this system informs or makes
Consequence tier	1 to 4, assigned by the tiering criteria below
Build or buy	Internal, vendor, or vendor component embedded in a wider product
Model and version	Including vendor model identifiers where applicable
Data sources	Systems of origin, plus lawful basis where personal data applies
Human role	Decides, reviews, or is informed
Stopping condition	Observable trigger for withdrawal
Authorised to stop	Named individual and their delegate
Approval date and approver
Next review date	Mandatory field, no null values permitted
Incidents to date	Count and link to records

How to use it

Create one table with one owner. Distributed registers held per department stop reconciling within a quarter.
Populate business owner and technical owner with named individuals, never a team or a role. Accountability that is not attached to a person is not accountability.
Update the register at every gate rather than on a review cycle, so the record and reality do not diverge between reviews.
Treat next review date as mandatory with no null values permitted. A null there is how systems quietly leave supervision.

This template comes from the AI Governance: A Practical Playbook, which sets out the reasoning behind it, the rules of thumb that govern its use, and the signals that tell you the approach is failing. The full playbook is also available as Markdown. See all AI governance templates.