Short answer: An AI usage policy is a short document that says which tool employees may use, with which information, and for which work. European data protection authorities recommend exactly this: clear written rules instead of leaving use uncontrolled. A good policy fits on one or two pages and answers seven questions: purpose and scope, approved tools, information classes, use of output, access, training and reporting, owner and review. At the end of this article you will find a template with these seven sections.
This article refers to the GDPR, the EU AI Act and guidance from a European data protection authority. It is for information only and is not legal advice. Review your own situation with your data protection officer or legal counsel.
Why a Ban Doesn't Work
In most companies, AI use did not start with a decision. Employees began using Claude or ChatGPT with their own accounts for email drafts, summaries or translations. This is often called shadow AI: tools used for work without the company's knowledge, approval or control.
The Hamburg data protection authority puts the risk plainly in its checklist for companies: if you don't set internal rules on whether and how generative AI may be used, you have to assume that employees will use these tools without authorisation and without control, and the company may be liable for it1.
The first reflex is often a ban. But a ban doesn't remove the need. Employees who find the tools useful keep using them, just where the company can't see it. So the question is not "should we use AI?" but "how should we use it?" A policy is the written answer.
What Should the Policy Cover?
The same checklist starts with this point: write down precise internal rules on whether and under what conditions which tools can be used, with examples of allowed and prohibited use2. Together with the rest of the checklist, the topics fit into seven sections:
| # | Section | The question it answers |
|---|---|---|
| 1 | Purpose and scope | Who and which tools does this policy cover? |
| 2 | Approved tools | Which tool can be used, with which account? |
| 3 | Information classes | What can go into the tool, and what can't? |
| 4 | Use of output | How do we treat text, code or analysis the AI produces? |
| 5 | Access | Who can use it, from which device? |
| 6 | Training and reporting | Where do employees learn the rules, and who do they tell about a problem? |
| 7 | Owner and review | Who manages the policy, and when is it reviewed? |
A policy also has to be announced and easy to find. A document forgotten in a shared folder is not a policy.
The Most Important Section: What Can Go In?
Most policies get stuck on the list of tools. But the real risk is not the tool, it's the information that goes into it. To help employees answer "can I put this in?" quickly, it works to sort information into three classes:
| Class | What it means | Examples |
|---|---|---|
| 🟢 Allowed | Can go into any approved tool | Public information, general text drafts, language editing without names, research on a general topic |
| 🟡 Business account only | Only into the company-managed account | Internal correspondence, internal documents, customer requests with personal details removed |
| 🔴 Not allowed | Never goes into any tool (unless there is a written exception) | Personal data (names, phone numbers, ID, health, financial data), customers' drawings and documents, cost and price information, passwords and access details |
The examples change by industry. For a software company, source code is red. For an agency, a client's campaign plan. What matters is that the classes are clear in advance.
This follows GDPR's data minimisation principle: personal data must be limited to what is necessary3. The Hamburg checklist goes further. If the provider can use inputs for its own purposes, no personal data should go in at all. And removing names is not always enough: the context alone, such as which company and when, can identify a person4.
Why the red class is about more than GDPR, with customer contracts and trade secrets also in play, is explained in our article on AI and GDPR. The Hamburg checklist makes the same point: data protection is not everything, and trade secrets need rules too5.
AI Usage Policy Template
The template below is a starting point. Fill in the parts in square brackets for your company and change the examples to fit your work. Before you publish it, review it with your data protection officer, legal counsel and IT.
1. Purpose and scope
This policy covers how employees of [Company name] use generative AI tools for work. It applies to all employees, interns and consultants working on behalf of the company. The goal is to use the benefits of AI safely, not to ban it.
2. Approved tools
- For work, only tools with a company business account are used: [e.g. Claude Team, ChatGPT Business].
- Work information is not entered into personal accounts. Business accounts are not used privately.
- An employee who wants to use a tool that is not on the list asks [team/person]. The request is answered within [time].
3. Information classes
- Allowed: [public information, general text drafts, language editing without names]
- Business account only: [internal correspondence, internal documents, customer requests with personal details removed]
- Not allowed: [personal data, customers' drawings and documents, cost and price information, passwords and access details]
- If an employee is not sure which class something belongs to, they treat it as "not allowed" and ask [team/person].
4. Use of output
- AI output is a draft. It is never the only basis for a decision.
- Text, quotes, contracts and code that go to customers are checked by an employee before use. The person who checks is responsible for the content.
- Numbers, dates and sources in the output are verified.
5. Access
- Tools are used only from [company devices], with strong passwords and multi-factor authentication.
- [Which teams may use which tools; e.g. extra rules for people working with HR data.]
- When an employee leaves, their access is closed [on the same day].
6. Training and reporting
- Every employee learns about this policy when they join and [once a year].
- An employee who puts "not allowed" information into a tool by mistake reports it to [person/address] right away. Reporting is not punished; the goal is to limit the damage quickly.
- Questions and suggestions go to [person/address].
7. Owner and review
- Policy owner: [role, e.g. IT manager], with the data protection officer involved.
- The policy is reviewed [every 6 months] and whenever a new tool is approved.
- Last updated: [date].
Common Mistakes
Writing too much. Nobody reads a ten-page policy. An employee should be able to answer "can I put this in?" in one minute.
Only listing bans. If the policy doesn't say what is allowed, employees either ask about everything or about nothing. Both make the policy useless.
Setting rules without giving approved tools. Saying "don't use personal accounts" without providing a business account pushes use back into the shadows. The Hamburg checklist also recommends company-owned accounts instead of employees' private ones6. We summarise the difference between personal and business versions in the table in our GDPR article.
No owner, no date. Tools and provider terms change often. A policy without an owner is out of date within months. The checklist also says internal rules should be reviewed regularly7.
Punishing people who report mistakes. If an employee who entered something by mistake is punished for saying so, they won't say so next time.
A Policy Alone Is Not Enough
A policy writes the rule. It doesn't make sure the rule is followed. Three things need to go with it:
- Training: Since 2 February 2025, the EU AI Act requires organisations that use AI systems to take measures to ensure a sufficient level of AI literacy among their staff8. A policy that nobody has been trained on doesn't meet this.
- Human review: AI can produce content that sounds right but is wrong (hallucination). The person using the output is responsible for checking it. Decisions with legal effect on people should be made by humans; otherwise the strict rules of GDPR Article 22 apply9.
- The data protection officer: Involve them when you write the policy and before the first use case. Depending on the use, a data protection impact assessment may be required10.
If your company has an information security management system such as ISO 27001, the AI policy should not stay a separate document. Link it into the existing system. Unrecorded AI use can turn into a finding at your next audit.
How the policy handles work that needs personal data is a separate question. Options include masking data before it is sent, using a model where data stays inside the company, or making sure the AI can only reach data the employee can already see (AI access limits).
Where to Start
Before you write the policy, you need to know where you stand today: which team uses which tool, with which account, for which work? A policy written without this inventory either falls behind real use or becomes a document nobody follows. To see where you stand across six dimensions, you can use our AI Readiness Assessment.
A policy says how AI is used in the company. Where it pays off is a different question. Our AI Discovery service starts with that question: together, we find which process AI creates value in, without your company data leaving your control.
Transparency note: Dtech Bilişim is an Anthropic Registered Partner.
Sources
Numbers match the markers in the text. "Hamburg checklist": The Hamburg Commissioner for Data Protection and Freedom of Information, Checklist for the use of LLM-based chatbots, 13 November 2023. The checklist is guidance, not binding law; it predates the EU AI Act. The seven-section structure and the three information classes are our suggestion.
- Hamburg checklist, point 1 (p. 1): "If you do not specify internal regulations on whether and how generative AI may be used in day-to-day work, you will have to assume that employees and other members of the organisation will make unauthorised and uncontrolled use of the new tools. The employing organisation may be liable for these actions." ↩
- Hamburg checklist, point 1 (p. 1): "Formulate and document precise internal directives as to whether and under what conditions which tools can be used. Specific examples of authorised and prohibited usage scenarios help to clarify this." ↩
- GDPR, Article 5(1)(c): personal data shall be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (data minimisation). ↩
- Hamburg checklist, points 5 and 7 (pp. 2–3). If the provider's terms allow it to process data for its own purposes, no personal data should be entered; this covers customers, business partners and the company's own employees. "It is not sufficient to remove names and addresses from the entry. It may also be possible to draw conclusions about authors and data subjects from the context." ↩
- Hamburg checklist, point 14 (p. 4): "Data protection is not everything … It is also advisable to regulate other aspects such as the protection of copyrights or trade secrets." ↩
- Hamburg checklist, points 3 and 4 (p. 2): provide organisation-owned accounts instead of employees signing up with private data, do not authorise private use of these business accounts, and use strong passwords with additional authentication factors. ↩
- Hamburg checklist, points 13 and 15 (p. 4): raise employees' awareness through training, guidelines and discussions; and "it should be regularly reviewed whether the internal requirements need to be adapted." ↩
- EU AI Act (Regulation (EU) 2024/1689), Article 4: providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with AI systems on their behalf. Applies from 2 February 2025. ↩
- Hamburg checklist, points 10 and 12 (pp. 3–4): "It is your responsibility as a user to check the accuracy of the result"; "Decisions with legal effect should generally only be made by humans. Otherwise, the requirements of Art. 22 GDPR must be met." GDPR Article 22 covers decisions based solely on automated processing that produce legal or similarly significant effects. ↩
- Hamburg checklist, point 2 (p. 1): "Always involve your internal data protection officer when creating internal directives or implementing a use case for the first time. Depending on the use case, you should conduct a data protection impact assessment." See also GDPR Article 35 (data protection impact assessment). ↩
🗓️Let's map your personalised roadmap in a free 30-minute strategy call.
Book a Free Call🧭Let's find where AI pays off in your business — without your data leaving your control.
Talk to Us About AI DiscoveryFound this useful? Share it with your team.