Why almost every AI workflow is subject to co-determination
The key provision is section 87(1) no. 6 of the German Works Constitution Act (BetrVG). Under it, the works council has a say in the introduction and use of technical equipment intended to monitor the behaviour or performance of employees. The word "intended" is misleading: according to the established case law of the German Federal Labour Court, it is enough that the equipment is objectively capable of doing so. Whether the employer actually wants to evaluate the data is irrelevant.
An AI workflow that works in your systems almost always logs who processed, approved or corrected a task. That makes it capable of monitoring, and therefore subject to co-determination. So the question in normal cases is not whether the works council has a say, but over what and how early.
There are borderline cases. On 16 January 2024 (case no. 24 BVGa 1/24), the Hamburg Labour Court ruled that permission to use a chat tool via private accounts in the browser was not subject to co-determination under section 87(1) no. 6, because the employer received no usage data. That is a first-instance decision on a special case. It cannot be relied on for a workflow that is built into the CRM, ERP or mailbox and keeps a log.
The works council's rights at a glance
Besides section 87(1) no. 6, further provisions regularly apply when AI is introduced. Since the Works Council Modernisation Act of 2021, the statute has mentioned artificial intelligence explicitly in several places.
| Provision | What it is about | What it means in practice |
|---|---|---|
| Section 90(1) no. 3 Works Constitution Act | Information and consultation on the planning of working procedures and workflows, expressly including the use of AI | In good time, with documents, while things can still be changed. Not only once the workflow is running. |
| Section 87(1) no. 6 Works Constitution Act | Co-determination on technical equipment capable of monitoring behaviour or performance | No introduction without consent. If no agreement is reached, the conciliation committee (Einigungsstelle) decides (section 87(2), section 76). |
| Section 87(1) no. 1 Works Constitution Act | Order in the establishment and conduct of employees | Binding rules on how employees should use AI tools may fall under this. |
| Section 95(2a) Works Constitution Act | Selection guidelines for recruitment, transfer, dismissal | Co-determination also applies if the guideline is drawn up or applied with the help of AI. Relevant to any pre-selection of applicants. |
| Section 80(3) sentence 2 Works Constitution Act | Calling in an expert | If the works council has to assess an AI introduction, an expert is deemed necessary. Plan for this instead of fending it off. |
| Section 111 sentence 3 no. 5 Works Constitution Act | Change to operations through fundamentally new working methods | To be examined for major changes in companies with more than 20 employees entitled to vote. A single workflow rarely reaches this threshold. |
| EU AI Act, Regulation (EU) 2024/1689, Article 26(7) | Information before a high-risk system is put into service in the workplace | Applies in addition if a workflow falls under Annex III, for example applications or performance assessment. |
In data protection terms, a works agreement under Article 88 GDPR can itself be the legal basis for processing employee data. It must then contain suitable and specific measures to protect employees. The GDPR's requirements, for example on transparency and purpose limitation, also apply within the agreement.
A framework agreement instead of individual negotiations
Negotiating every workflow separately means a great deal of negotiating. What has proven effective is a framework works agreement on AI that sets out the principles once: purpose, exclusion of performance monitoring, logging rules, deletion periods, involvement in changes. Each new workflow then gets an annex, a two-page profile: what the workflow does, which data it processes, what it logs, who has access, where the model runs. The works council checks the annex against the principles instead of starting from scratch every time.
This saves both sides time and has a second advantage: the profile is also the description that the data protection officer, IT and the business department need. One document for four readers.
What a workflow may log, and what it does not need
This is what decides whether a workflow is seen as a tool or as surveillance. The principle is: a workflow logs tasks, not people. For operation, troubleshooting and traceability you almost never need evaluations of individual employees. You can take the following breakdown straight into an annex.
| Log content | What it is needed for | Recommendation |
|---|---|---|
| Task identifier, time, rule applied, result of the check | Operation, troubleshooting, evidence of why a text reads as it does | Record. No link to employees. |
| Technical errors, run times, volumes, model version | Monitoring the workflow | Record. No link to employees. |
| Who approved a task | Traceability for legally relevant outputs, such as regulated texts or customer replies | Record, but limited to that purpose: access only in individual cases by named roles, no evaluation by person, fixed deletion period. |
| Processing time or correction rate per employee | Not needed for the workflow | Do not collect. Where a figure is needed for management, only for teams above a fixed minimum size. |
| Content of the texts and emails processed | Troubleshooting in individual cases | Not in the log. The log contains identifiers; the content stays in the source system. |
| Employees' inputs into a chat tool | Quality improvement | Only anonymised or not at all. Otherwise an aid turns into a diary. |
What matters is that these rules do not only exist on paper. A workflow should be built so that it never produces data that the rules do not provide for. What is not logged cannot be evaluated by anyone, and for the works council that is the most convincing argument.
Checklist for a works agreement on AI
These points belong in a framework agreement or in the agreement on an individual workflow. This is meant as a working list, not a model text.
- Subject matter and scope: which workflows and systems, which establishments and groups of employees.
- Purpose: what the workflow is used for, described exhaustively.
- Exclusion of performance and behaviour monitoring: explicitly, with the list of evaluations that are permitted (volumes, errors, run times of the workflow).
- Log content as a positive list: what is recorded, and nothing else.
- Access rights: which roles see what, access to individual logs only for a documented reason.
- Storage and deletion periods per type of data, with proof of deletion.
- Operating mode and data location: on your own servers, EU data centre or cloud under a data processing agreement, with the model providers used.
- Human decision: no workflow makes decisions on HR measures; this is also in line with Article 22 GDPR.
- Use against employees: data from the workflow is not used for employment law measures. Whether such a prohibition on use holds up in court is disputed; as a purpose limitation within the company it still works.
- Changes: what must be resubmitted (new purpose, new types of data, new log content, change of operating mode) and what is not (change of model version with the same function, adjustment of text rules). This point saves most negotiations later on.
- Training: training for those involved, which also serves as evidence of AI literacy under Article 4 of the EU AI Act; where activities change, involvement under section 97(2) of the Works Constitution Act.
- Inspection rights: the works council's access to the logging configuration, calling in an expert.
- Complaints procedure for employees who consider an output of the workflow to be wrong.
- Review after a fixed period, for example six months of operation, and rules on termination and continued effect after termination.
The employees belong at the table, not just the works council
The concern behind many objections is rarely data protection. It is the question of what will happen to their own work. There is an honest answer to that if the workflow is designed properly: it takes over the copying, checking and transferring, the work nobody likes doing. The decisions stay with the people, and they get more time for them.
This answer is only convincing if the people affected experience it themselves. That is why we begin every workflow analysis with conversations with the people who do the work today, and have them check the outputs in the trial run. Anyone who has helped write the rules by which the workflow operates does not fear it. An example: at a technical distributor with around 2,000 employees, the rules for distributing enquiries had to be adjusted twice for edge cases, such as a customer in one country with delivery to another. The people in sales know such cases, not the analysis; more on this in the case study on distributing enquiries in five languages.
What we supply for the negotiations
For every workflow we build, we provide the documents a works council needs for its assessment. They include the description of the workflow, the data flow sketch from the analysis, the list of log content, the roles and permissions concept and a statement of where each model runs. This is not extra effort, but the same documentation that your IT receives at handover. How we handle data is described on our data sovereignty page. Tools for HR, where co-determination is most extensive, are covered under Tools that fit you.
If your company has no works council, the rights under the Works Constitution Act do not apply. Data protection law, the EU AI Act and the obligation to inform employees about the processing of their data remain. This article reflects the position as of October 2026 and is not legal advice; for the agreement itself, involve your legal advisers.
What this means for you
Treat the works council as a participant from week one, not as a hurdle before the start. Inform it under section 90 as soon as a workflow becomes concrete, present the profile with the positive list for the log, and use a framework agreement to settle which changes must be resubmitted. Then the question "Can you use this to see who answers how quickly?" becomes a sentence in the annex: no, the workflow does not record that. Our checklist for introducing AI on a sound legal footing shows which other points should be settled before the start, from the legal basis to the contract with the service provider.
Further reading
- The EU AI Act for mid-sized companies: which obligations arise for which workflows
- Case study: enquiries and advice in five languages at a technical distributor
- Service: tools that fit you
- Data sovereignty: data flow per service
- Industry: AI in mechanical engineering, with the works council in production
