Works Council and AI Agents: When German Co-Determination Applies to Your Rollout, and How to Get the Betriebsvereinbarung Right

A German manufacturer signs off on an AI agent to handle invoice matching and supplier follow-ups. IT is ready. The budget is approved. Then the works council asks one question: “What does this system log about our people, and who can see it?” Nobody has a clear answer. The rollout stops for four months.

This is not a rare edge case. In a company with a works council (Betriebsrat), the introduction of an AI agent is almost always a co-determined matter under German law. Get the Mitbestimmung conversation right and it becomes a two-week formality. Get it wrong and you face an Einigungsstelle, an injunction, or a system you have to switch off after go-live.

This guide is for the Geschaeftsfuehrer, CTO, or operations lead at a German company who wants to deploy AI agents without turning the works council into a blocker. It covers exactly when co-determination is triggered, what the council can and cannot demand, and how to write a framework Betriebsvereinbarung that unblocks rollout instead of stalling it. It is DACH-specific by design.

The Stalled Rollout: Why AI Projects Hit the Works Council Wall

AI adoption in Germany is no longer experimental. Bitkom found that 36 percent of companies now use AI, nearly double the prior year, and another 47 percent are planning or discussing it¹⁶. But adoption inside a co-determined workplace runs into a legal reality most project plans ignore: the works council has a real say, and it is not optional.

• The trigger is broad - Section 87(1) No. 6 BetrVG covers any technical system suitable to monitor behaviour or performance, and courts read that expansively¹.
• AI agents log everything - who asked what, which records were touched, when, and by whom. That granular logging is exactly what makes them objectively suitable to monitor³.
• Intent does not save you - the BAG has confirmed that whether you plan to monitor is irrelevant; suitability alone triggers the right².
• The cost of skipping it is high - a works council can seek an injunction to stop use and, in principle, demand the system be removed¹.
• Timing compounds the pain - retrofitting an agreement after a contested launch takes longer and costs more than agreeing one first.
• A second layer is arriving - the EU AI Act adds its own worker-information duty for high-risk systems from August 2026¹⁰.

The good news: none of this makes AI rollout impossible. It makes preparation mandatory. The companies that move fastest are the ones that treat the works council as a design input, not an obstacle.

Why Co-Determination Applies to AI Agents

Mitbestimmung is not a courtesy. It is a hard legal right that changes who gets to decide. Understanding the difference between information rights and genuine co-determination is the foundation of every AI rollout in a co-determined company.

Information rights versus co-determination

• Information (Section 80, Section 90) - the employer must inform the works council and consult it in good time, but can ultimately proceed with the decision^6,7.
• Co-determination (Section 87) - the employer cannot lawfully introduce or operate the measure without the council agreeing, or an Einigungsstelle deciding in its place¹.
• The practical gap - an information right slows you down; a co-determination right can stop you entirely until agreement is reached.
• Why AI lands in the strong category - because AI agents are technical systems suitable to monitor, they fall squarely under Section 87(1) No. 6, the co-determination bucket, not merely the information bucket^1,2.

What the law actually says

Section 87(1) No. 6 BetrVG gives the works council co-determination on “the introduction and use of technical devices designed to monitor the behaviour or performance of employees”¹. Two words carry the weight: “designed to”. German courts do not read this as employer intent. They read it as objective suitability.

What Triggers Section 87(1) No. 6: The Objective Suitability Test

The single most important legal concept for AI rollouts is the objective suitability test. Once you understand it, you can predict with high accuracy whether any given deployment needs a works agreement.

The test in one sentence

A technical system is subject to co-determination if it is objectively capable of collecting or evaluating data about employee behaviour or performance, whether or not the employer intends to use it that way^2,3. Intent, actual use, and even whether the monitoring feature is switched on are all irrelevant to the trigger.

• Logging is enough - if the system records who did what and when, it can be cross-referenced to individuals, so it is suitable to monitor³.
• Real-time capability counts - in the headset case, the mere possibility of a supervisor listening in was enough, without any recording².
• Aggregation matters - data that seems anonymous can become performance data once combined with schedules, user IDs, or timestamps².
• AI raises the stakes - agents log prompts, actions, outcomes, and corrections, which is richer behavioural data than most legacy tools ever produced³.
• Cloud and third-party tools included - the trigger does not care where the software runs, only whether the employer can access monitoring-relevant data.

The narrow exception: private tools you cannot see

