Tokenisierung für LLM-Eingaben: Wie KI liest, was sie nicht sehen darf

1. Was Tokenisierung in diesem Kontext tatsächlich leistet

Der Transformationsschritt zwischen einem Unternehmensdokument und einem externen LLM ist konzeptionell einfach: Elemente identifizieren, die die Systemgrenze nicht passieren dürfen, durch Platzhalter ersetzen, die ihre strukturelle Rolle erhalten, und das Ergebnis an das Modell übermitteln. In der Praxis verbirgt diese Einfachheit eine Reihe von Architekturentscheidungen, die bestimmen, ob der Ansatz im Produktivbetrieb skaliert oder unter Last versagt.

Dieser Artikel behandelt diese Entscheidungen. Es handelt sich nicht um ein Tutorial zu einer bestimmten Bibliothek oder einem Produkt, sondern um die Entscheidungen, die jedes Team beim Einsatz vorgelagerter Tokenisierung explizit treffen muss — einschließlich der jeweiligen Abwägungen.

Der Begriff Tokenisierung wird hier im datenschutzrechtlichen Sinne verwendet: sensible Werte durch nicht-sensible Platzhalter ersetzen, die sich zurückmappen lassen. Nicht im NLP-Sinne, wo er das Aufteilen von Text in Teilwörter für die Modelleingabe bezeichnet. Beide Begriffe teilen ein Wort — und nahezu nichts sonst.

Ein Hinweis zur Terminologie: In der CUBIG-Architektur ist Tokenisierung der zentrale Substitutionsmechanismus innerhalb einer umfassenderen Verkapselungsschicht, die auch Erkennung, Formaterhalt und optionale statistische Schutzmaßnahmen umfasst. Dieser Artikel konzentriert sich auf den Tokenisierungsmechanismus. Die Entwurfsentscheidungen sind weitgehend dieselben, unabhängig davon, ob eine Implementierung sich selbst als Tokenisierung, Verkapselung oder unter einem anderen in der Branche gebräuchlichen Namen bezeichnet.

Wenn ein Unternehmensdokument für ein externes LLM vorbereitet wird, ist das Ziel, dass das Modell eine Dokumentversion erhält, die alles für die Aufgabe Notwendige behält und alles entfernt, was innerhalb der Unternehmensgrenze bleiben soll. Tokenisierung ist der Mechanismus, der die zweite Hälfte bewirkt: sensible Elemente identifizieren und durch Platzhalter ersetzen.

Ein hilfreicher Rahmen: Das LLM muss nicht wissen, dass der Kunde Marlene Schmidt heißt. Es muss wissen, dass es einen Kunden gibt, dass dieser an drei verschiedenen Stellen im Dokument erwähnt wird und dass alle Verweise auf dieselbe Entität zeigen. Ein Token wie CUST-7F2A trägt dieselbe Information — eine referenzierbare Entität, die konsistent an mehreren Stellen erscheint — ohne die Identität preiszugeben.

Das ist die Kerneigenschaft der Tokenisierung: referentielle Integrität ohne semantische Offenlegung. Das Modell kann über „den Kunden" im gesamten Dokument schlussfolgern, weil der Token konsistent durch das Dokument führt. Die Identität lässt sich nicht rekonstruieren, weil der Token sie nicht kodiert.

Alles Weitere in diesem Artikel sind Variationen der Frage, wie diese Eigenschaft implementiert wird und welche zusätzlichen Eigenschaften sich darüber schichten lassen.

2. Deterministische vs. randomisierte Tokenisierung

Die erste Architekturentscheidung betrifft die Frage, ob ein bestimmter sensibler Wert stets denselben Token erzeugt oder bei jedem Auftreten einen anderen.

2.1 Deterministische Tokenisierung

Deterministische Tokenisierung bedeutet: Marlene Schmidt wird in jedem Dokument und jedem Workflow zu CUST-7F2A. Der Token ist eine Funktion des Werts — in der Regel unter Einbeziehung eines geheimen Schlüssels.

Der Vorteil liegt in der dokumentenübergreifenden Konsistenz. Referenzieren zwei Tickets denselben Kunden, sieht das LLM in beiden denselben Token — Analysen, die auf dokumentenübergreifenden Verknüpfungen beruhen, bleiben funktionsfähig. Für Workflows, die Dokumente aggregieren oder vergleichen — Betrugserkennung, Kundenhistorie, Kohortenanalyse — ist die deterministische Variante in der Regel die einzige praktikable Wahl.

Der Nachteil: Determinismus schafft eine Re-Identifikationsfläche. Ein Angreifer, der ausreichend tokenisierte Dokumente beobachtet und über Hintergrundwissen verfügt, wo welche Kunden auftreten, kann Token mit Identitäten korrelieren. Dieses Risiko ist bei hochvolumigen Workflows oder bei Entitäten, die über längere Zeit in vielen tokenisierten Ausgaben erscheinen, real.

