What to include in an AI policy
The headings are common; the decisions are yours. A policy is worth having only when it records choices your organisation has actually made.
An AI policy should cover approved tools and approval, acceptable use, human review, data and confidentiality, personal data and AI literacy, an owner, and a review date.
An AI policy is an organisational document, so most of what follows is reasoning rather than regulation. Where the law is invoked it carries its article. More organisations are writing one: CIPD on generative AI at work reports that 31% of employers had worked on a generative AI policy in the past 12 months, compared with 16% previously.
What is an AI policy for?
It gives staff one place to check what is allowed and gives you a record of what was agreed. Without it, people make their own calls tool by tool and nobody can see the pattern until something goes wrong.
That framing matters for what goes in: a policy is a decision record, so every section should reflect a decision, not a placeholder. The parts you have not decided yet are the parts to settle before you issue it.
What does it have to cover?
The workable list is short and specific. Name the approved tools and who signs off a new one. Set out how AI may and may not be used, and what has to be checked before AI-assisted work reaches a customer. State clearly what can and cannot be put into an external tool: NCSC on the risk of public large language models is blunt that sensitive information should not go into public large language models and that providers can retain and access what is submitted.
Then the duties: personal data and confidentiality, transparency to the people affected, AI literacy for the staff who handle AI (Article 4, in force), reporting a problem, and an owner and review date. The the GOV.UK AI Playbook is a useful public-sector reference a private organisation can borrow from, including its emphasis on human review and on logging use for audit.
What changes by sector?
The obligations change; the structure does not. A clinic handling patient data, a firm giving regulated advice and a school teaching minors each carry duties a generic template cannot know, so the personal-data, confidentiality and review sections are where sector weight lands.
The generator reflects this without asking your sector directly: it conditions the draft on your AI activity and the functions that use AI, and marks the decisions it cannot make for you. You settle the sector-specific ones against your own obligations before the policy is issued.
Who owns and approves it?
Name an owner, usually whoever already owns risk, security or operations, with sign-off from leadership. Someone has to be answerable for keeping it accurate and for deciding the questions it raises, and a policy nobody owns goes stale by default.
Approval is a separate decision from ownership: the owner maintains the policy, but leadership approves it and any material change, so the record shows who agreed to what and when.
How does it stay current?
Give it a review date and revisit it when your tools, your obligations or the way you use AI change. The usual cause of drift is shadow AI: staff adopt a new tool without telling anyone and the policy stops describing reality. The shadow AI guide covers what to do about that.
Keeping the approved-tools list and the approval route live is most of the maintenance, so make those the easiest parts to update.
What can a policy not do?
It cannot make a prohibited use lawful, it cannot decide your obligations for you, and it cannot keep itself current. It is a record of decisions, so it is only as good as the decisions behind it and the discipline of reviewing it.
That is the honest limit, and it is worth stating in the policy itself. The generator produces a starting draft with the decisions still yours marked in the text, and the policy skeleton gives you the bare headings if you would rather start from those.