Engineering

Semantic Redaction vs. Regex: Warum Kontext beim Schutz personenbezogener Daten zählt

31.12.2025

Von

Tom Jordi Ruesch

Foto von <a href="https://unsplash.com/@purzlbaum?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Claudio Schwarz</a> auf <a href="https://unsplash.com/photos/text-BvqmW7VGRRk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

In den letzten 20 Jahren war Datensicherheit im Grunde ein Spiel von "Suchen und Vernichten".

Im Zeitalter von Datenbanken und E-Mails war der Schutz von personenbezogenen Daten (PII - Personally Identifiable Information) ein binäres Problem. Tauchte eine Kreditkartennummer im Log auf? Schwärzen. Stand eine Steuernummer in der E-Mail? Blockieren. Das Werkzeug der Wahl war RegEx (Regular Expressions). Simples, starres Pattern-Matching.

Aber wir arbeiten nicht mehr nur mit Datenbanken. Wir arbeiten auch mit Large Language Models oder LLMs.

Wenn du die Holzhammer-Methode von Regex auf die feinen Wahrscheinlichkeits-Maschinen von GenAI loslässt, sicherst du vielleicht die Daten, aber du killst oft die "Intelligence". Um KI zu bauen, die sicher und schlau ist, müssen wir weg vom Pattern-Matching und hin zur Semantischen Redaktion.

Hier ist der Grund, warum Kontext zählt und warum deine Redacting-Strategie wahrscheinlich die Performance deines LLMs in den Keller zieht.

Das "Schwarzer Balken"-Problem

Stell dir vor, du gibst einem Anwalt einen Vertrag, aber vorher nimmst du einen dicken Edding und schwärzt jeden Namen, jedes Datum und jede Firma. Dann fragst du den Anwalt: "Wer haftet in dieser Vereinbarung?"

Der Anwalt kann nicht antworten. Nicht, weil er das Gesetz nicht kennt, sondern weil du den relationalen Kontext zerstört hast, der für die Anwendung notwendig ist.

Regex-basiertes Redacting funktioniert wie dieser schwarze Edding. Es sucht nach Mustern (wie [A-Z][a-z]+) und ersetzt sie durch eine generische Maske wie [REDACTED] oder ******.

Der linguistische Kollaps

LLMs basieren auf Wahrscheinlichkeiten. Sie sagen das nächste Token voraus, basierend auf der Sequenz der Tokens davor. Wenn du eine spezifische Entität durch eine generische Maske ersetzt, flachst du die Wahrscheinlichkeitsverteilung ab.

Nimm diesen Prompt:

"Jan sagte Miriam, dass er nicht am Meeting teilnehmen kann, weil Andrea krank sei."

Wenn du hierfür simples Regex oder eine Keyword-Liste nutzt, bekommst du vielleicht:

"*** sagte ***, dass er nicht am Meeting teilnehmen kann, weil *** krank sei."

Für ein LLM (und ehrlich gesagt auch für einen Menschen) ist dieser Satz jetzt mathematischer und semantischer Müll. Das Modell hat die Subjekt-Objekt-Beziehungen verloren (Attention is all you need, anyone?). Es weiß nicht, wer wem etwas gesagt hat oder wer (oder was) krank war. Wenn du das LLM fragst "Warum hat Jan das Meeting verpasst?", wird es halluzinieren oder die Antwort verweigern, weil die kritischen Anker der Story weg sind.

Bühne frei für Semantic Redaction

Semantic Redaction (oft durch Named Entity Recognition / NER oder Small Language Models SLMs) wählt einen anderen Ansatz. Statt Daten zu zerstören, transformiert es sie und bewahrt die Struktur.

Wir suchen nicht nur nach Mustern, sondern Kontext. Es checkt, dass "Apple" in "Apple Pie" ein Essen ist, aber "Apple" in "Apple Inc." eine Organisation. Viel wichtiger: Es ersetzt sensible Daten durch Typed Tokens, die die referenzielle Integrität wahren.