2.2 Randomisierte Tokenisierung

Randomisierte Tokenisierung erzeugt bei jedem Auftreten einen anderen Token — auch für denselben Wert. Marlene Schmidt kann in einem Dokument CUST-7F2A werden, in einem anderen CUST-3B91.

Der Vorteil: Es wird keine dokumentenübergreifende Verknüpfung offengelegt. Jedes tokenisierte Dokument ist ein geschlossenes System.

Der Nachteil: Dokumentenübergreifende Analysen sind nicht möglich. Das LLM kann nicht erkennen, dass zwei Token denselben Kunden referenzieren — strukturell tun sie es nicht. Für Workflows ohne dokumentenübergreifende Verknüpfungsanforderungen — etwa die Zusammenfassung eines einzelnen Dokuments oder die Extraktion von Klauseln aus einem Vertrag — ist Randomisierung geeignet. Wo diese Verknüpfung benötigt wird, muss sie nach der LLM-Antwort rekonstruiert werden, was die Komplexität erhöht.

2.3 Das Hybridmuster der meisten Produktivdeployments

Die meisten Produktivdeployments münden in ein Hybridmodell: deterministisch innerhalb eines Workflow-Bereichs (damit mehrstufige Konversationen über einen Kunden kohärent bleiben), randomisiert über Workflow-Bereiche hinweg (damit Analysen aus einem Workflow nicht mit einem anderen verknüpft werden können). Die Abgrenzung des Bereichs — nach Session, Nutzer, Dokument oder Mandant — ist selbst eine Entwurfsentscheidung, die ein Team vor dem Go-Live festlegen muss.

3. Formaterhaltende Tokenisierung — warum generische Platzhalter nicht ausreichen

Eine naive Implementierung ersetzt sensible Werte durch generische Platzhalter: [CUSTOMER], [ACCOUNT_NUMBER], [DATE]. Das LLM sieht ein mit solchen Markierungen durchsetztes Dokument und versucht, darüber zu schlussfolgern.

In der Praxis funktioniert das schlecht — aus einem spezifischen Grund: Die Schlussfolgerungen eines LLM werden durch die Oberflächenform des Inputs geprägt. Ein Dokument mit dem Text „Kunde Marlene Schmidt rief am 2026-03-15 wegen Konto 4471-9028 an" ist für das Modell ein kohärenter Betriebsvorgang. Dasselbe Dokument mit Platzhaltern — „Kunde [CUSTOMER] rief am [DATE] wegen Konto [ACCOUNT_NUMBER] an" — liest sich wie eine Vorlage oder eine Schwärzungsnotiz. Modelle reagieren empfindlich auf dieses Signal. Die Ausgabequalität sinkt entsprechend: Zusammenfassungen werden abstrakter, Extraktionen ungenauer, und das Modell kommentiert gelegentlich die Schwärzung selbst.

Formaterhaltende Tokenisierung erzeugt Token, die den ersetzten Werten ähneln. Ein Name wird zu einem plausibel wirkenden Namens-Token: Lyra Vesper. Ein Datum wird zu einem echten Datum in einem plausiblen Bereich. Eine Kontonummer wird zu einer Zahl gleicher Länge im gleichen Format, die keine echte Kontonummer ist.

Das Dokument, das das LLM sieht, liest sich als kohärentes Betriebsdokument mit anonymen, aber realistisch wirkenden Stellvertretern. Die Modellausgaben erreichen die Qualität, zu der das Modell tatsächlich in der Lage ist — ohne Qualitätsverlust durch die Wahrnehmung, eine Vorlage verarbeiten zu sollen.

Formaterhalt bringt eigene Entwurfsentscheidungen mit sich: Wie plausibel sollen die Token sein? Werden sie aus einem festen Pool fiktiver Namen gezogen oder dynamisch generiert? Wie werden Datumsangaben und Zahlenwerte behandelt, deren Wert selbst analytische Bedeutung trägt — ein Datum aus 2019 gegenüber 2024 kann für eine Analyse relevant sein, auch wenn das genaue Datum sensibel ist. Die allgemeine Regel: Der Token muss genau die analytische Eigenschaft des Originalwerts erhalten — nicht mehr und nicht weniger.

4. Wo das Mapping gespeichert werden muss

Tokenisierung schützt die Daten nur dann, wenn das Mapping — die Tabelle, die Token mit Originalwerten verknüpft — innerhalb der Unternehmensinfrastruktur verbleibt. Dieser Teil der Architektur entscheidet am zuverlässigsten darüber, ob der Ansatz seinen Schutz tatsächlich liefert.

