Warum KI-Workflows an Tabellen, Tickets und operativen Dokumenten scheitern

1. Warum Maskierung und Schwärzung der erste Versuch sind

In KI-Pilotprojekten von Unternehmen wiederholt sich ein bekanntes Muster: Der Proof of Concept funktioniert auf bereinigten Texten, die Demo überzeugt die Führungsebene — doch sobald derselbe Workflow auf ein echtes Service-Ticket oder ein operatives Dokument angewendet wird, kommt ein unbrauchbares Ergebnis zurück. Das Modell ist in Ordnung. Die Integration ist in Ordnung. Was versagt, ist etwas Spezifischeres — und es lässt sich fast immer auf die Datenvorbereitung zurückführen.

Der Standardansatz zur Vorbereitung ist eine Form der PII-Behandlung: eine Maskierungsbibliothek, eine Guardrail-API oder eine Schwärzungsverarbeitung. Das Team installiert eine dieser Lösungen, konfiguriert sie für Namen und IDs und geht davon aus, dass das Datenschutzproblem gelöst ist. Bei einer kleinen Klasse von Dokumenten — Fließtext, bei dem der sensible Teil ein Name in einem Satz ist — funktioniert das. Bei den Dokumenten, mit denen operative Teams tatsächlich arbeiten, schlägt dieser Ansatz auf eine Weise fehl, die schwer zu diagnostizieren ist.

Die Intuition ist nachvollziehbar. Das Problem sieht so aus: „Sensible Daten befinden sich im Dokument; die KI soll sie nicht sehen; also werden die sensiblen Teile entfernt." Die verfügbaren Werkzeuge — Open-Source-PII-Erkennungsbibliotheken, kommerzielle Guardrail-APIs, in Dokumentenmanagementsysteme integrierte Schwärzungsmodule — gehen alle von diesem Rahmen aus. Sie nehmen ein Dokument, identifizieren benannte Entitäten und ersetzen diese durch Platzhalter oder entfernen sie.

Diese Annahme gilt ausreichend gut, wenn das Dokument unstrukturierter Fließtext ist und der sensible Inhalt in wenigen namentlichen Erwähnungen konzentriert ist. Ein Lebenslauf. Eine Vertragszusammenfassung. Ein Pressemitteilungsentwurf. In diesen Dokumenten macht der Name des Kunden oder der Partei einen kleinen Anteil des Textes aus — und seine Entfernung beeinträchtigt die Bedeutung nicht.

Diese Annahme hält nicht mehr, sobald das Dokument operativer Natur ist. Und operative Dokumente sind genau das, was Unternehmens-KI tatsächlich verarbeiten soll.

2. Szenario 1 — Das Service-Ticket

Betrachten Sie ein einzelnes Kunden-Service-Ticket aus einem Telekommunikationsbetriebszentrum. Das Ticket hat eine Struktur: eine Kopfzeile mit Kundenkontonummer, Geräteseriennummer, betroffenem Dienst sowie Datum und Uhrzeit. Eine Freitextbeschreibung des Agenten: „Kunde meldet intermittierende Verbindungsabbrüche auf Mobile-X-Leitung, nach zweitem Anruf von Stufe 1 eskaliert. Gerät zeigt Rücksetz-Ereignis um 14:22 UTC. Teilnehmer bestätigt keinen physischen Schaden, erwähnt aber niedrige Geschwindigkeiten seit dem Firmware-Update letzten Dienstag." Ein verknüpfter Anhang mit einem Netzwerkprotokoll-Fragment. Verweise auf zwei weitere Ticket-IDs desselben Kunden aus dem vergangenen Monat. Eine Asset-Referenz auf den Mobilfunkmast, der die betroffene Leitung versorgt.

Ein PII-Guardrail analysiert dieses Ticket und findet: einen Kundennamen (sofern er in der Beschreibung steht), möglicherweise eine Telefonnummer und eine E-Mail-Adresse, falls der Agent den Kunden zitiert hat. Alles andere ist aus Sicht des Guardrails nicht sensibel.

