Guide

AI governance framework: a policy template mapped to controls

An AI governance framework has two halves. The policy states the rules in plain language: how the organisation may use AI and who answers for each use. The controls make those rules true in the running systems: who may use which tool, what an AI system may read and change, which actions need a person’s approval, how a change is tested before it ships, and what record is kept, so anyone can check that the rules are followed. A policy without the second half is a statement of intent. This guide gives an eight-clause AI policy template you can copy, and maps each clause to a control, an owner and the evidence an auditor would ask for.

AI governance framework. The policy that states how an organisation may use AI, together with the controls, owners and evidence that make each of its rules enforceable and checkable.

Written by Tayyeb Mahmud, founder and Principal Architect. Claude Certified Architect – Professional · LinkedIn profile of Tayyeb Mahmud

What an AI governance framework contains

A framework that works is short enough to read in one sitting. It has seven parts, and each one should exist somewhere a colleague can point to. A part that only exists in a slide deck is not yet part of the framework.

Policy: The rules, in plain language, approved by someone with the authority to enforce them. The template on this page has eight clauses.
Register of AI uses: Every AI tool and system in use, with its owner, its purpose and the data it touches. A use nobody has recorded cannot be governed.
Risk tiers: A short scale that sets how much control a use needs. A drafting assistant a person reads before sending sits low. An agent that writes to a finance system sits high.
Controls: The mechanisms that enforce each rule: permissions, approval gates, tests and logs. This is the part that changes what a system actually does.
Owners: A named role for each control, not a committee. When a control fails, one person is asked why.
Evidence: The record each control produces as it runs, so compliance is shown from logs and test results rather than from anyone’s memory.
Review: A fixed date to re-read the register, the tiers and the policy, because the tools change faster than policies do.

The published frameworks, and what each one is not

Four published sources are useful reference points. None of them is a ready-made framework for your estate. Each answers a different question, so read each one for what it is.

The UK approach: The UK government’s February 2024 response to its AI regulation white paper set five cross-sectoral principles for existing regulators to apply: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. They sit on a non-statutory basis, which the government said it would keep under review. Where AI processes personal data, UK GDPR and the Data Protection Act 2018 apply as they do to any other processing. The ICO lists innovative technology, including AI, among the criteria that, combined with others, make a data protection impact assessment (DPIA) necessary. Regulations made in April 2026 require the Information Commissioner to prepare a code of practice on AI and automated decision-making, and the ICO says its AI guidance is under review following the Data (Use and Access) Act 2025.
The EU AI Act: Regulation (EU) 2024/1689 is law, built on risk tiers: prohibited practices, high-risk systems, transparency duties, and minimal-risk uses it adds no rules for. It can reach a UK organisation: as first published, its scope includes providers placing AI systems on the EU market and providers and deployers outside the EU whose system’s output is used in the EU. The original eight prohibited practices have applied since 2 February 2025; a ninth, added by the AI Omnibus, applies from December 2026. The European Commission lists the transparency rules as taking effect in August 2026. After the AI Omnibus amendment, which the Commission says entered into force on 27 July 2026, the high-risk rules for areas such as employment and education apply from 2 December 2027, and for AI built into regulated products from 2 August 2028. It is not a management-system standard: beyond the risk management and quality management systems it requires of providers of high-risk systems, it does not tell you how to run governance day to day.
The NIST AI Risk Management Framework: AI RMF 1.0 (NIST AI 100-1, January 2023) is a voluntary US framework organised in four functions: Govern, Map, Measure and Manage. Govern is cross-cutting: it builds the culture of risk management that the other three depend on. NIST added a Generative AI Profile (NIST AI 600-1) in July 2024 and says the framework is being revised. It is not law and not a certification. It is a well-structured list of the questions a risk process should ask.
ISO/IEC 42001: ISO/IEC 42001:2023, published in December 2023, specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. Organisations can be certified against it: in the UK, the accreditation body UKAS granted its first accreditation for certifying AI management systems to the standard in January 2026. It is not a set of technical controls for any one system, and a certificate shows that a management system exists, not that a particular AI system behaves well.

This section describes those instruments as published on 29 September 2026. It is not legal advice. Whether an instrument applies to you, and what it requires of you, is a question for your legal adviser or data protection officer.

