AI Policy for Companies: Guide with Template
An AI policy defines what's allowed — not just what's forbidden. This guide provides the complete template structure along with ready-to-use wording.
What you will learn
- Why an AI policy isn't a list of bans but a system of approvals
- Which ten building blocks belong in a solid AI policy
- How to define data and use-case classes that everyone can follow
- How the policy interacts with the EU AI Act, GDPR, and the works council
- Which wording templates you can use directly
The AI policy in one sentence
An AI policy is the internal rulebook that defines which AI tools may be used in the company for which tasks with which data, who approves it, who checks it, and who's liable — usually on three to six pages, binding for all employees.
The most common mistake: the policy gets written as a list of bans. The outcome is predictable — employees use AI anyway, just invisibly through personal accounts. A good policy first answers the question “What am I allowed to do?” and makes the permitted path more convenient than the secret one.
Why you need one — three separate reasons
Legal. The EU AI Act requires companies that use AI to ensure their employees have adequate AI literacy. The GDPR requires documented technical and organizational measures. A policy is where both visibly come together. What else the EU AI Act requires is explained in The EU AI Act Explained Simply.
Operational. Without rules, every department decides for itself which tool to buy. After a year, there are twelve subscriptions, three data protection risks, and no shared quality baseline.
Cultural. Uncertainty slows things down more than any ban. Anyone who doesn't know whether AI use is tolerated either doesn't use it at all or hides it. Both cost you.
The ten building blocks of an AI policy
This structure can be used directly and filled in whatever order suits you. It's deliberately kept lean — a policy nobody reads doesn't work.
# | Block | What belongs in it |
|---|---|---|
1 | **Purpose and scope** | What the policy applies to, for whom (including freelancers and working students), from when |
2 | **Terms** | Short definitions: AI system, generative AI, prompt, output — three lines per term, not a treatise |
3 | **Approved tools** | A positive list with approval status; a named path for requesting new tools |
4 | **Data classes** | Which data may go into which tools — the most important section (see below) |
5 | **Permitted and prohibited use cases** | Concrete examples instead of abstract categories |
6 | **Human oversight** | Who reviews AI outputs before publication or a decision — staged by result type |
7 | **Labeling** | When AI involvement is documented internally and when it's disclosed externally |
8 | **Roles and responsibility** | Who approves tools, who's the subject-matter contact, who reports incidents |
9 | **Training and competence** | Who gets trained when, how it's documented |
10 | **Violations, incidents, and updates** | Reporting path for data breaches, consequences, review interval |
The core: data classes, not gut feeling
No section shapes effectiveness as much as this one. Instead of “be careful with sensitive data,” you need a classification that's applicable in five seconds during the workday. Three classes are usually enough:
Class | Examples | Rule |
|---|---|---|
**Green – free** | Published content, general subject-matter questions, anonymized drafts, public market data | Usable in all approved tools |
**Yellow – approved environments only** | Internal concepts, draft proposals, unpublished campaigns, process descriptions | Only in business accounts with a data processing agreement |
**Red – forbidden** | Personal data of third parties, health and applicant data, access credentials, security-relevant source code, contract data under confidentiality obligations | No input into external AI systems; only self-hosted models with individual approval |
The classes only work together with a clear statement about which accounts are business accounts. The difference between a personal subscription and a business workspace here isn't a matter of convenience, it's a liability issue — covered in ChatGPT for Business. The data protection fundamentals are covered in AI and Data Protection: Working GDPR-Compliant.
Three classes are enough: what matters is that everyone knows within seconds which data may go into which tool.
Staging human oversight correctly
Blanket statements like “all AI outputs must be reviewed” get ignored because they're unrealistic in daily practice. A staging by impact works better:
- Internal drafts (notes, brainstorming, rough copy): no formal review needed.
- External communication (website, proposal, newsletter, social): sign-off by a named subject-matter person, all figures and quotes cross-checked.
- Decisions affecting individuals (hiring, performance review, termination, creditworthiness): AI provides input at most, never the decision — and that gets documented.
- Technically high-risk outputs (law, medicine, finance, engineering): four-eyes principle with subject-matter qualification.
The reason for this staging isn't a formality: AI systems invent facts in the same confident tone as correct information. Why this happens structurally is explained in AI Hallucinations: Why AI Invents Facts.
A blanket review requirement gets ignored — staged by impact, it stays workable in daily practice.
Sample wording to reuse
These sentences can be carried over into your own document almost unchanged and adapted to your circumstances:
Scope: “This policy applies to all employees as well as to freelancers and service providers acting on behalf of the company. It applies to every use of AI-supported systems in a work context, regardless of which device or account is used.”
Tool approval: “For business purposes, only the tools listed in Appendix 1 may be used. Additional tools can be requested informally from [role]; review takes place within [X] business days and covers data protection, contract status, and suitability for the intended use.”
Data use: “Class Red data may not be entered into externally hosted AI systems. This also applies to excerpts, screenshots, and paraphrased versions. When in doubt, the higher class applies.”
Responsibility for outputs: “Responsibility for the substance of a work product remains fully with the person who submits or publishes it. Using an AI system does not release anyone from their duty of care.”
Labeling: “For externally published content that is substantially AI-generated, labeling follows the requirements in Section [X]. Editorially reworked drafts do not require labeling.”
Incidents: “If an impermissible input was made by accident, it must be reported to [role] immediately. A report by itself does not lead to any employment-law consequences; failing to report can.”
The last sentence matters more than it looks: punish reports, and you stop getting them.
Training as a mandatory component
Since February 2025, the EU AI Act has required that employees who use AI systems have adequate AI literacy. That's not a recommendation, and it applies regardless of the system's risk class. The policy should therefore state: who gets trained, with what, on what schedule and what the proof looks like. What that means in concrete terms is covered in Training obligation under Art. 4 of the EU AI Act; possible formats and ways to document it are collected in AI Training: Paths to AI Knowledge.
Works council, alignment, taking effect
AI tools are often subject to co-determination — particularly when they're capable of monitoring behavior or performance, which applies to usage logs in business workspaces. So bring in the works council early, not after the contract is signed. This sequence has proven itself: draft by the responsible subject-matter role, alignment with data protection and IT security, works council involvement, sign-off by management, communication to everyone with a short explanation — not just as a PDF attachment.
Also set a review interval realistically every six to twelve months. Tools, models, and the legal landscape move faster than traditional policies.
Common mistakes
Too long. Twenty pages of legalese don't get read. Three to six pages plus a tool appendix are enough.
Bans only. Without a positive list and a convenient request path, you get shadow IT instead of compliance.
No named role. “IT reviews it” isn't a responsibility. A name or a concrete function belongs here.
Written once, never touched again. A policy without an update date loses its authority within a year.
Published without a rollout. The policy is the framework; the rollout itself needs its own plan — see Introducing AI in Your Company: The Roadmap.
Conclusion
An AI policy works when it makes the permitted path clearer and more convenient than the secret one. At its core is a data-class system applicable in seconds in daily work, plus a positive list of approved tools, a review requirement staged by impact, and named accountable people. Legally, it's completed by documented training under the EU AI Act and alignment with data protection and the works council. Everything beyond that is trimming — and the shorter the policy, the greater the chance it actually gets read.
FAQ
Frequently Asked Questions
Four points are essential: a list of approved tools, a classification of which data may go into which tools, a rule for human review of outputs, and a named contact person. Everything else — labeling, training plan, reporting path — raises the quality, but without these four the document doesn't work.
Three to six pages for the rules section, plus an appendix with approved tools that can be updated separately. Longer documents tend not to get read and also go out of date faster, because they fix too many details in place.
A policy as such isn't explicitly required. What is required, though, are the obligations it fulfills: adequate AI literacy for employees under the EU AI Act, and documented technical and organizational measures under the GDPR. A written policy is the most practical way to demonstrate both.
As a rule, yes, as soon as the systems in use are capable of monitoring behavior or performance — usage logs in business workspaces usually meet that criterion. Involvement should begin before tool selection, not after the contract is signed.
Every six to twelve months on a fixed schedule, plus as needed for new tools, changed provider terms, or new legal requirements. A visible version date in the document helps, because it makes currency verifiable.
Quiz
Test Your Knowledge
Five questions on the structure, content, and effectiveness of an AI policy.
Question 1 of 5
Why does an AI policy consisting only of bans fail?