AI Policy Template

9

sections the document needs

4

wordings people reliably get wrong

7

things an auditor asks to see

a day or two

to write it yourself

Two very different documents get called an AI policy: the acceptable-use rules staff follow, and the governed set an ISO 42001 auditor reads. This guide covers the first one in full, in the order it should be written. Four clauses carry more weight than the rest, so those come with example wording and the reason it holds up.

1. 1

   Opening statement

   What it must contain

   One short paragraph naming the AI in play - the assistants you license and the AI features already built into software you use - and the outcome you want from it.

   What the auditor checks

   It is the first evidence of intent. An auditor reads the opening to judge whether the policy was written for your business or lifted from a search result.

2. 2

   Purpose and scope

   What it must contain

   Who the policy binds (employees, contractors, third parties), on which devices, and that it covers both the tools you provide and public tools reached from a browser.

   What the auditor checks

   Scope decides what the rest of the audit can touch. A policy that quietly covers only company laptops leaves your real exposure - personal phones and free web tools - ungoverned.

3. 3

   Approved tools

   What it must contain

   The named list of AI tools people may use, and the route to getting one added: who to ask, and at what point in the process.

   What the auditor checks

   They compare the list against what is actually in use. A list nobody maintains is treated as worse than no list, because it shows a control that was written once and then abandoned.

   If you want to use a tool that is not on the list, ask [role, e.g. IT Manager] before putting any company or customer information into it.

   It names a role and a moment. A list of approved tools with no route to adding one gets ignored the first time somebody needs a tool that is not on it, and the shadow use that follows is what an auditor eventually finds. Naming the role rather than a person means the clause survives that person leaving.

4. 4

   What you must not put into a public AI tool

   What it must contain

   Named categories of data rather than adjectives: information that identifies a person, credentials and keys, source code, anything covered by a contract or NDA.

   What the auditor checks

   This is the clause a data-exposure incident gets judged against. If it is vague, there is nothing to have breached, and nothing to train people on.

   Never paste the following into a public or unapproved AI tool: customer personal information or anything that could identify a person; confidential business information, credentials, API keys or passwords.

   It names data types instead of adjectives. "Do not share confidential information" is unenforceable because nobody agrees where confidential starts, whereas "anything that could identify a person" and "credentials, API keys or passwords" can be followed without a judgment call and tested after the fact.

5. 5

   Check the output before you rely on it

   What it must contain

   That output is a draft until checked - facts, figures, code, and legal or compliance statements - and that responsibility for the result does not move to the tool.

   What the auditor checks

   Human oversight. They want the checkpoint named, and where a decision affects a person, some record that the check actually happened.

   Treat every output as a draft: check facts, figures, code and legal or compliance statements before you use or send them. You remain responsible for anything you produce with AI, exactly as if you had written it yourself.

   The first sentence sets the standard of care; the second closes the gap people actually fall through, which is the quiet assumption that using a tool moves the responsibility onto it. That second sentence is what turns a review step from advice into an obligation.

6. 6

   Transparency

   What it must contain

   Where the use of AI has to be disclosed - customer-facing content, decisions that affect people, anything a regulator or auditor might review - and that AI output is not presented as human work where the distinction is material.

   What the auditor checks

   Disclosure duties are turning up in customer contracts and in law. The auditor checks that you have taken a position at all, and that the position matches what your customers were told.

7. 7

   Data and privacy

   What it must contain

   That a tool must meet your privacy and security requirements for the data involved, a preference for tools that do not train on your input (or that setting turned off), and who to ask when it is unclear.

   What the auditor checks

   It ties AI use back to the data-protection commitments you already made elsewhere. Auditors specifically look for the training-on-your-data question being answered, because most policies skip it.

8. 8

   Accountability and breaches

   What it must contain

   That misuse runs through the disciplinary and incident processes you already have, and the immediate reporting route when information may have been exposed through a tool.

   What the auditor checks

   They test whether AI incidents land in the same incident register as everything else, rather than on a separate track that nobody reviews.