Für einen EU-Telekommunikationsanbieter unter branchenspezifischen Datenlokalisierungsanforderungen ist jedoch nahezu alles andere in irgendeiner Form sensibel. Die Mobilfunkmast-Kennung offenbart geografische Standortdaten. Die Asset-Referenz kann zusammen mit dem Firmware-Update-Datum die Hardware-Konfiguration des Kunden identifizieren. Die Querverweise auf Ticket-IDs legen ein Verhaltensmuster offen. Die Seriennummer ist ein eindeutiger Identifikator. Nur die offensichtliche PII zu entfernen hinterlässt ein Dokument, in dem das meiste von dem, was es sensibel machte — und das meiste von dem, was es für die KI nützlich machte — unberührt bleibt. Der Name des Kunden ist weg; der Kunde selbst ist für jeden mit Zugang zum CRM des Betreibers weiterhin identifizierbar.

Dazu kommt ein zweites Problem: Das Entfernen der vom Guardrail markierten Daten beschädigt auch die Funktionsfähigkeit der KI. Die Freitextbeschreibung des Agenten referenziert durchgehend „den Kunden". Wird der Kundenname in der Kopfzeile durch [REDACTED] ersetzt, entstehen im Freitext hängende Verweise. Die zurückgegebene KI-Zusammenfassung wird Formulierungen enthalten wie „der Nutzer erwähnte niedrige Geschwindigkeiten, aber [REDACTED] berichtete auch" — für den nächsten Agenten, der dieses Ticket liest, ist das wertlos.

Das Ticket ist ein Geflecht aus Identifikatoren, Verweisen und Kontextfragmenten, die voneinander abhängen. Die sensiblen Teile lassen sich nicht herausnehmen, ohne die Abhängigkeiten zu zerstören — und genau diese Abhängigkeiten sind es, die die KI-Verarbeitung überhaupt erst sinnvoll machen.

3. Szenario 2 — Das Betriebsprotokoll

Ein weiteres Beispiel: ein Zeitfenster aus den Betriebsprotokollen eines Network Operations Centers — zwanzig Minuten Alarmereignisse vor einem Dienstausfall. Das Format ist strukturiert: Zeitstempel, Schweregrad, Geräte-ID, Ereigniscode, Freitextbeschreibung, Korrelations-ID.

Ein PII-Guardrail findet hier praktisch nichts. Es gibt keine Kundennamen, keine E-Mail-Adressen oder Telefonnummern. Die Felder sind technische Identifikatoren und Ereigniscodes. Der Guardrail gibt das Protokoll unverändert zurück, und das Team fühlt sich sicher, es zur Root-Cause-Analyse an ein externes LLM zu senden.

Für Netzwerkbetreiber in den meisten EU-Ländern umfassen branchenspezifische Verpflichtungen jedoch die Netzwerktopologie selbst. Geräte-IDs legen die Infrastrukturarchitektur offen. Die Alarmsequenz zusammen mit der Korrelations-ID kann Traffic-Routing-Entscheidungen preisgeben. Ereigniscodes sind teils herstellerspezifisch und verraten, welche Geräte welche Segmente betreiben. Für einen Netzbetreiber mit Kundenverpflichtungen zur Datenlokalisierung stellt die Übertragung des Rohprotokolls an einen Endpunkt außerhalb der EU einen Verstoß dar — auch wenn der Guardrail keine PII erkannt hat.

Die strukturellen Informationen — was mit was verbunden ist, was in welcher Reihenfolge ausgefallen ist, welches Teilsystem den Fehler weitergegeben hat — sind genau das, was die KI für eine sinnvolle Root-Cause-Analyse benötigt. Sie sind zugleich das, was das Protokoll sensibel macht. Entfernt man die Struktur, hat die KI keine Grundlage mehr. Lässt man sie stehen, sind die Daten faktisch nicht geschützt.

Das ist die Erkenntnis, die die meisten Teams auf die harte Tour machen: Bei operativen Daten ist die Struktur die Sensibilität. Feldbasierte Entfernung erkennt sie nicht, kann sie nicht modellieren und nicht erhalten.

4. Szenario 3 — Das klinische oder finanzielle Dokument

