AI policy for staff: structure, wording and a template to adopt

This guide covers the rules for staff, that is, what ends up on the intranet and in training. The agreement with employee representatives is covered in the guide on a model works or service agreement for AI, and the overall planning of a public administration in the guide on an AI strategy for municipalities.

What is an AI policy, and how does it differ from other sets of rules?

An AI policy is an instruction from management to staff: it says which AI tools are allowed at work, which data may go into them, who checks results and whom to contact. Other names for it are AI usage policy, AI guideline, service instruction on AI or AI handbook. The German Data Protection Conference (DSK, the body of German data protection authorities) expressly recommends such instructions: they should set out in documented form “whether, under which conditions and for which specific purposes” which AI applications may be used, ideally with examples of permitted and prohibited uses (guidance of 6 May 2024, section 2.2).

The policy does not replace any of the other rules; it complements them:

Set of rules	Issued by	Signed by	Content	Binding effect
AI policy, service instruction on AI	Management (managing directors, board, head of authority)	Management alone	Tools, data classes, duty to check, labelling, reporting channel	Instruction to staff (employer’s right to give instructions, civil service law)
Works or service agreement on AI	Management and employee representatives jointly	Both sides	Introduction of the system, logs, exclusion of performance and conduct monitoring, training, procedure for new apps	Has the effect of a legal norm for all staff (§ 77 BetrVG, § 63 BPersVG)
AI strategy	Management, in municipalities sometimes with a council resolution	Management	Goals, fields of application, procurement, measurement	Planning document, does not bind staff
Data protection policy, IT usage policy	Management	Management	Handling of personal data, devices, internet and email in general	Instruction; also applies to AI, but does not regulate it specifically

The AI policy refers to the other documents instead of repeating them. What is already there, such as password rules or private use of the internet, does not belong in it again.

Does every organisation need an AI policy?

No law expressly requires “an AI policy”. Several obligations, however, can hardly be met without written rules:

• AI literacy (Art. 4 AI Act): Anyone who deploys AI systems must take measures that promote the AI literacy of their staff. Since the amendment by Regulation (EU) 2026/1744 on 27 July 2026, a specific level is no longer owed, but the obligation remains. The Austrian AI Service Centre of the RTR recommends keeping an internal AI policy in writing and easy to access. Details in the guide AI literacy under Art. 4.
• Accountability in data protection: The controller must be able to demonstrate compliance with the principles (Art. 5(2) GDPR). It takes appropriate measures, which also include internal data protection policies (Art. 24 GDPR), and ensures that staff process data only on its instructions (Art. 29 and Art. 32(4) GDPR). An AI policy is such an instruction.
• Professional and official secrecy: Doctors, nurses, social workers and public officials must not disclose secrets without authorisation (§ 203 StGB, the German Criminal Code; § 37 BeamtStG; § 67 BBG). Staff must be able to know whether an AI tool is approved for this.
• Information security (NIS2): Particularly important and important entities need concepts for personnel security and access control as well as training and awareness (§ 30(2) no. 7 and 9 BSIG, in force since 6 December 2025).
• Shadow AI: According to a Bitkom survey from October 2025, four in ten companies assume that staff use private AI accounts for work. Without rules, each person decides for themselves what they copy into which service. More in the guide on shadow IT in public authorities.

In short: there is no obligation to have a policy as a document, but there are obligations that a policy covers in one step. For the federal administration, the AI guidelines of March 2025 state that the head of the authority decides whether and which AI systems may be used at work.

Why do organisations find an AI policy so hard?

Because it regulates a technology that changes quickly, and because many parties have a say. The concerns of those involved are legitimate. The usual hurdles can be overcome:

Hurdle	What lies behind it	Solution
Culture of prohibition	Out of caution, everything not expressly allowed is forbidden. Staff turn to private accounts.	An approved list instead of a list of bans: name the approved tools and offer a permitted alternative for confidential data.
Legalese	The text is correct, but nobody understands it without asking.	Short sentences, everyday examples for each rule, a one-page summary. The legal bases are in the annex.
Unclear responsibility	IT, data protection and HR wait for each other.	One unit gets the mandate and holds the pen; the others are involved on a fixed basis.
Rapid change of tools	Every new feature seems to require a new policy.	Principles in the main text, tools in an annex that is updated without a new procedure.
Fear of mistakes	Staff fear consequences if they get something wrong and do not report errors.	Set up a reporting channel without blame; report accidental entries rather than conceal them.
No alternative to private accounts	The policy forbids what staff need for their work.	Provide an approved tool before or while the rules apply. The DSK recommends that employers provide devices and accounts (section 2.4).

Which rules belong in an AI policy?

Twelve building blocks cover what is needed. The wording comes from the template below and is a suggestion, not reviewed clauses. Placeholders are in square brackets.

1. Scope

Purpose: Set out to whom and to which tools the policy applies, including AI features in familiar software.

Template: “This policy applies to all staff of [organisation], including trainees, interns and agency workers, when they use AI tools for work tasks. It applies to standalone AI tools and to AI features in other software, such as word processing, email or video conferencing.”

Common mistake: forgetting AI features in existing software. The Bavarian guide for staff points out that it is often not apparent whether an application uploads documents to third-party servers in the background.

2. Approved and non-approved tools

Purpose: Clarity about which tools are allowed. Everything else is not approved until it has been reviewed.

Template: “For work tasks, only AI tools listed in Annex 1 may be used, and only for the purposes and data classes stated there. You apply for new tools to [unit]. [Management] decides on approval after review by IT, information security and data protection.”

Common mistake: keeping a list of banned services. It is out of date on the day it is published.

3. Data classes as a traffic light

Purpose: Enable staff to decide quickly which information may go into which tool.

Class	Examples	Rule
Green: public	published texts, laws, press releases	into any approved tool
Yellow: internal	templates, internal processes, minutes without personal data	only into tools with a contract and approval for internal data
Orange: confidential	personal data, contracts, offers, security information	only into tools expressly approved for this (data processing, storage location, access rights clarified)
Red: specially protected	health, social and HR data, data under professional, tax or official secrecy	only into tools approved for exactly this data; otherwise not at all

Template: “Before you enter or upload information into an AI tool, assign it to a data class under Annex 2. If in doubt, the higher class applies. Even with approved tools, enter only what is needed for the task.”

Common mistake: considering data without names to be harmless. File numbers, addresses or details of a case often allow conclusions about individuals. The federal guidelines provide that where no classification is given, the most restrictive case applies (principle A3).

4. Private accounts and devices

Purpose: Prevent work data from leaking through accounts without a contract, and protect staff from profiles at third-party providers.

Template: “Work information of classes Yellow to Red must not be entered into private accounts of AI services. For work tasks, [organisation] provides the tools in Annex 1. If registration is needed for an approved tool, it is done with a functional work account in consultation with [IT].”

Common mistake: banning private accounts without offering an approved tool. The federal guidelines and the Bavarian guide advise against registering for freely available services with private accounts or with personal work accounts.

5. Duty to check and responsibility

Purpose: Make clear that AI delivers drafts and the person decides.

Template: “Results from AI tools are drafts. Check content, figures, names, dates and legal references against a reliable source before you use a result. Responsibility for the work result remains with you. Decisions about people are made by a person.”

Common mistake: writing only “check critically”. It is more helpful to say what to check and against what. The DSK also requires results to be checked for discrimination (section 3.4). If an AI is to decide on hiring, promotion or dismissal, that is high-risk AI under Annex III no. 4 of the AI Act, see Identifying high-risk AI.

6. Labelling

Purpose: Meet the obligations under Art. 50 of the AI Act and handle AI results consistently internally.

Template: “Label images, videos and audio recordings created or altered with AI that could show real people, places or events as AI-generated. Texts that [organisation] publishes are checked by a responsible person before publication. A chat service for citizens, patients or customers must make clear that an AI is answering.”

