Der interne KI-Assistent ist seit vier Wochen live. Auf Ihrem Server liegt seitdem ein Protokoll: Angebotsentwürfe, Formulierungshilfen, Fragen zur Reklamationsabwicklung. Dazwischen eine Recherche zu Abfindungen bei Aufhebungsverträgen, dreimal dieselbe Grammatikfrage von derselben Person und ein Bewerbungsanschreiben, dessen Adressat nicht Ihr Unternehmen ist. Vor vier Wochen wäre all das bei einem Cloud-Anbieter gelandet. Jetzt liegt es bei Ihnen.
Genau das war der Plan. Wer Sprachmodelle im eigenen Haus betreibt, muss keinem Anbieter vertrauen, keinem Auftragsverarbeiter hinterherprüfen und keine Drittlandübermittlung begründen. Das Argument stimmt. Wir vertreten es selbst, ausführlich und mit Quellen, im Artikel Warum On-Premise-KI fast immer sicherer ist. Es hat nur eine zweite Hälfte, die im Prospekt fehlt: Der Datenschutz verschwindet mit der Cloud nicht. Er zieht bei Ihnen ein.
Von dieser zweiten Hälfte handelt dieser Artikel.
Wer die Daten hält, ist die Stelle, vor der sie geschützt werden müssen.
Der Datenschutz zieht mit ein
Mit dem Betrieb im eigenen Haus wechseln Sie die Rolle. Sie sind jetzt Verantwortlicher im Sinne der DSGVO [1], und zwar für eine Datenart, die es in Ihrem Unternehmen bisher nicht gab. Prompts sind keine Nutzungsdaten wie Login-Zeitstempel. Menschen schreiben einer Maschine, was sie einem Kollegen nie schreiben würden: den Fehler, den sie gerade gemacht haben und erst verstehen wollen, bevor sie ihn melden. Die Frage, ob ein Symptom für eine Krankschreibung reicht. Den Konflikt mit dem Vorgesetzten, verpackt als Bitte um eine diplomatische Antwort auf diese eine Mail. Über Monate gelesen ist ein Prompt-Protokoll ein Verhaltensprofil, und ein intimeres als der E-Mail-Verkehr, weil die Hemmschwelle gegenüber der Maschine niedriger liegt.
Rechtlich landet das im Beschäftigtendatenschutz, §26 BDSG [2]. Die Aufsichtsbehörden haben in ihrer Orientierungshilfe zu KI und Datenschutz klargemacht, dass sie Zwecke, Rechtsgrundlagen und Zugriffskonzepte sehen wollen, bevor produktiv gearbeitet wird [3]. Die Mittelstandsrealität dazu: Es gibt keine Datenschutzabteilung. Es gibt einen IT-Leiter, der das nebenher macht, und vielleicht einen externen Datenschutzbeauftragten mit vier Stunden im Monat. Die Frage, wer in das Protokoll schauen darf, muss trotzdem beantwortet sein, bevor die erste Anfrage darin liegt. Danach beantwortet sie sich von selbst, und zwar falsch.
Die harmlose Frage
Sechs Wochen nach dem Go-live kommt sie, meist in einer Geschäftsführungsrunde: Welche Abteilung nutzt das Ding eigentlich am meisten? Die Frage ist legitim. Die Maschine hat Geld gekostet, jemand will wissen, ob sie sich trägt. Eine Tabelle, sechs Zeilen. Fertig.
Nur ist eine Nutzungsstatistik über Beschäftigte keine Betriebskennzahl wie der Stromverbrauch. Sie sagt, wer wie viel mit einem Werkzeug arbeitet, und ist damit objektiv geeignet, Leistung und Verhalten zu überwachen. Genau dafür hat das Betriebsverfassungsgesetz eine Vorschrift: §87 Abs. 1 Nr. 6 BetrVG macht technische Einrichtungen, die zur Überwachung geeignet sind, mitbestimmungspflichtig, und auf die Absicht kommt es dabei nicht an [4]. Wir wollten doch nur die Auslastung sehen, ist der Satz, mit dem solche Auswertungen anfangen.
Das heißt nicht, dass die Statistik unterbleiben muss. Es heißt, dass sie so gebaut sein muss, dass beide Seiten ihr trauen können: die Geschäftsführung, weil die Zahlen stimmen, und der Betriebsrat, weil aus den Zahlen niemand herauslesbar ist. Das klingt nach Verhandlungssache. Zunächst ist es aber schlicht Rechnen.
Anonymisierung ist Arithmetik
Rechnen wir es an einem Modellbetrieb durch, dessen Größen aus unserer eigenen Testumgebung stammen: 45 Beschäftigte, sechs Abteilungen. Fertigung 24, Qualitätsmanagement 7, Vertrieb 5, Einkauf 4, Geschäftsführung 3, IT 2. Im ersten Monat stellen sie zusammen 1.240 Anfragen: Fertigung 180, QM 310, Vertrieb 440, Einkauf 150, Geschäftsführung 90, IT 70.
Der Lehrbuchansatz heißt k-Anonymität [5]: Eine Zeile wird nur gezeigt, wenn mindestens k Personen dahinterstehen, üblich ist k = 5. Klingt solide. In diesem Betrieb löscht die Regel drei der sechs Zeilen, denn Einkauf, Geschäftsführung und IT liegen unter der Schwelle. Die verbliebenen Zeilen summieren sich auf 930. Jeder, der die Gesamtzahl kennt, rechnet nach und fragt, wem die fehlenden 310 Anfragen gehören. Eine Unterdrückung, die die Summen nicht mehr aufgehen lässt, zeigt genau auf das, was sie verbergen soll. Der brauchbare Umgang ist ein Sammelposten: Kleine Abteilungen verschmelzen zu einer Zeile „übrige Abteilungen“, und die Rechnung geht wieder auf.
Die zweite Falle steckt in der Frage, was k eigentlich zählt. Die Kopfzahl der Abteilung? Dann passiert im Pilotbetrieb Folgendes: In der Fertigung arbeiten 24 Menschen, am Assistenten arbeitet genau einer, der Meister in der Arbeitsvorbereitung. Die 180 Anfragen der Zeile „Fertigung“ sind seine 180 Anfragen, und jeder im Haus weiß das. Eine Schwelle auf die Kopfzahl winkt die Zeile durch, 24 ist ja größer als 5. Geschützt wird niemand. Zählen muss die Schwelle die Personen, die im Auswertungszeitraum tatsächlich aktiv waren, denn das ist die Menge, aus der die Zahl stammen kann. Bei einem einzigen aktiven Nutzer heißt das: Die Zeile Fertigung verschwindet im Sammelposten, so groß die Abteilung auf dem Papier auch ist.
Eine Schwelle auf die Anfragenzahl wäre noch schiefer. Der Vertrieb hat fünf Leute und 440 Anfragen. Nach Volumen wirkt die Zeile völlig unbedenklich, dabei ist es das kleine Team mit der intensivsten Nutzung, also genau der Fall, in dem sich Aktivität am ehesten einzelnen Personen zuordnen lässt. Und noch der Zeitraum: Eine Monatsstatistik über 45 Leute wirkt harmlos. Kann der Betrachter das Zeitfenster aber frei wählen, kann er Tagesfenster abfragen und Differenzen bilden, Dienstag gegen Mittwoch, die Woche vor dem Urlaub gegen die danach. Wer weiß, wer wann im Haus war, liest aus der Differenz zweier harmloser Zahlen einen Namen. Die Schwelle muss deshalb im abgefragten Fenster gelten, nicht im Kalendermonat. Ein Tagesfenster hat dann fast überall zu wenige aktive Personen und liefert eben nur den Sammelposten.
Nichts davon ist KI-spezifisch, die Statistik-Ämter kämpfen mit denselben Effekten seit Jahrzehnten. Aber KI-Assistenten erzeugen in vielen Betrieben zum ersten Mal eine feingranulare, zentrale Aufzeichnung von Kopfarbeit. Damit wandert diese Arithmetik aus der Fachliteratur in die Betriebsvereinbarung.
Nicht wissen als Bauprinzip
In der DSGVO steht das zuständige Prinzip in Art. 5: Datenminimierung [1]. Gelesen wird es meist als Sparsamkeitsregel, erhebe wenig, lösche früh. Ernst genommen ist es eine Bauvorschrift: Das System bekommt zu bestimmten Daten gar keinen Weg.
Ein Beispiel aus unserer eigenen Entwicklung. Die Auswertungsschicht unserer Plattform, die genau die Abteilungsstatistik von oben erzeugt, hätte naheliegenderweise einen Anschluss an das Nutzerverzeichnis bekommen, das LDAP, das Anmeldungen und Rollen verwaltet. Dann kennt sie Kopfzahlen und Abteilungslisten, die ganze Organisation. Wir haben diesen Anschluss gestrichen. Die Komponente, die zählt, was gefragt wurde, kann die Belegschaft nicht aufzählen. Von einer Person kennt sie das, was deren Anmeldung mitbringt: eine Kennung und eine Abteilungsangabe. Wer nie angemeldet war, existiert für sie nicht.
Das war keine Großzügigkeit, die Entscheidung hat sich technisch sogar ausgezahlt: Die Anonymitätsschwelle zählt ohnehin aktive Personen im Zeitfenster, und die stehen in den Anfragedaten selbst. Der Verzeichnisanschluss wäre ein zweites Teilsystem gewesen, eine zweite Kopie der Zugangsdaten, eine weitere Stelle, die beim Ausfall des Verzeichnisses mit ausfällt. Der Verzicht hat ein Teilsystem entfernt statt eines hinzuzufügen.
Der eigentliche Wert liegt woanders. Was nicht verbunden ist, kann nicht abgefragt werden, von niemandem: nicht von der neugierigen Auswertung, die in drei Jahren jemand nachrüstet, nicht von einem kompromittierten Admin-Konto und auch nicht von uns als Hersteller. Selbst die Geschäftsführung in einer schwachen Stunde findet keinen Hebel. Ein Zugriffsverbot ist eine Regel. Regeln müssen durchgesetzt werden und lassen sich umgehen. Eine fehlende Verbindung ist Topologie. Sie lässt sich von außen sogar prüfen: Ob eine Komponente eine Verbindung nie aufbaut, sieht man ihrer Konfiguration und ihrem Netzverkehr an. Ob sie eine erlaubte Verbindung nie missbraucht, muss man glauben.
Die Rechnung
So weit die Theorie, jetzt die Rechnung. Bezahlt wird der Verzicht in Fragen, die keine Antwort mehr haben.
Wer hat das Werkzeug noch nie benutzt? Keine Antwort. Das System sieht nur, wer handelt. Die Differenz zur Belegschaft kann es nicht bilden, weil es die Belegschaft nicht kennt. Für den Management-Report heißt das: Eine Adoption-Quote über alle Beschäftigten gibt es nicht. Es gibt die Zahl der aktiven Personen pro Monat, und dabei bleibt es.
Die Folgefrage hat seit Februar 2025 sogar Rechtsbezug. Artikel 4 der KI-Verordnung verlangt von Betreibern, für ausreichende KI-Kompetenz ihres Personals zu sorgen [6]. Die naheliegende Kennzahl wäre eine Quote, geschult sind 31 von 45. Ein System ohne Personalliste kann diese Quote nicht ausrechnen. Es kann sagen, wer von den tatsächlich aktiven Nutzern eine Schulung nachweisen kann und wer nicht, mehr nicht. Die Quote über die ganze Belegschaft muss woanders geführt werden, in der Personalverwaltung, wo sie hingehört. Der Reflex, alles in das neue System zu legen, weil es doch da ist, läuft hier ins Leere, und im Alltag fühlt sich das je nach Tag wie Arbeitsteilung oder wie ein Mangel an.
Auch kleinere Härten bleiben. Ein fehlgeschlagener Anmeldeversuch benennt keine Person: Ein Name, der sich nicht anmelden konnte, ist eine Behauptung in einem Eingabefeld, keine Identität. Wer wissen will, ob jemand systematisch fremde Kennungen durchprobiert, bekommt das Muster zu sehen, aber keinen Namen aus der Statistik. Und der Sammelposten von oben zählt an einer Stelle bewusst ungenau: Wechselt eine Person im Auswertungszeitraum die Abteilung, wird sie darin doppelt gewogen. Der Fehler ist bekannt, und er liegt, offen gesagt, auf der durchlässigen Seite: Im Zweifel bleibt eine Sammelzeile stehen, die bei strenger Zählung verschmelzen müsste. Die Alternative wäre, genau die Zuordnung von Person zu Abteilung in die Auswertung zu holen, die dort nie ankommen soll. Also steht der Fehler benannt in der Dokumentation, statt still im Code zu wohnen.
Und dann ist da der Moment im Vertriebsgespräch, unserem eigenen. Können wir sehen, wer die meisten Anfragen stellt? Nein. Können Sie das freischalten? Nein. Es ist nicht abgeschaltet, es ist nicht gebaut, und der Umbau wäre kein Konfigurationshäkchen, sondern eine andere Architektur. Es gibt Interessenten, für die an diesem Punkt das Gespräch kürzer wird. Das ist der Preis, und es wäre unehrlich, ihn kleinzureden.
Dem steht ein Gewinn gegenüber, der sich schlecht vorführen lässt, weil er darin besteht, dass nichts passiert. Die Auswertung, die niemand bauen kann, taucht in keinem Konflikt mit dem Betriebsrat auf, und das Verhaltensprofil, das nie entsteht, steht weder in einem Auskunftsersuchen noch in einem Datenleck. Sicherheitsgewinne dieser Art haben keine Demo. Man erkennt sie daran, dass bestimmte Vorfälle ausbleiben, und Ausbleiben ist keine Folie im Pitch.
Wer das entscheiden muss
Die Grenze zwischen „wollen wir wissen“ und „wollen wir nicht wissen können“ ziehen Geschäftsführung und Betriebsrat gemeinsam, und sie gehört in die Betriebsvereinbarung zur KI-Einführung, bevor das System läuft. Kein Hersteller kann diese Entscheidung abnehmen, auch wir nicht. Ein Hersteller kann nur dafür sorgen, dass die getroffene Entscheidung hinterher in der Architektur steht statt in einer Richtlinie, die niemand durchsetzt. Die Orientierungshilfe der Aufsichtsbehörden sagt im Kern dasselbe: Zwecke festlegen, bevor Daten fließen [3].
Für das Gespräch mit einem Anbieter, uns eingeschlossen, genügen zwei Prüffragen. Erstens: Welche Komponente Ihres Systems kann unsere Personalliste aufzählen, und worüber? Zweitens: Welche Auswertung verweigert das System konstruktionsbedingt, und wo ist das dokumentiert? Auf die erste Frage gibt es eine richtige kurze Antwort. Wer auf die zweite nur hört, was alles möglich ist, hat seine Antwort auch.
Warum die Daten überhaupt ins eigene Haus gehören, steht im Artikel Warum On-Premise-KI fast immer sicherer ist. Wie eine Appliance aussieht, bei der solche Entscheidungen in der Architektur liegen, unter Produkt.