What AI systems log, and how to agree it with the works council

Why the logs decide whether the works council has a say

The works council has a say because of what a system can record, not because of what you intend to do with the data. Section 87(1) no. 6 BetrVG gives it a right of co-determination over the "Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen", the introduction and use of technical devices designed to monitor employees' behaviour or performance. The Federal Labour Court reads "designed" broadly. In its decision of 8 March 2022 on Microsoft Office 365 (1 ABR 20/21) it held that a device is designed for monitoring when it is objectively suitable for collecting and recording information on employees' behaviour or performance, and that the employer's subjective intention to monitor does not matter. A gateway log with a user ID and a timestamp fits that description.

The often cited ChatGPT decision points the same way once you read the facts. The Hamburg Labour Court (16 January 2024, 24 BVGa 1/24) rejected a works council's applications because staff used ChatGPT in the browser through their own private accounts and the employer received no data from the providers, according to the law firm Gleiss Lutz's summary of the decision. The same summary warns against generalising it and notes that co-determination may arise where the employer uses its own AI systems or has access to the data they collect. A company AI platform is exactly that case: the employer runs the gateway and holds the logs.

Two further rules shape the conversation. If the two sides cannot agree, the conciliation board (Einigungsstelle) decides under section 87(2). And under section 80(3) BetrVG, bringing in an expert counts as necessary when the works council has to assess the introduction or use of artificial intelligence, so expect technical questions from someone who reads configuration files. Here we deal with the technical side. Whether and how co-determination applies in your company is a question for your employment lawyer, and nothing here is legal advice.

What an assistant, a gateway and coding agents record

Each layer records something different, and the gateway usually holds the most complete record because every request passes through it. The table summarises what the vendors' documentation says each component can record, as of 7 November 2026. Check your own versions and settings, because defaults and field names change between releases.

Telemetry in Claude Code stays off until someone sets CLAUDE_CODE_ENABLE_TELEMETRY, and administrators can switch it on for everyone through the managed settings file. So switching it on is a decision the works council should see in advance. One developer should not make it locally.

Which fields make monitoring technically possible

Monitoring becomes possible when a field that identifies a person is stored next to a field that describes what that person did. Model name, token count or latency on their own say nothing about an employee. Joined to a user ID and a timestamp, they become a record of working time and intensity. Review the log schema with that join in mind:

• Identifiers: user ID, email address, account UUID, an API key issued to one person, IP address
• Time: request timestamps, session start and end, active time, which together show when someone worked
• Volume and cost per person, which invite comparisons between colleagues
• Output metrics such as lines changed, commits and pull requests, which read as performance figures
• Content: prompts, answers and tool arguments, which reveal what someone worked on and how

There is a second reason to keep these fields apart. The European Commission's guidance on high-risk use cases in employment treats AI systems that evaluate workers' performance and behaviour and allocate tasks on that basis as falling under point 4(b) of Annex III to the AI Act. A usage log on its own is not such a system, but a pipeline that ranks individuals from it and feeds staffing decisions moves in that direction. In our judgement, the simplest protection is not to build the per-person view in the first place.

Configuring the logs so the agreement can be kept

A works agreement is only as good as the configuration behind it, so write each promise as a setting that someone can check. The steps use LiteLLM and Claude Code as examples because their documentation names the relevant settings. Other gateways and agents may offer similar options under other names, so confirm them before you promise anything.

1. 1

   Issue keys per team where the use case allows it

   In LiteLLM, a service account key requires a team ID and always has an empty user ID, and budgets and rate limits apply at team level. Finance gets cost per team without a personal identifier in the log. Check that your chat front end does not forward a personal ID with every request anyway, because the gateway records an end user field too. Where a use case needs per-person attribution, name it in the agreement together with its purpose.

2. 2

   Keep prompts and answers out of the logs by default

   With store_prompts_in_spend_logs off, LiteLLM keeps metadata such as tokens, cost and model in its spend logs instead of message content, and turn_off_message_logging stops messages and responses from reaching your logging callbacks while spend is still tracked. Values set in the admin UI override the config file, so restrict who can change them. For Claude Code, leave OTEL_LOG_USER_PROMPTS and OTEL_LOG_TOOL_DETAILS at their disabled defaults.