There is one meaningful escape hatch, and it is narrow. The Arbeitsgericht Hamburg (16 January 2024, 24 BVGa 1/24) found no co-determination right where an employer merely permitted non-mandatory use of employees own private ChatGPT accounts and had no access to usage data⁵.

For AI agents connected to real company systems, the exception almost never applies. The moment you provide the infrastructure or can read the logs, you are back in Section 87 territory. Plan accordingly.

What the Works Council Can and Cannot Demand

A common fear is that co-determination hands the works council a veto over your business strategy. It does not. The right is specific: it covers how a monitoring-capable system is introduced and used, not whether you are allowed to automate work at all.

What the works council can legitimately demand

• No covert monitoring - a ban on secret behavioural surveillance and on using logs for hidden performance ranking¹.
• Purpose limitation - logs used only for defined purposes such as security, audit, and error correction, not general employee assessment.
• No automated discipline - a rule that AI outputs cannot trigger warnings or dismissals without human review.
• Data minimisation and deletion - retention limits and access restrictions on who can view usage data.
• Transparency - a clear, understandable description of what the system does and what it records.
• Involvement in changes - the right to be consulted again when the system is materially changed or extended.
• An external expert - under Section 80(3) BetrVG, a Sachverstaendiger at the employer expense where genuinely needed, subject to agreement on scope and cost⁷.
• Training and qualification - support for employees to work with the new tools, which also aligns with the EU AI Act literacy duty¹¹.

What the works council cannot demand

• A veto on automation itself - the decision to automate a process is an entrepreneurial one, outside co-determination.
• Control over headcount strategy - staffing decisions are governed by other provisions, not Section 87(1) No. 6.
• Choice of vendor for its own sake - the council co-determines the monitoring dimension, not your commercial procurement.
• Indefinite delay - a deadlock goes to the Einigungsstelle, whose decision replaces agreement⁹.
• Rules unrelated to monitoring - demands with no link to behaviour or performance data fall outside this specific right.

The Full Legal Map: BetrVG, EU AI Act, and GDPR

Co-determination is the headline, but it is not the only duty attached to an AI rollout. Three legal regimes overlap, and they land at different times. Mapping them once saves you from nasty surprises mid-project.

Layer 1: German works constitution (BetrVG)

• Section 87(1) No. 6 - mandatory co-determination for monitoring-suitable systems, the core AI trigger¹.
• Section 90 - the employer must inform and consult the council in good time when planning technical equipment and work processes, early enough that concerns can still shape the plan⁶.
• Section 80 - general information rights and the basis for an external expert under Section 80(3)⁷.
• Section 111 - if the AI rollout amounts to a major operational change, a reconciliation of interests and a social plan may be required⁸.
• Section 76 - the Einigungsstelle resolves deadlock with a binding decision when the parties cannot agree⁹.

Layer 2: EU AI Act

• Article 26(7) - deployers who are employers must inform worker representatives and affected employees before putting a high-risk AI system into use at the workplace¹⁰.
• High-risk timing - deployer obligations for high-risk systems apply from 2 August 2026¹².
• Article 4 literacy - providers and deployers must ensure staff have sufficient AI competence, a duty already in force¹¹.
• Risk classification first - most internal process agents are not high-risk, but employment-related uses such as hiring or performance evaluation can be¹⁰.
• It stacks, it does not replace - the AI Act duty sits on top of German co-determination, not instead of it.

Layer 3: Data protection (GDPR and BDSG)

• Employment context - Article 88 GDPR and Section 26 BDSG govern processing of employee data^13,14.
• Lawful basis - a works agreement can itself serve as a legal basis for processing under Article 88 GDPR¹⁴.
• Impact assessment - higher-risk processing needs a data protection impact assessment (DPIA) before launch.
• No constant surveillance pressure - continuous behavioural monitoring that creates permanent pressure is impermissible and reinforces the council position.
• Handle it together - the DPIA and the works agreement should be developed in parallel, since they share the same facts.

The Framework Betriebsvereinbarung That Unblocks Rollout

The mistake that kills momentum is negotiating a fresh agreement for every new AI tool. The alternative, recommended by Bitkom, is a Rahmenbetriebsvereinbarung: a framework agreement that sets the rules once, then admits individual agents through a light annex or approval step¹⁵.

Why a framework agreement beats tool-by-tool deals

