Anonymisieren und an eine KI senden: warum das die Frage nicht beantwortet

Der Reflex: Namen maskieren, dann senden

Der Ansatz ist verbreitet, und er hat echte Vorzüge. Ein Filter erkennt identifizierende Daten in einem Text, ersetzt sie durch Platzhalter, schickt den Rest an ein Online-Modell und setzt danach die echten Werte wieder in die Antwort ein. Der Zugang zu den besten Modellen am Markt bleibt erhalten, es wird keine Infrastruktur aufgebaut, bezahlt wird nach Nutzung.

Für viele Anwendungsfälle ist das ein klarer Fortschritt gegenüber dem Versand von Rohdaten. Das Problem beginnt dort, wo eine Organisation eine strikte Anforderung gesetzt hat: Die Daten dürfen ihr Netz nicht verlassen. Dann zeigen sich drei Fallstricke.

Erster Fallstrick: Pseudonymisieren ist nicht Anonymisieren

Die CNIL definiert die Pseudonymisierung als eine Verarbeitung, die es verhindert, die Daten ohne Hinzuziehung zusätzlicher Informationen einer Person zuzuordnen, und stellt klar, dass sich die Identität der Personen sehr oft über Daten Dritter wiederherstellen lässt. Die Folge: Pseudonymisierte Daten behalten ihren Personenbezug. Sie bleiben im Anwendungsbereich der DSGVO, mit allen damit verbundenen Pflichten.

Echte Anonymisierung ist ein deutlich strengerer Maßstab. Sie setzt voraus, dass drei Bedingungen zugleich erfüllt sind: Es darf weder möglich sein, eine einzelne Person herauszugreifen, noch Datensätze über sie miteinander zu verknüpfen, noch mit nahezu sicherer Wahrscheinlichkeit neue Informationen über sie abzuleiten.

Bei Freitext sind diese Bedingungen kaum zu erfüllen. Ein Sitzungsprotokoll enthält implizite Identifikatoren, die kein Filter vollständig maskiert: ein Alter, eine seltene Erkrankung, eine Abteilung, ein Datum, eine Abfolge von Ereignissen, ein familiärer Kontext. Die Kombination „47 Jahre alt, diese Erkrankung, diese Abteilung, dieses Datum“ genügt oft, um eine Person wieder zu identifizieren. Was Werkzeuge als Anonymisierung von Freitext bezeichnen, ist juristisch fast immer nur eine Pseudonymisierung.

Zweiter Fallstrick: Verschlüsselung deckt den Moment der Verarbeitung nicht ab

Verschlüsselung bei der Übertragung und im Ruhezustand ist real und nützlich. Aber sie schützt den Transportweg und den Datenträger, nicht die Berechnung. Um einen Text zu transkribieren oder zusammenzufassen, muss das Modell ihn im Klartext lesen. Genau in diesem Moment liegen die Daten entschlüsselt in der Infrastruktur des Anbieters.

Der Europäische Datenschutzausschuss schreibt das in seinen Empfehlungen zu zusätzlichen Maßnahmen ausdrücklich: Verschlüsselung reicht nicht aus, wenn der Dienstleister Zugriff auf die Daten im Klartext benötigt, um sie zu verarbeiten. Genau das ist bei einem Online-KI-Dienst der Fall.

Dritter Fallstrick: Das Recht folgt dem Anbieter, nicht dem Server

Hartnäckig hält sich die Vorstellung, ein Hosting „in der Region Europa“ löse die Frage extraterritorialer Gesetze. Das ist nicht der Fall. Maßgeblich ist der Anbieter, nicht der physische Standort der Maschinen: Ein Dienstleister, der US-Recht unterliegt, kann zur Herausgabe der Daten verpflichtet werden, über die er verfügt, auch wenn sie in Europa gespeichert sind.

Die europäischen Datenschutzbehörden haben zudem festgestellt, dass eine solche Anordnung keine taugliche Rechtsgrundlage für eine Übermittlung im Sinne der DSGVO darstellt. Das macht den Anbieter nicht immun: Es erzeugt einen Normenkonflikt. Und das Konformitätsrisiko trägt der Verantwortliche, also die Kundeneinrichtung, nicht der Softwarehersteller.

Die eigentliche Frage ist nicht juristisch, sie ist architektonisch

Das ist der entscheidende Punkt, und der am häufigsten übersehene. Wenn eine Leitung zur Regel macht, dass ihre Daten unter keinen Umständen über das Internet laufen dürfen, stellt sie keine Frage der rechtlichen Einordnung. Sie stellt eine Frage der Netzflüsse.

Einen Text an eine Online-Schnittstelle zu senden, und sei er noch so sorgfältig bereinigt, heißt aber per Definition, Daten über das Internet laufen zu lassen. Die Anforderung ist mit dem ersten gesendeten Byte verletzt, unabhängig davon, ob dieses Byte ein personenbezogenes Datum ist oder nicht.

Anders gesagt: „Anonymisieren, dann senden“ beantwortet eine Frage, die die Organisation nicht gestellt hat, und scheitert an der, die sie gestellt hat. Eine solche Anforderung ist eine Anforderung an die Architektur. Die einzige Antwort, die ihr wörtlich genügt, ist die, dass die Verarbeitung vollständig im Netz der Organisation abläuft und nichts nach außen gesendet wird.

Was an der Anonymisierung nützlich bleibt

Nichts davon entwertet das Maskieren identifizierender Daten. Es ist eine ausgezeichnete Praxis, sofern man ihr den richtigen Platz gibt: eine gestaffelte Verteidigung innerhalb des eigenen Bereichs und kein Freibrief, ihn zu verlassen.

Identifikatoren in einer Verarbeitung zu maskieren, die bereits auf Ihrer eigenen Infrastruktur läuft, verringert die Folgen einer Fehlkonfiguration oder eines unbefugten Zugriffs. Bei strukturierten Daten oder Aggregaten ist echte Anonymisierung mitunter erreichbar, und dann hat sie ihren vollen Wert. Der Unterschied liegt in der Reihenfolge: Man anonymisiert aus Vorsicht, nicht um sich das Recht zum Export zu verschaffen.

Das Modell zu den Daten bringen

Die Umkehrung ist einfach formuliert: Statt die Daten zum Modell zu senden, installiert man das Modell dort, wo die Daten bereits liegen. Die Verarbeitung läuft auf der Infrastruktur der Organisation. Dann gibt es weder eine Übermittlung noch einen ausländischen Dienstleister, weder ein Risiko der Re-Identifizierung außerhalb des eigenen Bereichs noch einen Normenkonflikt.

Diese Entscheidung hat ihren Preis: Es braucht eine Maschine und eine Lösung, die für den Offline-Betrieb ausgelegt ist. Dafür muss die Konformität nicht mehr verwaltet werden, sie entfällt bereits durch die Architektur. Für eine Leitung, die „nichts verlässt das Netz“ als Regel und nicht als Wunsch formuliert hat, ist das die einzige Antwort, die trägt.