Monday morning, just after eight. A pilot with an AI assistant has been running in a department for four weeks, and the mood is good. Quotes get written faster, fault reports can be looked up quickly, and the first colleagues are asking when it will finally be available to everyone. Then an email arrives from the works council chair, three lines long. Who approved this deployment? What data is being recorded? And who can see it? The pilot is paused until those questions are answered.
This is an imagined scenario, not a customer case. But it is easy to picture in many companies, and it shows something important: the mistake is not that the works council asks questions. The mistake is that those questions were not asked four weeks earlier, when the answers could still be given calmly.
This article is general orientation for management, IT and HR. It describes where introducing AI typically touches co-determination, what a works council can sensibly want to see, and why a works agreement as a frame achieves more than a dozen one-off arrangements. This is not legal advice. Whether and to what extent co-determination rights apply depends on the individual case and belongs with your legal counsel.
The Thesis: The Works Council Is the Cheapest Reviewer
Many project teams treat the works council as a hurdle to be cleared as late and as quickly as possible. We think that is the most expensive option. At its core the council asks the questions that someone has to answer anyway, whether the data protection officer, IT security or the management: What do we use the system for? What data is created? Who may see what? What happens when something changes?
Answering these questions early gets you three things. First, better decisions, because a second perspective finds gaps before they show up in production. Second, predictability, because co-determination rights exist regardless of everyone's good will and cannot be wished away. Third, acceptance, because employees are more willing to use what they understand and what their representation has helped examine.
Answering the same questions late means answering them under pressure, with a running pilot behind you and a department waiting for results. That is the worst negotiating position for both sides.
One caveat up front: not every company has a works council. Where there is none, the questions do not disappear. Only the counterparts change, for example the data protection officer, the workforce or line managers. You can therefore also read the structure of this article as a checklist without a council.
Where AI Typically Touches Co-Determination
Three areas keep coming up when AI is introduced: the data traces a system creates, the training of employees, and changes to how work is organized. The graphic gives an overview.
Technical Systems for Monitoring Performance and Behavior
The best-known hook is section 87(1) no. 6 of the German Works Constitution Act (BetrVG). It gives the works council, where no statutory or collective-bargaining rule applies, a say in the introduction and use of technical systems that are intended to monitor the behavior or performance of employees. According to a widespread reading, it does not matter whether the employer wants to monitor. It is enough that the system is objectively suitable for it. That is why the sentence “We do not want to control anybody” is not enough on its own. It is an intention, and the agreement has to deliver more than an intention.
An AI assistant almost inevitably creates traces. That is not a design flaw but a consequence of what security, audit and operations demand anyway. The question is only which traces exist and who may evaluate them for what purpose.
| Data trace | What it contains | Why the council wants to see it |
|---|---|---|
| Chat history | Questions and answers of one person | It shows the content and working style of a single person |
| Audit log | Time, process, action, status, duration, person | It shows who triggered what, and when |
| Usage statistics | Frequency, times, volumes, possibly per person | It makes comparisons between people possible |
| Technical error log | Error messages and run times without names | It serves operations and troubleshooting |
None of these traces is a scandal in itself. An audit log is exactly what IT security and audit typically require. It becomes delicate once a trace can be tied to individual people and nobody has regulated what it may be used for.
One possible classification, which we mean as a negotiating proposal and not as a legal opinion, is shown in the traffic light below.
The red row deserves a comment. Nobody who wants to introduce AI sensibly needs a ranking of people by usage. Whether someone asks twelve or twenty questions a day says nothing about how well they work. What it does very well is sow mistrust. Excluding it in writing costs you nothing and gains you credibility.
Training
The second point is less spectacular but often more important. When an AI assistant changes tasks, the question arises whether existing skills are still enough. The Works Constitution Act recognizes co-determination rights for in-company vocational training measures, and some provisions are triggered when tasks change. Whether the conditions are met in a specific case is a question for your legal counsel.
Independently of that, Article 4 of the EU AI Act requires organizations that use AI systems to take measures for a sufficient level of AI literacy among their staff. A training plan belongs on the table anyway, and it is wise to treat it as a fixed part of the project and not as an extra. A usable training plan answers three things: What may the assistant do, and what not? How do you check an answer against its sources? What do you do when an answer is obviously wrong?
Work Organization
The third area concerns who will do what in the future. Section 90 of the Works Constitution Act provides information and consultation rights for the works council when technical facilities, work procedures and workflows are planned, and by its wording expressly includes the use of artificial intelligence. In addition, under section 80(3) the council may call in experts, by arrangement with the employer, where that is necessary for it to do its job properly. For assessing AI introductions, the statute expressly names this as necessary. Plan time and budget for it instead of reading it as distrust.
An example makes the question tangible. A workflow drafts the reply to a customer inquiry, in the explicitly fictional example about error E-217 on the filler FL-200, and one person approves it. Writing has turned into reviewing. Who reviews? Within what deadline? What happens if nobody reacts? These are questions of work organization, and they can be modeled concretely in a workflow, for example with an approval step with named people. The council does not want to prevent such processes, but to understand them before they apply to everyone.
What a Works Council Sensibly Wants to See
Good councils do not ask for architecture diagrams. They ask about effects. If you clarify five points before the first conversation, you have already answered most of the questions:
- Purpose: What is the system used for, and what expressly not?
- Data: What data is created, where does it live and how long does it stay? Data is stored in Germany and AI processing happens in the EU. The provider should be able to back that up contractually.
- Rights: What may the assistant read, what may it trigger on its own, and who decides on actions with external effect?
- Logs: Which logs exist, who may view them, and is that access itself traceable?
- Limits: What happens after the pilot, with new features or when changing providers?
For each of these questions there should be a verifiable answer, not just an assurance. The following table shows what that can look like.
| Council's question | What a good answer contains | How to prove it |
|---|---|---|
| Which documents does the assistant see? | Only what the person asking could open themselves | A test with two people with different rights |
| What may the AI trigger on its own? | Per tool one of the three settings Allow, Ask first, Block | The settings page for AI tools |
| Who decides on external effects? | An approval step with named people, a deadline and the four-eyes principle | Workflow editor, approval step |
| What is logged? | Time, process, action, status, duration, person | Audit log with filters and CSV export |
All four answers can be shown on the interface in TheroAI. What this looks like in your environment is something you should check with every provider yourself, ideally together with the council. A demonstration on the real system convinces more than any slide. Details on data storage and processing are on our security page.
Logs Show What Is Logged
The audit log is where co-determination and security meet. The table contains time, process, action, status, duration and person, and it can be filtered and exported as CSV.
Honestly, this log contains one column that needs to be talked about: the person. We think hiding it would be wrong. Anyone who operates a log with personal reference should discuss it openly with the works council and define who may read it for what purpose. A log nobody has explained makes employees suspicious. A log whose purpose and access are written into an agreement is evidence of reliability.
Rights per Tool Instead of Blanket Trust
The second piece of evidence a council appreciates is the permissions table for AI tools. Every tool is set to Allow, Ask first or Block. Read access runs without a prompt, while write actions carry their own label and stop at an approval.
The numbers in the picture come from our own demo environment and are an example, not a benchmark. What matters is the form: a list you can take into a works agreement as an annex and go through together is more concrete than any statement of intent.
Two Questions Not to Mix Up
A common misunderstanding goes: if the assistant only shows what a person may see anyway, the co-determination topic is settled. It is not. Permission mirroring answers the question of which documents an assistant may evaluate. The question of monitoring employees is a different one: it concerns the traces that arise while people work with the system. Both questions need an answer, and neither replaces the other.
For the second question, a simple matrix of who may see which trace helps. It is a proposal for the negotiation. Whether and how such a rule can be mapped in your configuration is something you have to check with your provider.
The matrix follows one idea: anyone who can see content needs a narrowly defined purpose for it. Anyone who needs only figures without names to steer capacity and quality gets them without restriction. That protects employees and takes nothing away from the operation that it really needs to run the application.
The Works Agreement as a Frame
Under section 77(4) of the Works Constitution Act, a works agreement applies directly and mandatorily. That makes it a strong instrument, but also one that should be built with care. The most common mistake is regulating every function individually. With AI applications the scope of functions keeps changing; in TheroAI alone, the connector catalog currently holds 29 apps. An agreement that lists every function by name is outdated before it is signed.
A layered structure works better: a framework agreement with the principles and three annexes that are easier to adapt.
The principles at the top rarely change. The annexes are adjusted more often, and operations underneath move fastest. When a new feature arrives, clarification runs through the affected annex and not through a new overall negotiation. Whether that suffices in an individual case depends on the wording and belongs in the hands of your legal counsel.
The Seven Building Blocks
The following table assigns the contents that have proven themselves in practice to the layers.
| Building block | What it contains | Where it sits |
|---|---|---|
| Purpose and scope | What the system is for, what expressly not, who it covers | Framework agreement |
| Ban on performance and behavior monitoring | No evaluation of individuals, exceptions narrow and named | Framework agreement |
| Data types and retention | Which traces arise and how long they stay | Logs annex |
| Access to logs | Who, when, why, and the access itself becomes traceable | Logs annex |
| Tools and rights | Per tool Allow, Ask first or Block, who makes changes | Tools annex |
| Training | Training before use, contact persons, handling of errors | Training annex |
| Pilot, evaluation and change | Duration, evaluation criteria, what triggers a new negotiation | Framework agreement |
Two building blocks deserve special attention. The ban on performance and behavior monitoring is only as good as its exceptions. Anyone who leaves exceptions open gives the council good reason for doubt. And the block “Pilot, evaluation and change” is the one that creates trust: if it is settled in advance what the pilot will be measured against, nobody can shift the criteria afterwards.
A Small Agreement for the Pilot
For the time before the framework agreement, a short pilot agreement is a good fit. It is time-limited, names a defined group, assumes test data or non-critical content and states that the evaluation does not look at individuals. That way the project can start without anyone having to fear a head start on the big agreement. If no agreement is reached, the law provides for a conciliation committee in cases of enforceable co-determination. But it is worth not letting it come to that.
The Path: Start Early and Plan Honestly
How much time this saves cannot be generalized. That is why we explicitly calculate an example here, with round assumptions that we chose and did not measure. Two paths are compared over twelve weeks: the late one, where the works council is involved only after four pilot weeks, and the early one, where things are clarified before the start.
| Assumption in the example | Late path | Early path |
|---|---|---|
| Clarification before the pilot | None | 2 weeks |
| Pilot before the stop | 4 weeks (week 0 to 4) | Not applicable |
| Stop and clarification | 6 weeks (week 4 to 10) | Not applicable |
| Pilot afterwards | 2 weeks (week 10 to 12) | 10 weeks (week 2 to 12) |
| Pilot weeks in total | 6 | 10 |
The calculation is deliberately simple: on the late path, 4 plus 2 equals 6 pilot weeks are available after twelve weeks, on the early path 12 minus 2 equals 10. The numbers are assumptions. What matters is the direction: in this example, two weeks of clarification before the start are far cheaper than a six-week stop in the middle of the pilot. Whether that holds for you only your own planning will show. And of course the early path can also take longer. Then it is at least a delay before the start and not an abort afterwards.
Five Steps That Hold Up
- 1.First conversation before the pilot. Present purpose, data types and rights, clarify the role of the council and name a date for the pilot agreement.
- 2.Pilot agreement. Time-limited, with a defined group, without evaluation of individuals.
- 3.Joint evaluation. The criteria are fixed before the pilot, and the council sees the same figures as the project lead.
- 4.Framework agreement. Negotiate principles and three annexes, with the pilot experience as material.
- 5.Rollout with training. Train first, then enable, and agree on a review date.
For industries with heavy documentation duties, such as manufacturing or healthcare, this sequence is especially worthwhile, because data questions are central there anyway.
Common Objections and What Lies Behind Them
“That takes too long.” That is true if you treat the works council as the last stop. As the first stop the work shifts, and it gets easier, because nothing running needs defending yet.
“We do not intend to monitor anyone.” That may be true, but it is not enough. As described above, under a widespread reading it is the objective suitability that counts. Precisely those who do not want monitoring have nothing against excluding it in writing.
“The provider says it is data protection compliant.” That answers a different question. Data processing on behalf under Article 28 GDPR governs the relationship between you and the provider. It does not govern the relationship between employer and workforce. Data protection and co-determination are two reviews, and both belong to the introduction.
“Then the works council will block the project.” A council can enforce co-determination rights, and that is its good right. In practice, though, it rarely blocks what it understands and was allowed to help shape. Delayed information is the most common reason for mistrust.
What You Can Take Away
If you are preparing an AI deployment, these checks help. They do not replace legal advice, but they put the preparation in order:
- Can we say in two sentences what the system is used for and what expressly not?
- Do we know which traces arise (chat history, audit log, usage statistics, error log) and who sees them?
- Do we have a rule that excludes rankings of individuals by usage?
- Is there a traceable setting per tool (Allow, Ask first, Block) that we can submit as an annex?
- Is a training plan in place before the feature is enabled for everyone?
- Have we approached the works council before the pilot, and are the evaluation criteria in writing?
- Have we answered the questions on co-determination and data protection separately?
Our position in one sentence: the works council is not an obstacle to AI in the company but the route by which it becomes sustainable. Whoever asks early gets an agreement that survives everyday life. Whoever asks late usually gets the same agreement, only later and on worse terms.
If you would like to see what logs, rights and approvals look like in a running system, we are happy to show it in a demo, also together with your council and without time pressure.
See Thero live
Book a short demo. You talk directly to the founding team.