Concede the Point You Are Going to Lose
If your employees are going to use the tool, § 87 (1) 6 BetrVG applies and the works council holds an enforceable veto. Not “might apply”, not “depends on the use case”. Almost certainly applies. Most project teams spend their first two months arguing the opposite — we are not monitoring anyone, we are drafting claim letters — and they lose, because that argument was never about what anyone intended.
Intent is irrelevant; capability is the test
The provision covers technical systems that are “bestimmt” to monitor the performance or behaviour of employees. The Bundesarbeitsgericht has read that word as an objective test for decades: it is enough that the system is suitable for producing performance or behaviour data about identifiable people. Nobody has to want it. If your assistant writes a user ID, a timestamp and a query into a trace so you can debug a bad answer, you have built precisely that — and so did the platform underneath it, because a Microsoft 365 tenant attributes activity per user before you deploy anything on top of it. The assistant you are proud of is usually the smallest monitoring-capable component in the stack.
A pilot is not a co-determination-free zone
“It is only a trial” buys no exemption: a test run with real employees on real data is introduction and use. This is where projects lose the thing they cannot rebuild, which is credibility — the works council hears about the tool from an employee rather than from you, and from that moment you are negotiating trust instead of scope. The better move is an explicit pilot agreement: one narrow use case, a fixed user group, an expiry date. It is far easier to sign, because nobody is being asked to bless a permanent state, and the expiry does the same work a deadline does in any decent pilot — it forces a verdict.
Which Parts of the BetrVG Actually Bite
Four hooks matter, and the useful thing about them is that they attach at different moments.
§ 90 (1) 3 has named Künstliche Intelligenz explicitly since the Betriebsrätemodernisierungsgesetz of 2021. It attaches during planning, it obliges you to inform and consult in good time, and it is not a veto — which is why it gets skipped. Skipping it is also what converts a six-week negotiation into a nine-month one. § 87 (1) 6 is the enforceable one: no agreement means an Einigungsstelle under § 76, and a works council can seek an injunction against a system introduced without it. That is the switch-off risk, and it lands after you have paid for the build. § 80 (3) 2, also from 2021, says that where the works council has to assess the introduction or use of AI, bringing in an external expert counts as necessary — at your cost. And § 95 (2a) extends co-determination over selection guidelines to cases where AI is involved.
That expert clause gets treated as a threat. It is the opposite. The expert has to write a recommendation, and an expert who cannot follow your data flows will recommend the most restrictive version they can defend, because that is the only version they can defend. Vagueness does not buy you room; it costs you room. The cheapest thing you can do for your own negotiating position is a data-flow document a stranger can read in an hour.
The Works Council Fight Is About Scope — and Scope Is Architecture
Take a regional insurer, around 600 staff, building a retrieval assistant over policy wordings and claim files for its motor claims handlers. The team logs the query, the retrieved chunks, the answer, the user ID and the latency. That is not sloppiness; it is what you need to evaluate quality and to run the thing in production at all. It is also, unmodified, a report on who asks the most questions and who takes longest per case. The works council will see that in the first meeting, because it is the first thing anyone sees.
The instinct is to promise not to look. The better answer is to make looking structurally hard: split the telemetry into a quality store that carries no user ID and is used for evaluation and regression tests, and an audit store that is attributed, retention-limited, and reachable only through a defined procedure. The honest cost, which you should say out loud in the meeting: pseudonymised evaluation logs take away your ability to walk over to the handler and ask what they actually meant by that query. Debugging gets slower. I would pay that price, because it converts a two-month argument into a paragraph.
What you cannot do is minimise your way out. If the system ever counts as high-risk, the AI Act pulls in the other direction and requires logging and retention. The GDPR wants minimisation — that tension is its own conversation — the AI Act wants a record, and § 87 wants no evaluation of individuals. Those do not cancel out. You keep the logs and you make them useless for evaluation through access control and the agreement, not through deletion.
One thing you can genuinely design away is the classification. An assistant that drafts a letter and leaves the decision with the handler is a different animal from one that scores handlers or allocates their work. The moment per-user telemetry feeds something that evaluates a person, you are arguably in Annex III of the EU AI Act, with a conformity assessment attached — and you have handed the works council their strongest objection in the same move. Co-determination you cannot avoid. High-risk classification you often can. Teams routinely conflate the two and end up negotiating the wrong one.
What a Betriebsvereinbarung for AI Tools Covers
Before drafting anything, ask whether an agreement already exists. Your Microsoft 365, ticketing or ERP agreement may already regulate this system — or already forbid what you are planning, because an evaluation ban written years ago for a phone system does not care that your thing is new. An annex to an existing agreement is often faster than a fresh one, and your works council chair can answer the question in five minutes.
Beyond that, these agreements have in practice covered a recognisable set of things:
- Scope — which system, which data sources, which user groups, which purposes. Narrow beats broad every time.
- Purpose limitation and the evaluation ban — the heart of it: the system's data may not be used to assess individuals, with one named exception path for concrete suspicion, under four eyes, with the works council involved.
- Data categories, retention and deletion periods, and role-based access to the logs.
- No automated decision about a person — a human decides, and stays accountable for the decision.
- Transparency and training for the people expected to use it.
- Inspection rights for the works council, including a test account.
- A term and a review date — and what happens to the tool when it lapses.
The clause AI agreements get wrong
Here is where an AI agreement genuinely differs from the one your company wrote for its time-recording system. That system did not change. Yours does: the vendor swaps the underlying model and behaviour shifts with no deployment on your side, no ticket, no announcement. An agreement pinned to “System X, version Y” is either breached continuously or reopened every quarter, and neither side wants either.
Describe the system by its data flows and purposes rather than its version. Then define what counts as a material change — a new data source, a new user group, a new purpose, a new decision the system makes — as against what does not: model version, interface, retrieval tuning. Full co-determination on the first category, a lightweight notification duty on the second. Works councils tend to accept that split, because it gives them the thing they actually want, which is a guarantee they will hear about the first category at all rather than reading about it in a release note.
What I Would Not Do
I would not start with a framework agreement covering “AI” in general. It is tempting — settle the question once, cover everything after. But an abstract framework negotiated with no concrete system in the room gets negotiated against imagined worst cases, and lands either so tight that reasonable uses are blocked or so vague that every rollout reopens it. Do one narrow agreement for one real tool, then a second, then generalise from two things that exist. The exception is when you are switching on Copilot for the whole company on Monday, in which case you do not have the luxury and should get help.
I would not send the vendor’s “works-council-ready” datasheet as your documentation, because it describes their product while the expert is assessing your deployment, your data sources and your log configuration. And I would not promise anything the system cannot demonstrate. “No personal data in the logs” is a sentence that gets falsified the moment somebody opens the tracing tool and finds a UPN sitting in a span. Promise less, and be able to show it.
Where Tippel Fits
What unblocks these conversations is almost never rhetoric. It is a document: what data goes in, what gets stored, for how long, who can read it, and what the system does and does not decide. That artefact is what the works council’s expert needs, what your lawyer needs in order to draft anything, and what most teams do not have until month four. It falls out of the AI Readiness Check as a by-product, because you cannot scope a build without knowing those things anyway.
If you are planning something your staff will use and there is a works council in the building, the cheapest hour you will spend is the one that makes the data flows legible before anyone has to defend them. Get in touch if it is easier to talk it through.