Einigungsstelle IT-Systeme: Datenschutz und Kontrolle regeln

Zuletzt aktualisiert am: 15. September 2025

Kurzfassung

Neue Software wirkt oft harmlos: Zeiterfassung, Ticketsystem, Recruiting-Tool, Schließanlage, Lohnabrechnung, Kommunikationsplattform, Microsoft 365, Security-Tool oder KI-gestütztes Monitoring. Für den Betriebsrat ist aber nicht entscheidend, wie harmlos ein System klingt. Entscheidend ist, ob es objektiv geeignet ist, Verhalten oder Leistung von Beschäftigten zu überwachen.

Genau dann wird § 87 Abs. 1 Nr. 6 BetrVG relevant. Danach hat der Betriebsrat mitzubestimmen, wenn technische Einrichtungen eingeführt oder angewendet werden, die dazu bestimmt sind, Verhalten oder Leistung der Arbeitnehmer zu überwachen. Die Einigungsstelle nach § 76 BetrVG ist das gesetzliche Instrument, wenn Arbeitgeber und Betriebsrat über eine solche Betriebsvereinbarung keine Einigung erzielen. (Gesetze im Internet)

Gerade moderne IT-Systeme verschieben die Grenze: Was früher reine IT-Sicherheit war, kann heute zu Verhaltensanalyse, Produktivitätsmessung, Risiko-Scoring oder verdeckter Leistungsbewertung werden. Die beigefügten Beiträge zu „Internal Risk Monitoring“ und verdeckter Überwachung zeigen, dass insbesondere Microsoft Purview, Microsoft Sentinel, Microsoft Viva, UEBA-Systeme, SIEM-Systeme und KI-gestützte Sicherheitslösungen erhebliche Beschäftigtendaten verarbeiten können.

1. Warum IT-Systeme so häufig in der Einigungsstelle landen

IT-Systeme sind heute fast nie neutral. Sie erzeugen Daten. Sie protokollieren Zugriffe. Sie speichern Zeitpunkte. Sie zeigen Bearbeitungsstände. Sie dokumentieren Kommunikation. Sie erfassen Fehler, Aktivitäten, Abweichungen und Nutzungsmuster.

Aus Sicht des Arbeitgebers dient das häufig legitimen Zwecken: IT-Sicherheit, Datenschutz, Compliance, Arbeitsorganisation, Abrechnung, Qualitätssicherung oder Cyberabwehr.

Aus Sicht des Betriebsrats entsteht aber eine andere Frage: Können diese Daten genutzt werden, um Beschäftigte zu kontrollieren?

Bei IT-Systemen reicht häufig schon die technische Möglichkeit. Es muss nicht bewiesen werden, dass der Arbeitgeber tatsächlich überwachen will. Wenn ein System objektiv geeignet ist, Verhalten oder Leistung sichtbar zu machen, ist der Betriebsrat regelmäßig beteiligt.

Für den Betriebsrat zählt nicht, was ein System verspricht, sondern was es technisch kann.

Kontrollrisiken bei IT-Systemen im Überblick

IT-System	Kontrollrisiko
Zeiterfassung	Arbeitsbeginn, Pausen, Überstunden, Fehlzeiten
Microsoft 365 / Teams / Outlook	Kommunikation, Reaktionszeiten, Meeting-Verhalten
Ticketsysteme	Bearbeitungsdauer, Fehlerquote, Produktivität
CRM-Systeme	Kundenkontakte, Aktivitätszahlen, Abschlussquoten
Recruiting-Tools	Bewerberauswahl, HR-Entscheidungen, Bewertungslogik
Lohnabrechnungssysteme	Fehlzeiten, Zulagen, Abwesenheiten
Schließanlagen	Zutritte, Bewegungsprofile, Anwesenheit
GPS / Telematik	Standort, Fahrverhalten, Routen
Videoüberwachung	Verhalten, Anwesenheit, Arbeitsweise
SIEM / UEBA / Sentinel	Risiko-Scoring, Anomalien, Nutzerverhalten
Purview / DLP-Systeme	Kommunikation, Datenabfluss, interne Risiken
KI-Tools	Mustererkennung, Prognosen, automatisierte Bewertungen

