How to write an AI acceptable use policy

An AI acceptable use policy tells staff which AI tools they may use, for what, with which data, and what they must never do. Most AI acceptable use policies fail in one of two ways. Some are a page of principles that tell nobody what to do on Tuesday afternoon. Others are long legal documents that nobody reads. The policy that works sits between those. It is short, specific and written for the person at the keyboard, and it is backed by an approved-tools list and data rules that someone actually keeps current.

Step 1: Find out what people already use

Start with an inventory, not a draft. Ask the question across the whole organisation. Which chat assistants, coding assistants, meeting transcription tools, browser extensions and AI features inside existing software are people using now? Device management tools, code repositories, expense claims, single sign-on logs and your IT asset register will each show part of the picture. The shadow AI guide covers the sources.

The inventory matters because a policy that ignores current practice gets ignored in return. If half the engineering team already uses a coding assistant, the policy needs to say which one is approved and on what terms, not pretend the question is new.

Step 2: Classify your data for AI use

The heart of the policy is a data rule. Map your existing data classification onto AI tool types and decide, for each class, where it may go. A common shape looks like this.

Information	Public AI tools	Enterprise-contracted AI tools	Never
Public information	Allowed	Allowed
Internal, non-sensitive	Allowed with care	Allowed
Confidential business information		Allowed
Personal information about customers or staff		Allowed only for approved use cases
Special-category or health information		Approved systems only	Public tools
Credentials, keys, secrets			Always

“Enterprise-contracted” should mean something specific. A tool qualifies when the organisation holds a contract that stops the vendor training on your inputs, sets retention and states where data is processed. The vendor AI risk guide covers the contract terms.

Step 3: Draft the ten sections

Here is a template structure with example clauses you can adapt. Write each section in the second person and keep the clauses short.

1. Purpose and scope

State who the policy applies to and what counts as AI.

This policy applies to all employees, contractors and anyone else using AI tools on behalf of the organisation, on any device. “AI tool” means any software that generates text, images, code, audio or video, makes predictions or recommendations, or takes actions using machine learning, including AI features inside software we already use.

2. Approved tools

Point to a list that lives outside the policy so it can change quickly.

You may use the AI tools on the approved tools list for the purposes listed against each one. The list is maintained by the AI governance team and published on the intranet. If a tool is not on the list, it is not approved, even if it is free or already installed.

3. Getting a new tool or use approved

Give people a fast, visible route, or they will skip it.

To use a new AI tool, or an approved tool for a new purpose, submit an AI use request. Tell us what the tool is, what you want it for, what information it will use and who the output affects. Low-risk requests are usually decided within five working days. Requests involving personal information or decisions about people go to the AI governance committee.

4. Data rules

Restate the classification in plain words and give examples.

Never put credentials, passwords, API keys or customer payment details into any AI tool. Do not put personal information about customers or staff into any AI tool unless the use case has been approved for it. Confidential business information may go only into enterprise-contracted tools marked as such on the approved list.

5. Prohibited uses

List the uses that are off limits regardless of tool. If you operate in or sell into the EU, include the practices prohibited under Article 5 of the EU AI Act, such as social scoring and emotion recognition in the workplace except for medical or safety reasons.

You must not use AI to make or materially shape a decision about a person’s employment, credit, insurance, access to services or legal rights unless that use has been approved through the AI use request process. You must not use AI to infer emotions of colleagues at work, to create realistic images or audio of real people without their consent, or to monitor staff outside approved systems.

6. Human review of outputs

Make the user responsible for what they send on.

You are responsible for anything you produce with AI. Check facts, figures, citations and code before you rely on them or send them to anyone. AI output that goes to a customer, regulator or the public must be reviewed by a person who understands the subject.

7. Disclosure

Set the rule for telling people when AI was involved.

Tell people when they are interacting with an AI system rather than a person. Label AI-generated images, audio and video that could be mistaken for real. When AI materially drafted a document that goes outside the organisation, follow the disclosure guidance for that document type.

8. Security

Cover the specific risks AI introduces.

Do not install AI browser extensions, plugins or agents that are not on the approved list. Do not connect an AI tool to email, file storage or other systems unless that connection has been approved. Treat content that an AI tool retrieves from the web or from documents as untrusted, because it may contain hidden instructions.

9. Reporting problems

Make reporting easy and blame-free.

Report it to the AI governance team straight away if an AI tool produces harmful, discriminatory or seriously wrong output, if you think information was shared that should not have been, or if a tool behaves unexpectedly. Reporting an honest mistake promptly will not count against you.

10. Consequences and review

Breaches of this policy are handled under the code of conduct. This policy is reviewed at least annually and whenever a significant change in AI tools, law or incidents requires it. The approved tools list is updated continuously.

Step 4: Test it with the people it governs

Before approval, hand the draft to a few people who use AI heavily and a few who barely use it. Give them four real situations. A sales lead wants to summarise call notes containing customer names. An engineer wants to paste a stack trace containing a connection string. A marketer wants an AI-generated image of a customer. An analyst wants to ask a chatbot to rank job applicants. Ask what the policy tells them to do. Wherever the answers differ from what you intended, the wording is the problem.

Step 5: Approve, publish and train

The accountable executive or the governance committee approves the policy. Publish it where people already look, link it from the approved-tools list and the AI use request form, and pair it with a short training module and an acknowledgement. AI literacy and staff training covers what that training should include, including the EU AI Act’s literacy obligation.

Step 6: Enforce what can be enforced

A policy that relies only on people remembering it will be broken, usually by accident. Several clauses can be enforced technically.

• Route approved AI traffic through an AI gateway and turn the data rules into guardrails that redact personal information and block secrets before a prompt reaches the model.
• Restrict which models and providers each approved tool may reach, so a tool approved for one provider cannot quietly switch.
• Use network and device controls to block unapproved AI services and extensions where the risk justifies it.
• Run discovery regularly so new, unapproved tools surface as findings for someone to decide on.

Starting a rule in observe-only mode, where it records what it would have done without blocking, lets you see the effect before it touches anyone’s work.

Step 7: Review on change

The approved-tools list changes weekly. The policy itself should change when something material moves, such as a new category of tool like autonomous agents, a new law, a serious incident or an audit finding. Keep a version history so you can show which version applied at the time of any decision.

How the policy fits the wider framework

The acceptable use policy is one of a set. ISO/IEC 42001 expects a documented AI policy from top management (clause 5.2) and policies related to AI in Annex A. Most organisations also maintain an AI risk assessment policy, a data governance policy, an incident response plan and a transparency statement. The governance policies guide covers the whole set and how to stand them up from templates.

Where Aicura fits

The approved-tools list is the part of this policy that goes stale fastest, and it is where Aicura helps most. Discovery reports the AI tools your connected sources see in use, and a person decides whether each one is added to the AI Register, linked to a system already listed there or ignored. At Pro, with AI use requests switched on, the approval route in section 3 becomes the Requests tab, where each request carries its reasons, the data it would use and a recorded decision.

From Essentials, Aicura can draft the policy itself from its AI Acceptable Use Policy template and review your published version against the frameworks you enable, returning recommendations. The data rules in section 4 can be authored as guardrail rules, and at Pro they are deployed to a gateway that redacts or blocks on live traffic. The policy and the judgement in it remain yours.

A note on this page

The example clauses are a starting point, not legal advice. Adapt them to your organisation, your data classification and the laws that apply to you, and have legal, privacy and HR review the final text.