How to write an AI policy (with a template)

An AI policy is the top-level document that sets out how your organisation develops, buys and uses AI. Get it right and it is the anchor everything else hangs off: the principles, the rules, the accountability. Get it wrong, or skip it, and every other control you build has nothing to hold onto. The single most important thing to understand is this: an AI policy is not a standalone PDF you write once and file. It is the apex of a system you run. That system is an AI Management System, and the policy sits at the top of it.

Most organisations that “have an AI policy” have something else: a page of generic principles copied from a template, or an acceptable-use notice about ChatGPT, with no owner, no link to what AI they actually use, and no teeth. This post is how to write one that works, grounded in the ISO 42001 standard, aware of the EU AI Act and UK rules, and, at the end, a template you can adapt.

What an AI policy is, and is not

A good AI policy is short, high-level, and approved by leadership. It states your organisation’s intent and the boundaries within which AI may be used. It is the document a regulator, auditor, customer or new employee reads first to understand how you govern AI.

It is not:

• A procedure manual. The policy says “AI systems that affect people get human oversight.” The procedures say exactly how. Keep them separate so the policy stays stable while the detail evolves.
• An acceptable-use notice. Acceptable use is one section of the policy, not the whole thing. Conflating the two is the most common way organisations end up with a policy that governs staff prompts and nothing else.
• A one-off project. A policy that is written once and never reviewed is wrong within a quarter, because your AI use and the rules around it both move.

Think of it as the constitution, not the statute book. It sets direction and principle; the rest of the management system carries the detail.

Where the policy sits in ISO 42001

If you are aligning to ISO 42001, the international standard for AI management, the policy is not optional and it is not vague. The standard treats it in two distinct places, and understanding the difference is what separates a serious policy from a templated one.

Clause 5.2 (the AI policy) is mandatory. It sits under Leadership, and it requires top management to establish an AI policy that:

• is appropriate to the purpose of the organisation and its strategic direction;
• provides a framework for setting AI objectives;
• includes a commitment to satisfy applicable requirements (legal, regulatory and other);
• includes a commitment to continual improvement of the management system;
• is documented, communicated internally, and available to interested parties as appropriate.

This is the structural, non-negotiable part. You cannot exclude it. Notice what it does not say: it does not tell you to write down your stance on bias, data or oversight. That content lives in the second place.

Annex A control A.2.2 (AI policy) describes what the policy should contain. Annex A is the reference set of controls you select from based on your risk (via the Statement of Applicability). The controls that matter here are:

Control	What it covers
A.2.2	The AI policy itself: your approach to AI, reflecting strategy, values and risk appetite, and addressing legal requirements, the risk environment, stakeholder impact, and how deviations and exceptions are handled
A.2.3	Alignment of the AI policy with your other policies (information security, privacy, quality, HR, procurement) so they complement rather than contradict each other
A.2.4	Review of the AI policy at planned intervals and on significant change

The practical takeaway: clause 5.2 is that you must have a policy and the shape it must take; A.2.2 is what goes in it. Most commercial guides blur the two and fold the content requirements into clause 5.2. Keeping them straight is useful, because it tells you the policy has to satisfy a leadership-level structural bar and carry the substantive content the controls describe.

How the policy anchors the rest of the AIMS

The reason the policy matters so much is that everything downstream refers back to it. In an ISO 42001 system the chain runs like this:

• The policy (clause 5.2) sets direction and provides the framework for objectives.
• AI objectives (clause 6.2) must be consistent with the policy, and measurable.
• Roles and accountability (clause 5.3) assign who delivers against the policy and objectives.
• Risk assessment and the Statement of Applicability (clause 6.1) select the controls, proportionate to risk, that put the policy into practice.
• Operation (clause 8) runs those controls day to day.
• Management review (clause 9.3), with control A.2.4, closes the loop and feeds changes back into the policy.

So the policy is not paperwork sitting beside the real work. It is the reference point the real work is measured against. This is also why a policy that floats free of an AI system register and a risk classification method cannot be enforced: there is nothing concrete for its principles to attach to.

The regulatory backdrop your policy has to reflect

A credible AI policy acknowledges the rules that already bind you. You do not need to reproduce them, but the policy should show it is written with them in view and point to where the detail lives.