2. Rechtliche Grundlage: § 87 Abs. 1 Nr. 6 BetrVG

Der zentrale Mitbestimmungstatbestand ist § 87 Abs. 1 Nr. 6 BetrVG. Er betrifft technische Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung der Arbeitnehmer zu überwachen. Die Norm ist eine der wichtigsten Schutzvorschriften des Betriebsverfassungsrechts bei Digitalisierung.

Dabei geht es nicht nur um klassische Überwachungskameras oder Stechuhren. Auch Software kann eine technische Einrichtung sein.

Entscheidend sind drei Fragen:

Gibt es eine technische Einrichtung?
Werden personenbezogene oder personenbeziehbare Beschäftigtendaten verarbeitet?
Kann das System Verhalten oder Leistung sichtbar machen?

Wenn diese Fragen bejaht werden, braucht der Arbeitgeber eine mitbestimmte Regelung. Ohne Zustimmung des Betriebsrats darf das System in diesem Umfang nicht eingeführt oder genutzt werden.

Kommt keine Einigung zustande, kann die Einigungsstelle angerufen werden. Nach § 76 BetrVG wird sie zur Beilegung von Meinungsverschiedenheiten zwischen Arbeitgeber und Betriebsrat gebildet; in erzwingbaren Fällen ersetzt ihr Spruch die fehlende Einigung. (Gesetze im Internet)

3. Warum Datenschutz allein nicht reicht

Viele Arbeitgeber argumentieren: „Das ist datenschutzrechtlich geprüft.“ Oder: „Der Datenschutzbeauftragte hat keine Einwände.“ Das reicht nicht.

Datenschutz und Mitbestimmung sind zwei verschiedene Ebenen.

Die DSGVO fragt: Ist die Verarbeitung personenbezogener Daten rechtmäßig, transparent, zweckgebunden, erforderlich und verhältnismäßig?

Das BetrVG fragt zusätzlich: Hat der Betriebsrat bei Einführung und Anwendung des Systems mitbestimmt?

Ein System kann datenschutzrechtlich teilweise zulässig sein und trotzdem mitbestimmungspflichtig bleiben. Umgekehrt kann eine Betriebsvereinbarung keine rechtswidrige Datenverarbeitung „heilen“. Beide Ebenen müssen zusammenpassen.

Besonders bei Internal Risk Monitoring zeigt sich dieses Spannungsverhältnis. Sicherheitslösungen sollen Angriffe verhindern. Gleichzeitig können sie Beschäftigte kategorisieren, bewerten und überwachen. Der Beitrag „Internal Risk Monitoring vs. Totalüberwachung“ beschreibt genau diesen schmalen Grat: Cybersecurity ist notwendig, aber KI-gestützte Tools können die Grenze zur Dauerüberwachung überschreiten.

4. Internal Risk Monitoring: Sicherheitsinstrument oder Überwachung?

Internal Risk Monitoring meint die technische Erkennung interner Risiken. Das kann sinnvoll sein. Unternehmen müssen sich gegen Datenabfluss, Sabotage, Malware, Social Engineering, Phishing und Insider-Bedrohungen schützen.

Typische Risiken sind:

ungewöhnlich hohe Downloads,
massenhafte Dateiübertragungen,
Zugriff auf sensible Ordner,
Nutzung nicht genehmigter Apps,
ungewöhnliche USB-Vorgänge,
verdächtige Login-Muster,

Datenabfluss an private E-Mail-Adressen,
auffällige Löschaktionen,
Umgehung von Zugriffskontrollen,
verdächtige Kommunikation.

Das Problem: Diese Sicherheitsindikatoren beziehen sich häufig auf konkrete Personen. Damit entsteht schnell ein Beschäftigtenprofil.

Die beigefügten Unterlagen beschreiben sechs interne Risikotypen: Saboteur, unwissender Nutzer, anspruchsberechtigter Insider, erpressbarer Entwickler, Leaker und nachlässiger Manager. Zusätzlich werden Reifegrade wie Prädisposition, Stressor, auffälliges Verhalten sowie Planung und Vorbereitung genannt.