Common mistake: requiring every email that AI helped with to be labelled. Art. 50 does not require this; internal drafts that a person checks are generally not covered. More in the guide Transparency obligations under Art. 50.

7. Copyright and sources

Purpose: Respect the rights of others and know what is protected in AI results.

Template: “Upload third-party texts, images or data only if [organisation] may use them for this purpose. Before publication, check AI results for whether they reproduce third-party works. Adopt quotations and references only once you have found them in the source.”

Common mistake: assuming that an AI result automatically belongs to the organisation. Copyright protects only personal intellectual creations (§ 2(2) UrhG, the German Copyright Act); purely machine-generated content is generally not protected. Whether uploading third-party works into an AI tool is permitted as text and data mining under § 44b UrhG has not been settled. The rule “only what we may use” keeps you on the safe side.

8. Agents and actions that AI carries out itself

Purpose: Rules for AI that does not only write texts but sends emails, creates appointments or changes data in systems.

Template: “AI tools may only carry out actions in other systems, such as sending, changing, deleting or booking, if a responsible person has confirmed the individual action beforehand. An AI tool acts only with the permissions of the person using it. [Unit] approves workflows that carry out recurring tasks on their own before they are used.”

Common mistake: not mentioning agents in the policy because they do not exist yet. Many tools bring such features with updates. Hidden instructions in documents or web pages also play a role, see Manipulated instructions in documents.

9. Training

Purpose: Meet Art. 4 of the AI Act and make the rules understandable.

Template: “Anyone who uses AI tools at work first attends training that [organisation] offers during working hours. It covers how AI works and its limits, this policy and examples from your area of work. [Organisation] documents attendance and refreshes the training when there are significant changes.”

Common mistake: training as a one-off formality. The federal guidelines provide for a training offer that is available before introduction. For in-company training, the works council has a say (§ 98 BetrVG); at federal level, the staff council has a say on general questions of further training (§ 80(1) no. 10 BPersVG). Templates in the guide AI literacy under Art. 4.

10. Contacts and reporting channel

Purpose: Answer questions and learn about errors early.

Template: “Questions on AI use are answered by [name, contact]. If you have accidentally entered data into a tool that is not approved for it, or if an incorrect AI result has reached the outside world, report this without delay to [data protection, information security]. Anyone who reports an error helps to limit damage.”

Common mistake: not setting a reporting channel. For personal data breaches, the deadline for notifying the supervisory authority under Art. 33 GDPR is generally 72 hours. The Bavarian guide provides for informing the data protection officer when personal data has been entered by mistake.

11. Breaches

Purpose: Take them seriously without deterring people.

Template: “Breaches of this policy may have consequences under employment or civil service law. [Organisation] takes the circumstances of the individual case into account, in particular whether a breach was self-reported. Criminal law provisions protecting secrets remain unaffected.”

Common mistake: threatening dismissal. That drives use underground. Proportionality and self-reporting belong in the text.

12. Review and amendment

Purpose: Keep the policy up to date.

Template: “[Unit] reviews this policy at least once a year and when there are significant changes in law or tools. [Unit] updates Annexes 1 and 2 according to the procedure in section 3. Changes are recorded in the change log (Annex 4) and communicated to staff.”

Common mistake: no version date and no responsibility. The DSK recommends a routine for regularly reviewing internal requirements (section 2.8).

How specific should the policy be?

Specific enough that a person with no prior knowledge of AI can decide in ten seconds whether they may do something. Four tools help:

• Approved list: tool, permitted purposes, highest permitted data class, contact. One line per tool.
• Everyday examples: two cases from your organisation for each data class, such as “rephrase the invitation to the summer party: green” or “summarise a nursing report: red, only in [approved tool]”. The DSK expressly recommends examples of permitted and prohibited uses.
• One-page summary: the ten most important rules for training, notice boards and the intranet. The template contains one (Annex 3).
• Language: formal address, active sentences, one rule per sentence. Explain technical terms such as “data processing on behalf” once or move them to the annex.

How long? For the main text, three to six pages are usually enough. What changes often goes into annexes. That way a new tool changes the annex, not the policy.

