Does an AI coding assistant need works council consent in Austria or Germany?

It can, depending on what the tool logs and who can see it. In Austria, § 96(1) no. 3 ArbVG makes control measures and technical systems that touch human dignity legally effective only with the works council's consent. In Germany, § 87(1) no. 6 BetrVG gives co-determination over equipment designed to monitor behaviour or performance. Have a lawyer classify your set-up before you switch on per-user logs.

Is individual employee consent enough under the GDPR?

I would not rely on it. § 26(2) BDSG asks decision-makers to weigh the employee's dependence on the employer when judging whether consent was freely given. Article 88 GDPR points to rules set by law or collective agreement, so put the rules into the works agreement.

Does the EU AI Act apply to a coding tool?

Not automatically. The high-risk rules apply only if your use falls into an Annex III category, such as monitoring performance and behaviour. Regulation (EU) 2026/1744 moves the Annex III application date to 2 December 2027. If a system is high-risk for your use, Article 26(7) requires telling workers' representatives and affected workers before first use.

AI coding tools and works councils

Q: What must a works agreement for AI tools cover?

The statutes give no template. Article 88(2) GDPR asks for suitable and specific measures, with particular regard to transparency and to monitoring systems at the workplace. I would cover purpose, logged fields, access, retention, a ban on performance use, training and a review date.

Rolling out an AI coding assistant to developers looks like a licence decision. In Austria and Germany it is also a works council question, and the trigger is often the admin console. The usage data that tools show administrators can say who used the tool, when and how often. That can be enough to make it a technical system capable of monitoring employees, whatever purpose the rollout slide gives. My answer is to involve the works council before the first seat is active, and to let the logs follow the agreement rather than the other way round.

In Austria, consent is needed for certain measures to take legal effect. In Germany, co-determination covers the introduction and use of such equipment. Below I set out what the logs can show, what the statutes and the decisions I could check say, what a works agreement should cover, and a rollout timeline.

What the logs reveal

Many coding tools now have an admin layer, and that layer is where the monitoring question starts. Here are two examples from documentation I opened in October 2026.

GitHub's Copilot metrics give each user a last_activity_at timestamp for their most recent Copilot interaction. The per-user record also carries the login, last_authenticated_at and last_surface_used. The report refreshes every 30 minutes, although processing can take up to 24 hours. The data sits on a rolling 90-day window that cannot be changed, and after 90 days without activity, last_activity_at is null.

Claude Code's monitoring setup, as Anthropic documents it, exports OpenTelemetry metrics and events. The telemetry carries an anonymous user.id, the user.email when it is available, and the account UUID for signed-in users, which OTEL_METRICS_INCLUDE_ACCOUNT_UUID controls (default true). The prompt attribute is redacted unless OTEL_LOG_USER_PROMPTS is set to 1.

The first question is whether the tool can tie activity to a person. It is a practical screen, not the legal test, which asks whether the equipment is suitable for monitoring.

That distinction matters. The legal tests below ask what a piece of equipment is suitable for, not what the employer plans to do with it. A dashboard that nobody opens today can still be a monitoring system.

Austria: §§ 96 and 96a ArbVG

Section 96(1) no. 3 of the Labour Constitution Act (ArbVG) makes certain employer measures legally effective only with the works council's consent. One of them is the introduction of control measures and technical systems for monitoring employees, insofar as these measures (systems) touch human dignity. The German wording is 'technischen Systemen zur Kontrolle der Arbeitnehmer, sofern diese Maßnahmen (Systeme) die Menschenwürde berühren'.

Section 96(2) allows either party to end a works agreement on these matters in writing, at any time and without notice, unless the agreement sets its own term. The term is therefore part of the negotiation, not a formality.

Section 96a covers systems that collect, process or transmit employees' personal data beyond general personal details and professional qualifications. No consent is needed where the use stays within what law, collective rules or the employment contract require. A second item covers systems for assessing employees, where the data collected is not justified by operational use.

Under § 96a(2), a decision of the arbitration body (Schlichtungsstelle) can replace the works council's consent for these items. Section 96a(3) says these rules leave the consent rights under § 96 untouched. The text I checked gives the arbitration body no power over consent under § 96(1) no. 3, so I would treat a tool that touches human dignity as needing the works council's agreement. Confirm that reading with a lawyer.

Germany: §§ 87 and 90 BetrVG and § 26 BDSG

Section 87(1) no. 6 of the Works Constitution Act (BetrVG) gives the works council co-determination over the introduction and use of technical equipment designed to monitor employees' behaviour or performance. If no agreement is reached, the conciliation committee (Einigungsstelle) decides, as § 87(2) provides.

Section 90 is the information and consultation duty. The current text of § 90(1) no. 3 covers the planning of work procedures and workflows 'including the use of artificial intelligence' (einschließlich des Einsatzes von Künstlicher Intelligenz). The employer must inform the works council in good time and with the documents needed. Under § 90(2), the employer must also consult on the planned measures and their effects on how people work, early enough that the works council's proposals and concerns can still be considered.

