AI policy template and implementation guide

Why most AI policies fail before they are read

The typical first draft of an AI policy is a page of principles — fairness, transparency, accountability, human-centricity — and nothing an employee can act on at 4pm on a Thursday with a deadline. Principles are necessary as a framing device, but they answer none of the questions people actually have: can I paste this contract into an assistant, can I ship a feature that scores applicants, and who do I ask when I am unsure?

A policy earns its keep by removing ambiguity. That means naming the specific tools you have approved, listing the data categories that may never leave your tenancy, defining what counts as a high-risk use, and naming the person who decides in edge cases. Everything else — model cards, evaluation protocols, retention schedules — sits in supporting procedures the policy references.

The second failure mode is scope creep. Teams try to write one document covering internal productivity tools, customer-facing AI features and machine learning in the product, and the result satisfies nobody. Write one policy that covers all AI use at a principles-and-guardrails level, then attach separate procedures for product AI and workplace AI.

The AI policy template: section by section

Use the structure below as your drafting skeleton. Each heading maps to something an ISO 42001 auditor, an enterprise procurement reviewer or a data protection regulator will look for, and each can be written in a few short paragraphs.

Resist the urge to add sections. A policy with nine tight headings is auditable; a policy with twenty-four is a document nobody updates after its first approval.

• 1. Purpose and scope — what the policy covers (all AI, including embedded features in existing SaaS), who it applies to (employees, contractors, suppliers) and what it excludes.
• 2. Definitions — 'AI system', 'generative AI', 'high-risk use', 'personal data', 'confidential data'. Borrow the EU AI Act's definition of an AI system to stay defensible.
• 3. Roles and accountability — the named policy owner, the approval authority, who maintains the AI inventory, and who staff contact with questions.
• 4. Permitted use — an explicit list of approved tools and approved use cases, plus the process to request a new tool.
• 5. Prohibited use — the hard lines: no confidential or personal data in unapproved tools, no fully automated decisions affecting individuals, no AI-generated code shipped without human review, no covert use in customer interactions.
• 6. Risk classification — the four tiers and what each tier triggers (see the next section).
• 7. Data handling — training-data provenance, whether vendor retention or model training on your prompts is permitted, and where outputs may be stored.
• 8. Human oversight — where a human must review, approve or be able to override an AI output, and how that review is evidenced.
• 9. Monitoring, incidents and review — how AI use is monitored, how staff report AI incidents, and the review cadence.

Risk tiers: the part that makes the policy workable

A single uniform control set is why governance gets a reputation for slowing teams down. Tier your AI uses and apply proportionate controls, so a marketing team drafting copy is not subject to the same gate as a model that influences hiring or credit decisions.

The four tiers below deliberately mirror the EU AI Act's structure, which means the classification work you do for internal governance also feeds your regulatory position if you sell into or operate in the EU. It also maps neatly to ISO/IEC 42001's requirement to assess AI risks and impacts across the system lifecycle.

• Prohibited — social scoring, emotion inference in the workplace, covert manipulation. Blocked outright; no approval route exists.
• High risk — AI that materially affects a person's rights, safety, employment, finances or access to services. Requires a documented impact assessment, named human reviewer, bias testing and leadership sign-off before deployment.
• Limited risk — customer-facing AI where the person interacts with or receives AI-generated output. Requires disclosure, an escalation path to a human, and output logging.
• Minimal risk — internal drafting, summarising, code assistance on non-sensitive material. Requires only the baseline rules: approved tool, no prohibited data, human review before anything is published or shipped.

A 90-day implementation plan

Policies fail in implementation far more often than in drafting. Treat the rollout as a small project with three phases, a named owner and a defined artefact at the end of each phase.

Weeks 1–3: draft and approve. Run a two-hour workshop with engineering, legal or DPO, security and one commercial stakeholder. Draft against the nine-section skeleton, circulate for a one-week comment period, then take it to your board or leadership team for formal approval with a signature and version number. Do not let this phase run longer than three weeks — an imperfect approved policy beats a perfect draft.

Weeks 4–8: inventory and tier. Survey every team for the AI tools they actually use, including features embedded in existing SaaS such as meeting transcription, CRM summarisation and code assistants. Expect the real list to be two to three times what leadership assumed. Record each system with an owner, purpose, data categories, supplier, risk tier and lifecycle stage, then run impact assessments on anything you tiered high risk.

Weeks 9–12: train, enforce and evidence. Deliver short role-specific training — fifteen minutes for general staff, longer for engineering and anyone building AI features. Capture acknowledgements. Turn the prohibited-use rules into technical controls where you can: block unapproved tools at the network or identity layer, and configure approved tools to disable training on your data. Then set the review date and the metrics you will review against.

• Artefact from phase 1: an approved, versioned AI policy with a named owner.
• Artefact from phase 2: an AI system inventory with a risk tier per system and impact assessments for high-risk entries.
• Artefact from phase 3: training records, acknowledgement evidence and a monitoring plan with a next-review date.

Making the policy hold up under audit and procurement scrutiny

Both ISO 42001 auditors and enterprise buyers assess a policy the same way: they read it, then they ask for evidence that it operates. The three questions that catch teams out are 'show me your AI inventory', 'show me the impact assessment for this system' and 'show me the last review'. If the answer to any of those is a search through a shared drive, the policy is not yet operational.

Keep the evidence chain short. The policy references the inventory; the inventory links each high-risk system to its impact assessment; the assessment links to the controls that treat the risks; the review record shows the whole thing was examined on a date by a named person. That chain is what turns a document into a management system — and it is exactly what a security questionnaire is trying to establish when it asks whether you have AI governance in place.

One practical tip: publish a summarised version of your AI policy and inventory on your trust centre. Buyers who can self-serve that answer stop sending bespoke questionnaires, and the same artefact serves both governance and sales.

Common mistakes to avoid

The mistakes below account for most of the failed AI policy rollouts I see. None require budget to avoid — only a decision made early.

• Banning AI outright. Staff use it anyway on personal accounts, and you lose all visibility. An approved-tools list beats a prohibition you cannot enforce.
• Copying a template without changing the tool list. A policy that references tools you do not use, and omits the ones you do, signals to an auditor that nobody read it.
• No named owner. 'The management team' is not an owner. ISO 42001 expects an individual with defined responsibility.
• Ignoring embedded AI. Transcription, summarisation and predictive features in existing SaaS are AI systems and belong in the inventory.
• Treating suppliers as out of scope. If a vendor's model touches your customer data, their AI posture is part of your risk, and your policy should say how you assess it.
• Annual-only review. AI tooling and regulation move faster than an annual cycle; review quarterly for the first year.

Where an AI policy sits in the wider standards landscape

If you are heading towards certification, the AI policy is Clause 5.2 of ISO/IEC 42001 — one requirement among many, but the one everything else hangs from. The standard then expects AI objectives (6.2), risk and impact assessment (6.1, 8.x), Annex A control decisions recorded in a Statement of Applicability, internal audit (9.2) and management review (9.3).

If your exposure is regulatory rather than certification-led, the same policy supports EU AI Act readiness: the tiering exercise establishes which systems carry provider or deployer duties, and the inventory is the substrate for the technical documentation the Act expects for high-risk systems.

And if you already run ISO 27001, do not build a parallel structure. Extend your existing risk register, supplier review and incident process to cover AI-specific risks — bias, drift, prompt injection, training-data leakage, hallucination — rather than standing up a second management system that duplicates access control and change management for a second time.

Next steps

• AI governance software for ISO 42001 — run the policy, inventory, tiering and Annex A controls in one workspace.
• An ISO 42001 AI policy that boards and buyers both approve — the certification-grade version of this policy.
• AI impact assessments under ISO 42001 — the assessment your high-risk tier triggers.
• ISO 42001 vs the EU AI Act — mapping your tiers to regulatory obligations.
• Shadow AI: finding the tools nobody told you about — how to build the inventory in phase two.

Frequently asked questions