Your staff are already using AI tools. Some use the ones you've approved. Others use free accounts on their phones, browser extensions or features that appeared inside software you already pay for. An AI use policy doesn't stop that from happening. It makes it visible, sets clear limits and gives people a safe way to ask.
This guide gives you a structure for a policy that fits on two pages, that staff will actually read, and that supports your obligations under GDPR and the EU AI Act. It's general guidance, not legal advice; have counsel review the final version.
What a good policy does
A useful AI policy answers the questions people actually have at work:
- Which tools can I use?
- What can I put into them, and what must I never put into them?
- Do I need to check the output, and how carefully?
- Do I need to tell anyone that AI was involved?
- What do I do if I want to use a tool that isn't on the list?
If your policy answers those five questions clearly, it will do more than a long document that covers every theoretical risk and is never opened.
Before you write: find out what's in use
Start with a short inventory. Ask every team which AI tools they use and for what, and make it clear the goal is visibility, not punishment. Check your software subscriptions for AI features that were switched on by default.
The result shapes the policy. If half the company relies on a tool you haven't reviewed, banning it overnight won't work. Review it first, then approve it, restrict it or offer an alternative.
The structure
1. Purpose and scope
Two or three sentences. Why the policy exists (to let people use AI productively while protecting customers, colleagues and the company), and who it applies to: employees, contractors and anyone working with company data.
2. Approved tools
A short list of tools staff may use for work, with the account type that's approved. The account type matters: a company workspace with data-protection terms is different from a personal free account of the same product.
| Tool | Approved for | Account |
|---|---|---|
| Company AI assistant | Writing, research, analysis | Company workspace only |
| Code assistant | Software development | Company license, approved repositories |
| Meeting notes tool | Internal meetings | Company account; not for external calls without consent |
Keep the table current. A policy that lists last year's tools gets ignored.
3. Data rules
The most important section. Use simple categories people can apply in seconds:
- Allowed: public information, your own drafts, general questions.
- Allowed in approved tools only: internal documents, non-sensitive business data.
- Never: customer personal data unless the tool is specifically approved for it, passwords and keys, health or financial data about individuals, confidential information from clients or partners covered by an NDA, and source code from repositories that aren't approved.
Give examples for each category. "Customer personal data" is abstract; "a spreadsheet of customer names and emails" is not.
4. Review and responsibility
AI output can be confidently wrong. The person who uses it is responsible for it. State plainly:
- Check facts, figures, names and citations before relying on them.
- Review generated code like code from a new colleague: read it, test it and don't merge what you don't understand.
- Don't use AI output as the sole basis for decisions about people, such as hiring, evaluation or credit.
5. Disclosure
Set out when AI use must be disclosed: to customers who interact with an AI assistant, in content where AI-generated images, audio or video could mislead, and wherever a contract or client requires it. Several of these are also transparency obligations under the EU AI Act.
6. Requesting a new tool
Give people a simple route: who to ask, what information to provide (the tool, the purpose, the data involved) and how long a decision usually takes. A fast, predictable approval process is the most effective defense against shadow AI.
7. Reporting problems
Tell staff what to do if something goes wrong: confidential data entered into the wrong tool, a harmful or wrong output that reached a customer, or a tool behaving unexpectedly. Make reporting easy and blame-free; you want to hear about mistakes early.
8. Ownership and review
Name the owner of the policy and set a review interval. Quarterly is reasonable while tools change this quickly.
Keep it to two pages
Put the five everyday answers on the first page and the detail on the second. Link to longer guidance, such as vendor assessments or security standards, rather than including it.
Rolling it out
A policy only works if people know it and understand why:
- Announce it with the reasons, not just the rules. People follow rules they understand.
- Run a short training session covering the data rules and output review, with real examples from your company. This also supports the AI literacy obligation under the EU AI Act.
- Make the approved tools easy to use. If the approved option is slower or harder than a personal account, people will drift back.
- Keep records of who received the policy and training.
- Review after the first quarter with input from the teams using AI most.
Common mistakes
- Banning everything. It doesn't stop use; it hides it.
- Copying a template unchanged. A policy that doesn't mention your tools and your data reads as generic and gets ignored.
- No examples. Abstract categories leave people guessing at the moment it matters.
- No owner. Without someone responsible, the tool list goes out of date within months.
- Ignoring built-in AI features. AI now arrives inside email, documents, CRM and support software. The policy should cover those too.
The short version
Find out what's in use, then write two pages that answer five questions: which tools, what data, how to review, when to disclose and how to ask for something new. Train people with real examples, keep the tool list current and review the policy every quarter.