Data protection law applies alongside. Section 26 of the Federal Data Protection Act (BDSG) allows employee data to be processed for employment purposes where necessary, including for the rights and duties of employee representation under a law, a collective agreement or a works agreement. Section 26(4) allows processing on the basis of collective agreements, and the negotiating parties must observe Article 88(2) GDPR. Section 26(2) says that the employee's dependence on the employer must be considered when judging whether consent was freely given.

What the courts have said so far

The Federal Labour Court (BAG) decided in July 2024, in case 1 ABR 16/23, about a headset system that let managers listen in on staff calls. It held that the system was subject to co-determination under § 87(1) no. 6 BetrVG. The decision restates the test: equipment is designed to monitor if it is objectively suitable to collect or record information about behaviour or performance, and the employer's monitoring intent does not matter. Recording is not required; it is enough that the data is made available in a form that can be perceived. The local works council's appeal on points of law failed, because the group works council (Gesamtbetriebsrat) was the competent body.

A labour court in Hamburg looked at AI tools in a different setting. In an interim order of 16 January 2024 (24 BVGa 1/24), it rejected the group works council's applications, including one for a ban on AI use. The dispute centred on ChatGPT and similar tools. I have not read the order itself. What follows comes from two law-firm write-ups, by CMS and by Gleiss Lutz. According to them, the employer first blocked ChatGPT, then released it, encouraged its use and published guidelines asking staff to flag work results produced with AI. The tools were used through the browser, on employees' own accounts rather than on company hardware.

According to the same write-ups, the court found no co-determination under § 87(1) nos. 1, 6 and 7 BetrVG. It treated the tools as work equipment. On no. 6, it reasoned that the employer had no access to the self-created accounts and did not know when, for how long or for what purpose staff used the tool. Telling staff to disclose AI use did not change that. An existing group works agreement already covered browser use. The summaries I read do not discuss company-managed accounts with admin logs, and that is the set-up this article is about.

I would read the Hamburg order as a warning about facts, not as permission. Its reasoning rests on the employer having no access to the accounts. A managed rollout reverses those facts, and the BAG test asks what the equipment is suitable for, not what the employer does with it.

Article 88 of the GDPR allows member states or collective agreements to set more specific rules for employee data. Those rules must include suitable and specific measures to safeguard human dignity, legitimate interests and fundamental rights, with particular regard to transparency and to monitoring systems at the workplace. A works agreement is the natural place for those measures.

The general principles still apply. Personal data must be collected for specified purposes and not used in a way that is incompatible with them (Article 5(1)(b), purpose limitation). It must be adequate, relevant and limited to what is necessary (Article 5(1)(c), data minimisation). It must not be kept longer than necessary (Article 5(1)(e), storage limitation). I would design the logs around those three rules, and let the agreement name each field, its purpose and its retention.

Consent is a weak basis for monitoring at work. Section 26(2) BDSG asks decision-makers to weigh the employee's dependence on the employer when judging whether consent was freely given. Treat individual consent, if at all, as a supplement to the agreement.

Article 35 requires a data protection impact assessment where processing is likely to result in a high risk. Its paragraph 3(a) names a systematic and extensive evaluation of personal aspects, based on automated processing including profiling, on which decisions with legal or similarly significant effects are based. A usage dashboard alone is not automatically in that category, but a performance score built on it may be. Ask your data protection officer to decide. I would do the assessment anyway, because it supplies the facts the agreement needs.

The AI Act adds a second test. Annex III, point 4 covers AI used in employment. Point 4(b) covers AI intended to 'monitor and evaluate the performance and behaviour of persons in such relationships'. Annex III systems count as high-risk under Article 6(2). Article 6(3) can take a system out of that category where it does not pose a significant risk, including by not materially influencing decision-making. The AI Act asks about intended purpose, while the German courts ask about objective suitability, so the two tests do not map one-to-one.

If a tool is high-risk for your use, an employer that deploys it must tell workers' representatives and the affected workers that they will be subject to the system, before it is first used at the workplace (Article 26(7)). That notice sits next to the works council duties above, not in place of them. Regulation (EU) 2026/1744 moves the application date for Annex III high-risk obligations to 2 December 2027; recital 40 gives the original date as 2 August 2026. The same regulation replaces the AI literacy duty in Article 4 with a duty to take measures that support AI literacy, without guaranteeing any specific level for any individual. Check the dates on EUR-Lex before you plan around them.

