AI Acceptable Use Policy Template: The 12 Sections It Needs

What an AI acceptable use policy actually does

An AI AUP sits alongside your existing IT acceptable use policy, your data protection policy and your confidentiality rules. It does not replace them. Its job is narrower: to close the gap that generative AI tools opened when staff started pasting customer emails, contracts and source code into chat interfaces that your IT team never approved and your contracts never anticipated.

A good policy does three things. It gives people a clear yes or no on the tools they already want to use. It draws a bright line around the data that must never leave the building. And it sets an expectation that AI output is a draft to be checked, not a finished answer to be forwarded. Everything else in the document exists to support those three outcomes.

The 12 sections your policy must contain

The list below covers every element we see in policies that survive contact with a real workforce. You can merge sections for a very small team, but you should be able to point to where each topic is handled.

• Purpose and scope: why the policy exists, who it binds (employees, contractors, temps, interns) and which systems it covers, including personal devices used for work.
• Definitions: what you mean by AI system, generative AI, approved tool, company data and personal data. Keep each definition to one sentence.
• Principles: four to six short statements such as verify before you rely, protect confidential data, be transparent about AI use, and stay accountable for your own work.
• Approved tools and accounts: a named list of permitted tools, the tier or plan that is approved, and the rule that company work happens on company-managed accounts, not personal logins.
• Data classification table: the categories of information in your business and what may be entered into which class of tool. This is the section people will actually consult.
• Prohibited uses: entering restricted data, generating content that impersonates real people, making automated decisions about individuals without review, bypassing security controls, and using AI to produce material that breaches licences or discrimination law.
• Human oversight and verification: who checks output, what must always be checked (facts, figures, citations, code, legal or medical statements) and how the checker records that they did so.
• Transparency and disclosure: when to tell clients, customers or the public that AI was used, and how to label AI-generated images, audio, video and text where the law or the client requires it.
• Intellectual property and ownership: who owns prompts and outputs, the rule against pasting third-party copyrighted material as input, and how to handle output that reproduces someone else's work.
• Security: password and MFA requirements for AI accounts, browser extension rules, API key handling, and the ban on connecting AI tools to internal systems without approval.
• Training, incidents and reporting: what training people must complete, what counts as an AI incident (a data leak, a hallucinated fact sent to a client, a discriminatory output) and how to report it without fear of blame.
• Enforcement and review: the consequences of breaches, how they are handled proportionately, who owns the policy and when it will next be reviewed.

Common mistakes that make a policy useless

The most frequent failure is a blanket ban. A policy that says nobody may use AI tools is ignored within a week, and once people are ignoring one rule they stop reading the others. The second is the opposite: a vague statement that staff should use AI responsibly, with no definition of what responsible means for a payroll spreadsheet or a client pitch.

Other recurring problems include naming no tools at all (so nobody knows what is approved), copying a large enterprise policy with references to committees and roles the business does not have, forgetting contractors and freelancers, and never stating who owns the document. A policy with no owner has no reviewer, and a policy last updated before the tools it covers changed is worse than no policy, because it gives false comfort.

A worked example: the data classification table

Imagine a 25-person accountancy practice. Its table has four rows. Public information covers anything already on the website or in published marketing, and may be used in any approved tool. Internal information covers working documents, process notes and internal emails that contain no client or personal data, and may be used in approved tools on company accounts only. Confidential information covers client financial records, contracts, pricing and anything under an NDA, and may be entered only into tools that the practice has contractually confirmed do not train on inputs and that sit inside the company tenancy. Restricted information covers personal data such as payroll, health details, national insurance or tax identifiers, bank details and anything covered by professional privilege, and may not be entered into any generative AI tool at all without a documented exception signed by a director.

Each row also states a practical test. For confidential data the test is: would the client be surprised or unhappy to learn where this went? For restricted data the test is: could this be used to identify or harm a real person? Those two questions do more work than a page of definitions, because they can be applied to a case the table did not anticipate.

How a generator differs from a static template

A static template gives you the skeleton above with blanks to fill. That is a reasonable starting point if you have the time and confidence to decide, section by section, what applies to you. Where it falls down is the parts that have to be specific: the tool list, the data classes, the jurisdiction-specific transparency rules and the industry obligations that decide whether client data can go anywhere near a public model.

A generator asks you those questions first and writes the specific sections from your answers. You tell it your country, your sector, the data you handle and the tools your team wants, and it produces a policy that names those tools, includes the right classification rows and reflects the disclosure rules that apply where you operate. The free generator at aipolicy.wizeb.com/generator does exactly this, and the result is still yours to edit. Neither a template nor a generator replaces a review by someone qualified in your jurisdiction if you have specific legal exposure, but a generator gets you to a reviewable draft in a fraction of the time.

Frequently asked questions

How long should an AI acceptable use policy be?

For a business under about 50 people, four to six pages is plenty, with a one-page summary of rules at the front. Longer documents are read less, and the summary page is what most staff will actually use.

Is an AI acceptable use policy legally required?

In most countries there is no law that says you must have one. However, data protection law, confidentiality duties and, in the EU, the AI Act transparency and AI literacy obligations are much easier to meet if the rules are written down and communicated. A policy is the evidence that you took those duties seriously.

Should the policy name specific AI tools?

Yes. A policy that never names a tool leaves every decision to the individual. Keep the named list in an appendix or a separate tool register so you can update it without re-issuing the whole policy.

How often should we review it?

Every six months, or sooner when you approve a new tool, change a supplier, enter a new market or experience an incident. Put the next review date in the document itself.

Do contractors and freelancers need to sign it?

Anyone who handles your data or produces work under your name should be bound by it. Add a clause to contractor agreements that requires compliance with the policy as amended from time to time.

Related guides

• AI Tool Register Template: Columns, Risk Levels and Reviews
• Generative AI Policy for Employees: 10 Plain-English Rules
• AI Policy Generator vs Template: Which Do You Actually Need?