Worker Consultation & Co-Determination

The trigger is capability, and you already built it.

Section 87(1)(6) of the German Works Constitution Act gives the works council a co-determination right over the introduction and use of technical equipment "designed to monitor" employee behaviour or performance. The Federal Labour Court has long read that phrase objectively: it is enough that the system is suitable for recording such information. Whether the employer intends to monitor anyone does not enter the test, and courts have rejected the argument that a tool's primary purpose was something else — IT security, reliability — when the capability was present anyway.

Now read your own agent observability against that standard. A trace per run, joined to the user who initiated it, carrying duration, retry count, tool calls, error rate and cost. That is an objectively suitable record of individual performance, and you built it in week one because you could not debug without it.

• Co-determination here is not a notification duty. It means the council has a genuine say, and a system introduced without agreement can be ordered out of use.
• The right attaches to introduction and use, so "we already shipped it" is the problem rather than the answer.
• Germany is the sharpest case, not the only one. The Netherlands, France and others run their own consultation regimes with different triggers and timetables; a multi-country rollout has several clocks, not one.

Two obligations, routinely conflated, with different remedies.

Information and co-determination are not the same duty, and satisfying one does not discharge the other.

• Inform. Article 26(7) of the EU AI Act requires deployers who are employers to inform workers' representatives and the affected workers before putting a high-risk AI system into service or use at the workplace. It is a one-directional obligation: you tell them, in line with national rules on worker information. For standalone Annex III systems those deployer duties apply from 2 December 2027 — see the EU AI Act for agents.
• Agree. Co-determination under national labour law is bilateral. The output is a works agreement, negotiated, with an arbitration path if you cannot reach one. It is not on your timetable.

Note which side of the line an agent falls on. Annex III covers employment and worker management — systems used to allocate tasks or to monitor and evaluate performance — so an agent that assigns work, scores output, or routes tickets by worker is plausibly in scope for the information duty on its own merits. But the co-determination right can attach to an agent that does none of that, purely on the strength of the telemetry it emits. The boring internal tool is the one that surprises people.

"An AI agent" is not a scope. Write the system description before someone writes it for you.

What gets negotiated is a document describing a system. If you do not bring one, the other side's draft becomes the baseline, and a draft written defensively will prohibit things you actually need. Bring a description that is specific enough to be agreed to and narrow enough to live with.

• What is collected, at what granularity, keyed to whom. Per-run, per-user, per-team, aggregate. This is the single most consequential line in the document.
• How long it is kept, and what happens at expiry — the same decisions as trace sampling & retention, now with an external counterparty.
• Who can query it, under what purpose, and through which interface. "Engineers with production access" is not a purpose limitation; a named role querying a view that cannot group by individual is.
• What is prohibited outright. A negotiated ban on using the data for performance evaluation or disciplinary measures is usually the concession that makes the rest possible — and it is one you can implement technically rather than promise verbally.
• What triggers a re-look. Define now which changes reopen the agreement, or every change will.

Design so that the answer can be yes.

Most of the friction is avoidable, and it is avoidable in the data model rather than in the negotiation. Four moves make a system that is easy to agree to.

• Aggregate by default, attribute by exception. Operational dashboards almost never need an individual key — p95 latency, error rate and cost per task are team-level questions. Push individual identifiers behind a separate, purpose-gated path used for support and incident response.
• Pseudonymise at write time. A stable per-session identifier that resolves to a person only through a controlled join is a materially different object from a user ID stamped on every span, both legally and in what an engineer can do on a bad afternoon.
• Make the prohibition demonstrable. A promise not to run performance queries is worth less than a warehouse view with no individual dimension, plus an access log on the raw table. You can show the second one; you can only assert the first.
• Shorten retention. Ninety days of individually attributable traces is a harder negotiation than fourteen, and the debugging value beyond a couple of weeks is close to nil. See PII redaction in agent traces for the mechanics.

Your release train and a negotiated agreement run at different speeds.

The agreement is written against a system description, and agents change constantly — a new tool, a new model, a new field on a span. Left unmanaged, either every deploy is a notification event or the description silently stops describing the system, and the second is worse.

• Version the description and bind it to a release. Treat it as an artefact in the repository, reviewed like a schema change, and record which version was in force when — the rollout & versioning discipline applied to a compliance document.
• Classify changes once, in the agreement. A model swap behind the same interface, a new tool with no new telemetry, a new per-user field: pre-agree which of these are notification-only and which reopen negotiation. Doing this at signing costs one conversation; doing it per-change costs one per change.
• Put a gate on new telemetry fields. The realistic failure is not a dramatic new feature. It is an engineer adding user_email to a span to debug something on a Friday, which quietly moves the system outside what was agreed.
• Keep the list of affected workforces in your agent inventory. "Which of our agents are used by employees in Germany" should be a query, not an email thread.

Keep the record, because the question arrives years later.

The evidence you will be asked for is not your good intentions. It is a small, dull set of artefacts that takes minutes to capture at the time and is unreconstructable afterwards.

• The system description, by version, with the date each version took effect.
• Who was informed, when, in what form, and for the AI Act duty, that it happened before use began — a date order that is trivial to record and impossible to prove later.
• The agreement itself and any arbitration outcome, joined to the systems it covers.
• The access log on individually attributable data. This is the one that actually answers the question people care about, which is not "what did you promise" but "what did you run".

All four belong in the same place as the rest of your audit trails, owned by a named person under accountability & roles — a compliance record with no owner degrades faster than the system it describes.