• Define governance once - the hard questions about monitoring, data, and oversight are settled a single time.
• Add tools quickly - a new agent enters through an annex describing its scope and data, not a full renegotiation.
• Predictable for both sides - the council knows the guardrails; the business knows the timeline.
• Scales across departments - the same framework covers finance, HR, service, and operations agents.
• Reduces conflict - most disputes are about principles; settle the principles and individual tools become routine.

The clauses that most often cause friction

1. Log access - who inside the company can see agent logs, and under what conditions. Narrow, role-based access resolves most concerns.
2. Performance evaluation - an explicit exclusion of individual performance ranking from agent data is often the deal-maker.
3. Retention - short, defined deletion periods signal that logs exist for security and audit, not surveillance.
4. Scope of the annex process - agreeing lead times (for example, a two-week review window per new agent) keeps rollout fast and predictable.
5. Change management - defining what counts as a “material change” that reopens consultation prevents future disputes.

The Co-Determination Rollout Playbook

A works agreement does not have to take a year. With preparation, a framework agreement is realistic in two to four months. Here is the sequence that keeps rollout moving.

Phase 1: Prepare before you talk (Weeks 1-3)

1. Map the system - write a plain-language description of what the agent does, which systems it touches, and what it logs. The council cannot assess what it cannot see.
2. Draw the data flows - document every data source, where employee data appears, and who can access logs. This single artefact defuses most monitoring fears.
3. Classify the risk - determine the EU AI Act risk category and whether Article 26(7) applies, and start the DPIA in parallel^10,12.
4. Draft the guardrails - bring proposed answers on purpose limitation, retention, and no automated discipline, rather than an empty page.

Phase 2: Involve the council early (Weeks 4-8)

5. Brief before you build - present the plan under Section 90 while there is still room to shape it, which builds goodwill⁶.
6. Offer a shared expert - propose a Section 80(3) Sachverstaendiger early to level the knowledge gap and speed agreement⁷.
7. Run a live demo - let council members see exactly what the agent does and what it records. Transparency beats reassurance.
8. Negotiate the framework - focus on principles, not the specific tool, so the agreement covers future agents too.

Phase 3: Deploy and maintain (Weeks 9-16)

9. Sign the framework and first annex - the framework plus one tool-specific annex lets you launch the first agent.
10. Pilot with the guardrails on - deploy to a limited scope with the agreed logging, access, and oversight rules active.
11. Report back - share how the agent is used and confirm that logs are handled as agreed, reinforcing trust.
12. Add the next agent via annex - subsequent tools enter through the light annex process, not a fresh negotiation.

How Superkind Fits the Works Council Conversation

Superkind builds AI employees: custom AI agents connected to a company real systems, with a Company Brain that holds company-specific knowledge and processes. The relevant point for co-determination is not marketing. It is that transparency and audit trails are built in, which is exactly what makes the Mitbestimmung conversation easier, not a way to sidestep it.

• Defined scope per agent - each AI employee has a clear, documented job description, which maps directly onto an annex in a framework agreement.
• Audit trails by design - every action the agent takes is logged and attributable, so you can show the council precisely what happens and prove purpose limitation.
• Company Brain, not covert profiling - the knowledge base stores processes and documents, not secret behavioural scores on individual employees.
• Human oversight built in - critical actions can require human review, supporting a no-automated-discipline clause.
• Connects to your systems - it works on top of your existing email, SharePoint, CRM, and ERP rather than introducing hidden data collection.
• Transparent data flows - the integration map is explicit, which is the exact artefact the works council and the DPIA both need.
• Role-based access - who can see logs and outputs is configurable, matching agreed access-restriction clauses.
• Governance you can show - the same documentation supports the works agreement, the DPIA, and the EU AI Act information duty.

Decision Framework: Do You Need a Works Agreement?

Use this framework to decide quickly whether a given AI deployment needs co-determination, and how urgent the works council conversation is.

Frequently Asked Questions

Related Articles

• EU AI Act 2026: What the Mittelstand Must Know Before August
• DPIA for AI Agents: Implementing GDPR Article 35 for Agent Rollouts
• Shadow AI in the Mittelstand: The Governance Playbook
• Human-in-the-Loop: Building Trust in AI Agents
• NIS2 Meets AI Agents: Securing Agent Deployments
• AI Agents for the Mittelstand: How Hidden Champions Deploy AI

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He has seen how many rollouts stall not on technology but on governance, and believes the works council conversation is far easier when transparency and audit trails are built in from the start. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach.