An AI Governance Framework UK Organisations Will Actually Use

Search for an AI governance framework and you will find something designed for an organisation with a chief data officer, a model risk function and a standing ethics committee. If you have four hundred people and one very busy IT manager, that framework is not going to be adopted. It is going to be downloaded, admired, and quietly forgotten.

The useful version is smaller. What matters is not the number of committees but whether each decision has a clear home, and whether the people making those decisions can actually make them within a week.

What governance is for

Strip away the language and AI governance answers four questions:

• Who decides whether we may use this?
• Who is accountable when the output is wrong?
• How do we know whether it is still working?
• What do we do when it stops?

An organisation that can answer those four in plain sentences is governed. An organisation with a forty-page framework that cannot answer them is not.

The five layers

1. BoardSets risk appetite, approves the highest-risk categories, and receives one page a quarter. Should not be reviewing individual tools.
2. Oversight groupThree to five people meeting monthly. Approves new use cases, maintains the register, escalates what genuinely needs the board.
3. Use case ownersOne named person per live AI use. Accountable for its outputs, its monitoring and its retirement. Not a committee.
4. PractitionersEveryone using AI in their work. Operate inside the policy, report problems, and are accountable for what they put their name to.
5. AssuranceWhoever independently checks that the above is really happening. Internal audit, an external reviewer, or a nominated director in a smaller firm.

Note what is not here. There is no ethics board, no separate model risk function and no AI centre of excellence. For most UK mid-market organisations those are aspirations that consume the energy that should go into the register.

The board layer

The board’s job is risk appetite and nothing more granular. It should state, in writing and in plain English, which categories of AI use are off the table entirely, which need board approval, and which the oversight group may approve alone.

A workable articulation runs something like this: uses that materially affect an individual’s employment, credit, safety or access to a service require board approval; uses that touch client confidential data require oversight group approval; internal productivity uses within the approved tool list need neither.

Then one page a quarter: what is live, what changed, what went wrong, what is coming. A board that receives more than that stops reading it.

The oversight group

This is the layer that does the actual work, and it is the layer most organisations skip, which is why decisions either stall or get made by whoever shouts loudest.

Three to five people. Someone from technology, someone from legal or compliance, someone from the business side, and ideally someone from a function that will be on the receiving end. Meeting monthly for an hour with a standing agenda: new requests, register review, incidents, and horizon items.

Its authority has to be real. If the group can only recommend, everything routes around it within two quarters.

Use case owners

Every live AI use has one named person. Not a team, not a department. A person.

That person is accountable for whether the outputs are fit for purpose, for the monitoring being looked at rather than merely existing, and for saying when the thing should be switched off. When ownership is collective, monitoring gets checked by nobody and retirement happens by accident.

Practitioners

Covered by the AI use policy rather than by the framework. The governance link is that they have a route to raise concerns and a genuine assurance that reporting a mistake promptly is not a disciplinary matter.

Assurance

Someone independent has to check that the register reflects reality, that the monitoring is real, and that the approvals actually happened. In a large organisation this is internal audit. In a smaller one it can be a nominated non-executive or an annual external review. What it cannot be is the same people who run the use cases.

The register, which is the actual product

If you implement one thing from this article, implement the register. Everything else is scaffolding around it.

What and whyThe use in one sentence, and the outcome it is supposed to produce.

OwnerA person's name. If this cell contains a team, the row is not governed.

Data usedWhat goes in, whether it includes personal data, and the lawful basis if it does.

Decision effectDoes this make or shape a decision about a person? If yes, Articles 22A to 22D safeguards apply.

Human reviewWhere a person checks the output, and what they are checking against.

MonitoringThe measure that would tell you it has degraded, and who looks at it.

Approved by, whenWhich layer approved it and on what date. Your audit trail in one cell.

Review dateWhen it gets looked at again, whether or not anything has gone wrong.

A spreadsheet is fine. Governance software is not the constraint, and buying it before you have twenty rows is a way of avoiding the work rather than doing it.

The first time you fill this in you will find uses nobody had recorded, owners who did not know they were owners, and at least one row where the decision effect column produces an uncomfortable pause. That discomfort is the register earning its keep.

Where the standards fit

Two frameworks come up repeatedly, and both are useful as reference material rather than as things to implement wholesale.

ISO/IEC 42001 is the AI management system standard. It is certifiable, which matters if your clients or your procurement process will ask for it. Treat it as a structure to borrow from and a destination to work towards, not a starting point.

The NIST AI Risk Management Framework organises the work into govern, map, measure and manage. It is free, voluntary and genuinely well written. Its main value for a mid-market organisation is as a vocabulary and a checklist for what you might have missed.

Neither is a legal requirement in the UK. What is binding is covered in our piece on what belongs in a UK AI policy: UK GDPR as amended by the Data (Use and Access) Act 2025, the Articles 22A to 22D automated decision safeguards in force since February 2026, your sector regulator’s existing rules, and the Equality Act.

Sequencing it

Trying to install all five layers at once is how these programmes die. The order that works:

1. 01Build the registerFind what is already running, including the unapproved. Owners and decision effects filled in. Weeks one to three.
2. 02Name the groupThree to five people, monthly, with real authority to approve. First meeting reviews the register. Week four.
3. 03Set risk appetiteBoard states what is banned, what needs approval, and what is delegated. One page. Weeks five to six.
4. 04Publish the policyNow it can be specific, because you know what people are actually doing. Weeks seven to nine.
5. 05Run and reviewMonthly meetings happen. First assurance check at ninety days. Then it is business as usual, which is the goal.

Register first is deliberate. Writing policy before you know what is running produces a document that describes an imaginary organisation, and everyone who reads it knows immediately that it does.

How to tell whether it is working

Four signs, none of which involve the framework document:

People ask before they use something new. They only do this when asking is fast and the answer is sometimes yes.

The register matches reality. Spot-check three rows a quarter. If two are out of date, the process is theatre.

Something has been switched off. An organisation that has never retired an AI use is not governing it, it is accumulating it.

A mistake got reported early. The first time somebody flags a problem within an hour instead of a quarter, the framework has paid for itself.

The short version

AI governance in a mid-market organisation is a register, a monthly meeting of five people who can actually decide things, a named owner for every live use, and one page to the board each quarter. Everything beyond that is either scaffolding to add later or someone else’s operating model borrowed wholesale.

Start with the register. It will tell you what the rest of the framework needs to be.

If you want that first inventory built independently, with the decision points and the gaps identified before you commit to a structure, that is the front half of an AI readiness audit.

This article is general information and not legal advice.