Worked example: an eight-clause AI policy mapped to controls

The table takes each clause of the template below and names the control that enforces it, the role that owns the control and the evidence the control leaves behind. The technical controls are the kind we build into client estates: identity, verifier gates, evaluation in CI and audit trails. Change the owners to fit your structure, but keep one owner per control.

Each clause of the AI policy template, with the control that enforces it, its owner and the evidence it produces
Dimension	Control	Owner	Evidence
1. Accountability and register	An AI register listing every AI tool and system with its owner, purpose, data and risk tier. A release check refuses to deploy an AI system that has no entry.	A named executive for the policy; a governance lead for the register	The register’s change history and the release check’s log
2. Approved tools and training	Single sign-on for each approved tool, with access granted from HR-record groups rather than by hand, and only once the training is recorded as complete. Uses the organisation does not permit are listed in the register. New tools go through a short request and review.	IT or platform lead; HR for training records	The approved list, training completion records, group membership exports and the provisioning log
3. Data	Each data class mapped to the tools cleared for it. A vendor’s terms on data use and retention checked before its tool is approved. A DPIA where a use is likely to be high risk.	Data protection officer, with IT	Register entries showing the data class per tool, and the DPIAs
4. Access	Each AI system runs under its own named identity and inherits, from the source systems, the permissions of the person or service it acts for. No shared admin keys.	Platform engineering	Identity configuration in version control, and access review results
5. Human responsibility and approval	For people: the duty to check AI output is taught in the clause 2 training. For systems: verifier gates, deterministic checks on every proposed action. Failed checks, and actions in the approval classes, route to a named approver with the reason attached.	The business owner of the process	Training completion records, and gate logs: the proposed action, the checks run, the approver and the time
6. Testing	An evaluation suite runs in CI on every change to a prompt, model, tool or rule. A release is blocked when a score falls below its agreed threshold.	The engineering lead for the system	CI run history with the scores for each release
7. Transparency	Disclosure text where people interact with an AI system, and labels on AI-generated content where it matters to the reader, checked in release review.	The product owner	Interface tests that assert the disclosure is present
8. Incidents and review	A reporting route anyone can use, a switch that turns off each AI capability, a rollback path, and a fixed review date for the register and the tiers.	The service owner; the governance lead for the review	The incident log, switch tests and review notes

Two published figures show parts of this shape. One runs in production: at a large international marketing agency, access to two tools is provisioned from the HR record across more than 600 groups and more than 1,000 users, so access ends when somebody’s record changes (engagement file D-04). The other is a threshold as built: on a government-accredited EdTech’s speaking assessment, the confidence gate is set to route about 15% of interviews to a human examiner, with a further 5% audited at random, and the rollout is staged behind controls (engagement file D-02).

Until these controls are built in your own estate, the table is a starting design, not a claim about your results. Not every use needs every row. A read-only assistant over public documents needs the register, approved access and logging; the gates earn their cost once a system can write to something that matters or handles personal data.

AI policy template you can copy

Eight clauses, written to be adopted as they stand or edited. Replace the bracketed text. Keep the register and the review date even if you cut everything else: without them, nobody can say what the policy covers or when it was last true. It is a starting point, not legal advice.

AI use policy

Organisation: [name]
Policy owner: [executive role]
Approved by: [board or committee]
Effective from: [date]
Next review: [date, no more than 12 months away]

Scope. This policy covers every use of AI by our staff, contractors and systems acting for [organisation], including AI features inside tools we already use.

1. Accountability and register. [Executive role] owns this policy. Every AI tool and system in use is recorded in the AI register with its owner, purpose, the data it uses and its risk tier. No AI system goes live without a register entry.

2. Approved tools and training. Staff use only AI tools on the approved list, signed in with company accounts, and complete [training] before access is granted. AI is not used for [uses the organisation does not permit]. Requests for a new tool go to [role], who decides within [number] working days.

3. Data. Personal, confidential and client data is entered only into tools approved for that class of data. A data protection impact assessment is completed before any use that is likely to be high risk.

4. Access. Every AI system acts under its own named identity, with no more access than the person or service it acts for.

5. Human responsibility and approval. People remain responsible for anything they send, publish or decide using AI output, and check it first. An AI system may propose, but a named person approves, any action that moves money, changes a record of consequence, or affects a person’s rights, employment or access.

