Die Benchmarks liegen vor. Das Budget ist freigeschaufelt. Die Lizenzen für Claude Code, Cursor oder GitHub Copilot sind bestellt. Dann landet der Rollout-Plan auf dem Schreibtisch des Betriebsrats. Plötzlich steht alles still. Aus vier Wochen werden sechs, dann zehn. Irgendwann ruft jemand aus dem Engineering: „Das ist doch nur ein Entwickler-Werkzeug, was soll das Theater?"
Beide Seiten haben recht. Beide Seiten sind schlecht vorbereitet. Genau dort entsteht der Schaden.
Dieser Artikel ist für Engineering Leads geschrieben, die verstehen wollen, was bei der nächsten BR-Verhandlung auf dem Spiel steht und mit konkreten Handlungsoptionen ins Gespräch gehen möchten. Wer den Rollout im größeren Kontext sehen will, findet in unserem Leitfaden zu KI-Coding-Agents den Platz der BR-Einbindung in der Gesamtstrategie.
Das Kernproblem in einem Satz
Wenn Ihr Unternehmen Entwickler-Accounts für ein KI-Coding-Tool bereitstellt und Arbeitgeber-Admins personenbezogene Nutzungs- oder Aktivitätsdaten einsehen, exportieren oder einzelnen Beschäftigten mit vertretbarem Aufwand zuordnen können, kommen Sie sehr wahrscheinlich nicht ohne eine Betriebsvereinbarung oder eine andere mitbestimmte Regelung aus.
Das ist der rechtliche Kern, um den sich alles dreht. Im Folgenden erkläre ich, warum das so ist, was das konkret für Claude Code, Cursor und GitHub Copilot bedeutet, und wie Sie die Verhandlung vorbereiten.
Warum der Betriebsrat überhaupt mitredet
Der entscheidende Paragraph ist §87 Abs. 1 Nr. 6 BetrVG. Er gibt dem Betriebsrat ein Mitbestimmungsrecht bei der „Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen."
Das Gesetz fragt nicht nach Ihrer Absicht. Es fragt, ob die Technik objektiv geeignet ist, Verhalten oder Leistung kontrollierbar zu machen. Das Bundesarbeitsgericht legt diesen Begriff weit aus.
Für Sie als Engineering Lead bedeutet das: Es spielt keine Rolle, dass Sie niemanden überwachen wollen. Es spielt eine Rolle, ob die technische Einrichtung im konkreten Setup objektiv dazu geeignet ist, Verhalten oder Leistung einzelner Beschäftigter kontrollierbar zu machen.
Was Claude Code, Cursor und Copilot im Admin-Dashboard zeigen
Bei allen drei Tools können in Team-, Business- oder Enterprise-Plänen Admin-Ansichten mit personenbezogenen oder personenbeziehbaren Nutzungsdaten relevant werden. Genau diese Kombination aus Firmenaccount, Admin-Zugriff und Nutzungsmetriken löst regelmäßig die Mitbestimmungspflicht aus.
Claude Code zeigt im Team- und Enterprise-Dashboard pro Nutzer die E-Mail-Adresse und akzeptierte Codezeilen im aktuellen Monat. Die Daten lassen sich als CSV exportieren. Eine dokumentierte Admin-Analytics-API liefert Sitzungen und Akzeptanzraten pro Nutzer und Tag. In der Beta „Contribution Metrics" kommen nach GitHub-Verknüpfung weitere beitragsbezogene Metriken hinzu, etwa zu Pull Requests und ausgeliefertem Code.
Cursor bietet auf Team- und Enterprise-Plänen nutzer- und tagesbezogene Admin-Analytik: CSV-Download aus dem Dashboard und, auf Enterprise, JSON über eine dokumentierte Admin-API. Je nach Plan enthalten die Daten Tab-Completion-Akzeptanz, hinzugefügte und gelöschte Zeilen sowie einen Aktiv-Status pro Nutzer. Die Messlogik ist in Cursor-Foren regelmäßig Gegenstand von Diskussionen, weil die Zahlen manchmal unplausibel wirken. Für die BR-Relevanz ändert das nichts. Im Gegenteil: Wenn solche Metriken später als Produktivitätsindikatoren verkauft werden, macht ihre methodische Schwäche die Verhandlung eher schwieriger.
GitHub Copilot liefert über Usage Metrics und REST-API ebenfalls eine Administrations- und Reporting-Ebene für Organisationen und Enterprises. Je nach Report stehen aggregierte und teilweise nutzerbezogene Daten zur Verfügung, etwa zu aktiven Nutzern, Akzeptanzaktionen, vorgeschlagenen und akzeptierten Codezeilen sowie Chat- und Agent-Nutzung.
Das ist kein hypothetisches Monitoring-Potenzial. Das ist die Admin-Ebene der Pläne, die Sie gerade einkaufen. Entscheidend bleibt aber immer die konkrete Konfiguration: Plan, Rollenmodell, Exportrechte, SSO-Zuordnung und aktivierte Reports können den rechtlichen Befund verändern.
Zwei Grenzen, die Sie kennen sollten
Nicht jede technische Einrichtung löst automatisch §87 aus.
Erstens: Reine Aggregat- oder Systemdaten ohne Personenbezug reichen nicht automatisch. Das Bundesarbeitsgericht hat in neuerer Rechtsprechung zum Headset-System (1 ABR 16/23) betont, dass eine Überwachung durch technische Einrichtungen grundsätzlich die Zuordenbarkeit zu einzelnen Beschäftigten voraussetzt.
Zweitens: Bei privaten Accounts ohne Arbeitgeber-Zugriff auf Nutzungsdaten sieht die Sache anders aus. Die erste veröffentlichte arbeitsgerichtliche Entscheidung zu KI und Mitbestimmung (ArbG Hamburg, 16. Januar 2024, 24 BVGa 1/24) lehnte den Antrag des Konzernbetriebsrats ab, weil ChatGPT über private Accounts im Browser genutzt wurde und der Arbeitgeber keinen Zugriff auf die Nutzungsdaten hatte.
Das klingt zunächst beruhigend. Aber bei einer Firmen-Lizenz für Claude Code, Cursor oder GitHub Copilot mit personenbezogener Admin-Analytik ist genau das anders. Die Hamburger Entscheidung ist kein Freibrief. Sie bestätigt eher das alte Prinzip: Bei firmenprovisionierten Accounts mit zugänglicher personenbezogener Admin-Analytik ist §87 Abs. 1 Nr. 6 BetrVG sehr wahrscheinlich einschlägig.
Das ist der Ausgangspunkt der Verhandlung, nicht die Debatte.
Was die Standard-BV-Vorlagen übersehen
Die Betriebsvereinbarungs-Muster, die 2025 und 2026 durch deutsche Mittelständler zirkulieren, wurden größtenteils für ChatGPT Business oder Microsoft Copilot als Chat-Assistenz geschrieben. Sie beschreiben ein Gespräch zwischen Mensch und Modell, sonst nichts.
Agentic Coding Tools bringen drei zusätzliche Themen ins Spiel. Nicht alle gehören in die Betriebsvereinbarung. Wer alles in die BV packt, überlädt sie und blockiert sich selbst.
MCP-Server und Zugriffsarchitektur (primär IT-Security). Das Model Context Protocol verbindet den Agent mit Ihrem Code-Repository, Ihrem Jira, Ihrem Cloud-Account, manchmal Ihrem Monitoring-Stack. Die Systeme selbst gab es schon lange. Neu ist der MCP-vermittelte Zugriffspfad und die Tatsache, dass ein Agent sie gleichzeitig orchestriert. Das ist primär eine Security-Architektur-Entscheidung. BR-relevant wird sie dort, wo eine Konfiguration personenbeziehbare Nutzungs- oder Verhaltensdaten erzeugt oder Arbeitsabläufe spürbar neu strukturiert. In die BV gehört trotzdem nicht die gesamte Security-Architektur, sondern nur das, was für Beschäftigtendaten, zulässige Datenkategorien und Arbeitsabläufe relevant ist.
Sandboxed Execution (primär IT-Security). Der Agent führt Code aus. Manchmal in einer Sandbox, manchmal auf einer VM, die sehr nah an Produktion steht. Wenn ein Entwickler sagt „schreib einen Test für Modul X", holt sich der Agent die Fixtures, schreibt den Code, lässt ihn laufen, iteriert. In diesem Zyklus berührt er Daten, die in einem Chat-Fenster nie auftauchen würden. Auch hier liegt der Schwerpunkt bei Security. BR-relevant werden Sandbox-Fragen, sobald sie auf Logging-Tiefe, Beschäftigtendaten oder die Rekonstruierbarkeit einzelner Arbeitsschritte durchschlagen.
Drittlandverarbeitung und Datentransfer (Datenschutz/DSB). Je nach Anbieter, Tarif und Deployment-Modus reist der Prompt zum Anbieter oder in eine vom Anbieter betriebene Umgebung. Darin steckt nicht selten Kundenlogik, ein Secret in einem Kommentar, eine Test-Fixture mit echten Personendaten, die irgendein Praktikant vor zwei Jahren eingecheckt hat. Ob das in einer EU-Region, einem US-Rechenzentrum oder einer Zero-Retention-Konfiguration landet, hängt von der konkreten Produkt- und Vertragskonfiguration ab. Der AV-Vertrag nach Art. 28 DSGVO muss die Inferenz-Region, die eingesetzten Subprozessoren, die Transfergrundlage für Verarbeitungen außerhalb der EU/des EWR und die Retention-Konfiguration konkret benennen. Die BV referenziert den gewählten Pfad, regelt ihn aber nicht an seiner Stelle.
Der wichtigste Hebel für diese Betriebsvereinbarung ist trotzdem ein anderer: personenbezogene Admin-Analytik. Das ist die Ebene, auf der §87 Abs. 1 Nr. 6 BetrVG besonders klar greift, und die Ebene, auf der eine BV echte Schutzwirkung entfaltet.
Die Verhandlung: Was Sie zugestehen und wo Sie hart bleiben sollten
In der Verhandlung haben Sie rund ein halbes Dutzend Hebel. Es hilft zu wissen, welche Sie früh auf den Tisch legen.
Was Sie früh einräumen sollten
Transparenz über Usage-Logs. Die brauchen Sie ohnehin für Ihre FinOps-Berichte. Der BR sieht darin Monitoring-Potenzial. Beide Seiten gewinnen, wenn die Logs definiert, zweckgebunden und technisch getrennt von Einzelauswertungen sind.
Ein benannter Datenschutzkontakt für KI-Tools. Kostet nichts, signalisiert Ernsthaftigkeit.
Das Sachverständigen-Recht nach §80 Abs. 3 BetrVG. Seit dem Betriebsrätemodernisierungsgesetz 2021 gilt die Hinzuziehung eines Sachverständigen als erforderlich, wenn der Betriebsrat die Einführung oder Anwendung von KI zu beurteilen hat. Das ist geltendes Recht. Wer die gesetzliche Vermutung der Erforderlichkeit grundsätzlich verhandeln will, verliert Zeit. Verhandelbar bleiben Person, Umfang und Kosten der Hinzuziehung; das gehört praktisch in eine gesonderte Verständigung der Betriebsparteien, nicht in den Streit darüber, ob der Betriebsrat überhaupt Sachverstand hinzuziehen darf.
Eine Review-Klausel alle zwölf Monate. Die Tools ändern sich schneller als die BV. Ein ehrlicher Review-Rhythmus ist im Interesse beider Seiten und kostet Sie in der Sache nichts.
Was Sie hart halten sollten
Keine individuelle Leistungsbewertung aus KI-Nutzungsdaten. Ziehen Sie hier eine vertragliche Linie. Aggregierte Teammetriken für Betrieb, Kostensteuerung und Adoption ja; individuelle Produktivitäts- oder Leistungsbewertung auf Basis von Token-Verbrauch, akzeptierten Codezeilen, Agent-Sitzungen oder Chat-Nutzung nein. Wichtig: Diese Klausel schützt die Entwickler im Alltag, aber sie ist kein juristischer Ausstieg aus §87. Auslöser der Mitbestimmung ist die objektive Eignung der Technik, nicht der erklärte Verwendungszweck.
Keine rückwirkende Anwendung auf Schatten-IT. Wenn drei Teams Cursor bereits seit Monaten über private Abos nutzen, legalisieren Sie das nicht rückwirkend über die neue BV. Regeln Sie es prospektiv, dokumentieren Sie den Stichtag, klären Sie den Übergang sauber.
Kein pauschales Veto gegen neue Modellversionen oder Tool-Updates. Formulieren Sie das stattdessen als Informations- und Konsultationsrecht mit definierter Frist. Eine Ausnahme: Updates, die Logging-Tiefe, Admin-Analytik, Repo-Verknüpfung, Telemetrie-Export, Retention, Rollenrechte oder Datenregionen verändern, lösen einen vollen Nachverhandlungsanspruch aus.
Die meisten eskalierten Verhandlungen kippen an einer Stelle: Eine Seite versucht, individuelle Leistungsbewertung hinter dem Wort „Transparenz" durchzuschmuggeln. Wer diese Linie sauber zieht, hat einen Großteil der potenziellen Konfliktfläche entschärft.
Für das Briefing an den Fachanwalt gehören §90 BetrVG (Beratung bei Arbeitsplatz- und Arbeitsablaufgestaltung, seit der Reform ausdrücklich einschließlich KI-Einsatz) und die Einigungsstelle nach §76 BetrVG auf die Liste der Nebenthemen.
Der Anhang, der die halbe Verhandlung erledigt
Bringen Sie nicht nur einen BV-Entwurf mit, sondern für jeden geplanten Coding-Agenten einen einseitigen Konfigurations-Anhang. Er zeigt, was tatsächlich aktiv ist, und verhindert, dass dieselben Detailfragen alle sechs Wochen neu aufgemacht werden:
- Kontenmodell (SSO, Firma, individuell) und Rollen (wer ist Admin, wer kann exportieren)
- Zuordenbarkeit: welche Kennungen werden verwendet, etwa E-Mail, User-ID, SSO-ID oder GitHub-Handle
- Admin-Analytik auf Nutzer-Ebene: welche Metriken existieren im Plan, welche sind aktiviert, wer kann sie sehen, wer kann sie exportieren
- Repository- und Projekt-Sichtbarkeit: welche Repos, Branches, Tickets darf der Agent sehen
- Retention pro Datenkategorie: Prompts, Outputs, Sitzungen, Telemetrie
- Region und Subprozessoren: Inferenz, Speicher, beauftragte Dritte
- Zero-Retention-Scope, inklusive Ausnahmen (Abuse-Detection und ähnliches)
- Verbundene MCP-Server, Ticket- und Monitoring-Integrationen
- Sichtbarkeit privater Arbeit: können Forks, Side-Projects oder persönliche Repos in der Analytik auftauchen
Der BR kann in konkreten Zeilen argumentieren, DSB und Security können ihre Fragen sauber zuweisen, und Sie haben ein Dokument, das tatsächlich beschreibt, was eingekauft wurde.
Der AI Act als gemeinsame Deadline
Für einen KI-Coding-Rollout hat der AI Act einen direkt relevanten Anker: Artikel 4, die Pflicht zur KI-Kompetenz. Die Regelung gilt seit dem 2. Februar 2025. Behördliche Aufsicht und Durchsetzung setzen nach der AI-Literacy-Q&A der EU-Kommission ab Anfang August 2026 ein.
Für Ihre Entwickler bedeutet das konkrete, dokumentierbare Kompetenzmaßnahmen, meist in Form eines planbaren Schulungsprogramms. Für den BR bedeutet es einen echten Hebel, Schulungsqualität mitzugestalten. Hier liegt ein Gespräch, das Sie gemeinsam führen können, ohne dass es sich nach Konfrontation anfühlt.
Die Hochrisiko-Pflichten aus Annex III sind für einen Coding-Assistenten als reines Arbeitsmittel regelmäßig nicht einschlägig. Sie können aber relevant werden, sobald dieselben Daten oder Auswertungen zur Leistungs- oder Verhaltensbewertung, zur Aufgabensteuerung oder zu arbeitsbezogenen Entscheidungen über einzelne Beschäftigte herangezogen werden. Das ist die eigentliche Pointe: Eine BV, die individuelles Performance-Tracking aus KI-Daten untersagt, senkt das Risiko, dass der Einsatz in einen arbeitsbezogenen Hochrisiko-Kontext kippt. Sie ersetzt nicht die eigenständige regulatorische Einordnung, sie reduziert die Wahrscheinlichkeit, überhaupt in deren Anwendungsbereich zu geraten.
Der Rat hat im März 2026 seine Position zur Streckung bestimmter Hochrisiko-Termine auf 2027 und 2028 beschlossen. Für diesen Rollout ist das weitgehend Hintergrundrauschen. Relevant ist: Der Rechtsrahmen ist im Fluss, Ihre Lizenzen laufen seit gestern. Eine BV stabilisiert das interne Verhältnis, während die externe Regulierung sich noch einpendelt.
Fazit
Die Teams, die 2026 KI-Coding-Tools ruhig und kontrolliert ausrollen, sind nicht diejenigen, die das schlauste Schlupfloch gefunden haben. Es sind die, die sechs Wochen vor dem Rollout den Betriebsrat einbinden, in einfacher Sprache erklären, was MCP und sandboxed execution technisch bedeuten, und einen BV-Entwurf samt Konfigurations-Anhang mitbringen.
Der Betriebsrat ist nicht der Gegner in diesem Spiel. Er ist die Kontrollinstanz, die genauso wenig Vorbereitungszeit hatte wie Sie, weil die Werkzeuge schneller waren als die mentalen Modelle auf beiden Seiten.
Die Entscheidungs-Geschwindigkeit des BR haben Sie nicht in der Hand. Den Zeitpunkt, zu dem Sie ihn ins Boot holen, schon. Verzug entsteht fast immer aus zu spätem Anfangen, selten daraus, dass der BR seine gesetzlichen Prüf- und Beratungsrechte ordentlich ausübt.
Dieser Artikel ersetzt keine Rechtsberatung; für konkrete Fälle empfiehlt sich ein Fachanwalt für Arbeitsrecht.
Häufige Fragen
- Greift §87 Abs. 1 Nr. 6 BetrVG auch, wenn wir die Admin-Analytik nie aktivieren oder auswerten?
- Meist ja, wenn im konkreten Setup personenbezogene Nutzungsdaten administrativ einsehbar, exportierbar oder mit vertretbarem Aufwand einzelnen Beschäftigten zuordenbar sind. Entscheidend ist nicht, ob der Arbeitgeber die Daten tatsächlich auswertet, sondern ob die technische Einrichtung objektiv geeignet ist, Verhalten oder Leistung kontrollierbar zu machen. Ist die Admin-Analytik im konkreten Plan technisch nicht verfügbar, nicht aktiviert, nicht zugänglich und auch nicht über Export, API oder andere Systeme rekonstruierbar, spricht das gegen §87 Abs. 1 Nr. 6 BetrVG. Der Einzelfall gehört dann gesondert geprüft.
- Reicht der AV-Vertrag nach Art. 28 DSGVO aus, oder brauchen wir zusätzlich eine Betriebsvereinbarung?
- Beides, und auf getrennten Ebenen. Der AV-Vertrag regelt das Datenschutzverhältnis zum Anbieter, die BV regelt das Mitbestimmungsverhältnis zum Betriebsrat. Ein sauber verhandelter AV-Vertrag macht die BV leichter, weil Retention, Region und Subprozessoren dann bereits fixiert sind, ersetzt sie aber nicht.
- Können wir bestehende Schatten-IT-Nutzung von Cursor rückwirkend über die neue BV legalisieren?
- Regeln Sie es prospektiv mit einem dokumentierten Stichtag, nicht rückwirkend. Eine rückwirkende Legalisierung vermischt einen Alt-Compliance-Fall mit der neuen Vereinbarung und belastet die Verhandlung ohne Gegenwert. Übergangsregelungen gehören in einen separaten, zeitlich befristeten Abschnitt.
- Macht die Pflicht zur KI-Kompetenz aus Art. 4 AI Act eine Betriebsvereinbarung überflüssig?
- Nein. Art. 4 AI Act adressiert Schulung und Kompetenzaufbau, nicht Mitbestimmung nach deutschem Arbeitsrecht. §87 BetrVG bleibt einschlägig, sobald die Technik objektiv geeignet ist, Leistung oder Verhalten zu kontrollieren. Die Schulungspflicht ist ein gemeinsamer Hebel, aber kein Ersatz für die BV.
- Wie lange sollten wir für die BR-Verhandlung realistisch einplanen?
- Sechs bis zwölf Wochen sind in vielen Unternehmen ein realistischer Rahmen, wenn Sie mit BV-Entwurf und Konfigurations-Anhang ins erste Gespräch gehen. Ohne diese Vorbereitung verdoppelt sich der Zeitraum regelmäßig, weil der BR jede Detailfrage von Null erarbeiten muss. Der Verzug entsteht fast immer aus zu spätem Anfangen, nicht aus bewusster Blockade.
Weiterführende Quellen
- CMS Hasche Sigle: Einführung von KI im Unternehmen, Einbindung des Betriebsrats
- Anthropic: Claude Code Usage Analytics und Claude Code Analytics API
- Cursor: Team Analytics Dashboard und Admin API
- GitHub: Copilot Usage Metrics und REST API endpoints for Copilot usage metrics
- Skill-Sprinters: KI-Betriebsvereinbarung Muster 2026
- § 80 BetrVG: Gesetzestext auf gesetze-im-internet.de
- EU-Kommission: AI Literacy · Questions & Answers
- Rat der EU: Council agrees position to streamline rules on AI (13. März 2026)
