Your AI policy has to answer the question one of your people will ask this week: can I paste this client contract into a chat window? A page of principles such as "use AI responsibly" and "protect client data" is easy to agree with, but it cannot answer that.
An assessor will read a policy like that as a statement of intent, so these are the eight sections that turn it into rules your people can follow.
1. The categories of data that may go in
Write a named list of categories, each with a yes, a no or a condition attached. The list might cover client documents, personnel records, financial data before it is published, anything covered by a non-disclosure agreement, code, client contact details, pricing, draft bids and board papers.
For four of those categories it might look like this, although the answers are only examples and yours will differ, because each one is a decision about your clients and your obligations:
- A client's documents: no, unless the client has agreed in writing and the tool is on a company account.
- Personnel records: no, on any tool and any account.
- Material you have already published: yes, on any approved tool.
- Draft bids and pricing: yes on a company account only.
Your people make this call several times a day, so the list is the paragraph they will use most, and it takes the most work because each line is a decision.
2. The named tools you approve
A policy that says "approved AI tools" without naming them leaves each person to guess which ones count. The register belongs alongside the policy: this tool, on this account type, for this kind of work.
It will go out of date, which is what the next item is for.
3. Who decides and what they check
When one of your people asks for a new tool, one named role decides against a written test. Without that, requests either get refused by default, which pushes use underground, or approved by whoever was asked first, which is not a control.
Your test does not need to be elaborate, because four questions will do it: where the data goes, what the account can reach, who supplies it and whether there is a business case.
4. A direct rule on personal accounts
Personal accounts are usually the largest exposure in the building. Someone has signed up with their work email address, on a personal subscription, paid on their own card. That account is outside your control entirely. You cannot see what went into it, you cannot revoke it when they leave and it appears on no system you administer.
The policy has to say what happens to those accounts, and since nobody was given rules, it should treat them as a practical matter rather than a disciplinary one. Make it an instruction with a route: here is how to move what you are doing onto a company account, and here is who to talk to.
5. Where a person must review the output
Governance is mostly a question of who checks what and when. Your policy should name the categories of work where output cannot leave unreviewed.
That means anything that becomes a commitment, anything with a figure in it, anything about a named individual and anything a client will read as a statement of fact from your business.
This is also the section that protects your people, because without it the first mistake becomes somebody's fault personally. AI hallucinations explains why each of those categories is on the list.
6. What gets recorded
If a client, an insurer or an assessor asks how AI use is controlled, you need something to show beyond the policy itself: which accounts exist, who approved what, and when the policy was last reviewed and by whom.
Most of it is a spreadsheet, kept as you go, because it cannot be assembled after the question arrives. If the question names a standard, ISO 42001 or ISO 27001 sets out which one applies.
7. A review date and an owner
A policy approved once and never reviewed becomes a documented position that is no longer true, and a client or an assessor will hold you to it. Tools change every few months, and while the controls stay the same, the tool register has to change with them.
8. What it does not cover
The most credible policies we see are explicit about their own limits, and yours should say what it leaves out. For example: "This policy covers general-purpose AI tools used by our people. It does not cover AI features built into systems we already run, AI used by our suppliers on our behalf or the regulatory position in any specific jurisdiction."
Writing that down keeps the policy from being cited later as covering something it never addressed.
The page your people follow day to day is a shorter document written from these eight decisions, and an AI acceptable use policy explains how the two differ. What goes under each section changes by sector, and there are versions for a charity or membership body, a creative agency, a hotel group, a law firm and an accountancy practice.
Where this fits
Section one is the hard part because it is a leadership decision, and in Govern it is settled in a half-day workshop with the people who can make it. Before that, a readiness snapshot shows which tools are in use, on whose accounts and what each one can reach, so the workshop decides section one from what is already happening.
If you would rather see the shape of the whole thing first, the policy page sets out the eight sections in summary, what a template can and cannot do for you and how the decisions get settled.