6. Testing. No change to a prompt, model, tool or rule reaches users until it passes the tests agreed for that system. Test results are kept for [period].

7. Transparency. People are told when they are dealing with an AI system, and AI-generated content is labelled where it matters to the reader.

8. Incidents and review. Anyone can report an AI error or misuse to [contact]. [Role] can switch off any AI system. The register, the risk tiers and this policy are reviewed by the date above.

Putting it in place: the register first, then the risky uses

Start with the register, because every other clause refers to it. Compiling it is also how unapproved use comes to light, and that is better treated as information about what people need than as a breach.

Then tier the uses and build controls for the top tier first. An agent that can write to a finance system or change somebody’s access needs identity, gates, tests and logs before it runs. A drafting assistant a person reads before sending needs far less, and spending the same effort on both slows everything down.

Build the controls during the platform build, not after it. Retrofitting identity, gates and logging onto a running system costs more than designing them in. Where data residency is a requirement, as it can be for Gulf deployments, record the region of each store and each inference endpoint separately, because where data rests and where inference runs are different facts.

For engineers: architecture, controls and evidence

The worked example in engineering terms. Each item is a control a reviewer can test by reading configuration or logs, not by asking someone.

Identity: Each agent runs as its own service principal. Where the source system supports delegation, tool calls carry the end user’s identity. Entitlements come from the source system, not from a second access list.
Verifier gates: Every proposed write passes deterministic checks: schema, business rules, reconciliation against the system of record, and idempotency. A failed check holds the action and routes it to review with the reason.
Evaluation in CI: Prompts, model versions, tool definitions and rules live in the repository. Each change runs a regression suite with recorded thresholds, and a breach fails the build.
Audit trail: Each gate writes a structured record: input reference, model and prompt version, check results, approver and timestamp. Store it append-only, with a stated retention period.
Register as code: Keep the AI register as structured data in version control. A release check fails when a service calls a model endpoint that has no register entry.
Residency: Record the region of every store and every inference endpoint. Data at rest and inference location are separate facts, and a residency claim needs both.
Switches and rollback: Put each AI capability behind a flag that turns it off without a deploy. Use dry-run modes, so a change can be inspected before it lands.

Sources

Frequently asked questions

What is the difference between an AI policy and an AI governance framework?

The policy is the rules. The framework is the rules plus the register, the risk tiers, the control that enforces each rule, the owner of each control and the evidence each control produces. An organisation can have a good AI policy and no framework, and it usually finds out the first time someone asks what stops a particular system from breaking a particular rule.

Can we use this AI policy template as it stands?

As a starting point, yes. Replace the bracketed text, map the roles to your own structure, and check the data and transparency clauses against your legal obligations with your adviser. The clauses are deliberately short, because each one has to become a control that someone can test.

Do we need ISO/IEC 42001 certification?

None of the other instruments on this page requires it. It is worth considering when customers or tenders ask for it, or when you want an external audit of how AI is managed. It certifies a management system, so it sits above the technical controls rather than replacing them. We hold no ISO or SOC certification ourselves, and we do not certify anyone.

Does the EU AI Act apply to a UK company?

It can. As first published, its scope includes providers placing AI systems on the EU market wherever they are established, and providers and deployers outside the EU where the output of their AI system is used in the EU. A UK company selling into the EU, or whose system’s output is used there, should take legal advice on its position. This page is not that advice.

Who should own AI governance?

One named executive owns the policy and answers for it. Each control is owned by the team that runs the system it protects, because that team can change it. A committee can review the register, but a control owned by a committee has nobody to ask when it fails.

Further

AI governance implementation · The engagement that builds these controls into your estate, during the platform build.
Agent proposes, verifier gates · The gate pattern behind clause 5, explained in full.
Gulf AI data residency · Where residency is a requirement: the three questions to ask of every store and endpoint.
Engagement file D-04 · Access provisioned from the HR record, with dry runs, an audit trail and a way back from a bad run.
Engagement file D-02 · Confidence-routed human review and fairness gates in CI on a regulated assessment.

We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.

Book a 30-minute call tayyeb@1aym.com See the engagement files

Last reviewed 29 September 2026 · 1AYM