Question	Austria	Germany	EU: GDPR and AI Act
Trigger	Control measures and technical systems that touch human dignity (§ 96(1) no. 3 ArbVG)	Equipment designed to monitor behaviour or performance (§ 87(1) no. 6 BetrVG)	AI intended to monitor and evaluate performance and behaviour (Annex III, point 4(b))
Works council role	Consent needed for legal effect; the arbitration body can replace only the § 96a consent	Co-determination; the conciliation committee decides without agreement (§ 87(2))	Information to workers' representatives before first use of a high-risk system (Art. 26(7))
Written agreement	Works agreement; can be ended in writing at any time unless it sets a term (§ 96(2))	Works agreement; § 26(4) BDSG allows processing on the basis of collective agreements	GDPR Art. 88(2): rules need suitable and specific measures

What the works agreement should contain

The statutes name goals and procedures, not a template. Here is what I would put in, roughly in this order.

Purpose. One sentence per use: licence management, security, cost control. Anything outside the list needs a new agreement.
Logged fields. Name each field, for example seat activity dates and tool version. Name the fields that are never logged, such as prompt text and code content, unless a named purpose needs them.
Access. Which roles can see per-user data, who logs each access, and that managers get aggregated reports only.
Retention. A fixed period for each log, with automatic deletion. Do not inherit the vendor's window. GitHub's per-user activity data covers a rolling 90 days, so say what you keep beyond that, if anything.
No performance use. No appraisal, ranking, bonus or disciplinary use of tool data, and no AI-use score for individuals.
Training. AI literacy measures for everyone with a seat, in line with the duty to take measures under Article 4 as amended.
Review and exit. A review date, a right for the works council to see the configuration on request, and a deletion plan for when the tool is switched off.

The telemetry switches are where the agreement becomes technical. This is a conservative setup for Claude Code, based on Anthropic's documentation, with prompt text left redacted:

# Telemetry on; prompt text stays redacted (the default)
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317  # your own collector
# Leave this unset unless the agreement names a purpose:
# export OTEL_LOG_USER_PROMPTS=1

The switches are the easy part. The user identifiers still travel with the metrics, so the access rules matter as much as the configuration. Start with aggregated reporting, and switch per-user views on only once the agreement says who may see them.

A rollout timeline that fits the statutes

The timing follows the statutes' own wording. Germany's § 90 asks for information in good time, with the documents needed. Austria's § 96 makes the measure legally effective only with consent. Germany's § 87 covers introduction and use. The weeks below are my planning suggestion, not a legal timetable.

Phase	Weeks	What happens	Gate
Map	1–2	List the logged fields per user and per team, and what the vendor sets by default. Draft the purpose list.	Field list approved internally
Inform	2–4	Give the works council the field list, purposes and pilot plan in writing. Start the impact assessment with the data protection officer.	Works council has documents and time to respond
Pilot	4–10	Volunteers only, aggregated reporting, no per-user dashboards. Anything that logs people needs the works council's agreement first.	Pilot data agreed with the works council
Agree	10–12	Negotiate and sign the works agreement, including term, notice and review date. Austria: consent under § 96. Germany: works agreement or conciliation.	Signed works agreement
Roll out	From week 12	Activate seats in waves, turn on only the telemetry the agreement names, and train every seat holder.	Access list and retention jobs running
Review	Every 6 months	Check logs against the agreement and reopen it if the vendor changes its fields.	Review minutes on file

The gate is the signature, not the pilot. Pilots use aggregated data, so the agreement is the first point where per-user views can switch on.

What I would do first

Write down, per plan and per team, which admin fields and telemetry your tools expose, and their default retention.
Cut the purposes you do not need. Keep one sentence for each purpose you do.
Switch prompt text off, and decide whether account identifiers belong in metrics at all.
Brief the works council in writing and early, with the field list and a pilot plan. In Germany, § 90 requires timely information with documents. In Austria, start the § 96 consent conversation before anyone gets per-user access.
Ask an employment lawyer to classify the set-up under § 96 ArbVG, § 87 BetrVG and the AI Act, and ask your data protection officer about the impact assessment.
Draft the works agreement from the list above, and settle the term and review date in the first draft.

For the data side of the same stack, see GDPR LLM data residency, PII redaction in LLM pipelines and observability for LLM agents with OpenTelemetry. For the AI Act timeline, see EU AI Act beyond Article 50.

AI coding tools and the works council: when usage logs count as monitoring

Key takeaways

What the logs reveal

Austria: §§ 96 and 96a ArbVG

Germany: §§ 87 and 90 BetrVG and § 26 BDSG

What the courts have said so far

What the works agreement should contain

A rollout timeline that fits the statutes

What I would do first

Sources

Frequently asked questions

Sounds like what you need?

Key takeaways

What the logs reveal

Austria: §§ 96 and 96a ArbVG

Germany: §§ 87 and 90 BetrVG and § 26 BDSG

What the courts have said so far

GDPR and the AI Act

What the works agreement should contain

A rollout timeline that fits the statutes

What I would do first

Sources

Frequently asked questions

Sounds like what you need?