Ein drittes Szenario, weniger offensichtlich, aber häufiger anzutreffen: ein klinisches Workflow-Dokument oder ein finanzielles Prüfdokument. Eine Patientenakte mit Querverweisen auf frühere Besuche, Laborbefunde, Rezepte und einen Freitext-Kliniker-Vermerk. Eine Kreditakte mit Antragstellerdaten, Vermögensdetails, Transaktionshistorie und der Einschätzung des Underwriters.

Diese Dokumente enthalten etwas, das den ersten beiden fehlt: explizite persönliche Identifikatoren, die ein PII-Guardrail erkennt — Patientenname, Geburtsdatum, Kontonummer, Sozialversicherungsnummer. Das Team konfiguriert den Guardrail, führt ihn aus, und die offensichtlichen Identifikatoren werden maskiert. Das Dokument sieht bereinigt aus.

Die Querverweise bleiben jedoch bestehen. Der Kliniker-Vermerk nennt den Patienten „den Patienten" — soweit in Ordnung — verweist aber auch auf „das Ergebnis vom vorherigen Aufenthalt" und „die Medikamentenanpassung beim dritten Besuch". Die Laborbefundtabelle enthält strukturierte Zeilen mit Datumsangaben, Codes und Werten. Das Finanzdokument enthält eine Transaktionshistorie mit Händlernamen, Beträgen und Zeitstempeln.

Zwei Probleme entstehen.

1. Querverweise können nicht mehr aufgelöst werden. Die KI sieht „das Ergebnis vom vorherigen Aufenthalt", aber der vorherige Aufenthalt wurde durch ein Token maskiert, das keine inhaltliche Information trägt. Die KI-Zusammenfassung bleibt entsprechend vage.
2. Das Dokument bleibt auch nach der Maskierung identifizierbar. Die Laborbefund-Verlaufskurve eines Patienten kann zusammen mit ungefähren Zeitangaben eine Identifizierung auch ohne Namen ermöglichen. Das Transaktionsmuster eines Kreditantragstellers kann zusammen mit grober geografischer Einordnung und einer Asset-Referenz zur Identifizierung führen. Diese Re-Identifizierungspfade sind keine theoretischen Konstrukte — sie werden von Datenschutzforschern regelmäßig demonstriert. Ein Guardrail, der direkte Identifikatoren abfängt, aber die Struktur unangetastet lässt, erreicht nicht das Datenschutzniveau, das das Team erwartet.

Das Ergebnis ist das schlechteste aus beiden Welten: Die KI-Ausgabe ist degradiert, weil Querverweise unterbrochen wurden — und der Datenschutz wurde nicht verbessert, weil die strukturellen Informationen, die eine Re-Identifizierung ermöglichen, weiterhin vorhanden sind.

5. Warum ein besserer Guardrail das nicht löst

Die naheliegende Reaktion auf diese Szenarien ist die Forderung nach einer leistungsfähigeren PII-Erkennungsmaschine. Breitere Entitätsabdeckung. Benutzerdefinierte Regeldefinitionen. Kontextbewusste Erkennung. Der Markt hat geliefert — heute gibt es PII-Guardrails mit Hunderten von Entitätstypen, konfigurierbaren benutzerdefinierten Markierungen und ML-basierter Erkennung, die über reguläre Ausdrücke hinausgeht.

Das sind Verbesserungen, aber sie ändern die grundlegende Architektur nicht. Die Architektur lautet nach wie vor: sensible Elemente erkennen, entfernen oder ersetzen, Ergebnis übermitteln. Die Erkennungsschicht verbessert sich; die Entfernungsschicht bleibt Entfernung. Und Entfernung zerstört dieselben Dinge wie eh und je: Querverweise, strukturelle Beziehungen, Dokumentenkohärenz.