How is an AI policy drawn up, and when are employee representatives involved?

In six steps, over a few weeks. Who is involved:

Party	Task
Management	gives the mandate, decides on tools, issues the policy
IT and information security	review tools, accounts, storage locations, permissions
Data protection officer	advises on data classes, data processing agreements and data protection impact assessments; according to the DSK, should always be involved (section 1.12)
Works council, staff council, church employee representative body (MAV)	information, codetermination on the introduction of the system and on training
Specialist departments	provide use cases and examples
Representative body for severely disabled employees, equal opportunities officer	are involved under their own laws, for example under § 178(2) SGB IX; the federal guidelines expressly name the representative body for severely disabled employees

1. Take stock: Which AI tools are already in use, officially and unofficially? An anonymous survey often reveals more than a ban.
2. Provide or select a tool: Without a permitted alternative, the policy remains a ban. For data of classes Orange and Red, this includes a contract, storage location and, where applicable, a data protection impact assessment.
3. Write the draft: one unit holds the pen, the template as a basis, examples from the specialist departments.
4. Involve employee representatives: early and with documents, see below.
5. Issue and announce: on the intranet with a version date, via the one-page summary and in training. Acknowledgement can be combined with the training confirmation.
6. Train and review: training before use, review after one year.

When do employee representatives have a say? Two things must be kept apart: the policy itself and the system it regulates.

• The rules for work: The Hamburg Labour Court ruled that requirements for the use of AI services concern work conduct and are therefore not subject to codetermination under § 87(1) no. 1 BetrVG (Works Constitution Act; order of the establishment) (decision of 16 January 2024, 24 BVGa 1/24). It is an urgent decision at first instance. In public-sector staff representation law, § 80(1) no. 18 BPersVG names order in the office and the conduct of staff; whether an AI policy falls under it has not been settled by the courts.
• The system provided: In the same proceedings, codetermination under § 87(1) no. 6 BetrVG was lacking only because staff used the service in the browser with private accounts and the employer received no data. If the organisation provides an AI system of its own, it is as a rule objectively capable of monitoring conduct or performance. Employee representatives then have a say: under § 87(1) no. 6 BetrVG, § 80(1) no. 21 BPersVG, the staff representation act of the federal state, § 36(1) MAVO or § 40(k) MVG-EKD.
• Further rights: information when AI is being planned (§ 90 BetrVG), experts (§ 80(3) BetrVG), training (§ 98 BetrVG, § 80(1) no. 10 BPersVG), fundamentally new working methods (§ 80(1) no. 20 BPersVG).

In practice, the policy and the works or service agreement are agreed together: the agreement regulates logs and the exclusion of performance monitoring, the policy regulates day-to-day conduct. The DSK names both routes side by side (section 2.2). For employee data: since the CJEU judgment of 30 March 2023 (C-34/21), a general national legal basis such as § 26(1) BDSG (Federal Data Protection Act) only holds if it meets Art. 88 GDPR; a carefully worded agreement with a clear purpose therefore gains weight. Details in the guide Codetermination on AI.

What also applies in hospitals, municipalities, critical infrastructure and health insurers?

The twelve building blocks fit everywhere. Four areas need additional rules in the data traffic light and the approved list:

• Hospitals and care: Patient data are health data (Art. 9 GDPR) and subject to medical confidentiality (§ 203 StGB). An AI tool for such data needs a provider that is bound to confidentiality as a contributing person, and a data processing agreement. On top of this come the state hospital acts, such as Art. 27(4) and (6) BayKrG, which contain their own conditions for processing on behalf of others. See the guide on § 203 StGB and AI. Church-run organisations check the KDG or DSG-EKD (Catholic and Protestant church data protection laws), see the guide on church data protection.
• Municipalities and public authorities: Official information is subject to official secrecy (§ 37 BeamtStG, § 67 BBG, for public-sector employees § 3 TVöD). An approved tool with a contract makes the processing an internal official communication; a freely available service is a third party. Tax, social and registration data have their own secrecy rules. See the guide on official secrecy and AI.
• Critical infrastructure and NIS2 entities: The policy becomes part of information security management (§ 30 BSIG); management implements the measures, monitors them and regularly attends training itself (§ 38 BSIG). Security information such as network plans or access credentials belongs in class Red. Classified information is subject to the rules on protection of classified information; the federal guidelines expressly name protection of classified information as a criterion for approval, and the Bavarian guide excludes classified information from freely available services. See ISO 27001 and NIS2.
• Health and long-term care insurers, Medical Service: Social data are subject to social secrecy (§ 35 SGB I). Processing on behalf of others must be notified to the supervisory authority in advance (§ 80 SGB X), and cloud services for social and health data need a C5 attestation or equivalent proof (§ 393 SGB V). The Medical Service may process social data only for its reviews and opinions (§ 276(2) SGB V). See the guide on tax and social secrecy.

How do you keep the AI policy up to date?

With a fixed responsibility, a review cycle and a log of changes:

• Responsibility: One unit maintains the policy and annexes, usually IT, digitalisation or information security, together with data protection.
• Review cycle: at least annually, and also with new tools, new features such as agents, new laws or guidelines and after incidents. The AI Act is being supplemented continuously, see EU AI Act overview.
• Change log: date, section, change, reason, involvement of employee representatives. This is also evidence for Art. 4 of the AI Act and Art. 5(2) GDPR.
• Communication: announce changes on the intranet, update the one-page summary and take them up in the next training. A version date on every page prevents old printouts from remaining in force.

What is different in Austria and Switzerland?

Austria: The AI Act applies directly, as in Germany, including Art. 4. The Data Protection Authority generally regards the body that deploys an AI system as the controller under data protection law and recommends setting out internally which data may be processed with the system. The AI Service Centre of the RTR recommends a written AI strategy, an easily accessible internal AI policy and a training concept, and refers to model policies of the Austrian Economic Chamber. Codetermination: control systems that affect human dignity require a works agreement (§ 96(1) item 3 ArbVG); systems that process employee data beyond general information require the consent of the works council (§ 96a ArbVG). In the public service, official secrecy has been replaced by the Freedom of Information Act since 1 September 2025; what § 6 IFG protects remains secret. See Austria: DSG and official secrecy.

Switzerland: There is no dedicated AI law; the FDPIC considers the Data Protection Act technology-neutral and directly applicable to AI, and data subjects should be able to recognise whether they are communicating with an AI system. Professional secrecy holders involve providers as auxiliaries (Art. 321 of the Swiss Criminal Code), see Professional secrecy in Switzerland. There is no codetermination right as in Germany: employee representatives have a right to information and special participation rights, for example on occupational safety (Art. 9 and 10 Participation Act), and systems for monitoring conduct at the workplace are prohibited (Art. 26 ArGV 3). The AI Act affects Swiss organisations only if they offer AI in the EU or results are used there. Here too, an AI policy is the usual way to bundle instructions and data protection requirements. See Switzerland: FADP and AI.

What changes in the policy with an AI platform?

Many rules can be implemented technically instead of only being written down. On an AI platform such as basebox, your staff use only what your administrator has enabled: apps, connections to systems and AI models. Apps are shared with groups from your identity management or with individual people, and the AI may never do more than the person using it; sharing an app shares its documents, never your own access. An app with an external model exists only if you have it set up, and web search is off by default. Your administrator sets usage policies and system instructions centrally. The audit log records actions, and content only if you switch it on. Agents act with the person’s permissions, and write actions run only after approval by a person; with the App Builder from November 2026, you describe a task and the agents turn it into an app that carries it out. The policy then needs to forbid less and can explain more: what the tool is meant for, how to check results and whom to ask. Details on Security and on the logs.

Not legal advice: This guide and the template reflect the state of research as of 12 October 2026. State staff representation acts, church law and state hospital acts differ in detail, and case law on codetermination for AI is still thin. Have your policy reviewed by your data protection officer, legal department and employee representatives.