🤖 AI

Addressing Labelled Data Scarcity: Taxonomy-Agnostic Annotation of PII Values in HTTP Traffic using LLMs

Dieser Beitrag stellt eine mehrstufige Pipeline auf Basis von Large Language Models vor und evaluiert diese, die eine flexible, taxonomieneutrale Annotation von personenbezogenen Daten in HTTP-Datenverkehr ermöglicht, die Datenknappheit durch die Generierung synthetischen Datenverkehrs adressiert und eine präzise Erkennung über unterschiedliche Datenschutzdefinitionen hinweg nachweist.

Ursprüngliche Autoren: Thomas Cory, Axel Küpper

Veröffentlicht 2026-05-08

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Thomas Cory, Axel Küpper

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind Datenschutzinspektor für eine belebte Stadt. Ihre Aufgabe besteht darin, jeden Brief, jedes Paket und jede digitale Nachricht zu überprüfen, die die Stadt verlässt, um sicherzustellen, dass niemand versehentlich geheime persönliche Informationen (wie Hausadressen, Telefonnummern oder medizinische Aufzeichnungen) weiterleitet. Diese geheimen Informationen werden als PII (Personenbezogene Daten) bezeichnet.

Seit Jahren nutzen Inspektoren zwei Hauptwerkzeuge:

Das Regelbuch: Eine starre Liste von Schlüsselwörtern (wie „E-Mail" oder „Sozialversicherungsnummer"). Dies funktioniert gut bei einfachen Briefen, versagt jedoch, wenn Menschen Dinge auf seltsame Weise schreiben oder Codes verwenden.
Der trainierte Hund: Ein maschinelles Lernmodell, das auf tausenden Beispielen trainiert wurde. Es ist intelligent, kennt aber nur die spezifischen Regeln, denen es beigebracht wurde. Wenn sich die Regeln ändern (z. B. wenn ein neues Gesetz „Gesundheitsdaten" anders definiert), muss der Hund von Grund auf neu trainiert werden, was lange dauert und eine massive Menge echter, geheimer Briefe zum Studium erfordert.

Das Problem: Echte geheime Briefe sind schwer zu beschaffen (wegen Datenschutzgesetzen), und die Regeln dafür, was als „geheim" gilt, ändern sich ständig. Dies lässt Inspektoren mit einem Mangel an guten Trainingsdaten und Werkzeugen zurück, die sich nicht anpassen können.

Die neue Lösung: Der „Super-Übersetzer"

Diese Arbeit stellt einen neuen Ansatz unter Verwendung von Large Language Models (LLMs) vor. Betrachten Sie ein LLM nicht als trainierten Hund, sondern als einen superintelligenten, flexiblen Übersetzer, der fast alles in der Bibliothek gelesen hat. Sie müssen diesen Übersetzer nicht auf spezifische Regeln trainieren; Sie geben ihm das Regelbuch einfach im laufenden Betrieb (zur Laufzeit) in die Hand, und er kann es sofort verstehen.

So haben die Autoren ihr System mit einfachen Analogien aufgebaut:

1. Das Fließband (Die Pipeline)

Anstatt den Übersetzer zu bitten, alles auf einmal zu erledigen, bauten die Autoren eine dreistufige Fließbandlinie:

Schritt 1: Der Reiniger (Vorverarbeitung): Bevor der Übersetzer die Nachricht sieht, bereinigt eine Maschine sie. Sie entschlüsselt Codes (wie das Zurückverwandeln von %20 in ein Leerzeichen), damit der Übersetzer einen klaren, lesbaren Satz sieht.
Schritt 2: Der Detektiv und der Schreiber (Zweistufige Annotation):
- Der Detektiv: Zuerst betrachtet das LLM die Nachricht und sagt: „Ich sehe hier eine Telefonnummer und einen Namen, aber keine medizinischen Aufzeichnungen." Es erstellt eine kurze Liste dessen, wonach gesucht werden soll.
- Der Schreiber: Dann konzentriert sich ein zweiter Durchlauf nur darauf, den genauen Text für diese spezifischen Elemente zu finden. Durch die Eingrenzung des Fokus wird der Schreiber nicht durch andere Zahlen oder Wörter verwirrt.
Schritt 3: Der Redakteur (Überprüfung): Eine letzte Prüfung betrachtet die Arbeit. Wenn der Schreiber eine Zahl übersehen oder das falsche Wort erwischt hat, korrigiert der Redakteur es.

2. Die „Fake-Brief"-Fabrik (Synthetische Daten)

Da die Inspektoren die geheimen Briefe echter Menschen nicht zum Trainieren ihrer Werkzeuge verwenden können, bauten die Autoren eine Fabrik, die Fake-Briefe herstellt.

Diese Fabrik nimmt ein Regelbuch (eine Taxonomie) und bittet das LLM, realistisch aussehende Briefe zu schreiben, die spezifische Geheimnisse enthalten (wie „John Does Telefonnummer").
Entscheidend ist, dass die Fabrik auch die Antworten (die Ground Truth) für jeden von ihr hergestellten Brief aufschreibt.
Warum dies wichtig ist: Dies löst das Problem des „Mangels". Sie können Tausende von Übungsbriefen mit perfekten Antworten sofort generieren, ohne jemals die privaten Daten einer echten Person zu berühren.

3. Die Testfahrt (Evaluation)

Die Autoren testeten dieses System mit drei verschiedenen „Regelbüchern" (Taxonomien):

AI4Privacy: Eine breite Liste gängiger Geheimnisse (Namen, E-Mails, IDs).
mHealth: Eine spezifische Liste für Gesundheits-Apps (Vitalzeichen, Fitnessdaten).
PlayStore: Eine übergeordnete Liste, die von App-Stores verwendet wird (z. B. „Finanzdaten" oder „Standort").

Die Ergebnisse:

Erfolg: Das System funktionierte bei den ersten beiden Regelbüchern unglaublich gut. Es konnte eine Nachricht lesen, das an diesem Tag bereitgestellte spezifische Regelbuch betrachten und die Geheimnisse genau finden.
Herausforderung: Es hatte etwas mehr Schwierigkeiten mit dem „PlayStore"-Regelbuch. Die Autoren erklären dies damit, dass dieses Regelbuch sehr breite Kategorien verwendet (wie „Finanzdaten"), die schwieriger auf ein bestimmtes Wort in einer Nachricht festzumachen sind als konkrete Dinge wie „Telefonnummer".
Der „Redakteur"-Schritt: Interessanterweise machte der abschließende „Redakteur"-Schritt die Dinge nicht immer besser. Manchmal korrigierte er Fehler, aber manchmal führte er neue ein. Die Autoren vermuten, dass dies daran liegen könnte, dass der Redakteur dasselbe „Gehirn" wie der Schreiber verwendete und daher dieselben Arten von Fehlern machte.

Das Fazit

Diese Arbeit beweist, dass man eine Maschine nicht jedes Mal neu trainieren muss, wenn sich Datenschutzregeln ändern. Stattdessen kann man eine flexible KI verwenden, die die Regeln im laufenden Betrieb liest.

Für Inspektoren: Sie können Regelbücher sofort austauschen, ohne Ihre Werkzeuge neu aufbauen zu müssen.
Für Datenknappheit: Sie können Ihre eigenen Übungsdaten (Fake-Briefe) generieren, um Ihre Werkzeuge zu testen, sodass Sie nicht die Daten echter Menschen stehlen müssen.

Die Autoren kommen zu dem Schluss, dass dies zwar noch kein perfekter Ersatz für leichte, schnelle Detektoren ist, aber ein mächtiges Werkzeug zur Erstellung hochwertiger Trainingsdaten und zur Auditierung von Systemen ist, während sich Datenschutzgesetze weiterentwickeln. Sie schlagen vor, dass der beste zukünftige Weg darin besteht, diese flexible KI zur Datenerstellung zu nutzen und dann kleinere, schnellere Maschinen zu lehren, wie sie die Aufgabe erledigen.

Technischer Überblick: Taxonomieneutrale Annotation von PII-Werten in HTTP-Datenverkehr mittels LLMs

Problemstellung

Automatisierte Datenschutzprüfungen von Web- und mobilen Anwendungen stützen sich zunehmend auf die Analyse von ausgehendem HTTP-Datenverkehr, um die Offenlegung von personenbezogenen Daten (PII) zu erkennen. Bestehende lernbasierte Detektoren stoßen jedoch auf zwei kritische Einschränkungen:

Datenknappheit: Sie sind auf hochwertige, manuell gekennzeichnete Datensätze angewiesen, deren Erstellung arbeitsintensiv und deren Wartung schwierig ist.
Starrheit der Taxonomie: Diese Modelle sind eng an feste Label-Taxonomien gekoppelt. Da Datenschutzdefinitionen sich weiterentwickeln oder zwischen verschiedenen Domänen variieren (z. B. DSGVO vs. mHealth vs. Play Store-Richtlinien), ist ein Nachtraining erforderlich, und die Leistung verschlechtert sich oft erheblich, selbst bei geringfügigen Änderungen der Taxonomie oder der Datenverteilung.

Die Arbeit geht davon aus, dass Large Language Models (LLMs) als Generalistenmodelle, die Zero-Shot- oder Few-Shot-Aufgaben ohne Nachtraining bewältigen können, eine potenzielle Lösung bieten, um eine taxonomieneutrale Annotation von PII-Werten zur Laufzeit zu ermöglichen.

Methodik

Die Autoren schlagen ein umfassendes Framework vor, das aus zwei Hauptkomponenten besteht: einer mehrstufigen Annotationspipeline und einem synthetischen Datengenerator.

1. Mehrstufige Annotationspipeline
Die Pipeline zerlegt die komplexe Aufgabe der PII-Erkennung in spezialisierte Teilprobleme, um die Genauigkeit zu verbessern und die Variabilität des HTTP-Datenverkehrs zu bewältigen:

Deterministische Vorverarbeitung: HTTP-Nachrichtenkörper werden normalisiert, um Kodierungsvariabilität zu minimieren. Dies umfasst URL-Decodierung (RFC 3986), Auflösung von HTML-Zeichenreferenzen und optionale Anwendungsschicht-Decodierung (z. B. Base64) für Teilstrings, die bestimmte syntaktische Muster aufweisen. Sowohl die ursprüngliche als auch die normalisierte Darstellung werden zur Nachverfolgbarkeit beibehalten.
Zweistufige Annotation:
- Label-Ebenen-Klassifizierung: Ein LLM sagt die Menge der im Text explizit vorhandenen PII-Labels ( $L_m$ ) voraus und hält sich dabei an eine strikte Anforderung „expliziter Werte" (keine Inferenz aus leeren Schlüsseln).
- Instanz-Ebenen-Extraktion: Ein zweiter LLM führt eine gezielte Named Entity Recognition (NER) auf dem normalisierten Körper durch, konditioniert auf die vorhergesagten Labels. Diese Stufe konzentriert sich auf die Erkennung von Grenzen und die Disambiguierung unter Verwendung kontextueller Hinweise (Schlüsselnamen, Wertmuster, strukturelle Position).
Nachträgliche Annotationsprüfung: Eine dritte LLM-Stufe fungiert als Prüfer, der die initialen Annotationen verfeinert, um False Negatives, Label-Mismatches und Grenzfehler zu korrigieren.
LLM-Inferenz-Harness: Um Robustheit zu gewährleisten, setzt die Pipeline Retrieval-Augmented Generation (RAG) ein, um aufgabenrelevante Beispiele (strukturell und label-spezifisch) in Prompts einzufügen. Eine deterministische Validierungsschicht erzwingt die Schema-Konformität und normalisiert Label-Ausgaben (z. B. Abbildung von „E-mail" auf „Email") unter Verwendung der Kosinusähnlichkeit gegenüber der Ziel-Taxonomie.

2. Synthetischer HTTP-Nachrichtengenerator
Um die Knappheit an gekennzeichneten Daten zu adressieren, ohne echten Benutzerdatenverkehr offenzulegen, stellen die Autoren einen taxonomiebasierten Generator vor:

Szenariogenerierung: Der LLM erstellt Szenariovorlagen (z. B. Kontenerstellung, Checkout) basierend auf einer bereitgestellten Taxonomie.
Nachrichten-Instanziierung: Der LLM generiert konkrete HTTP-Anfragen (und optional Antworten), die explizite PII-Werte enthalten.
Validierung: Eine Validierungsschicht stellt strukturelle Wohlgeformtheit, Taxonomie-Konformität sicher und stellt sicher, dass alle annotierten Werte wortwörtlich im generierten Payload erscheinen.
Abdeckungsverfolgung: Das System überwacht die Label-Abdeckung, um eine vielfältige Repräsentation über die gesamte Taxonomie hinweg zu gewährleisten.

Hauptbeiträge

Die Arbeit skizziert drei primäre Beiträge:

C1 (Annotationspipeline): Ein mehrstufiger, LLM-basierter Ansatz zur granulareren PII-Identifizierung in HTTP-Payloads, der das Umschalten von Label-Taxonomien zur Laufzeit ohne Nachtraining unterstützt.
C2 (Synthetischer Generator): Ein LLM-basierter Mechanismus zur Generierung synthetischen HTTP-Datenverkehrs mit Ground-Truth-PII-Annotationen, der die Abhängigkeit von manueller Kuratierung für sich ändernde Taxonomien verringert.
C3 (Evaluation): Eine umfassende Evaluation über drei verschiedene Taxonomien (AI4Privacy, mHealth und PlayStore), die verschiedene Domänen und Granularitätsstufen abdecken, um Flexibilität und Leistung zu bewerten.

Ergebnisse

Die Evaluation nutzte drei Datensätze, die vom synthetischen Generator abgeleitet wurden und für die Evaluation und RAG-Beispiele im Verhältnis 80/20 aufgeteilt wurden. Die Leistung wurde mittels Precision, Recall und F1-Scores auf Label- und Instanzebene gemessen.

Gesamtleistung: Die Pipeline erzielte eine starke Leistung bei den Taxonomien AI4Privacy (53 Klassen) und mHealth (38 Klassen). Die Detektion auf Label-Ebene erreichte auf Klassifizierungsebene fast das Maximum (F1 > 0,98), und die Extraktion auf Instanzebene blieb hoch (F1 > 0,95).
Taxonomie-Variance: Die Leistung war bei der Taxonomie PlayStore (38 Klassen) geringer, die übergeordnete, richtlinienorientierte Kategorien verwendet. Dies deutet darauf hin, dass die Schwierigkeit der Annotation mit der semantischen Granularität der Taxonomie korreliert; breite Kategorien sind schwieriger auf spezifische Payload-Werte abzubilden als konkrete PII-Typen.
Architektonische Auswirkungen:
- Die zweistufige Konfiguration (Klassifizierung gefolgt von gezielter Extraktion) schnitt bei AI4Privacy und mHealth im Allgemeinen besser ab oder gleichauf mit der einstufigen Annotation ab, wobei vor allem die Recall-Werte auf Instanzebene verbessert wurden.
- Bei PlayStore verbesserte der zweistufige Ansatz zwar die Label-Erkennung, führte jedoch nicht zu einer besseren Instanzextraktion, was darauf hindeutet, dass verrauschte Klassifiziererausgaben in komplexen Taxonomien Fehler propagieren können.
Prüfstufe: Die Prüfstufe bot einen begrenzten Netto-Nutzen und verschlechterte die Leistung gelegentlich. Die Autoren vermuten, dass dies darauf zurückzuführen ist, dass dieselbe Modellfamilie für Annotation und Prüfung verwendet wurde, was möglicherweise gemeinsame Annahmen reproduziert, anstatt eine unabhängige Korrektur zu bieten.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass LLMs eine vielversprechende Grundlage für eine flexible, taxonomieneutrale Datenverkehrsannotation darstellen. Wichtige Erkenntnisse sind:

Durchführbarkeit: LLMs können explizit übertragene PII-Werte genau identifizieren und annotieren, wenn die Taxonomie zur Laufzeit bereitgestellt wird, wodurch das Nachtraining für neue Label-Sets entfällt.
Datengenerierung: Synthetischer HTTP-Datenverkehr mit Ground-Truth-Annotationen ist ein tragfähiges Substrat für kontrollierte Evaluationen und Few-Shot-Prompting, was der Knappheit an gekennzeichneten Realweltdaten entgegenwirkt.
Einschränkungen und Geltungsbereich: Die Autoren sind zurückhaltend bezüglich des Einsatzes dieses Ansatzes als direkter Ersatz für leichte Produktionsdetektoren. Sie stellen fest, dass:
- Die Leistung stark vom Taxonomiedesign und der Payload-Struktur abhängt.
- Synthetische Daten, obwohl nützlich für die Evaluation, die Verteilung des realen Datenverkehrs (z. B. Verschleierung, fehlerhafte Payloads) möglicherweise nicht vollständig abbilden.
- Die aktuelle Evaluation auf explizit übertragene Werte in Anforderungskörpern beschränkt ist und Header, Cookies sowie verschlüsselten Datenverkehr ausschließt.
Zukünftiger Weg: Die Autoren schlagen einen hybriden Ansatz als vielversprechendsten weiteren Weg vor: die Verwendung von LLM-basierter Annotation zur Erstellung oder Verfeinerung von gekennzeichneten Datensätzen unter sich entwickelnden Taxonomien und die anschließende Destillation dieser Annotationen in kleinere, diskriminierende Modelle für den Hochdurchsatz-Einsatz.