KI im Betrieb einführen: Betriebsrat frühzeitig beteiligen

Mitbestimmung bei KI ist keine pauschale Ja-Nein-Frage

Stand 9. Oktober 2026 enthält das Betriebsverfassungsgesetz mehrere Anknüpfungspunkte für KI-Vorhaben. Welcher davon im Einzelfall greift, richtet sich nicht allein nach der verwendeten Modellart, sondern nach Zweck, Daten, Arbeitsablauf und möglicher Wirkung. Ein Assistent für Textentwürfe, ein System zur Schichtplanung und eine KI-gestützte Bewerberauswahl sind deshalb getrennt zu bewerten, selbst wenn sie denselben technischen Dienst nutzen.

Der Beitrag ordnet die technische und organisatorische Einführung ein. Er ersetzt keine arbeitsrechtliche, datenschutzrechtliche oder betriebsverfassungsrechtliche Prüfung. Unternehmen sollten früh klären, welche zuständigen Stellen und Arbeitnehmervertretungen einzubeziehen sind und welche bestehenden Betriebsvereinbarungen bereits gelten.

Frühe Beteiligung beginnt vor Produktauswahl und Pilotstart

Nach § 90 BetrVG hat der Arbeitgeber den Betriebsrat über die Planung von Arbeitsverfahren und Arbeitsabläufen einschließlich des Einsatzes von KI rechtzeitig unter Vorlage der erforderlichen Unterlagen zu unterrichten. Die Beratung soll so früh stattfinden, dass Vorschläge und Bedenken noch in die Planung einfließen können. Eine fertige Konfiguration mit bereits importierten Produktivdaten lässt dafür deutlich weniger Gestaltungsspielraum als ein nachvollziehbares Zielbild vor der Beschaffung.

Praktisch beginnt die Beteiligung deshalb mit einer fachlichen Aufgabe: Welche Arbeit soll unterstützt werden, welche Entscheidung bleibt bei Menschen, welche Daten werden benötigt und welche Veränderung ist für Beschäftigte zu erwarten? Erst danach werden Produkt, Modell und Betriebsform verglichen. So diskutieren die Beteiligten nicht abstrakt über KI, sondern über einen konkret beschriebenen Arbeitsprozess.

Vier Prüffelder machen mögliche Beteiligungsrechte sichtbar

Ein einheitlicher Prüfvermerk verhindert, dass jedes Projekt mit einer unstrukturierten Rechtsdiskussion beginnt. Er ersetzt keine juristische Bewertung, liefert ihr aber die nötigen Tatsachen. Besonders wichtig sind Arbeitsgestaltung, Kontrollmöglichkeit, personelle Auswahl und erforderliche Sachkunde.

• Arbeitsablauf: Verändert die KI Aufgaben, Reihenfolge, Zuständigkeiten, Qualifikationsanforderungen oder Arbeitsplätze?
• Verhaltens- oder Leistungsbezug: Erzeugt die technische Einrichtung Protokolle, Kennzahlen, Rankings oder andere Auswertungen zu einzelnen Beschäftigten?
• Personelle Auswahl: Unterstützt KI Richtlinien für Einstellung, Versetzung, Umgruppierung oder Kündigung?
• Beurteilbarkeit: Benötigt der Betriebsrat für seine Aufgaben externe Sachkunde zur Einführung oder Anwendung der KI?

Protokollierung nach ihrem Auswertungspotenzial gestalten

§ 87 Absatz 1 Nummer 6 BetrVG nennt technische Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung von Arbeitnehmern zu überwachen. Ob ein konkretes System darunter fällt, muss fachkundig geprüft werden. Technisch sollte das Projektteam aber schon vorher sichtbar machen, welche personenbezogenen Ereignisse das System erfassen, verknüpfen oder später auswerten kann.

Ein KI-Assistent benötigt nicht automatisch eine dauerhafte Speicherung vollständiger Prompts, Antworten, Bearbeitungszeiten und Nutzerkennungen. Sicherheits-, Qualitäts- und Abrechnungszwecke lassen sich oft mit getrennten, minimierten Protokollen abbilden. Zugriff, Aufbewahrung und zulässige Auswertungen werden pro Zweck festgelegt; eine neue Analysefunktion oder ein Anbieter-Update darf diese Grenze nicht still erweitern.

• technische Fehlerdiagnose von fachlicher Nutzungsanalyse trennen
• Rohinhalte nur speichern, wenn ein klarer Zweck und eine zulässige Grundlage bestehen
• personenbezogene Kennungen minimieren und Auswertungsrollen begrenzen
• unzulässige Rankings und Zweckänderungen technisch und organisatorisch ausschließen
• Aufbewahrung, Zugriff, Export und Löschung testbar dokumentieren

Ein Systemsteckbrief liefert die erforderlichen Unterlagen für die Beratung

Eine Anbieterpräsentation reicht nicht, um Auswirkungen auf den Betrieb zu beurteilen. Das Projektteam sollte einen versionierten Systemsteckbrief führen, der fachliche Aufgabe, technische Grenzen und offenen Klärungsbedarf verbindet. Jede wesentliche Funktionsänderung aktualisiert diesen Stand.

• Zweck, Nutzergruppen, betroffene Tätigkeiten und ausdrücklich ausgeschlossene Nutzungen
• Eingaben, Ausgaben, Datenquellen, Empfänger, Speicherorte und Löschwege
• Modell, Anbieter, Betriebsform, verbundene Dienste und geplante Systemaktionen
• Identitäten, Rollen, Berechtigungen und menschliche Freigabepunkte
• Protokolle, Kennzahlen, mögliche personenbezogene Auswertungen und Zugriff darauf
• Fehlerbilder, betroffene Gruppen, Beschwerdeweg, Stop-Regel und Rückfallprozess
• Pilotumfang, Testkriterien, verantwortliche Stellen und Entscheidung vor der Skalierung

Der Pilot muss Erkenntnis erzeugen, ohne die Entscheidung vorwegzunehmen

Ein Pilot ist keine rechtsfreie Vorstufe. Zugleich sollte er technisch so gestaltet sein, dass Nutzen, Risiken und Arbeitsfolgen überhaupt belastbar bewertet werden können. Dafür werden Nutzerkreis, Datenbestand, Zeitraum und erlaubte Funktionen eng begrenzt. Produktive Schreibrechte, automatische Personenbewertungen und irreversible Aktionen bleiben zunächst außerhalb des Versuchs.

Testhypothesen werden vorab festgelegt: Welche Arbeitsschritte sollen sich verändern, welche Fehler sind kritisch, welche Rückfragen entstehen und wann muss der Versuch gestoppt werden? Beschäftigte erhalten einen verständlichen Meldeweg für falsche, diskriminierende oder arbeitspraktisch ungeeignete Ergebnisse. Diese Rückmeldungen fließen als strukturierte Fehlerklassen ein, nicht als verdeckte Leistungsbewertung der meldenden Person.

• separater Testmandant und ausdrücklich freigegebene Daten
• kleine, repräsentative Nutzergruppe statt ungesteuerter Freischaltung
• Lesen, Entwerfen, Empfehlen und Ausführen als getrennte Rechte
• messbare fachliche Kriterien für richtige Antwort, Ablehnung und Übergabe
• sicherer Stop, Rückbau und Löschung der Pilotdaten

AI Act und Betriebsverfassung als getrennte Ebenen behandeln

Der AI Act ersetzt nationale Informations-, Beratungs- oder Mitbestimmungsrechte nicht. In der konsolidierten Fassung vom 27. Juli 2026 verlangt Artikel 26 Absatz 7 bei einem Hochrisiko-KI-System am Arbeitsplatz vor dessen Inbetriebnahme eine Information der Arbeitnehmervertretung und der betroffenen Arbeitnehmer nach den einschlägigen Vorschriften und Verfahren. Ob ein System als Hochrisiko-KI gilt und wann die betreffende Pflicht anwendbar ist, muss gesondert geprüft werden.

Für die Projektarchitektur ist die Trennung hilfreich: Das KI-Inventar dokumentiert Rolle und regulatorische Einstufung des Systems. Der betriebliche Einführungsprozess dokumentiert zusätzlich Arbeitsfolgen, Beteiligung, Vereinbarungen und technische Kontrollen. Eine positive AI-Act-Einstufung beantwortet damit nicht automatisch alle Fragen aus Arbeitsrecht, Datenschutz oder Arbeitsschutz.

Regelungen müssen bis in Konfiguration und Betrieb reichen