• The EU AI Act. If you operate in or sell into the EU, two duties already apply: the AI literacy obligation (Article 4) and the outright ban on prohibited practices (Article 5). The heavier deployer obligations for high-risk AI, including human oversight, logging and transparency, land later. Your policy should commit you to the literacy duty now and to classifying systems so you know which obligations will apply.
• UK approach. The UK is principles-based rather than a single AI statute. The government’s five cross-sector principles, safety and robustness, transparency and explainability, fairness, accountability and governance, and contestability and redress, are a sound backbone for a UK policy’s guiding principles.
• Data protection. Under UK GDPR, AI that processes personal data will in most cases need a Data Protection Impact Assessment (DPIA), and the ICO’s AI guidance expects accountability, fairness and transparency by design. Your policy should link AI risk assessment to your existing DPIA process rather than inventing a parallel one.
• NIST AI RMF (if you reference it). The US framework’s Govern function is a useful cross-check: a documented AI policy is the primary evidence for understanding legal obligations (GOVERN 1.1), embedding trustworthy-AI characteristics (GOVERN 1.2), and establishing the risk process through transparent policy (GOVERN 1.4).

What to actually put in it: the sections

Here is the set of sections a genuinely useful AI policy contains. The first group is essential for almost any organisation. The second scales with how much your AI touches people.

Essential

1. Purpose and objectives. Why the policy exists and what good use of AI looks like for you.
2. Scope and a definition of “AI”. Who and what it covers, and what you mean by AI, so the policy does not turn on an undefined term.
3. Guiding principles. Your trustworthy-AI values: safety, fairness, transparency, accountability, human control. Keep them specific enough to guide a decision.
4. Roles and accountability. A named owner for AI governance, plus who owns each system and how issues escalate. This is the single most important line in the document. Ungoverned AI is AI nobody owns.
5. Acceptable use. What people may do with AI, tied to data classification (see below).
6. Prohibited use. The bright lines: what is never allowed.
7. Data, privacy and security. What data may be used with AI, how it is protected, and the link to your data-protection obligations.
8. Human oversight. Where a person stays in control, and for which systems it is mandatory.
9. Risk and classification. That every AI system is classified by risk and gets controls proportionate to its tier.
10. Third-party and procurement AI. How bought AI is evaluated and governed. Commonly left out, and a real gap, since most AI risk now arrives through tools you buy.
11. Training and AI literacy. That people using or overseeing AI are equipped to do so, satisfying the EU AI Act’s Article 4 duty.
12. Incident handling. What counts as an AI incident and how it is reported and fixed.
13. Monitoring and review. How the policy and the systems under it are checked, and how often the policy is reviewed.
14. Compliance and regulatory alignment. The rules you are committing to meet.
15. Enforcement. What happens when the policy is breached. A policy with no consequences is guidance, not a policy.

Scales with people-impact

• Transparency and explainability, and fairness and bias management, become essential the moment AI affects people (hiring, credit, customers) and can be folded into your principles for low-stakes internal tools.

The template

Here is a skeleton you can lift and adapt. Keep the whole thing to a few pages; depth belongs in the procedures the policy points to, not in the policy itself.

AI Policy: [Organisation]
Owner: [Name / role]   Approved by: [Leadership]   Version: [x.x]   Review: [date]

1. Purpose
   Why we have this policy and what we want from AI.

2. Scope and definitions
   Who and what this covers. What we mean by "AI".

3. Principles
   The values that govern our use of AI: safety, fairness, transparency,
   accountability, human oversight. [Tailor to your organisation.]

4. Roles and accountability
   - Accountable owner for AI governance: [role]
   - System owners: responsible for each AI system in the register
   - Escalation: how concerns are raised and decided

5. Acceptable use
   - Data classification rules (what data may be used with which class of tool)
   - Approval route for new AI tools and uses
   - Verification and human review expectations

6. Prohibited use
   The bright lines. [See list below.]

7. Data, privacy and security
   How data is protected; link to data-protection policy and DPIA process.

8. Human oversight
   Which systems require a human in control, and how.

9. Risk management and classification
   Every AI system is registered and risk-classified; controls scale with tier.

10. Third-party and procurement AI
    How bought AI is evaluated and approved before use.

11. Training and AI literacy
    Who is trained, on what, and how often.

12. Incident handling
    What counts as an incident; how it is reported and resolved.

13. Monitoring and review
    How compliance is monitored; when this policy is reviewed.

14. Compliance
    The laws and standards we commit to (EU AI Act, UK GDPR, ISO 42001, sector).