Drei Eigenschaften des Mappings müssen gewährleistet sein:

1. Es verbleibt unter ausschließlicher Unternehmenskontrolle. Das Mapping ist faktisch der Schlüssel zur Re-Identifikation der Daten. Verlässt es die Unternehmensinfrastruktur, sinkt der Schutz auf das Niveau des neuen Speicherorts. Für Workflows, bei denen Daten innerhalb der EU oder anderer definierter Grenzen verbleiben müssen — eine Anforderung, die sich aus der DSGVO ergibt —, muss das Mapping innerhalb derselben Grenze gespeichert sein: gemeinsam mit den Quellsystemen, nicht beim KI-Endpunkt.
2. Es ist integritätsgeschützt. Eine Manipulation des Mappings verändert, was bei der Rekonstruktion der LLM-Antwort zurückgegeben wird. Ein Angreifer, der das Mapping modifizieren kann, kann Identitäten im Output austauschen. Standardpraxis ist die Anwendung von Integritätsprüfungen auf das Mapping selbst — signierte Einträge, Zugriffs-Audit-Logs — sodass Manipulationen erkennbar sind.
3. Es ist separat vom LLM-Workflow zugangskontrolliert. Das Team, das die LLM-Integration betreibt, benötigt keinen Lesezugriff auf das Mapping. Der Rekonstruktionsschritt greift programmatisch auf das Mapping zu — Menschen müssen die Originalwerte nicht einsehen. Die Trennung der Zugriffspfade ermöglicht es, das Mapping unter strengeren Kontrollen zu verwalten als den LLM-Workflow selbst.

Die Speichertechnologie ist gegenüber diesen Eigenschaften nachrangig. Das Mapping kann in einer dedizierten Datenbank, einem Key-Value-Store, einer verschlüsselten Datei oder einem Hardware-gesicherten Tresor liegen — die Wahl hängt von Volumen, Latenzanforderungen und bestehender Infrastruktur ab. Entscheidend ist: Die drei genannten Eigenschaften sind nicht verhandelbare Entwurfseinschränkungen, keine konfigurierbaren Optionen.

5. Token-Konsistenz — gleiche Entität, gleicher Token

Ein subtileres Entwurfsproblem: sicherzustellen, dass dieselbe Entität konsistent denselben Token erhält — auch wenn sie an verschiedenen Stellen eines Dokuments unterschiedlich bezeichnet wird.

Ein Service-Ticket könnte „den Kunden", dann „Herrn Schmidt", dann „Marlene", dann „den Teilnehmer" erwähnen — alle verweisen auf dieselbe Person. Ein naiver Tokenisierer sieht vier verschiedene Erwähnungen und erzeugt vier verschiedene Token. Das LLM kann dann nicht mehr erkennen, dass alle auf dieselbe Entität verweisen. Die zurückgegebene Zusammenfassung behandelt sie möglicherweise als vier verschiedene Personen.

Dies erfordert Entitätsauflösung vor der Tokenisierung: Identifizierung, welche Erwähnungen in einem Dokument auf dieselbe zugrundeliegende Entität verweisen, und Sicherstellung, dass alle auf denselben Token abgebildet werden. Im Allgemeinen ist dies kein triviales Problem — Entitätsauflösung ist ein eigenes Forschungsgebiet. In der Praxis ist es jedoch handhabbar, da Unternehmensdokumente strukturelle Hinweise bieten: eine Kundennummer im Kopfbereich, die Freitexterwähnungen zusammenführt, formale Namenskonventionen in Betriebsprotokollen, schemadefinierte Beziehungen in strukturierten Datensätzen.

Die zweite Hälfte der Konsistenz betrifft Dokumente innerhalb eines Workflow-Bereichs. Referenzieren zwei Tickets denselben Kunden und muss der Workflow sie als zusammengehörig behandeln, muss die Tokenisierung in beiden denselben Token für den Kunden erzeugen. Hier wirkt die frühere Entscheidung zwischen deterministisch und randomisiert: Determinismus innerhalb des Bereichs ermöglicht es dem LLM zu erkennen, dass „derselbe Kunde in drei Tickets erscheint" — ohne zu erfahren, wer dieser Kunde ist.

Eine sorgfältig konzipierte Tokenisierungsschicht behandelt beide Konsistenzformen — innerhalb eines Dokuments und innerhalb eines Bereichs — als Teil der Transformation, nicht als nachträgliche Ergänzung. Teams, die Konsistenz nachträglich auf einen mentionsbasierten Tokenisierer aufsetzen, stellen in der Regel fest, dass der Workflow auf eine Weise degradiert, die wie ein Modellqualitätsproblem aussieht, aber tatsächlich ein Datenvorbereitungsproblem ist.