3. 3

   Strip or replace identifiers before storage

   Claude Code attaches the user's email whenever it is available, so remove or replace it in an OpenTelemetry Collector before the data reaches storage. The Collector's attributes processor can delete an attribute or hash it with SHA-256. For new setups the project now points to the transform processor. A plain hash of an email address is a pseudonym at best, because anyone with the staff directory can hash every address and match them. If you need to re-identify in documented cases, keep the mapping in a separate store owned by a different role.

4. 4

   Set the retention period in the system too

   LiteLLM's maximum_spend_logs_retention_period deletes spend logs automatically after a duration such as 30d. Set it to the period in the works agreement, and make sure the same period reaches exports, the observability backend and backups.

5. 5

   Separate access roles and report only aggregates

   Platform engineers see technical logs for operations, finance sees cost per team, and line managers see no per-person data at all. Reports go out per team and month, with a minimum group size fixed in the agreement so that a team of two cannot be read as individuals. For Copilot, limit who holds the permission to view usage metrics, because those reports are per user.

6. 6

   Document the exceptions, especially security investigations

   There will be cases where per-person data is needed, such as a leaked key or a suspicion that data is leaving through the assistant. Write down who may request re-identification or temporary content capture, who approves it, how the works council is informed, how long it lasts and when the captured data is deleted. An exception with a procedure is easier to agree than a vague promise never to look.

What the data protection officer and the AI Act add

For the data protection officer, logs that can be linked to employees are personal data, and the GDPR principles apply to them as to any other record. Article 5(1) requires a specified purpose, data limited to what that purpose needs and storage for no longer than necessary, which maps directly onto the steps above. Article 88 lets Member States set more specific rules for employee data by law or by collective agreements and names monitoring systems at the workplace as a point those rules must address. Where processing is likely to result in a high risk, Article 35 requires a data protection impact assessment before it starts. Whether yours does is a question to settle with your DPO.

Any provider that processes the logs or prompts on your behalf, whether a model API, hosting or a managed gateway, needs a processing contract under Article 28(3) that sets out the subject matter, duration, nature and purpose of the processing and the types of data, and that requires deletion or return of the data when the service ends. Ask each provider what it logs on its side and for how long, because those logs sit outside your configuration and outside anything you can show the works council.

The AI Act touches logging mainly through Article 26 on deployers of high-risk AI systems. Article 26(6) requires them to keep the logs the system generates automatically for a period appropriate to its intended purpose and of at least six months, unless other Union or national law provides otherwise. Article 26(7) requires employers to inform workers' representatives and the affected workers before a high-risk system is put into service or used at the workplace. According to the European Commission's AI Act Service Desk timeline, which reflects the Digital Omnibus amendments, the high-risk rules for Annex III systems apply from 2 December 2027 (as of 7 November 2026). In our assessment an internal assistant or a coding agent is usually not a high-risk system, but if you use AI for decisions about staff, the six-month minimum may collide with a short retention period in the works agreement, so plan both together.

Checklist for the conversation with the works council

Bring evidence. The works council, and any expert it brings in, will want to see what is configured on the live system. We find the conversation goes better when these items are ready before the first meeting:

• A data flow diagram from the user's screen to the model provider, marking every place where logs are written
• A field-by-field inventory of each log, with its purpose, who can read it and its retention period
• The live configuration: gateway settings, telemetry settings in the managed settings file, collector rules and any admin UI values 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, so nobody has to imagine them
• The role and permission matrix, including who holds admin rights on the gateway and who can view Copilot metrics
• The exception procedure for security investigations, with its approval and deletion steps
• A list of provider-side logs and the processing contracts that cover them
• A change process: which configuration changes need the works council's consent, and a check after every gateway or agent upgrade, because new versions can add fields

If you want help with the technical side, we build and run these platforms on your own servers or in your own cloud account and can prepare the configuration evidence for the conversation.

On-premise AI on your own serversLiteLLM gateway setup and operationLLM platform engineering