Ein allgemeiner Einführungsrahmen kann wiederkehrende Grundsätze für KI-Systeme festlegen; eine systemspezifische Anlage beschreibt Zweck, Nutzerkreis, Daten, Protokolle und Rechte der einzelnen Anwendung. Welche Form rechtlich und betrieblich passt, entscheiden die zuständigen Parteien. Technisch entscheidend ist, dass vereinbarte Grenzen nicht nur in einem Dokument stehen.

Ist beispielsweise eine personenbezogene Leistungsauswertung ausgeschlossen, müssen Rollen, Datenmodell und Analysezugänge diese Grenze stützen. Ist vor externem Versand eine menschliche Freigabe vorgesehen, erhält der KI-Dienst kein eigenständiges Senderecht. Wird eine Datenquelle ausgeschlossen, darf sie weder über direkte Schnittstellen noch über Erweiterungen oder Nutzeruploads erreichbar sein.

• Zweck und Geltungsbereich in freigegebene Funktionen übersetzen
• verbotene Auswertungen über Rollen und Datenzugriff begrenzen
• Freigaben unmittelbar vor der wirkungsreichen Systemaktion erzwingen
• Protokolle nach vereinbartem Zweck, Zugriff und Aufbewahrung konfigurieren
• Modell-, Anbieter-, Schnittstellen- und Funktionsänderungen als Prüfereignis behandeln

Qualifizierung richtet sich nach Rolle und tatsächlicher Entscheidung

Beschäftigte benötigen nicht alle dieselbe allgemeine KI-Schulung. Nutzer müssen erlaubte Daten, typische Fehler und den Meldeweg kennen. Fachprüfer benötigen Kriterien für Freigabe und Ablehnung. Administratoren müssen Berechtigungen, Protokolle und Anbieteränderungen kontrollieren. Führungskräfte müssen verstehen, welche Kennzahlen sie nicht zur Personenbewertung umdeuten dürfen.

Die Einweisung wird mit der konkreten Systemversion und Aufgabe verknüpft. Neue Datenquellen, autonome Aktionen, geänderte Speicherregeln oder eine andere Nutzergruppe lösen nicht nur ein technisches Update, sondern auch eine erneute Prüfung von Information, Beteiligung und Qualifizierung aus.

In sechs Schritten von der Idee zum kontrollierten Betrieb

Der Ablauf verbindet Beteiligung mit technischer Umsetzung, ohne beide Ebenen zu vermischen. Jede Phase endet mit einem sichtbaren Ergebnis und einer Entscheidung, ob das Vorhaben angepasst, fortgesetzt oder gestoppt wird.

• 1. Arbeitsfall, Ziel, Nutzer, betroffene Tätigkeiten und ausgeschlossene Wirkungen beschreiben
• 2. Datenfluss, Protokolle, Systemrechte und mögliche Personenbezüge im Systemsteckbrief erfassen
• 3. zuständige Stellen und Arbeitnehmervertretung rechtzeitig mit prüfbaren Unterlagen beteiligen
• 4. begrenzten Pilot mit Testdaten, Fehlerklassen, Stop-Regel und Rückbauweg konfigurieren
• 5. Nutzen, Qualität, Arbeitsfolgen, Beschwerden und technische Kontrollen gemeinsam auswerten
• 6. Freigabeumfang, Vereinbarungen, Schulung, Monitoring und erneute Prüfereignisse verbindlich festlegen

Im Betrieb zählen Wirksamkeit und Veränderung, nicht nur die Startfreigabe

KI-Dienste verändern Modelle, Funktionen und Integrationen. Ein einmal abgenommener Produktname ist deshalb keine dauerhafte Freigabe für beliebige Konfigurationen. Das Betriebsteam überwacht fachliche Fehler, Beschwerden, Rechteabweichungen, neue Auswertungsmöglichkeiten und still aktivierte Funktionen. Relevante Änderungen gehen erneut in den vereinbarten Prüf- und Beteiligungsweg.

Geeignete Kennzahlen beziehen sich auf Prozess und System: Anteil belegbarer Ergebnisse, sichere Ablehnungen, korrigierte Fehlerklassen, offene Ausnahmen, Rechteverletzungen und Zeit bis zum Stop einer fehlerhaften Funktion. Individuelle Nutzungsintensität oder Bearbeitungszeit ist dagegen nicht automatisch eine zulässige Leistungskennzahl.