Writing an AI policy: a guide for companies, with checklist
An AI policy is an internal set of rules defining who in the company may use which AI tools, with which data, for which purposes – and who decides on exceptions. It is not a legal document for the archive but a working instruction for daily use.
Its purpose is twofold: it gives employees the basis to decide correctly in individual cases, and it produces the documentation that data protection law, professional law and supervisors expect.
This guide covers structure, content and rollout – including a proposal for data classes that most companies can adopt directly.
Why a policy is more than a ban
Policies that only prohibit fail in practice: they do not answer the question employees actually have, which is what they are allowed to do. The result is either paralysis or circumvention.
An effective policy therefore names the permitted tool and the permitted use cases first, and the limits second. That also makes it the answer to shadow AI: people with an official alternative fall back on private accounts far less often.
It is also evidence. Since 2 February 2025, Art. 4 of the EU AI Act has required sufficient AI literacy among staff; a documented policy plus training is the pragmatic way to show it.
The structure: nine building blocks
A policy does not need to be long. Five to eight pages are usually enough if these blocks are present.
- Scope: who the policy applies to – expressly including temporary staff, interns, freelancers and external service providers.
- Approved tools: which systems are cleared, and through which access they are to be used.
- Data classes: which data may go into which tools. The most important section.
- Permitted and excluded use cases, each with examples from your own working day.
- Duty to verify: output counts as a draft; for figures, deadlines and legal bases, checking at the source is mandatory.
- Disclosure: when AI assistance has to be flagged internally or to clients.
- Roles: who owns the policy, who approves tools, who decides on exceptions.
- Reporting routes: whom employees turn to when in doubt or after a mistake – expressly without the threat of sanctions.
- Validity and review: a fixed date for the next revision.
Defining data classes
The practically most important part of the policy is a table mapping types of data to approved tools. It has to be concrete enough to apply without asking back. The proposal below can be adapted to your own situation.
| Class | Examples | Approved in |
|---|---|---|
| Public | Published content, website copy, general research with no company reference | Any approved tool |
| Internal | Templates, minutes without personal references, drafts for internal communication | The central company platform |
| Confidential | Client and personal data, quotations, contracts, HR files | The central platform, provided hosting is in the EU or Switzerland and training is contractually excluded |
| Strictly confidential | Professional secrets, health data, ongoing proceedings, transaction data | Only after a documented case-by-case assessment by the responsible role |
Roles and responsibilities
Without named individuals the policy has no consequences. Three roles are enough in smaller companies, and one person can hold more than one.
- Ownership of the policy: adopts, reviews and updates it – usually management.
- Tool approval: assesses new systems before use for processing location, contract and exclusion of training.
- Contact for borderline cases: decides on individual matters in the strictly confidential class and documents the decision.
Rolling the policy out
The rollout determines the effect. A policy distributed by email without a tool and without training will not be followed.
- Take stock: which tools are used today, and for what? Without the threat of sanctions, otherwise the answers stay incomplete.
- Provide the approved tool before communicating the rule.
- Agree the data classes with the business units – they know the borderline cases nobody sees centrally.
- Clarify co-determination where it applies and align the policy accordingly.
- Train with real examples from your own organisation rather than generic slides, and document attendance.
- Put it into force, name the contact person, communicate the reporting route.
- Review after three months: which cases came up, which rule was unclear, which tool is missing?
Co-determination in Germany, Austria and Switzerland
Introducing an AI platform with audit logs also means introducing a system capable of reflecting behaviour and performance. The three countries treat this differently.
In Germany the works council must be involved under Section 87 (1) no. 6 BetrVG where a technical system is capable of monitoring behaviour or performance. Intention is irrelevant – capability is enough, and audit logs regularly meet it.
In Austria, Sections 96 and 96a ArbVG apply: control measures affecting human dignity and the processing of personnel data require a works agreement. Switzerland has no comparable co-determination; there Art. 328b of the Code of Obligations and Art. 26 ArGV 3 set the limits, with monitoring systems aimed at controlling behaviour being impermissible.
How it connects to your other documents
The AI policy does not stand alone. Four documents have to fit together, otherwise a contradiction appears at the first audit.
- Record of processing activities: AI-supported processing belongs in it as its own entry.
- Privacy policy: it has to cover the use where personal data is processed.
- Data processing agreement with the provider, supplemented by a confidentiality undertaking for holders of professional secrets.
- Employment terms or a works agreement, wherever co-determination applies.
Common mistakes
Three patterns leave policies without effect.
- The policy comes before the tool: something is prohibited without an alternative in place. Usage moves into private hands.
- The data classes stay abstract: wording such as "no sensitive data" cannot be applied in an individual case. Without examples, everyone decides differently.
- There is no sanction-free reporting route: someone who cannot report a mistake without fearing consequences will not report it – and the company loses the chance of a timely notification under Art. 24 FADP or Art. 33 GDPR.
Frequently asked questions
How long should an AI policy be?
Five to eight pages are enough in most companies. What matters is not the length but how concrete the data classes and examples are. A policy nobody finishes reading has no effect.
Do small companies need an AI policy too?
Yes. The duties under data protection law and the AI literacy obligation in Art. 4 of the EU AI Act set no lower threshold. In small companies the policy is shorter but not dispensable – and it often takes effect faster because the lines of communication are short.
Does the works council have to be involved?
In Germany regularly yes, as soon as the system is capable of monitoring behaviour or performance – Section 87 (1) no. 6 BetrVG turns on capability, not intention. In Austria, Sections 96 and 96a ArbVG apply. Switzerland has no comparable co-determination.
How often should the policy be reviewed?
At least annually, plus whenever there is a trigger: a new tool, an incident or a change in the law. A fixed revision date in the document stops the review from being forgotten.
Should we ban private AI accounts?
For work data yes – but only once an official alternative is in place. A ban without an offering moves usage to private devices and removes only the visibility. The order is therefore: tool first, rule second.
Who should write the policy?
A small team of management, IT and someone from the business unit with the highest data sensitivity works well. The business units supply the borderline cases; management adopts it. A purely legal policy with no grounding in practice stays in the archive.
Sources
Related reading
Bring AI into your company securely.
Try Custodos with your team – and see how quickly secure AI becomes productive.
- Try it with the whole team
- Set up in minutes
- Productive from day one