9. 9

   Review, ownership and approval

   What it must contain

   The named owner, the review cadence, the events that force an early review, and an approval block: name, title, date and version.

   What the auditor checks

   The first page they turn to. An unowned, undated policy reads as unmaintained no matter how good the rest of it is.

   This policy is owned by [role] and reviewed at least once a year, and whenever the tools we use or the law change.

   An owner, a cadence and a trigger in a single line. The trigger is the part most policies leave out, and it is what stops an annual cycle from running a year behind the tools your staff are already using.

Length is not the goal. One or two pages that people read once and then follow beats eight pages nobody opens, and the shorter version is far easier to keep current - which is the test it has to pass every year afterward.

Reviewing an AI policy takes minutes, and almost none of it is about writing quality. These are the questions that come up, and what actually closes each one.

? Show me your AI policy.

Satisfies One current document with a version number, an owner, an approval date and a next-review date that has not passed.

Fails Two differing copies in two drives is a finding on its own.

? Who approved it, and when?

Satisfies An approval block with a real name and title, plus the thing that records the decision - a meeting note, an email, a ticket.

Fails A signature line left blank is the most common single failure.

? How do your staff know it exists?

Satisfies Evidence it was distributed: an induction step, an acknowledgment list, a link in the handbook people actually open.

Fails Approved but never circulated does not count as implemented.

? Which AI tools are approved right now?

Satisfies A current list that matches reality. Expect it to be cross-checked against your single sign-on app list, expense claims, or the browser extensions visible on the screens in the room.

? What happens when someone wants a tool that is not on the list?

Satisfies The named approver, plus one worked example: a request, what was considered, and the decision. One real case is worth more than a paragraph describing the process.

? Where does a human check AI output before it reaches a customer?

Satisfies A named checkpoint inside a named process, and a record showing the check happened on a specific piece of work.

Fails "Output is reviewed" with no location gives them nothing to sample.

? What happened the last time an AI tool caused a problem?

Satisfies An entry in your normal incident register and what changed afterward.

Fails "It has never happened" is accepted once; the second time it reads as nobody looking.

The pattern is consistent: the document is the small half of it, and the evidence that the document is being used is the large half. Write the policy so that each rule leaves a trace somewhere you can find later.

Almost every AI policy that fails a review fails for one of these reasons. None of them are about how well it is written.

• ! Placeholders survive into the approved version

  [Organization] and [role, e.g. IT Manager] still sitting in the signed PDF. It is the quickest way to be told the document is not real, and it happens because the approval step never included anybody reading it end to end.

• ! Prohibitions written as adjectives

  "Do not share sensitive or confidential information" cannot be followed or enforced, because nobody agrees where the line is. Name the data types instead, so a person on their first day can apply the rule without asking.

• ! A tool list frozen on the day it was written

  Staff move to whatever they saw last month. Within two quarters the approved list describes nothing, and the gap between the list and reality is the finding - not the tools themselves.

• ! A blanket ban with no approved alternative

  Prohibition without a sanctioned option does not stop AI use, it moves it to personal accounts where you cannot see it and cannot govern it. You lose the visibility you wrote the policy to get.

• ! No named owner and no review date

  Every other clause can be right and the document still reads as abandoned. Review dates that have quietly passed are just as bad: an expired review is evidence the control is not operating.

• ! Oversight asserted but never located

  "AI output is reviewed before use" names no step, no role and no record, so there is nothing for an auditor to sample and nothing for a staff member to actually do.

• ! An HR conduct template used as governance evidence

  Most templates on the market are written for behavior. They never touch data, tools, model training or oversight, so they answer the staff question and none of the audit ones.

• ! Treating the staff policy as the whole system

  One acceptable-use policy is the people-facing layer. It is not an AI management system, and presenting it as one is the mismatch that stalls an ISO 42001 audit before it starts.

The cover in the hero and the body page below are the structure in this guide run through PolicyMint's export path, with an example company's branding applied. Generated for your business, it comes back naming the AI tools you actually approve, the role that signs off a new one, the concerns channel your staff really use, and an approval and version block already filled in rather than left as brackets.

Same document either way. The difference is who does the drafting, and what evidence comes attached to it.