AI assistants and the works council: planning co-determination properly

An internal assistant with verifiable technical boundaries? We document data flows, roles, logs and evaluation capabilities and implement the agreed limits. Employment-law design remains with the organisation and its advisers. See the internal assistant

An internal AI assistant changes workflows and can process employee usage data. Involving the works council, data protection and information security only before rollout risks rework and delays. This article explains which questions should be clarified, documented and technically implemented early. It provides project-planning guidance on German law, not legal advice. As of August 2026.

Contents

• Why co-determination applies
• Capability matters, not intent
• The right moment is before the selection
• The logging scope decides almost everything
• What belongs in a works agreement
• Data protection is a second, separate review
• When the AI Act also becomes relevant
• What this means for the project plan
• Technical documentation WZ-IT can provide
• Sources

Why co-determination applies

An internal AI assistant answers employees' questions on the basis of company documents. To be operable it logs - at minimum which queries were made, how often an answer could be evidenced, and where it had to hand over. Without that data the system can neither be improved nor evidenced.

Where the system is objectively capable of collecting or processing conduct or performance information about identifiable employees, section 87(1) no. 6 BetrVG may apply. The German Federal Labour Court focuses on objective capability; a subjective intention to monitor is not required.

This is not unique to AI. In addition, section 90 BetrVG expressly mentions AI in planned work processes and workflows. The employer must inform and consult the works council early enough for proposals and concerns to affect the plan. Which rights apply depends on the system's features and use.

Capability matters, not intent

The point at which most discussions derail: "But we do not want to monitor anyone."

Good intentions do not settle the assessment. A system that stores queries with timestamps and user identifiers, or can link such data, may generate conduct information. Describe available functions, identifiability and possible analyses rather than relying on a statement that monitoring is not intended.

For the conversation with the body this distinction is useful because it takes the heat out of it. The question is not whether management deserves trust but which analyses the system technically permits and which of those are contractually excluded. That is a question that can be answered precisely.

The right moment is before the selection

The usual mistake is not bypassing the works council but involving it too late - typically when the system is finished and the rollout is due.

That is unhelpful for two reasons. First, a body handed a finished system negotiates differently from one that helped write the requirements: those who were not allowed to shape it have delay as their only instrument. Second, precisely the points under negotiation - logging scope, analysis rights, ability to shut down - are build decisions. Changing them afterwards means touching the system.

Involving the body before selection lets requirements enter the architecture and specification. This also reflects section 90's requirement that consultation occur while proposals can still influence planning.

The logging scope decides almost everything

Most conflicts come down to one question: what is actually stored?

Depending on quality and security goals, operating an assistant may need only a small set of fields:

• the time of the query
• the number of sources found
• whether an answer could be evidenced or was handed over
• the topic in rough categorisation

This can cover basic quality and capacity. Whether verbatim text is necessary for defect analysis or incidents requires a concrete decision. Permanent linking of full prompts and clear identities should not be the default.

That pair - verbatim plus person - is what turns an operational tool into a monitoring instrument. It is also the pair that makes the negotiation hard. Scoping the log narrowly from the outset gives you a much easier conversation and, incidentally, more data-frugal operation.

Where verbatim text is needed, use graduated measures: voluntarily submitted examples, short retention, pseudonymisation, separated keys or narrowly authorised samples. Do not call text anonymous automatically; unique wording and context can allow re-identification.

What belongs in a works agreement

An agreement that holds answers six questions. It does not replace legal review, but it structures the conversation.

Purpose limitation. What the system may be used for, and what it expressly may not. The commitment that analyses will not be used to monitor performance or conduct belongs here.

Logging scope. Which fields are stored, which expressly are not. The more concrete the list, the less room for interpretation.

Retention period. How long, and what happens afterwards. "As long as necessary" is not a period.

Analysis rights. Who may analyse, at what level of aggregation, and under what conditions person-level analysis is permissible at all - usually only on a concrete occasion and with the body involved.

Shutdown. How and by whom the system or an individual area can be stopped. Area-by-area shutdown makes technical sense too, for instance while a corpus is being revised.

Changes. Which changes remain within the agreement and when renewed participation is required, for example new sources, evaluations, models or agent capabilities.

Verification. How the works council and data-protection function can verify that technical settings, roles and deletion rules match the agreement.

Data protection is a second, separate review

Co-determination and data protection are regularly confused or played off against each other. They are two reviews with different people responsible and different questions.

Data protection asks about legal basis, purpose limitation, necessity, deletion periods and data subject rights - the data protection officer is responsible. Co-determination asks whether the body consented to the introduction - the works council is responsible.

A data-protection-oriented system can still trigger participation rights. Conversely, a works agreement does not automatically cure a missing legal basis or disproportionate processing. Section 26 of the German Federal Data Protection Act addresses necessity for employment data and expressly leaves representation rights unaffected.

Where processing is likely to result in high risk to people's rights and freedoms, a data protection impact assessment may also be required. The European Commission lists systematic and extensive automated evaluation of personal aspects as a core example. The assessment should happen before processing and remain a living document.

When the AI Act also becomes relevant

A general internal knowledge assistant is not automatically high-risk. AI used for recruitment, selection, promotion, task allocation based on personal behaviour or performance monitoring can fall within the employment context of Annex III. Under the Commission's current timeline, these high-risk rules apply from 2 December 2027.

Other duties apply earlier, including prohibited practices, AI literacy and potentially transparency. Keep the permitted purpose narrow. Repurposing the same logs for performance assessment can change both the employment-law and AI Act analysis.

What this means for the project plan

The item costs no development time but calendar time. Depending on the body, its meeting rhythm and its need for advice, that is weeks to months. That time belongs in the plan, not in the final phase.

A workable sequence is to define purpose and prohibited uses, involve the body before selection, and create the technical description for data protection, information security and the works council in parallel. Then run a bounded pilot with explicit users, data, duration and evaluation. Calling a pilot voluntary does not replace any required participation or legal basis.

Technical documentation WZ-IT can provide

For an internal AI assistant, WZ-IT can provide:

• architecture and data-flow diagrams including external services,
• a field inventory for prompts, answers, user IDs, traces and metrics,
• role and permissions matrices for use, administration and analysis,
• configurable retention, deletion and export,
• descriptions of models, sources, changes and rollback,
• tests for permissions, source grounding and disabled analyses.

These artefacts make an agreement technically concrete. WZ-IT does not issue employment-law approval; we implement the boundaries agreed with the competent parties.

How the permissions in the assistant work technically is covered in RAG with permissions - that is the second question the body will ask. Which option fits your corpus at all is placed in Chatbot or knowledge navigator. When the system does not only answer but acts, approvals and identities come into play - see AI agents: permissions and approvals. And the regulatory duties in overview are in The EU AI Act for companies.

Sources

• German Federal Ministry of Justice: section 87 BetrVG
• German Federal Ministry of Justice: section 90 BetrVG
• German Federal Labour Court: 1 ABR 16/23 on objective monitoring capability
• German Federal Ministry of Justice: section 26 BDSG
• German Data Protection Conference: guidance on AI and data protection
• European Commission: AI Act and current timeline