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. The policy itself needs one senior owner too, and our guide on whether that should be a chief AI officer or a head of AI covers who can hold it.
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. US banks have one more reference point: their regulators’ revised model risk guidance leaves generative AI to each bank’s own governance, which our guide to SR 26-2 and generative AI covers.
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.

In the Gulf: SDAIA's principles, the UAE charter and Dubai's guidelines

An organisation working in Saudi Arabia or the UAE will be asked how its framework lines up with the national AI ethics instruments as well. Four are worth mapping to the template before anyone asks. None of them replaces a law, and each reaches a different set of organisations.

SDAIA AI Ethics Principles: Published by the Saudi Data & AI Authority in 2025, they apply on their own text to everyone designing, developing, deploying, using or affected by AI systems in the Kingdom. There are seven principles: fairness; privacy and security; humanity; social and environmental benefits; reliability and safety; transparency and explainability; and accountability and responsibility. Systems are graded by risk. High-risk systems must undergo conformity assessments before and after deployment, and unacceptable-risk uses such as social profiling are not allowed. Adopting entities designate named roles: the head of the entity or chief data officer, a compliance officer, a responsible AI officer and an AI system assessor. Registration is optional.
The UAE Charter for the Development and Use of AI: Twelve priorities, as the UAE government portal lists them, among them safety, algorithmic bias, data privacy, transparency, human oversight, governance and accountability, and compliance with treaties and applicable laws. It sets direction rather than controls, and other instruments build on it: the UAE central bank’s AI guidance note asks to be read with it.
The UAE AI Ethics Principles and Guidelines: Issued by the UAE AI Office in December 2022, non-binding, for the public and private sectors. Eight principles, with guidelines that apply only to AI systems that make or inform significant decisions. It separates the AI developer organisation, which builds or tunes a system, from the AI operator organisation, which uses it or decides whether to proceed: in a supplier relationship, the supplier and the client.
Dubai’s AI Ethics Guidelines: Smart Dubai’s toolkit sets four principles (ethics, security, humanity and inclusiveness), guidelines on fairness, accountability, transparency and explainability, and a self-assessment tool for developers. The guidelines are non-binding and, like the federal ones, apply to systems that make or inform significant decisions.

The four Gulf AI ethics instruments, what each asks, and the clauses of the AI policy template on this page that answer it
Dimension	What it asks	Clauses that answer it
SDAIA AI Ethics Principles	Named roles for AI ethics, risk grading, conformity assessments for high-risk systems, human oversight, and fairness metrics monitored in production	1 (accountability and register), 3 (data), 5 (human approval), 6 (testing)
UAE AI Charter	Human oversight to correct errors and bias, a clear account of how systems decide, privacy, and safety, including modifying or removing systems that pose risks	3, 5, 7 (transparency), 8 (switching a system off)
UAE AI Ethics Principles and Guidelines	Fair, accountable, transparent and explainable systems wherever they make or inform significant decisions, with duties split between developer and operator	1, 5, 7, and the supplier checks under clause 3
Dubai AI Ethics Guidelines	People told when significant decisions about them are being made, accountability for those decisions, and a self-assessment tool for developers	1, 5, 7

Sector rules sit on top. A licensed bank or insurer in the UAE works to the UAE central bank's guidance note on AI, and a controller in Saudi Arabia to the impact assessment the Saudi PDPL's Implementing Regulation requires. I would keep one register and one set of controls, and record against each control which instrument it answers, rather than run a separate framework for each country.

This section summarises the instruments as published on 30 September 2026. It is not legal advice.

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.

Clauses 3 and 5 decide most of the design when the documents are contracts, and our guide to AI contract review covers which steps a model can own, what it may see and where a lawyer signs.

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. Software can come later: our guide to what AI governance software does and does not do sets out when a register kept by hand stops being enough.

The register is also the first thing finance asks for once AI shows up on the bill, because it lists what is being paid for and who owns it. Seats, API usage and agent runs are billed on different meters, and our guide to AI spend governance sets out how to budget, cap and charge back each one.

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.

To place one use case on those tiers, our scoring template for a single AI use case rates it on six factors and ends in a decision to proceed, redesign or stop.

Before tiering an agent, check which workflows suit an AI agent at all. Many are better served by a fixed sequence of steps with one model call inside it, which is cheaper to run and easier to control.

If the use has not been chosen yet, our guide on how to choose which process to automate first scores the candidates on value, feasibility and risk, and puts the ones that decide something about a person last.

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.

The data clause reaches suppliers as well as tools. When a supplier that will build or run part of this cannot hand over an independent audit report, our guide to security reviews of AI suppliers without a SOC report sets out what to ask for instead and when to walk away.

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 work inside clients' ISO and SOC 2 compliant environments and build the technical controls a certified management system rests on.

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.

In this topic

How do we run AI safely and meet the rules that apply to us?

AI governance softwareGuide
What does AI governance software do, and when is a documented process enough?
AI spend governanceGuide
How do we forecast, cap and attribute AI spend across seats, tokens and agent runs?
AI contract reviewGuide
What can AI do in contract review, and where does a lawyer still have to sign off?
HIPAA-compliant AIGuide
What makes an AI chatbot or assistant HIPAA compliant, and do ChatGPT and Claude offer a business associate agreement?
SOX controls for AI in financeGuide
Can AI and agents do part of the financial close without creating a SOX control deficiency?
SR 26-2 and generative AIGuide
SR 26-2 replaced SR 11-7 and left generative AI out of scope. What do banks need for their language model systems now?
AI risk assessmentBuyer guide
How do you assess the risk of an AI use case before you build it?

Further

AI governance implementation · The engagement that builds these controls into your estate, during the platform build.
Engagement file D-02 · Confidence-routed human review and fairness gates in CI on a regulated assessment.
Agent proposes, verifier gates · The gate pattern behind clause 5, explained in full.
AI agents for business · Which workflows suit an agent at all, and the controls to set before one goes live.
Reviewing an AI supplier with no SOC report · What to ask a supplier for when your data clause reaches it and it has no audit report.
Chief AI officer or head of AI · Who owns the policy at executive level, and when that needs a new role.

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 enquiries@1aym.com See the engagement files

Last reviewed 30 September 2026 · 1AYM