Eine präzisere Formulierung des Problems lautet: Der KI-Workflow benötigt die Dokumentstruktur — Beziehungen, Verweise, Format, Sequenz — um sinnvolle Arbeit zu leisten. Die datenschutzrechtliche Anforderung besagt, dass bestimmte Elemente des Dokuments nicht an das externe Modell übermittelt werden dürfen. Diese beiden Tatsachen stehen nur dann im Konflikt, wenn die einzig verfügbare Maßnahme das Entfernen ist. Gibt es einen Weg, die Struktur zu übermitteln, ohne den identifizierenden Inhalt zu senden, löst sich der Konflikt auf.

Das ist der architektonische Wechsel, der entfernungsbasierte Ansätze (PII-Guardrails, Maskierung, Schwärzung) von transformationsbasierten Ansätzen unterscheidet. Entfernungsbasierte Werkzeuge optimieren dafür, was herausgenommen wird. Transformationsbasierte Werkzeuge optimieren dafür, was nutzbar bleibt — das ist eine andere Entwurfsbedingung und erzeugt andere Architekturen.

6. Fälle, in denen Maskierung tatsächlich ausreicht

Es ist sinnvoll, präzise zu benennen, wann der traditionelle Ansatz geeignet ist. Drei Bedingungen müssen gleichzeitig erfüllt sein:

• Das Dokument ist Fließtext und kein strukturiertes operatives Artefakt. Die sensiblen Elemente machen einen kleinen Teil des Inhalts aus, und das Dokument bleibt auch ohne sie kohärent lesbar.
• Die KI-Aufgabe erfordert weder das Auflösen von Querverweisen noch das Erhalten von Struktur oder das Verstehen von Sequenzen. Die Zusammenfassung eines narrativen Einzelquelldokuments ist unproblematisch. Das Extrahieren wesentlicher Klauseln aus einem Vertrag kann ausreichen, wenn die Vertragsparteien die einzigen sensiblen Elemente sind.
• Die datenschutzrechtliche Anforderung betrifft benannte Entitäten, nicht strukturelle Informationen. Wenn die Anforderung lautet: „Der Kundenname darf dem externen Modell nicht sichtbar sein", löst Maskierung das. Wenn sie lautet: „Dieses Dokument identifiziert einen Kunden auch ohne den Namen", löst Maskierung das nicht.

Für diese Fälle — sie existieren — ist ein gut konfigurierter PII-Guardrail ein geeignetes Werkzeug. Der Fehler liegt darin anzunehmen, dass die übrigen Dokumente im Unternehmen dieselbe Struktur haben.

7. Konsequenzen für die Workflow-Architektur

Die Schlussfolgerung, zu der die meisten Teams nach mehrfachem Auftreten dieser Probleme gelangen, ist diese: Die Datenvorbereitung muss etwas anderes leisten als Entfernung. Sie muss Struktur und Querverweise des Dokuments erhalten und gleichzeitig die Elemente ersetzen, die die Vertrauensgrenze nicht überschreiten dürfen. Gleiche Form, anderer Inhalt.

Diese Erhaltungseigenschaft — die Struktur beizubehalten und sensible Elemente durch Platzhalter zu ersetzen, die im Kontext dieselbe Rolle übernehmen — ist das, was transformationsbasierte Ansätze von Maskierung und Schwärzung unterscheidet. Die KI erhält weiterhin ein Dokument, das wie ein Service-Ticket aussieht: mit Kopfzeile, Freitextbeschreibung und Querverweisen. Das externe Modell kann weiterhin über die Beziehungen schlussfolgern. Die zurückgegebenen Ergebnisse referenzieren dieselben strukturellen Rollen. Innerhalb der Unternehmensumgebung werden die Platzhalter auf die Originalwerte zurückgemappt — das Ergebnis ist ein unmittelbar einsatzbereites Dokument mit echten Namen, echten IDs und echten Referenzen.

Das ist keine andere Konfiguration von Maskierung. Es ist eine andere Kategorie der Datenvorbereitung — konzipiert für die Anforderung, dass Unternehmensdokumente strukturierte Artefakte sind, deren Wert für die KI ebenso in ihrer Struktur wie in ihrem Inhalt liegt. Diese Anforderung ist im deutschen Unternehmensumfeld besonders relevant: DSGVO (GDPR) und BSI C5 decken operative Strukturinformationen ab, nicht nur namentliche Personendaten.