AI usage policy: what it must cover and how to write it
By Kike Gandia · Co-Founder & CEO, OSCP
Most companies discover they need an AI usage policy the day someone pastes an entire contract into a public chatbot. By then the data is already out. An AI usage policy is not a defensive legal document: it is the set of rules that lets your team use these tools —which they will use anyway— without turning every prompt into a data leak. This guide covers what it must contain, which decisions to make before writing it, and why blanket bans do not work.
Why a blanket ban does not work
The first instinct of many leadership teams is to ban ChatGPT at work. In practice that does not remove the usage: it moves it to personal phones, where there is no logging and no control at all. The outcome is worse than the starting point, because the company loses all visibility over what information is leaving and through which tool.
A policy that works starts from a different premise: the team will use AI because it saves them real time. The goal is not to prevent that, but to define which tools, which data and which oversight. A permissive, clear policy gets followed; an absolute, prohibitive one gets quietly ignored.
The central decision: which data may leave the organisation
Everything else follows from this classification. The most practical way to frame it is by levels, mapping each level against the type of tool allowed.
| Data level | Examples | Allowed tooling |
|---|---|---|
| Public | Press releases, already-published content, open documentation | Any tool, including free accounts |
| Internal | Minutes, drafts, internal procedures, training material | Corporate accounts only, with retention disabled |
| Confidential | Contracts, customer data, payroll, proprietary source code | Only deployments with a data processing agreement and no training on your data |
| Regulated | Health data, third-party financial data, data on minors | Does not leave the organisation: self-hosted model or nothing |
The policy should name the levels using the vocabulary your company already uses. If you already have an information classification for ISO 27001 or the ENS, reuse it instead of inventing a parallel one: two competing taxonomies guarantee neither gets applied.
The seven points that cannot be missing
1. Approved tools, by name and specific version. "Corporate AI tools" is not a list: nobody knows whether their new plugin qualifies.
2. Which data never leaves, with literal examples from the business, not abstract categories.
3. Who approves a new tool and how fast they respond. Without a deadline, the process gets bypassed.
4. Mandatory human review of any AI output that reaches a client or a decision.
5. Labelling of generated content when it is published or delivered to third parties.
6. What to do when someone pastes something they should not: a no-blame channel. If reporting a mistake costs you a sanction, nobody reports.
7. A review date. The tool landscape shifts every quarter; a policy with no expiry ages within months.
Common mistakes when writing it
The most common is copying a generic template off the internet and publishing it unadapted: it ends up banning tools the team already uses daily, so the policy is born already breached and loses authority for everything else.
The second is writing it from legal alone, without talking to the people who use the tools. A policy that ignores real workflows generates informal exceptions from day one.
The third is not pairing it with training. A document in the document manager does not change behaviour; a thirty-minute session with concrete examples from the business does. That is why the policy and the training either ship together or neither works.
How it relates to the AI Act and to GDPR
An AI usage policy is not the same as complying with the AI Act, but it is its operational prerequisite: without knowing which tools your organisation uses and for what, you cannot classify your systems by risk level or demonstrate human oversight to anyone.
With GDPR the link is more direct: if an employee pastes customer personal data into a public chatbot, that is a disclosure to a third party with no legal basis and no processing agreement. The policy is the organisational control that prevents that scenario, and it is exactly the kind of measure an auditor expects to see documented.
FAQ
Does a 10-person company need an AI usage policy?
Yes, and it is probably easier than in a large one. In a small team one page is enough: the list of approved tools, three rules on which data never leaves, and who to ask when in doubt. Size does not change the risk of someone pasting a contract into a chatbot; it only changes how much paperwork it takes to prevent it.
Is using the paid version of ChatGPT or Copilot enough?
It helps, but it does not replace the policy. Enterprise plans typically do not train on your data and let you disable retention, which covers part of the contractual risk. They do not cover who decides what may be pasted, who reviews the output before it reaches a client, or what happens with regulated data. The tool is one piece; the policy is the frame.
How often should the policy be reviewed?
At least every six months, and whenever a new tool is approved or an existing one changes its processing terms. AI vendors revise their terms frequently, and a policy that authorises a tool under conditions that no longer apply is worse than having none, because it creates a false sense of control.
Who should sign off the policy?
Leadership, because it means accepting a level of risk, with input from whoever leads IT or security and from at least one owner of the areas that will use it most. If only legal signs it, the usual result is a correct document that nobody applies.
Related service
AI governance and safe AI use service
Related content
- AI governance and safe AI use
- Shadow AI: ungoverned AI at work
- How to use AI safely at work
- AI Act for freelancers and SMBs
- AI Act compliance consulting