Start KI-Lösungen Fertige Lösungen Peers & Simulation RAG & Retrieval Use Cases Frameworks Blog English Kontakt
Zurück zum Blog

Schwärzen vor dem Aufruf — und was Schwärzen nicht leistet

Wir haben Namen, Adressen und Kundennummern entfernt, bevor ein Support-Ticket an ein gehostetes Modell ging — und ein Kollege, der die geschwärzte Fassung las, erkannte den Kunden am verbliebenen Satz in etwa zehn Sekunden.

Die zehn Sekunden

Die Pipeline ersetzte jeden erkannten Namen, jede Adresse, Telefonnummer und Kundenreferenz durch einen typisierten Platzhalter, bevor der Text unsere Infrastruktur verließ. Auf dem Papier ist das eine saubere Geschichte über Datenminimierung, und sie bestand unsere eigene Prüfung.

Dann las jemand ein geschwärztes Ticket vor. Es beschrieb eine bestimmte Maschine in einem bestimmten Werk mit einem bestimmten Fehler, der zweimal zuvor aufgetreten war — und wer diesen Kunden betreut, weiß sofort, um wen es geht. Die Kennzeichen waren weg, die Identifizierung nicht.

Inputnicht vertrauenswürdig Guardrailsrichtlinien · pii Agentleast privilege FreigabemenschAktiongetraced
Nicht vertrauenswürdige Eingabe — Daten, keine Instruktionen. 1/4

Zwei verschiedene Probleme

Direkte Kennzeichen zu entfernen ist ein weitgehend gelöstes technisches Problem. Die Möglichkeit der Identifizierung zu entfernen ist es nicht, denn Identifizierung entsteht aus Kombinationen — und die Kombination, die einen Geschäftskunden identifiziert, ist oft genau der technische Inhalt, der das Ticket überhaupt verarbeitungswürdig macht.

Wir hatten beides vermengt, und diese Vermengung ist bequem, weil das Erste messbar ist. Man kann zählen, wie viele Namen man gefangen hat. Man kann nicht zählen, welche Schlüsse ein Leser ziehen könnte — eine Schwärzungskennzahl kann also hervorragend aussehen, während die Eigenschaft, um die es geht, unberührt bleibt.

Die Forschung, die es richtig rahmt

Pilán und Kollegen veröffentlichten Ende 2024 eine Arbeit zur Textsanitisierung, die sich an Inferenzangriffen orientiert: Die Frage ist nicht nur, ob Kennzeichen entfernt wurden, sondern ob das Verbliebene einem Angreifer weiterhin erlaubt, das geschützte Merkmal zu erschließen — bei zugleich wahrheitsgemäßem sanitisiertem Text.

Diese Rahmung haben wir übernommen. Sanitisierung, gemessen an dem, was sich erschließen lässt, ist ein weit härterer Maßstab als Sanitisierung, gemessen an einer Musterliste — und es ist der Maßstab, der dem entspricht, was ein Datenschutzbeauftragter meint, wenn er fragt, ob die Daten personenbezogen sind.

MaßnahmeWas sie erreicht
Namen und Nummern entfernenEntfernt nur direkte Kennzeichen
Technische Details verallgemeinernSenkt Inferenz, verschlechtert die Antwort
Daten in eigener Infrastruktur haltenBeseitigt die Frage
Vertragliche Kontrollen mit dem AnbieterRechtlich, nicht technisch. Beides nötig

Was wir geändert haben

Wir stellen Schwärzung nicht mehr als Anonymisierung dar. Intern und gegenüber Kunden sind geschwärzte Daten pseudonymisierte Daten, die unsere Infrastruktur verlassen haben, mit allem, was daraus folgt — und wir schreiben das ins Systemdokument, statt eine stärkere Eigenschaft anzudeuten.

Für die zwei Kunden, denen das nicht genügte, schickt die Pipeline gar nichts mehr. Ihre Einordnung und Extraktion laufen auf einem selbst betriebenen Modell. Das kostet mehr und ist die ehrliche Antwort auf eine Anforderung, die Schwärzung nicht erfüllen kann.

Das Platzhalterdetail, auf das es ankam

Unsere erste Umsetzung ersetzte jede Entität durch dieselbe Markierung. Das hielt die Antwort sicher und machte sie nutzlos: Aus einem Ticket, das drei verschiedene Personen nennt, wurden drei identische Platzhalter, und das Modell konnte nicht mehr sagen, wer wem was zugeschrieben hatte.

Typisierte und nummerierte Platzhalter haben es behoben. Eine erste Person, eine zweite Person, eine erste Firma. Der Text bleibt zusammenhängend, die Beziehungen überleben, und die Antwort lässt sich auf unserer Seite zurückabbilden. Ein kleines Umsetzungsdetail — und der Unterschied zwischen einer Schwärzung, die funktioniert, und einer, die die Ausgabe still ruiniert.

Was wir nicht schwärzen

Freitextbeschreibungen eines Fehlers, wo die identifizierende Kombination meist wohnt. Wir haben versucht, sie zu verallgemeinern, und die Antworten wurden so viel schlechter, dass das System aufhörte, nützlich zu sein — und ein nutzloses System ist keine Datenschutzverbesserung, sondern ein Projekt, das aus einem benennbaren Grund gescheitert ist.

Die Wahl, die wir Kunden vorlegen, ist deshalb ausdrücklich: die technische Beschreibung als pseudonymisierte Daten an ein gehostetes Modell geben, oder den Schritt auf eigener Infrastruktur betreiben. Eine dritte Option, die nach beidem klingt, bieten wir nicht mehr an, weil es sie nicht gibt.

Was wir protokollieren

Nicht den geschwärzten Text. Unsere Traces speichern einen Verweis auf den Originaldatensatz und die Platzhalterzuordnung, sodass ein Support-Techniker rekonstruieren kann, was gesendet wurde, ohne dass der Trace selbst zu einer zweiten Kopie von Kundendaten in einem System mit anderen Zugriffsregeln wird.

Das war ein Befund derselben Durchsicht. Wir hatten einen sorgfältigen Schwärzungsschritt gebaut und danach Eingabe und Ausgabe in ein Protokoll geschrieben, mit neunzig Tagen Aufbewahrung und weiterem Zugriff als das Quellsystem — was einen guten Teil der Sorgfalt wieder aufhob.

Was wir nicht behaupten

Wir behaupten nicht, unsere Schwärzung anonymisiere irgendetwas. Sie entfernt direkte Kennzeichen, senkt die Preisgabe, und nach dem maßgeblichen Maßstab ist sie Pseudonymisierung. Etwas anderes zu behaupten wäre eine Aussage, auf die ein Kunde sich zu seinem Schaden verlassen könnte.

Wir behaupten auch nicht, Eigenbetrieb erledige die Frage. Er ändert, wer die Daten verarbeitet, und lässt die übrigen Pflichten bestehen — einschließlich derer dazu, was das System erschließen darf und wie lange etwas aufbewahrt wird.

Quellen