Aus Betriebsratssicht ist daran heikel: Sobald ein System Beschäftigte nach Risiko, Verhalten, Stressoren, Abweichungen oder Auffälligkeiten bewertet, geht es nicht mehr nur um abstrakte IT-Sicherheit. Dann entsteht ein System zur Verhaltens- und möglicherweise Leistungsbewertung.

Nicht jedes Sicherheitssystem überwacht Beschäftigte – aber jedes Überwachungssystem beginnt als Sicherheitssystem.

5. Microsoft 365, Purview, Sentinel und Viva als Praxisbeispiele

Besonders praxisrelevant sind Microsoft-Umgebungen. Viele Unternehmen nutzen Microsoft 365 ohnehin. Dadurch werden Zusatzfunktionen wie Purview, Defender, Sentinel oder Viva oft technisch naheliegend aktiviert.

Der beigefügte Beitrag „Im Verborgenen überwacht?“ beschreibt, dass Microsoft Purview Kommunikation und Daten überwachen kann, darunter E-Mails, Chats, Sprachaufzeichnungen, Meeting-Transkripte und Dateien. Es können potenziell unangemessene Inhalte, Regelverstöße, Sicherheitsrisiken, Datenlecks und Kommunikationsmuster analysiert werden.

Microsoft Sentinel wird dort als System zur Sicherheitsüberwachung und Analyse von Benutzerverhalten beschrieben. Es sammelt Daten aus Microsoft-Tools, Firewalls, VPNs, Endpunktsystemen und anderen Quellen, speichert Logs zentral und kann Anomalien, nicht routinemäßige Aktionen und Risikofaktoren erkennen.

Der Beitrag „Internal Risk Monitoring“ weist zudem darauf hin, dass Microsoft Viva detaillierte Analysen über Meeting-Pünktlichkeit, Redeanteile oder Aufmerksamkeitskurven erstellen kann. Sentinel könne Arbeitsmuster mit historischen Daten vergleichen und Auffälligkeiten individuellen Risiko-Scores zuordnen.

Das sind genau die Fälle, in denen eine Betriebsvereinbarung zwingend präzise sein muss.

6. Wann gehört ein IT-System in die Einigungsstelle?

Ein IT-System gehört in die Einigungsstelle, wenn folgende Punkte zusammenkommen:

Der Arbeitgeber will ein IT-System einführen oder erweitern.
Das System verarbeitet Beschäftigtendaten.
Das System kann Verhalten oder Leistung sichtbar machen.

Der Betriebsrat verlangt eine Betriebsvereinbarung.
Arbeitgeber und Betriebsrat einigen sich nicht.
Der Streit betrifft einen erzwingbaren Mitbestimmungstatbestand.

Dann kann die Einigungsstelle angerufen werden. Typische Konflikte sind:

Streitpunkt	Warum einigungsstellenrelevant?
Arbeitgeber will System ohne BV einführen	Mitbestimmung nicht abgeschlossen
Arbeitgeber verweigert technische Unterlagen	Betriebsrat kann System nicht bewerten
Arbeitgeber nennt nur „IT-Sicherheit“ als Zweck	Zweck zu pauschal
Betriebsrat fordert Auswertungsverbote	Schutz vor Leistungs- und Verhaltenskontrolle
Arbeitgeber will personenbezogene Logs lange speichern	Speicherfrist und Zweckbindung streitig
KI-Funktionen werden per Update aktiviert	neuer mitbestimmungspflichtiger Funktionsumfang
Admins erhalten Vollzugriff	Rollen- und Rechtekonzept ungeklärt
Daten gehen in die Cloud	Datenschutz, Drittland, Zugriff, TOM streitig
Risk Scores werden erstellt	Profilbildung und Bewertung möglich
Daten sollen für arbeitsrechtliche Maßnahmen genutzt werden	Beweisverwertung und Zweckänderung streitig

7. Was die Einigungsstelle bei IT-Systemen regeln kann

Die Einigungsstelle kann die fehlende Einigung über eine Betriebsvereinbarung ersetzen. Sie kann also verbindliche Regeln für Einführung und Nutzung des IT-Systems festlegen.

Typische Regelungspunkte sind:

7.1 Zweckbindung

Jede Verarbeitung muss einem klaren Zweck zugeordnet werden.