6. Ergänzende Schutzschichten — wenn Tokenisierung allein nicht ausreicht

Tokenisierung löst das Substitutionsproblem. Für die meisten Workflows ist eine sorgfältig implementierte Tokenisierung mit Mapping unter ausschließlicher Unternehmenskontrolle ausreichend. Für bestimmte Workflows lohnt es sich, eine zusätzliche Schutzschicht zu ergänzen.

Zusätzlicher Schutz ist angezeigt, wenn das Restrisiko nicht in den Token selbst liegt, sondern in den Mustern, die sie bilden. Ein tokenisiertes Dokument kann ausreichend strukturelle Informationen enthalten — Häufigkeiten, Co-Vorkommen, Sequenzen, Verhältnisse —, damit eine ausgefeilte Korrelationsanalyse Entitäten auch ohne Rohwerte re-identifizieren könnte. Dieses Risiko ist besonders relevant bei hochkardinalen Daten, langen Zeitreihen und Workflows, bei denen sich über die Zeit viele tokenisierte Ausgaben ansammeln.

Die Standardantworten sind Differential Privacy, k-Anonymität und ähnliche statistische Schutzmaßnahmen, die auf tokenisierte Daten angewendet werden. Jede Methode fügt auf kontrollierte Weise Rauschen oder Aggregation hinzu, die begrenzt, wie viel ein Angreifer aus dem tokenisierten Output lernen kann — auf Kosten etwas analytischer Präzision. Ob dieser Kompromiss gerechtfertigt ist, hängt vom Bedrohungsmodell und der Rauschtoleranz des Workflows ab.

Für die meisten Unternehmens-KI-Workflows ist diese Schicht optional. Bei Workflows mit hochsensiblen Daten, hohem Volumen oder einer Defense-in-Depth-Anforderung — etwa im Kontext von BSI C5 oder branchenspezifischen Compliance-Vorgaben — ist die zusätzliche Komplexität gerechtfertigt. Die Entscheidung sollte workflow-spezifisch getroffen werden, nicht als globale Einstellung.

7. Was nicht tokenisiert werden sollte

Eine abschließende Entwurfsfrage, die häufig unbeabsichtigt beantwortet wird: Was sollte nicht tokenisiert werden?

Das Tokenisieren falscher Elemente verschlechtert die KI-Ausgabe, ohne den Schutz zu verbessern. Ein Tokenisierer, der jeden Eigennamen ersetzt, erzeugt unleserliche Dokumente. Ein Tokenisierer, der jedes numerische Feld ersetzt, vernichtet analytische Signale. Die Versuchung besteht darin, aggressiv vorzugehen — „alles tokenisieren, was möglicherweise sensibel sein könnte" —, doch die Konsequenzen zeigen sich unmittelbar in der Ausgabequalität.

Der disziplinierte Ansatz: Sensibilität explizit in den eigenen Unternehmensbegriffen definieren und nur diese Elemente tokenisieren. Allgemeine personenbezogene Datenkategorien im Sinne der DSGVO sind ein Ausgangspunkt, keine vollständige Liste. Interne Projektkennzeichen, Kundensegment-IDs, branchenspezifische Referenzen — was immer die unternehmenseigene Datenstrategie als schützenswert einstuft — gehört auf die Liste. Alles andere bleibt unverändert.

Die Liste muss versioniert sein, weil sich die Definition von Sensibilität verändert. Sie muss auch auditierbar sein — eine Prüfung des Workflows wird wissen wollen, was wann unter welcher Definition tokenisiert wurde. Die Definitionsebene ist der Bereich, in dem der größte Teil der langfristigen Betriebskosten dieser Architektur liegt und in den die meisten Teams zu Beginn zu wenig investieren.

8. Der nächste Schritt im Workflow

Tokenisierung bereitet das Dokument für das externe Modell vor. Das Modell verarbeitet das tokenisierte Dokument und gibt eine tokenisierte Antwort zurück. Diese Antwort ist für sich genommen noch nicht nutzbar — die Token müssen innerhalb der Unternehmensinfrastruktur auf Originalwerte zurückgemappt werden, bevor der Output den Nutzer erreicht.

Dieser Rekonstruktionsschritt ist Gegenstand des nächsten Artikels in dieser Reihe. Eine Übersicht über das übergeordnete Muster, zu dem dieser Artikel gehört, bietet der Pillar-Beitrag zum Betrieb externer LLMs mit sensiblen Unternehmensdaten. Warum Maskierung und Schwärzung keine gleichwertigen Alternativen zur Tokenisierung in operativen Workflows sind, erläutert der Artikel zu KI-Workflows, die an operativen Daten scheitern.