Assessing an AI system as a works council: what it records and what you can agree

A judgement on whether a system protects employees from performance and behaviour monitoring, and an agreement that still holds after go-live. The trigger is usually the logs. Under section 87(1) no. 6 of the Works Constitution Act (§ 87 Abs. 1 Nr. 6 BetrVG), co-determination applies when a technical system is objectively capable of monitoring the performance or behaviour of employees, whatever the employer intends. An AI assistant, a gateway in front of the models or a coding agent that records who sent which request and when can meet that test.

Private use is treated differently. The Hamburg Labour Court found in 2024 (24 BVGa 1/24) no co-determination right where staff used ChatGPT in the browser through their own private accounts and the employer received no data from the provider. Once the employer runs its own AI system and holds its logs, the situation is different. Your rights at a glance, as summarised in Bitkom's 2026 guide "KI und Mitbestimmung":

• § 90 BetrVG: the employer must inform you in good time when it plans work procedures, and AI is named explicitly.
• § 87 Abs. 1 Nr. 6 BetrVG: co-determination over systems that can monitor. If no agreement is reached, the conciliation board decides.
• § 80 Abs. 3 BetrVG: when you assess the introduction or use of AI, bringing in an expert counts as necessary.
• § 95 Abs. 2a BetrVG: selection guidelines need your involvement also when AI drafts them.

They come from employees, HR and management, and they appear in exactly this wording in union FAQs, law firm guides and forums:

• "AI agents in the company: must the works council co-determine their introduction?"
• "Is it enough to inform the works council before the rollout?"
• "What belongs in a works agreement?"
• "What can works councils do if they disagree with AI plans?"
• "How do we make sure the tool does not endanger jobs?"
• "What does the system log, and can performance or behaviour be evaluated from it?"
• "Does this feel like reasonable management data or does it feel invasive even without prompt content?"

The order follows the data: first what the system is for, then what it records, then who sees it and for how long.

• Purpose: what the system is for, and what it is explicitly not for, such as evaluating individual performance.
• Log fields: which fields are recorded, as a field list, and which are switched off.
• Identification: team keys or pseudonymised IDs instead of names, and who may hold any mapping back to a person.
• Access and reports: who sees what, at which aggregation level, with a minimum group size so that a small team cannot be read as individuals.
• Retention: how long each log is kept, set in the system itself as well as written into the agreement.
• Human approval: which results a person must check before they affect anyone, and that no decision about an employee is automated.
• Changes: which new tools, data sources or agent functions need your consent, and which can follow a simpler procedure.
• Exceptions: how a security investigation may access per-person data, who approves it, how you are informed and when the data is deleted.

Bitkom's 2026 guide recommends that a works agreement on AI says who may access which data and "wie Zugriffe protokolliert werden", how access is logged, and that it sets up a traffic-light approval process, a "KI-Steckbrief" (a short system profile), test phases and rules for human approval. A framework agreement with one profile per system means a new tool does not need a whole new agreement. We write the profile with IT and HR for every system we build, and it contains:

• The purpose and the tasks the system does, in plain words.
• The data sources it reads and the systems it can write to.
• The models and where they run: your own servers, your own cloud account or a provider.
• Every log field, its purpose, who can read it and how long it is kept.
• The approval points where a person checks the result.
• What the system does not do: no ranking or scoring of employees.
• The results of the acceptance test, and the change procedure.

One possible setup: green for uses covered by the framework agreement and its profiles, yellow for changes that are reported to you and checked against the profile, red for uses that need a separate agreement or are excluded, such as anything that evaluates individual employees. The exact categories are yours to negotiate with the employer. Technically, a gateway in front of all models makes the procedure enforceable: a model or tool that is not approved cannot be reached.

• Performance monitoring through logs: team keys or pseudonymised IDs, prompts not stored by default, team-level reports only and retention set in the system. We report by team, task and model, and never score individual people.
• The content of work becoming visible: chat histories and prompts show what someone worked on and how. Storing them is switched off unless a purpose is agreed with you.
• Functions added later: upgrades can add log fields or features. A change procedure and a check after each upgrade keep the agreement valid.
• Decisions about people: uses such as CV screening and ranking of applicants are high-risk under the AI Act. Under its Article 26(7), the employer must inform workers' representatives before such a system is used at the workplace, and the high-risk rules for these systems apply from 2 December 2027 after the Digital Omnibus. We do not build systems that decide about employees without people.
• Jobs: we will not promise that no job changes. In Bitkom's 2026 survey, 57% of companies expect AI to reduce their headcount within two years, 45% slightly and 12% significantly. What we can do is make the effect measurable per process and share the results with you and the team. Staffing decisions are made by management, subject to your rights. The system makes none.
• Acceptance and skills: in Bitkom's 2026 survey, lack of employee acceptance was a barrier for 42% of AI users, two thirds of companies rated their staff's AI skills as low and 25% offered no training. Involving the team in the tests and a short introduction to each tool help more than promises.

Ask us, and any other provider, for evidence you can check. Your expert under § 80 Abs. 3 BetrVG can go through all of it:

• A data flow diagram marking every place where logs are written.
• A field-by-field list of every log, with its purpose, its readers and its retention period.
• The live configuration itself: gateway settings, telemetry settings and any admin settings that override them.
• A test request sent during the meeting, followed by a look at exactly what landed in each log.
• Sample reports in their final form, aggregated by team.
• The role and permission matrix, including who holds admin rights.
• What the model provider records on its own side, and for how long.

Ask HR or IT for the system profile and the field list before the pilot starts, because a pilot with real employees whose logs identify them can already fall under co-determination. If your company works with us, we join a meeting with HR and IT and show the configuration live. The first 30-minute call is free and needs no access to systems or data, and HR or IT can invite you to it. Our guide on works councils and AI logs goes field by field through common assistants, gateways and coding agents.