Nicht ausreichend sind Formulierungen wie:

„zur IT-Sicherheit“,
„zur Compliance“,
„zur Optimierung“,
„zur Verbesserung der Prozesse“,
„zur Sicherstellung des Betriebs“.

Besser ist:

„Das System darf ausschließlich zur Erkennung konkreter sicherheitsrelevanter Ereignisse genutzt werden, insbesondere unautorisierter Zugriffe, Malware-Indikatoren, ungewöhnlicher Datenabflüsse oder technischer Störungen. Eine Nutzung zur Leistungs- oder Verhaltenskontrolle ist ausgeschlossen.“

7.2 Rollen- und Rechtekonzept

Es muss klar geregelt werden:

Wer darf auf welche Daten zugreifen?
Welche Rollen gibt es?
Welche Adminrechte bestehen?
Wer darf Auswertungen erstellen?

Wer darf Rohdaten sehen?
Wer darf personenbezogene Daten exportieren?
Wer kontrolliert privilegierte Zugriffe?

Gerade Admin-Zugriffe sind kritisch. Ein System kann auf dem Papier datenschutzfreundlich sein, aber durch weitreichende Adminrechte faktisch eine Totalüberwachung ermöglichen.

7.3 Protokolldaten

Protokolldaten sind oft der Kern des Problems. Sie zeigen, wer wann was getan hat.

Zu regeln sind:

welche Logs erhoben werden,
ob IP-Adressen gespeichert werden,
ob Gerätekennungen gespeichert werden,
ob Benutzer-IDs gespeichert werden,

ob Inhalte oder nur Metadaten erfasst werden,
ob Logs personenbezogen oder pseudonymisiert verarbeitet werden,
wann eine Re-Identifikation zulässig ist.

7.4 Löschfristen

Ohne klare Löschfristen entstehen Schattenarchive.

Die Betriebsvereinbarung sollte festlegen:

Standardlöschfrist,
Löschfrist für Rohdaten,
Löschfrist für aggregierte Daten,
Löschfrist für Sicherheitsvorfälle,

Sonderfristen bei konkretem Verdacht,
automatische Löschung,
Dokumentation der Löschung.

Als guter Standard kann ein eigenes Löschkonzept dienen, etwa orientiert an DIN 66398, wie es auch im beigefügten Beitrag als Referenz für strukturierte Governance genannt wird.

7.5 Auswertungsverbote

Der wichtigste Schutz ist ein klares Auswertungsverbot.

Beispiel:

„Eine Auswertung personenbezogener oder personenbeziehbarer Daten zum Zweck der Leistungs- oder Verhaltenskontrolle ist unzulässig. Dies gilt insbesondere für Rankings, Scorewerte, Produktivitätsvergleiche, Anwesenheitsprofile, Kommunikationsanalysen, Reaktionszeitmessungen und individuelle Bewegungsprofile.“

Je mehr ein System über Beschäftigte weiß, desto genauer muss die Betriebsvereinbarung sein.

7.6 Schnittstellen

Viele Risiken entstehen nicht im Hauptsystem, sondern durch Schnittstellen.

Zu regeln sind:

Schnittstellen zu HR-Systemen,
Schnittstellen zu Microsoft 365,
Schnittstellen zu SIEM-Systemen,
Schnittstellen zu Ticketsystemen,
Schnittstellen zu Zeiterfassung,

Schnittstellen zu Lohnabrechnung,
Schnittstellen zu Data Warehouses,
API-Zugriffe,
Exportfunktionen,
Reporting-Tools.

Jede neue Schnittstelle sollte zustimmungspflichtig sein.

7.7 Cloud-Nutzung

Bei Cloud-Systemen müssen geregelt werden:

Anbieter,
Serverstandorte,
Unterauftragnehmer,
Zugriffsmöglichkeiten des Anbieters,
Verschlüsselung,

Mandantentrennung,
Supportzugriffe,
Drittlandtransfer,
Protokollierung externer Zugriffe,
Exit-Konzept.

7.8 KI-Funktionen

KI-Funktionen müssen besonders streng geregelt werden.

Zu klären sind:

Gibt es automatisierte Bewertungen?
Werden Beschäftigte klassifiziert?
Gibt es Risiko-Scores?
Gibt es Empfehlungen an Führungskräfte?
Werden Anomalien personenbezogen gemeldet?

Welche Trainingsdaten werden genutzt?
Welche Schwellenwerte gelten?
Wer kann diese Schwellenwerte ändern?
Wie werden Fehlalarme behandelt?

Der beigefügte Beitrag weist ausdrücklich auf Black-Box-Algorithmen und nicht vergleichbare Risk Scores hin. Betriebsräte und Datenschutzbeauftragte können solche Systeme oft kaum nachvollziehen, weil Hersteller unterschiedliche Bewertungslogiken und Schwellenwerte verwenden.

7.9 Datenschutz-Folgenabschätzung

Bei besonders risikoreichen Systemen sollte eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO verbindlich vorgesehen werden.

Das gilt besonders bei:

systematischer Überwachung,
Profilbildung,
KI-gestützter Bewertung,
umfangreicher Verarbeitung von Kommunikationsdaten,

Verarbeitung sensibler Daten,
Verknüpfung vieler Datenquellen,
verdecktem Monitoring,
Risiko-Scoring.

7.10 Beweisverwertungsverbot

Ein starkes Instrument ist ein Beweisverwertungsverbot.

Beispiel:

„Daten, die unter Verstoß gegen diese Betriebsvereinbarung, gegen Mitbestimmungsrechte des Betriebsrats oder gegen datenschutzrechtliche Vorgaben erhoben, gespeichert oder ausgewertet wurden, dürfen nicht für personelle Einzelmaßnahmen, Abmahnungen, Kündigungen, Leistungsbeurteilungen oder sonstige Nachteile gegenüber Beschäftigten verwendet werden.“

Das ist besonders wichtig, weil das Bundesarbeitsgericht beim Einsatz eines Keyloggers entschieden hat, dass eine anlasslose umfassende Überwachung ohne konkreten Verdacht unzulässig sein kann und daraus gewonnene Erkenntnisse einem Verwertungsverbot unterliegen können. (Das Bundesarbeitsgericht)

8. Keylogger-Entscheidung des BAG: Warnsignal für digitale Totalüberwachung

Die Entscheidung des BAG vom 27.07.2017 – 2 AZR 681/16 ist für IT-Betriebsvereinbarungen besonders wichtig.

Dort ging es um einen Software-Keylogger. Der Arbeitgeber hatte Tastatureingaben protokolliert und Screenshots gefertigt. Das BAG stellte klar: Der Einsatz eines Software-Keyloggers ist nicht erlaubt, wenn kein auf den Arbeitnehmer bezogener, durch konkrete Tatsachen begründeter Verdacht einer Straftat oder einer anderen schwerwiegenden Pflichtverletzung besteht. (Das Bundesarbeitsgericht)

Für Betriebsräte bedeutet das:

Nicht alles, was technisch möglich ist, ist rechtlich zulässig.
Nicht alles, was der IT-Sicherheit dient, ist verhältnismäßig.
Nicht jede Datenerhebung darf später gegen Beschäftigte verwendet werden.

Gerade moderne Systeme können keyloggerähnliche Effekte erzeugen, auch wenn sie nicht „Keylogger“ heißen. Wenn Systeme Eingaben, Screens, Klicks, Kommunikationsverhalten, App-Nutzung, Login-Zeiten, Dateiaktivitäten oder Meeting-Verhalten personenbezogen auswerten, muss der Betriebsrat besonders genau hinsehen.

Nicht der Name eines IT-Systems entscheidet über die Mitbestimmung – sondern seine Überwachungsmöglichkeiten.

9. Die Rolle der Einigungsstelle bei der Betriebsvereinbarung

Die Einigungsstelle ist kein reines Datenschutzgremium. Sie entscheidet betriebsverfassungsrechtlich. Bei IT-Systemen geht es meistens um die Frage: Unter welchen Bedingungen darf das System eingeführt und genutzt werden?

Die Einigungsstelle kann insbesondere regeln:

Systembeschreibung,
zulässige Zwecke,
verbotene Zwecke,
Datenkategorien,
Nutzergruppen,
Rollen und Rechte,
Adminzugriffe,
Auswertungen,
Reports,
Dashboards,

