An AI governance policy is the organisation's rulebook for AI systems: who may approve them, how each one is classified by risk, which controls and gates apply at each tier, how systems are inventoried, monitored and retired, and who answers when something goes wrong. The template below gives model wording for every section, a committee charter and a worked example.
What the policy covers, and what it leaves to the acceptable use policy
An acceptable use policy for staff tells employees which tools they may use and with what data. A governance policy speaks to the organisation: it sets decision rights, risk tiers and the lifecycle every AI system passes through, whether bought, built or switched on inside existing software. Each should point to the other without repeating its clauses.
| Policy section | ISO/IEC 42001:2023 | NIST AI RMF 1.0 | EU AI Act |
|---|---|---|---|
| 1. Purpose, scope, definitions | Clause 4.3 scope | GOVERN 1.1 | Art. 3 definitions |
| 2. Principles | Clause 5.2 AI policy | GOVERN 1.2 | Recitals; Art. 4 literacy |
| 3. Roles and committee | Clause 5.3; A.3.2 | GOVERN 2.1, 3.2 | Art. 26 deployer duties |
| 4. Risk tiers | Clause 6.1.2 | GOVERN 1.3 | Art. 5, Art. 6, Annex III, Art. 50 |
| 5. Approval gates | A.6 life cycle | MAP 1.1; MANAGE 1.2 | Art. 9, Art. 27 |
| 6. AI inventory | A.4 resources | GOVERN 1.6 | Art. 49 registration (high-risk) |
| 7. Monitoring | A.6.2.6 | MANAGE 4.1 | Art. 26(5), Art. 72 |
| 8. Incidents | A.8.4; clause 10.2 | GOVERN 4.3; MANAGE 4.3 | Art. 73 |
| 9. Exceptions | Clause 6.1.3 | MANAGE 1.4 | None specific |
| 10. Review | A.2.4; clause 9.3 | GOVERN 1.5 | None specific |
Article references describe where the duty comes from; they apply only to the roles and systems the Act names. NIST states on its AI RMF page that version 1.0 is being revised under the White House AI Action Plan, so check subcategory numbers before quoting them in an audit (checked 23 October 2026).
The AI governance policy template
Replace the bracketed text, delete what does not apply and keep the numbering, because the other templates in this series refer to it. Legal, risk, security and privacy should review the draft before the board or executive committee approves it.
1. Purpose, scope and definitions
1. PURPOSE, SCOPE AND DEFINITIONS
1.1 Purpose. This policy sets how [Organisation] approves,
classifies, controls, monitors and retires AI systems, so
that AI delivers its intended value within our risk
appetite and legal obligations.
1.2 Scope. All AI systems that [Organisation] develops, buys,
configures or uses, in every business unit and subsidiary
listed in [Annex A], including AI features inside licensed
software and AI agents that act in other systems.
1.3 Definitions.
- AI system: a machine-based system that infers from input
how to generate outputs such as predictions, content,
recommendations or decisions (EU AI Act, Art. 3(1)).
- System owner: the business manager accountable for an AI
system's purpose, risks and results.
- Technical owner: the person accountable for how the
system is built, configured, run and changed.
- Material change: a new model or model version, data
source, tool permission, user group, purpose or vendor.2. Principles
2. PRINCIPLES
[Organisation] commits that its AI systems will be:
2.1 Accountable: every system has a named system owner.
2.2 Lawful: classified under the EU AI Act and assessed under
data protection law before use.
2.3 Proportionate: controls scale with the risk tier.
2.4 Overseen: a competent person can override or stop any
system whose output affects people or money.
2.5 Secure and measured: tested before go-live, after changes
and against agreed thresholds while it runs.
2.6 Transparent: people are told when they deal with AI where
the law or fairness requires it.3. Roles and responsibilities
3. ROLES AND RESPONSIBILITIES
3.1 Executive sponsor [name, role]: approves this policy and the
AI risk appetite; receives the quarterly AI risk report.
3.2 AI governance committee: approves Tier 1 systems, rules on
escalations and exceptions, owns the risk appetite in
practice. Charter in Annex B.
3.3 AI governance lead [name, role]: runs the inventory, the
gates and the committee secretariat; maintains this policy.
3.4 System owner: completes intake and risk assessment, owns
the risk register entries and the decision to go live
within the authority set by the tier.
3.5 Technical owner: maintains the model card, tests, logs and
change records; can suspend the system.
3.6 Information security, data protection officer, legal and
compliance: review at the gates set in section 5.
3.7 Internal audit: audits compliance with this policy at least
every [24] months.| Activity | Committee | Governance lead | System owner | Technical owner | Security | DPO / legal |
|---|---|---|---|---|---|---|
| Classify risk tier | A (Tier 1) | R | C | C | C | C |
| Approve go-live, Tier 1 | A | R | R | C | C | C |
| Approve go-live, Tier 2 | I | A | R | C | C | C |
| Keep the inventory current | I | A | R | R | I | I |
| Monitor performance | I | I | A | R | C | I |
| Lead incident response | I (Tier 1: C) | C | A | R | R | C |
| Grant exceptions | A | R | C | C | C | C |
R = responsible, A = accountable, C = consulted, I = informed.
4. Risk tiers
| Tier | Typical systems | Minimum controls |
|---|---|---|
| 0, Prohibited | Practices banned by EU AI Act Article 5, and uses outside our risk appetite such as [covert monitoring of staff] | Not permitted; exceptions cannot be granted |
| 1, High | Annex III or Annex I high-risk systems; anything that decides or materially shapes decisions on credit, insurance, employment, health or access to services | Full risk assessment, DPIA and FRIA where required, committee approval, model card, named human reviewer, logs kept at least six months, quarterly review |
| 2, Elevated | Customer-facing assistants, agents that write to other systems, systems handling Confidential data, Article 50 transparency cases | Risk assessment, security test, model card, approval gates on consequential actions, half-yearly review |
| 3, Low | Internal drafting, summarising and search on Public or Internal data | Intake record, inventory entry, annual review |
4. RISK TIERS
4.1 Every AI system is assigned a tier at intake and confirmed
at Gate 1. The higher tier applies whenever a system could
fit two.
4.2 A material change triggers re-classification.
4.3 The governance lead records the reasoning for each tier.
For systems that might fall under Annex III, the record
includes whether an Article 6(3) exception was considered
and why it was or was not applied.Use the EU AI Act compliance checker for a first pass on the legal class, then let the AI risk classification agent record the Article 6 and Annex III reasoning in the register. The Annex III obligations apply from 2 December 2027 and the Annex I route from 2 August 2028, the dates set by the Digital Omnibus on AI, Regulation (EU) 2026/1744.
5. Approval gates
| Gate | Question it answers | Evidence required | Who approves (Tier 1 / 2 / 3) |
|---|---|---|---|
| 0, Intake | Is this worth pursuing, and is it allowed at all? | Use case intake form, provisional tier | Lead / lead / system owner |
| 1, Design or purchase | Are the risks understood and the controls designed? | Risk assessment, DPIA screening, vendor questionnaire | Committee / lead / system owner |
| 2, Go-live | Do the controls work? | Test results, model card, oversight plan, register entries | Committee / lead / system owner |
| 3, Periodic review | Is it still performing and still needed? | Monitoring report, incidents, change log | Committee / lead / system owner |
| 4, Retirement | Can it be switched off safely? | Data return and deletion, user notice, archive of records | Lead / lead / system owner |
5. APPROVAL GATES
5.1 No AI system may process production data or reach users
before it has passed Gate 2 for its tier.
5.2 Gate decisions, conditions and approvers are recorded in
the AI inventory.
5.3 A system that misses its Gate 3 review date by more than
[30] days is reported to the committee and may be
suspended.
5.4 Retirement follows the steps in Gate 4; records are kept
for [the retention period in the Records Policy].6. AI inventory
6. AI INVENTORY
6.1 The governance lead keeps one inventory of all AI systems
in scope, including pilots and embedded vendor features.
6.2 Each entry records: ID, name, purpose, system owner,
technical owner, tier, our role under the EU AI Act
(provider, deployer or both), models and versions, data
classes, users, gate status, next review date, and links
to the risk assessment, model card and register entries.
6.3 System owners confirm their entries every [6] months.
6.4 Unregistered AI use is handled as an incident under
section 8.7. Monitoring and evaluation
7. MONITORING AND EVALUATION
7.1 Each Tier 1 and Tier 2 system has metrics, thresholds and
a test set agreed at Gate 2, recorded in its model card.
7.2 The technical owner reports results at the frequency set
by the tier, and immediately when a threshold is breached.
7.3 Logs of inputs, sources, tool calls, outputs and approvals
are kept for [period], and for high-risk systems at least
six months, in storage [Organisation] controls.
7.4 Any material change is re-tested before release.8. Incidents
8. INCIDENTS
8.1 An AI incident is an event in which an AI system causes or
nearly causes harm to people, property, operations, data
or legal obligations. Staff report suspected incidents to
[contact] as set out in the AI Acceptable Use Policy.
8.2 Incidents are handled under the AI Incident Response Plan,
which sets severity levels, the authority to suspend a
system and the deadlines for external reporting.
8.3 Every Severity 1 or 2 incident is reported to the
committee, and its lessons are fed into the risk register.9. Exceptions
9. EXCEPTIONS
9.1 Requests go to the governance lead in writing, stating the
rule, the reason, the risk and the compensating controls.
9.2 The committee decides exceptions for Tier 1 systems; the
governance lead decides others and reports them quarterly.
9.3 Every exception has an expiry date no later than [12]
months, an owner and an entry in the risk register.
9.4 Tier 0 is never subject to exception.10. Review and document control
10. REVIEW AND DOCUMENT CONTROL
10.1 The governance lead reviews this policy every [12] months
and after any new law, regulator guidance, major incident
or change of risk appetite.
10.2 Version [x.y], approved by [executive sponsor] on [date].
Next review due [date].AI governance committee charter
The charter is Annex B of the policy. Keep it to one page so members actually read it.
ANNEX B: AI GOVERNANCE COMMITTEE CHARTER
Purpose Oversee AI risk within the appetite set by
[executive sponsor / board risk committee].
Chair [CIO / CRO / head of AI], with authority to suspend
any AI system pending review.
Members Information security; data protection officer;
legal or compliance; [two or three] business unit
heads that run AI; AI governance lead (secretary).
Internal audit attends without a vote.
Quorum Chair or deputy plus [four] members, including
security and data protection.
Cadence Monthly, plus ad hoc within [48 hours] for a
Severity 1 incident.
Decides Tier 1 approvals at Gates 1 to 3; tier disputes;
exceptions for Tier 1; suspension or retirement of
any system; changes to the risk tiers.
Receives Inventory changes; Tier 2 approvals; open high and
critical register entries; incident summaries;
monitoring breaches; overdue reviews.
Reports to [Executive committee / board risk committee],
quarterly, using the AI risk report.
Records Minutes with decisions, conditions and dissent,
kept by the secretary for [period].
Review Charter reviewed with the policy every [12] months.How to fill it in, and who owns it
- Name the sponsor and the lead first. Without an accountable executive and someone who runs the process, the policy stays a document.
- Take the inventory before you set the tiers. An AI inventory and shadow AI discovery exercise finds what is already in use, including features vendors switched on. Test the tier table against that list.
- Fit the gates to existing processes. Gate 1 can sit inside procurement and architecture review, Gate 2 inside change management.
- Link the instruments. Each gate asks for a document: intake form, risk assessment for one system, model card, register entries, incident plan.
- Train the approvers. Committee members and system owners need a short session on the tiers and their decision rights.
The editable DOCX of this policy, along with the five companion templates in this series, comes in the AI Governance Template Pack offered on this page.
Worked example: a mid-sized insurer
The insurer below is fictional; the classifications show the method, not legal conclusions for a real system.
| System | Tier | Why | What the policy then requires |
|---|---|---|---|
| Pricing model for individual life insurance | 1, High | Annex III point 5(c) lists risk assessment and pricing for natural persons in life and health insurance | Committee approval at Gates 1 and 2, FRIA under Art. 27, model card, named actuarial reviewer, quarterly review |
| Claims-handler assistant that summarises files and drafts letters | 2, Elevated | Confidential data; letters reach customers after review | Risk assessment, prompt-injection test, approval before any letter is sent, half-yearly review |
| Marketing team drafting tool on public product information | 3, Low | Public data, human-edited output | Intake record and inventory entry, annual review |
| Emotion detection on call recordings to score agents | 0, Prohibited | Emotion recognition in the workplace falls under Art. 5(1)(f) | Rejected at Gate 0 and logged |
In its first quarter the committee approved the claims assistant at Gate 2 for a 50-user pilot and sent the pricing model back to Gate 1, because the vendor could not yet show results broken down by customer group.
From policy to framework
An AI governance framework is the whole set of instruments, not one document: this policy plus the staff acceptable use policy, a use case intake form, a risk assessment per system, an organisation-wide risk register, a model card per model and an incident response plan. The AI agent governance and security handbook covers the technical controls that sit underneath them for agents, and the AI readiness assessment shows which of these pieces is missing first.
To draft a first version with your own names, tiers and committee, the AI governance policy generator produces the policy text, a RACI matrix and an approval lifecycle aligned with ISO/IEC 42001.
How VDF AI fits
Gates and tiers are easier to enforce when the platform carries them. VDF AI installs on your own servers, on-premises, in a private cloud or air-gapped, so Tier 1 and Tier 2 systems can use Confidential data without it leaving your environment.
Roles decide which agents, tools and workspaces each group can reach, with role-based access control on every plan, and consequential agent actions can wait for a named approver. Agent configurations are versioned and can be rolled back, the Router enforces the list of approved models per workload, and each execution is logged with identity, model version, retrieved sources and tool calls, exportable to your SIEM as monitoring and audit evidence. The policy, the tiers and the committee’s decisions remain yours.