AI Governance: A Practical Playbook
Last updated: 2026-08-14
You have been asked to stand up AI governance. Someone has circulated a set of principles. Someone else wants a committee. Nobody has written down who is allowed to put a model into production, who can switch it off, and who carries the consequence when it fails.
AI Governance: A Practical Playbook
The decision this page helps you make
You have been asked to stand up AI governance. Someone has circulated a set of principles. Someone else wants a committee. Nobody has written down who is allowed to put a model into production, who can switch it off, and who carries the consequence when it fails.
That is the actual decision. Everything else follows from it. This page assumes you want a governance function that produces decisions on a schedule, not a document that sits on an intranet.
Rules of thumb
1. Start from decision rights, not principles. Principles do not constrain behaviour. A director cannot act on fairness. A director can act on a rule that says no model touching benefit eligibility goes live without sign off from the accountable business owner and the data protection lead. Write the decision rights first. Derive the principles later if you still want them.
2. Classify by consequence, not by technology. Tiering schemes built around technology age badly. You will end up maintaining separate rulebooks for generative, predictive, and whatever arrives next. Tier on what happens when the system is wrong: who is affected, whether they can appeal, and whether the effect is reversible. A rules engine that denies a claim deserves more scrutiny than a language model that drafts meeting notes.
3. Every approval carries a stopping condition. Approval without a defined kill criterion is not governance. It is optimism with a signature. Before a system goes live, write down the observable condition under which it comes down, the person authorised to take it down, and the maximum time between detection and removal. If nobody will accept that authority, the system is not ready.
4. Keep one register, not three. Organisations routinely end up with a model inventory in the data team, a risk log in the assurance function, and a project list in the transformation office. The three never reconcile. Pick one system of record. Give it one owner. Make every other view a query against it.
5. Give the governance body a fixed slot. Bodies that meet on demand do not meet. Fix a monthly date. Publish the papers deadline. Hold the meeting whether or not the agenda is full, because a short meeting that happened beats a long meeting that slipped.
6. Set a default decision for silence. Governance stalls when items sit unanswered. Define what happens when a reviewer does not respond within the window. For low tier systems, silence approves. For high tier systems, silence rejects. Ambiguity favours whoever is most willing to proceed without an answer, which is the opposite of what you want.
7. Separate the reviewer from the builder. The person who assesses risk must not report to the person whose delivery date depends on the answer. If the organisation is too small for real separation, escalate the sign off one level rather than pretending the conflict does not exist.
8. Govern the procurement, not just the build. Most AI in your organisation will arrive inside purchased software. Governance that only inspects internally built models will cover a small and shrinking share of actual exposure. Put an AI clause in the procurement template and a screening question in the intake form.
9. Log the decision, not the deliberation. Long minutes discourage attendance and get written after the fact. Record four fields: what was decided, on what evidence, by whom, and what triggers a review. That record is what an auditor, a regulator, or your successor will need.
10. Set the review cadence at the point of approval. Governance decisions decay. Data drifts, vendors change models, the business context moves. Assign every approved system a review date when you approve it. Systems without a next review date accumulate silently and become the bulk of your unmanaged estate within two years.
11. Publish the rules to the people they constrain. A governance framework known only to the governance function generates surprise and resentment at the gate. Publish the tiering criteria and the evidence requirements before anyone submits. Teams will design to the standard if they can read the standard.
12. Measure the function on throughput, not volume of policy. Report median days from submission to decision, the number of systems under review, and the number of overdue reviews. Do not report the number of policies issued. The first set tells you whether governance works. The second tells you whether people have been writing.
The artefact: AI Model Register
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 |
Consequence tiering criteria
| Tier | Test | Requirement |
|---|---|---|
| 4. Critical | Affects rights, safety, eligibility, or livelihood. Effect hard to reverse. | Full review, named accountable owner at director level, pre-agreed stopping condition, quarterly review |
| 3. Significant | Affects individuals materially but with appeal and correction routes. | Full review, semi-annual review cycle |
| 2. Operational | Affects internal process efficiency. Errors visible and correctable in workflow. | Light review, annual cycle, self-attestation against checklist |
| 1. Assistive | Drafting, summarising, search. Human reviews every output before use. | Registration only, no gate |
Approval gate checklist
Before a tier 3 or tier 4 system goes live, the submission shows all of the following:
- Purpose statement and the specific decision affected
- Named business owner who accepts the output in writing
- Evidence of performance on data representative of live conditions, including performance on the smallest affected subgroup you can measure
- Failure mode analysis covering what a wrong output does downstream
- Human role defined and the reviewer given authority to override without escalation
- Stopping condition, named stopper, and maximum time to withdrawal
- Data lawful basis and retention position
- Rollback plan to the prior process, tested
- Next review date
Failure signals
Watch for these. Each one indicates the function is producing paper rather than control.
- The register and reality diverge. Teams can name production systems that do not appear in the register.
- Every submission is approved. A gate with no rejections is a queue, not a gate.
- Governance is consulted after procurement closes. The function has been positioned as a formality.
- The committee spends its time on tier 1 systems. Triage has failed and attention is going to the lowest consequence items.
- Nobody has ever invoked a stopping condition. Either nothing has gone wrong, which is unlikely at scale, or nobody believes they hold the authority.
- The framework has been revised twice and no system has completed a review cycle. Policy writing has replaced operation.
What this does not cover
This page covers the operating mechanics of governance. It does not cover the substantive legal position in your jurisdiction, sectoral regulation, or the specific documentation obligations attaching to high risk systems under any given statutory regime. Establish those with counsel and then encode them into the gate above. The mechanics work for any rule set. They do not tell you which rules apply to you.