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

An internal assistant that plans for co-determination from the start? We supply the technical description your body needs for its decision - and build the boundaries the way you agreed them. See the internal assistant

The most common reason a finished internal AI assistant does not go live for months is not technical. It is that nobody involved the works council in time. That is annoying because it is avoidable, and expensive because a finished system sits idle. This article explains why co-determination applies, what turns on the logging scope, and what belongs in an agreement. It is orientation for project planning, not legal advice, and it describes German works constitution law. 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
• What this means for the project plan

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.

That very logging makes it a technical device capable of recording the behaviour and performance of employees. Section 87(1) no. 6 of the German Works Constitution Act attaches the co-determination right to the introduction and use of such devices. The works council therefore holds not merely a right to information but a genuine right of co-determination: without its consent the system may not be introduced.

This is not an AI-specific special case. The same provision has applied to ticket systems, telephone systems and time recording for decades. What is new is only that many project plans for AI systems are written as though this were a tool purchase.

Capability matters, not intent

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

That is true and irrelevant. The co-determination right attaches to the objective capability of the device, not to the employer's intent. A system that stores queries with a timestamp and a user identifier is capable of recording behaviour - regardless of whether anyone plans to. The analysis would be technically possible at any time, and that is precisely what the provision guards against.

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 the selection lets the requirements from the agreement go straight into the specification. That costs two extra meetings at the start and saves the loop at the end.

The logging scope decides almost everything

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

Operating an assistant needs surprisingly few 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

That is enough to measure answer quality, find unanswered topics and plan capacity. What is not needed for that: the question verbatim, stored together with the person who asked it.

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 the verbatim text is genuinely needed - to improve the knowledge base, say - there is a middle path: store queries without a personal reference, with a retention period, and keep the link to the person only as long as the session technically requires.

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. What happens when a new source is connected or the model is swapped. Without this point, every extension becomes a renegotiation.

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 solution set up impeccably under data protection law still may not be introduced without the works council's consent. Conversely, a works agreement does not cure a missing legal basis. Both reviews run in parallel, and both benefit from the architecture being laid open rather than asserted.

In practice that means: the same technical description - which data is collected, where processed, how long held, who can access it - serves both sides. Write it properly once and you save the second round.

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: sketch the requirements and logging scope, inform the body before the selection and take on the points it wants to contribute. Write the technical description for data protection and the works council in parallel. Negotiate the agreement while the system is being built - not afterwards. And plan a pilot with a bounded, voluntary group of users, from which both sides get real numbers rather than assumptions.

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.