Löschfristen,
Schnittstellen,
Cloud-Zugriffe,
KI-Funktionen,
Datenschutz-Folgenabschätzung,
Informationsrechte des Betriebsrats,
Audit-Rechte,
Eskalationsverfahren,
Sanktionen bei Verstößen,
Beweisverwertungsverbot.

Der Betriebsrat kann dafür externe Expertise nutzen. Die beigefügte Arbeitshilfe zur externen Beratung für Betriebsräte hebt hervor, dass Betriebsräte gerade bei IT-Systemen, Arbeitszeitmodellen, Sozialplänen und komplexen Betriebsvereinbarungen auf externen Sachverstand angewiesen sein können. Sie beschreibt auch, dass externe Beisitzer und Vertreter in der Einigungsstelle eine wichtige Rolle spielen können.

10. Typischer Ablauf einer Einigungsstelle bei IT-Systemen

Schritt 1: Arbeitgeber kündigt IT-System an

Der Arbeitgeber informiert den Betriebsrat über ein neues System oder ein Update. Häufig geschieht das zu spät oder zu allgemein.

Typische Aussagen:

„Das ist nur ein Sicherheitstool.“
„Das ist nur ein Update.“
„Das System wird nicht zur Überwachung genutzt.“
„Die Daten interessieren uns gar nicht.“
„Das ist Konzernstandard.“
„Das ist technisch notwendig.“

Der Betriebsrat sollte solche Aussagen nicht ungeprüft übernehmen.

Schritt 2: Betriebsrat verlangt vollständige Informationen

Der Betriebsrat sollte verlangen:

Produktname,
Anbieter,
Module,
Lizenzumfang,
Datenkategorien,
Systemarchitektur,
Rollen- und Rechtekonzept,
Adminrechte,
Auswertungsmöglichkeiten,
Standardreports,

Dashboards,
KI-Funktionen,
Schnittstellen,
Cloud-Standorte,
Unterauftragnehmer,
Löschkonzept,
Datenschutz-Folgenabschätzung,
TOM,
Verzeichnis der Verarbeitungstätigkeiten,
Berechtigungsmatrix,
Protokollierungskonzept.

Schritt 3: Betriebsrat prüft Mitbestimmung

Der Betriebsrat prüft, ob § 87 Abs. 1 Nr. 6 BetrVG betroffen ist. Bei Arbeitszeitbezug kommen zusätzlich § 87 Abs. 1 Nr. 2 und Nr. 3 BetrVG hinzu. Bei mobiler Arbeit kann § 87 Abs. 1 Nr. 14 BetrVG relevant sein. Bei Gesundheitsschutz kann § 87 Abs. 1 Nr. 7 BetrVG betroffen sein.

Schritt 4: Entwurf einer Betriebsvereinbarung

Der Betriebsrat sollte nicht nur reagieren, sondern einen eigenen Entwurf vorlegen. Dieser Entwurf sollte möglichst konkret sein. Allgemeine Datenschutzformulierungen reichen nicht.

Schritt 5: Verhandlungen

Arbeitgeber und Betriebsrat verhandeln. Häufig entstehen Streitpunkte bei Auswertungen, Logs, Löschfristen, Adminzugriffen, Cloud-Daten und Beweisverwertung.

Schritt 6: Scheitern der Verhandlungen

Wenn keine Einigung möglich ist, fasst der Betriebsrat einen Beschluss zur Anrufung der Einigungsstelle.

Schritt 7: Einsetzung der Einigungsstelle

Arbeitgeber und Betriebsrat einigen sich auf den Vorsitzenden und die Zahl der Beisitzer. Gelingt dies nicht, entscheidet das Arbeitsgericht. Die Einigungsstelle besteht aus einem unparteiischen Vorsitzenden und gleich vielen Beisitzern beider Seiten. (Gesetze im Internet)

Schritt 8: Technische Aufklärung

Bei IT-Systemen ist die Sachverhaltsaufklärung entscheidend. Ohne technische Klarheit kann keine gute Regelung entstehen.

Die Einigungsstelle sollte daher klären:

Was kann das System wirklich?
Welche Funktionen sind aktiviert?
Welche Funktionen sind lizenziert, aber deaktiviert?
Welche Funktionen können per Update aktiviert werden?
Welche Daten entstehen automatisch?

Welche Daten werden exportiert?
Welche Daten können personenbezogen ausgewertet werden?
Welche Reports existieren?
Welche KI-Komponenten sind enthalten?

Schritt 9: Spruch oder Einigung

Kommt eine Einigung zustande, wird eine Betriebsvereinbarung abgeschlossen. Kommt keine Einigung zustande, kann die Einigungsstelle in erzwingbaren Fällen einen Spruch fassen. Nach § 76 BetrVG ist der Spruch schriftlich niederzulegen und dem Arbeitgeber und Betriebsrat zuzuleiten. (Gesetze im Internet)

11. Musterstruktur für eine Betriebsvereinbarung IT-Systeme

Eine starke Betriebsvereinbarung sollte mindestens folgende Struktur haben:

Präambel
Geltungsbereich
Systembeschreibung
Zulässige Zwecke
Verbotene Zwecke
Datenkategorien
Rollen- und Rechtekonzept
Adminzugriffe
Protokolldaten
Auswertungen und Reports
Verbot von Leistungs- und Verhaltenskontrolle
KI-Funktionen und automatisierte Bewertungen

Schnittstellen
Cloud und externe Dienstleister
Datenschutz-Folgenabschätzung
Löschfristen
Informationsrechte des Betriebsrats
Audit- und Kontrollrechte
Change-Management bei Updates
Schulung der Beschäftigten
Beweisverwertungsverbot
Sanktionen bei Verstößen
Laufzeit, Kündigung, Nachwirkung
Anlagen: Berechtigungsmatrix, Datenfelder, Reports, Löschkonzept, TOM, Systemübersicht

12. Besonders wichtige Klauseln

13. Praxisproblem: „Das ist nur ein Update“

Viele Überwachungsrisiken entstehen nicht bei der Ersteinführung, sondern später.

Ein Tool wird zunächst harmlos eingeführt. Später kommen neue Funktionen hinzu. Ein Update aktiviert neue Dashboards. Ein neues Modul erlaubt Risk Scores. Eine neue Lizenz enthält KI-Analysen. Ein deaktivierter Bericht wird plötzlich nutzbar.

Der beigefügte Beitrag „Internal Risk Monitoring“ nennt genau dieses Problem: Fachabteilungen implementieren Updates, deren Datenschutzrelevanz auf den ersten Blick nicht erkennbar ist; zudem können zuvor deaktivierte Funktionen durch neue Versionen wieder aktiviert werden.

Deshalb braucht jede IT-Betriebsvereinbarung eine strenge Update-Klausel.

14. Praxisproblem: „Security first“

IT-Abteilungen argumentieren häufig mit Sicherheit. Das ist nachvollziehbar, aber nicht ausreichend.

IT-Sicherheit ist wichtig. Art. 32 DSGVO verpflichtet Verantwortliche und Auftragsverarbeiter, geeignete technische und organisatorische Maßnahmen zu treffen.

Aber daraus folgt kein Freibrief für Totalüberwachung. Auch Sicherheitsmaßnahmen müssen erforderlich, geeignet, transparent und verhältnismäßig sein.

Der richtige Ansatz lautet daher nicht: Sicherheit oder Datenschutz.

Der richtige Ansatz lautet: Sicherheit durch datenschutzfreundliche Gestaltung.

Das bedeutet:

so wenig personenbezogene Daten wie möglich,
so viel Aggregation wie möglich,
Pseudonymisierung als Standard,
Re-Identifikation nur bei konkretem Anlass,
klare Rollen,

dokumentierte Zwecke,
kurze Speicherfristen,
technische Deaktivierung unnötiger Funktionen,
keine heimlichen Auswertungen,
Betriebsratskontrolle.

Die größten Überwachungsrisiken entstehen oft nicht bei der Einführung – sondern mit dem nächsten Update.

16. Häufige Fehler des Betriebsrats

