Die Grenzen der PII-Filterung
Unternehmensteams stoßen regelmäßig auf dasselbe Problem: Die Daten bestehen die PII-Prüfung, der Workflow schlägt dennoch fehl. Namen und Telefonnummern sind entfernt. Die Netzwerkkonfiguration bleibt jedoch erkennbar. Die Incident-Sequenz identifiziert das Kundensegment. Das OT-Alarmmuster verrät die Anlage.
Genau diese Lücke adressiert Differential Privacy. PII-Filterung ist eine Schutzmaßnahme auf Feldebene: Sie erkennt und ersetzt Muster, die wie Namen aussehen. Differential Privacy ist ein verteilungsbasierter Schutz: Sie begrenzt, wie stark ein einzelner Datensatz das Ergebnis beeinflussen kann. Bei operativen, strukturierten und kontextuell re-identifizierbaren Daten sind beide Ansätze erforderlich.
Was Differential Privacy ist
Differential Privacy (DP) ist ein mathematisches Rahmenwerk, das 2006 von Cynthia Dwork und Kollegen eingeführt wurde. Das Grundprinzip: Eine Berechnung gilt als differentiell privat, wenn das Ergebnis nahezu identisch bleibt, unabhängig davon, ob ein bestimmter Datensatz einbezogen wurde oder nicht. Das „nahezu" wird durch den Parameter Epsilon (ε) quantifiziert — ein kleineres Epsilon bedeutet stärkeren Schutz bei geringerer Nutzbarkeit.
In der Praxis wird DP durch das Hinzufügen kalibrierten Rauschens zu Ausgaben, Abfragen oder Transformationen umgesetzt. Das Ausmaß des Rauschens wird durch die Sensitivität der Funktion und das gewählte Privacy-Budget bestimmt. Korrekt angewendet liefert DP eine quantifizierbare Schranke dafür, was ein Angreifer über einen einzelnen Datensatz aus der Ausgabe ableiten kann — selbst bei beliebigem Hintergrundwissen.
Was DP nicht ist
- DP ist keine binäre Garantie. Es ist ein einstellbarer Parameter, der Nutzbarkeit gegen Datenschutzrisiko abwägt.
- DP allein garantiert keine Konformität mit der DSGVO (GDPR), HIPAA oder anderen spezifischen Vorschriften.
- DP eliminiert Risiken nicht. Es begrenzt und charakterisiert Risiken, sodass Entwicklungsteams und Compliance-Verantwortliche fundiert damit arbeiten können.
Warum DP zur KI-Datenschicht gehört
Die KI-Datenschicht ist der Punkt, an dem regulierte operative Daten von „vertraulich" zu „LLM-nutzbar" werden. In einer reinen PII-Pipeline werden identifizierbare Felder erkannt, durch Token ersetzt, an das LLM weitergeleitet und anschließend wiederhergestellt. Dieser Ansatz funktioniert bei Kundenservice-Chats oder Vertragsüberprüfungs-Workflows, bei denen der sensible Inhalt überwiegend aus individuellen Kennungen besteht.
Er versagt, wenn die sensible Information die Netzwerktopologie eines nationalen Carriers ist, die Alarmsequenz vor einem Ausfall, die Konfigurationsabweichung zwischen zwei PLCs oder der Betriebsrhythmus einer Krankenhausstation. In diesen Fällen passieren die Felder die Maskierung, die zugrundeliegenden Muster bleiben jedoch für jeden lesbar, der den Kontext rekonstruiert.
Differential-Privacy-basierte Kapsulierung ergänzt die Feldmaskierung um eine verteilungsbasierte Schutzschicht. Sie wird während des Kapsulierungsschritts angewendet — bevor die Daten das LLM erreichen — und wird gegen das Sensitivitätsprofil der operativen Daten kalibriert.
Anwendung von Differential Privacy in LLM Capsule
LLM Capsule wendet Differential-Privacy-basierten Schutz innerhalb einer umfassenderen Transformation an, die als strukturerhaltende Kapsulierung bezeichnet wird. Der vollständige Prozessablauf:
- Einspeisung — Operative Daten gelangen über den Connector Lane in die Capsule Runtime (NOC-Plug-in, Ticket-Webhook, OT-Log-Tap oder Dateiüberwachung).
- Vertraulichkeitsmarker identifizieren — über generische PII hinaus: Netzwerkkennungen, System-Betriebslogs, OT/Asset-Referenzen sowie Missions- und klinischer Kontext.
- Strukturerhaltende Transformation anwenden — Tabellenlayout, Log-Sequenz, Dokumenthierarchie und Konfigurationsbaum bleiben erhalten, damit das LLM weiterhin darüber schlussfolgern kann.
- Differential-Privacy-basierten Schutz anwenden — kalibriert gegen das Privacy-Budget der Richtlinie für den jeweiligen Workflow. Epsilon-DP aktiv, Laplace-Rauschen, k-Anonymitätsdurchsetzung, semantische Tokenisierung, Freitext-NER-Maskierung.
- Ausführungspfad zuweisen — Pfad A (externes zugelassenes LLM, nur Kapseldaten) oder Pfad B (On-Premise-Leichtgewichtmodell, keine externe Übertragung).
- Wiederherstellung über State Vault — Die LLM-Ausgabe wird mit den originalen operativen Kennungen angereichert und in den Workflow zurückgeführt (RCA, Ticket-Aktualisierung, Runbook, Antwortentwurf).
Die technische Schutzaussage ist klar begrenzt: Differential-Privacy-basierte Kapsulierung reduziert Re-Identifikations-, Inferenz- und Kontextoffenlegungsrisiken für den operativen Datensatz. Es handelt sich nicht um eine Nullrisikoversprechen, sondern um eine definierte technische Schutzschicht mit einem für die Governance sichtbaren Privacy-Budget.
DP vs. PII-Filterung: Gegenüberstellung
| PII-Filterung / Schutzmaßnahmen | Differential-Privacy-basierte Kapsulierung | |
|---|---|---|
| Schutzebene | Feldebene (identifizierbare Felder erkennen und ersetzen) | Feldebene + verteilungsbasiert (Einfluss einzelner Datensätze begrenzen) |
| Abdeckung | Namen, IDs, Finanzfelder, Adressen | + Netzwerklogs, Konfigurationen, OT-Alarme, klinischer und Missionskontext |
| Fehlermuster | Muster passieren die Filterung (Struktur, Sequenz, Aggregation) | Risiko ist begrenzt und über das Privacy-Budget sichtbar |
| Typische Aussage | „PII entfernt" | „Datenschutzwahrend mit definiertem Risikoreduktionsumfang" |
| Prüfbarkeit | Erkennungsprotokolle | Privacy-Budget, Prüfpfad, Governance-Nachweise |
Fragen für Unternehmen vor dem DP-Einsatz auf KI-Ebene
- Wie hoch ist das Privacy-Budget je Workflow? Unterschiedliche Workflows können unterschiedliche Epsilon-Werte tragen. NOC-Analysen können höhere Nutzbarkeit tolerieren. Missionsübersichten erfordern möglicherweise stärkeren Schutz.
- Wo wird das Budget verbraucht? Jede Abfrage gegen denselben Datensatz verbraucht einen Teil des Budgets. Die Ausführungsschicht sollte dies nachverfolgen und der Governance sichtbar machen.
- Welche Anforderungen bestehen an die Strukturerhaltung? Wenn das LLM über die Topologie schlussfolgern muss, darf diese nicht durch naives Rauschen zerstört werden. Strukturerhaltende Kapsulierung löst dieses Problem.
- Wie ist der Schutz prüfbar? Differential Privacy ist nur dann aussagekräftig, wenn Parameter und Budgets dokumentiert, nachvollziehbar und an Richtlinien geknüpft sind.
Externes LLM vs. On-Premise-Ausführung
Differential-Privacy-basierte Kapsulierung unterstützt beide Ausführungspfade in LLM Capsule. Die operative Bedeutung unterscheidet sich jedoch:
Pfad A · Externes zugelassenes LLM — Kapseldaten werden an einen zugelassenen externen LLM-Endpunkt übertragen. Operative Rohdaten verlassen die Unternehmensumgebung nicht. Die DP-Schicht reduziert das Inferenzrisiko auf der Kapsel selbst.
Pfad B · On-Premise-Leichtgewichtmodell — Die Kapselausführung findet vollständig innerhalb der Unternehmensumgebung statt. Keine externe Übertragung. Einsatz bei Air-Gapped-, klassifizierten oder streng regulierten Betriebsumgebungen.
Die Wahl ist eine richtliniengesteuerte Entscheidung, die durch das regulatorische Profil des Workflows, Datensouveränitätsvorgaben und Kundenverpflichtungen bestimmt wird. Die Ausführungsschicht ermöglicht beide Varianten; die Governance legt fest, welche Variante wo gilt.
Zu absoluten Aussagen wie „100 % sicher" oder „DSGVO-garantiert"
Solche Aussagen sollten vermieden werden. Differential Privacy ist ein robustes, gut erforschtes Rahmenwerk — aber kein Allheilmittel. Die Herstelleraussage „mathematisch unmöglich zu rekonstruieren" vereinfacht das Rahmenwerk unzulässig und lädt zu Verifikationsangriffen ein. Die sachlich korrekte Formulierung lautet:
- „Datenschutzwahrend mit definiertem Risikoreduktionsumfang"
- „Begrenztes Inferenzrisiko im Rahmen des Privacy-Budgets der Richtlinie"
- „Keine Offenlegung operativer Rohdaten gegenüber externen LLMs (Pfad A)"
- „Keine externe Datenübertragung beim lokalen Ausführungspfad (Pfad B)"
Diese Formulierungen sind für Sicherheits- und Rechtsabteilungen regulierter Einkäufer nachvollziehbar und prüfbar. Absolute Aussagen hingegen werden hinterfragt.
Einordnung in die KI-Datenschicht
Differential-Privacy-basierte Kapsulierung ist eine Funktion innerhalb der LLM Capsule Runtime. Die Runtime umfasst darüber hinaus strukturerhaltende Transformation, richtlinienbasierte Markerkontrolle, State Vault für die Wiederherstellung sowie einen Prüfpfad. Die Differential-Privacy-Komponente schützt die Kapsel vor Inferenzangriffen auf Musterebene; die strukturerhaltende Komponente stellt die Nutzbarkeit für das LLM sicher; der State Vault ermöglicht die Rückführung der Ergebnisse in den Workflow.
Alle drei Komponenten zusammen — ergänzt durch den Connector Lane, der sie in bestehende NOC-, Ticket-, OT-, EHR- und Einsatzsysteme integriert — begründen die Positionierung von LLM Capsule als KI-Datenschicht und nicht als reines Datenschutz- oder PII-Werkzeug.
- PII-Filterung wirkt auf Feldebene. Differential Privacy wirkt auf Verteilungsebene. Operative Daten erfordern beide Ansätze.
- Differential-Privacy-basierte Kapsulierung ist die technische Grundlage von LLM Capsule und wird während der strukturerhaltenden Transformation angewendet.
- Sie reduziert Re-Identifikations-, Inferenz- und Kontextoffenlegungsrisiken — mit definiertem, prüfbarem Umfang. Es handelt sich nicht um eine absolute Garantie.
- Das Privacy-Budget ist workflowspezifisch und wird pro Abfrage verbraucht. Die Governance muss es nachverfolgen.
- Externes LLM (Pfad A) und On-Premise-Modell (Pfad B) werden beide unterstützt. Die Richtlinie bestimmt, welcher Workflow welchen Pfad nutzt.
- Aussagen wie „100 % sicher", „DSGVO-garantiert", „Nullrisiko" oder „mathematisch unmöglich" sind zu vermeiden. Sachgerechte, technisch begrenzte Formulierungen sind zu bevorzugen.