Den Graphen bewahren

Schauen wir uns das Beispiel von vorhin durch die Brille der Semantic Redaction an.

Original:

"Jan sagte Miriam, dass er nicht am Meeting teilnehmen kann, weil Andrea krank sei."

Semantisch Redigiert:

"[PERSON_1] sagte [PERSON_2], dass er nicht am Meeting teilnehmen kann, weil [PERSON_3] krank sei."

Das sieht ähnlich aus, ist aber für ein LLM ein himmelweiter Unterschied.

  1. Type Safety: Das Modell weiß, [PERSON_1] ist ein Mensch, kein Ort oder Datum. Es behält das "Reasoning" bei, dass Menschen handeln und Dinge "sagen" können.

  2. Konsistenz: Wenn [PERSON_1] später im Dokument auftaucht, versteht das Modell, dass es dieselbe Person ist.

  3. Grammatik: Die Satzstruktur bleibt intakt.

Wenn du das LLM jetzt fragst "Warum hat [PERSON_1] das Meeting verpasst?", kann es präzise schlussfolgern: "Weil [PERSON_3] krank war." Deine personenbezogenen Daten bleiben sicher – das LLM hat nie "Jan" oder "Andrea" gesehen – aber die Logik der Interaktion wurde bewahrt.

Der nächste Schritt weiter: Attribute Preservation

Fortgeschrittene Infrastruktur-Tools wie rehydra gehen über simple Platzhalter hinaus. Sie analysieren und bewahren nicht-identifizierbare Attribute (wie das grammatikalische Geschlecht), um den Sprachfluss zu erhalten.

In unserem Beispiel hängt "Jan" mit dem Pronomen "er" zusammen. Wenn ein Redaction-Tool alle Geschlechts-Indikatoren strippt, kommt das LLM durcheinander und produziert roboterhaften Output oder rät fälschlicherweise "She couldn't attend" (Gott bewahre).

rehydra löst das, indem es Metadaten an das Token heftet. Es erkennt, dass [PERSON_1] männlich und [PERSON_2] weiblich ist, ohne zu verraten, wer sie sind. Das erlaubt dem LLM, die korrekten Pronomen (er oder sie) in der Antwort zu nutzen. Der generierte Text liest sich natürlich, während die echten Identitäten komplett opak bleiben.

Der letzte Schritt: Rehydration

Das ultimative Ziel von Semantic Redaction ist nicht nur, Daten zu verstecken; es geht darum, die KI nutzbar zu machen. Das führt uns zum Konzept der Rehydration.

Da wir eindeutige Platzhalter ([PERSON_1]) genutzt haben, können wir lokal eine sichere Lookup-Table erstellen. Wenn das LLM antwortet "Die Vereinbarung besagt, dass [PERSON_3] haftet", kann das lokale System das Token sofort zum echten Namen zurücktauschen.

Der User sieht die echten Daten. Die KI sieht die sicheren Tokens. Dein Datenschutzbeauftragter sieht ein sauberes Audit-Log.

Fazit

Während wir uns von simplen Chatbots zu komplexen autonomen Agenten bewegen, zählt die Qualität unseres Inputs mehr denn je. Wir können es uns nicht leisten, AI-Prompts wie schmutzige Datenbank-Logs zu behandeln, die bis zur Unkenntlichkeit geschrubbt werden müssen.

Sicherheit muss nicht Dummheit bedeuten. Indem wir von Regex zu Semantic Redaction wechseln, erlauben wir unseren LLMs, über unsere Daten nachzudenken, ohne sie jemals wirklich zu sehen. Wir behalten den Kontext, und wir behalten die Geheimnisse.

Rehydra (Github) liefert die Infrastruktur für semantische Anonymisierung und Echtzeit-Rehydration.

Diesen Artikel teilen
Besuche unser Github