15. Enforcement
    Consequences of breach.

Two rules for using it. First, do not just fill in the blanks and publish. A policy that does not reflect your actual AI use is the most-cited failure mode, and an auditor spots it instantly. Second, govern by data class and use case, not by brand. Do not write “staff may use ChatGPT”; write rules about what data may go into what kind of tool. Models and vendors change monthly; your data classification does not.

Acceptable use: the section that does the most work

If you get one section right, make it this one. Acceptable use is where the policy meets the keyboard, and where most real risk is decided. Build it around data classification:

Data class	What may be used
Public	Any approved AI tool
Internal	Approved enterprise tools only
Confidential / personal / regulated	Not permitted in general-purpose AI, or enterprise-only with explicit approval

Then set out the non-negotiables:

• Enterprise accounts, not consumer ones. Free and personal tiers often grant the provider broad rights over your inputs and may train on them. Prohibit consumer tiers for company work regardless of anyone’s personal subscription, and use enterprise tiers that keep your data in your tenant and do not train on it. Verify the specific contract; terms vary by tier.
• Never paste personal or special-category data, customer or client data, credentials, or proprietary source code into general-purpose AI tools.
• Verify the output. Facts, figures, citations and legal or technical claims are checked by a human before use. AI output is a draft, not an authority.
• Human review before acting, scaled to the stakes: light for an internal memo, thorough for anything customer-facing or consequential.
• Disclose AI use where it matters, and note the EU AI Act’s specific transparency duties (chatbots, deepfakes, synthetic media).
• Route new tools through approval, so shadow AI does not accumulate outside the policy.

A prohibited-use list makes the bright lines explicit: no confidential or personal data in public tools; no sole reliance on AI for decisions about people (hiring, credit, discipline) without oversight; no impersonation or deception; no circumventing security controls.

How to stop it becoming shelfware

A policy’s value is entirely in whether it changes behaviour. Four things decide that:

• A named owner. One accountable person, not “the business”. Without it, no one maintains the policy or enforces it.
• A link to the register. The policy governs the AI in your register. If there is no register, the policy has nothing to point at, and cannot be enforced.
• Teeth. Pair the policy with technical controls (enterprise-account enforcement, data-loss prevention, monitoring) and clear consequences. Policies set expectations; they do not enforce themselves in real time.
• A review cycle. Scheduled review, plus a trigger on significant change (new regulation, new high-risk use, an incident). ISO 42001’s control A.2.4 exists precisely to stop the document going stale.

Common mistakes

• Copy-paste generic policy that does not match your real AI use. The single most common failure, and the most obvious to an auditor.
• Naming tools instead of principles, so the policy breaks the moment a vendor or feature changes.
• No named owner. The policy becomes a document nobody maintains or applies.
• No link to a register or risk process, so the policy floats free of the systems it is meant to govern.
• Blanket bans, which drive AI use underground rather than governing it. Most workers keep using tools they find useful whether or not you ban them.
• Written once, never reviewed. Stale within a quarter.
• No enforcement. Expectations with no consequences do not change behaviour.
• Never communicated or trained, which fails both ISO 42001 and the EU AI Act’s literacy duty.

The minimum viable AI policy

If the full list looks heavy, start where the leverage is. The smallest policy that genuinely governs is: a clear scope and definition, a short set of principles, a named owner, an acceptable-use section built on data classification, a prohibited-use list, a commitment to classify and register every AI system, and a review date. That closes the gaps most organisations have, no ownership, no rules people can follow, no link to reality, and gives you something you can stand behind and build on. The rest is depth you add as your AI use grows.

The short version

An AI policy is the top-level document that governs how your organisation uses AI: its principles, its rules, and above all who is accountable. Under ISO 42001 it is mandatory (clause 5.2) and it is the apex of your AI Management System, with the register, the risk classification and the controls flowing from it. Write it short and high-level, build the acceptable-use section around data classification rather than tool names, give it a named owner and real enforcement, link it to your register, and review it on a schedule. Do that and the policy is the foundation the rest of your governance stands on. Skip it, or copy one in, and everything downstream is built on sand.

Want to know how much of this you already have? The free AI governance readiness assessment gives you a quick, no-email read on your policy and the management system around it in about ten minutes. When you want to write the policy and stand up the system properly, talk to us.

For the full picture, see the AI governance guide.