Das System wird nur nach dem Namen bewertet. Ein „Ticketsystem“ kann harmlos sein oder ein Produktivitätsmesssystem.
Der Betriebsrat verlässt sich auf Aussagen der IT. Entscheidend sind Dokumentation, Rechte, Reports und technische Möglichkeiten.
Es wird keine Berechtigungsmatrix verlangt. Ohne Berechtigungsmatrix bleibt unklar, wer was sehen kann.
Es fehlen Regeln zu Updates. Dann entstehen spätere Überwachungsfunktionen durch die Hintertür.

Es gibt kein Beweisverwertungsverbot. Dann können unzulässig genutzte Daten später gegen Beschäftigte verwendet werden.
Löschfristen bleiben unklar. Dann werden Logs zu dauerhaften Schattenakten.
KI-Funktionen werden nicht gesondert geregelt. Dann entstehen Risk Scores, Empfehlungen oder automatisierte Bewertungen.
Schnittstellen werden unterschätzt. Die gefährlichsten Auswertungen entstehen oft erst durch Datenverknüpfung.

17. Häufige Fehler des Arbeitgebers

Einführung ohne vollständige Mitbestimmung.
Pauschale Berufung auf IT-Sicherheit.
Unklare Zwecke.
Keine Datenschutz-Folgenabschätzung.
Keine klare Trennung zwischen Security Monitoring und Mitarbeiterkontrolle.

Zu lange Speicherfristen.
Zu breite Adminrechte.
Fehlende Transparenz gegenüber Beschäftigten.
Aktivierung neuer Module ohne Beteiligung des Betriebsrats.
Verwendung von Systemdaten für arbeitsrechtliche Maßnahmen ohne klare Rechtsgrundlage.

18. Checkliste für den Betriebsrat

Vor Einführung eines IT-Systems sollte der Betriebsrat mindestens folgende Fragen stellen:

Welche Dashboards gibt es?

Welche KI-Funktionen gibt es?

Gibt es Scorewerte?

Gibt es Risikoklassen?

Gibt es automatische Warnungen?

Wer erhält Meldungen?

Wer darf Daten exportieren?

Welche Schnittstellen bestehen?

Wie lange werden Daten gespeichert?

Welche Reports gibt es?

Welche Daten sind personenbeziehbar?

Welche Daten werden erhoben?

Welche Funktionen sind deaktiviert?

Wo werden Daten gespeichert?

Gibt es Cloud-Zugriffe?

Gibt es Drittlandbezug?

Wurde eine Datenschutz-Folgenabschätzung durchgeführt?

Gibt es ein Löschkonzept?

Gibt es ein Rollen- und Rechtekonzept?

Gibt es eine technische Dokumentation?

Gibt es eine TOM-Dokumentation?

Gibt es eine Betriebsvereinbarung?

Gibt es ein Beweisverwertungsverbot?

Welche Module sind lizenziert?

Wie heißt das System genau?

Welche Funktionen sind aktiviert?

Hamburg, Berlin, München: regionale Besonderheiten

Die rechtlichen Grundlagen gelten bundesweit. Dennoch gibt es regionale Praxisunterschiede. Besonders relevant ist IT-Mitbestimmung erfahrungsgemäß in folgenden Regionen:

Hamburg

In Hamburg spielen Hafenlogistik, Luftfahrt, Medien, Handel und Konzernstrukturen eine große Rolle. Gerade dort sind Zeiterfassung, Zutrittskontrolle, Schichtplanung, Telematik, Logistiksysteme und Sicherheitsmonitoring häufige Themen.

Berlin

Berlin ist stark geprägt von Start-ups, Tech-Unternehmen, Plattformarbeit, öffentlichem Dienst, Forschung und hybriden Arbeitsformen. Typische Konflikte betreffen Microsoft 365, Slack, Jira, GitHub, HR-Tools, Recruitingsoftware, KI-Tools und Homeoffice-Monitoring.

München

In München sind große Konzernstrukturen, Automotive, Versicherungen, IT-Dienstleister und Forschungseinrichtungen prägend. Häufige Einigungsstellenthemen sind SAP, Microsoft 365, Cloudsysteme, Engineering-Tools, Zutrittskontrolle, mobile Arbeit und konzernweite Security-Systeme.