PII-Schutz in LLM gemäß 152-FZ ohne UX-Verlust

PII-Schutz in LLMs für die Einhaltung der 152-FZ: Token-Ersatz mit NestJS

Bei der Entwicklung eines KI-Assistenten für die Lead-Verarbeitung bei einem Baustellenunternehmen wurde ein kritischer Risikofaktor deutlich: Jede Benutzer-Nachricht, die personenbezogene Daten (PII) enthielt, wurde direkt an die Google Gemini API gesendet. Namen, Telefonnummern, E-Mail-Adressen und Angaben zu Kundenunternehmen wurden über Grenzen hinweg auf fremde Server übertragen – eine Verletzung des russischen Gesetzes 152-FZ. Diese grenzüberschreitende Datenübertragung erfordert eine Anzeige bei Roskomnadzor und die ausdrückliche Zustimmung des Betroffenen, wobei Bußgelder bis zu 3 Millionen Rubel möglich sind.

Lösung: Ersetze PII durch Tokens, bevor die Daten an das Modell gesendet werden. Das LLM verarbeitet anonymisierten Text, generiert aber personalisierte Antworten. Die echten Daten werden erst im Endstadium der Ausgabe wiederhergestellt.

Prinzip des Token-Ersatzes

Der Prozess umfasst vier Schritte:

• Erfassen von Benutzernachrichten, bevor sie die API erreichen.
• Ersetzen von PII durch Platzhalter: [USER_NAME], [USER_EMAIL], [USER_COMPANY], [PHONE].
• Versenden des maskierten Textes an das LLM und Empfang einer Antwort mit Tokens.
• Wiederherstellung der echten Daten, bevor das Ergebnis dem Nutzer angezeigt wird.

Das LLM sieht: "Toll, [USER_NAME]! Ich erstelle ein Angebot für [USER_COMPANY] unter [USER_EMAIL]." Der Nutzer erhält natürliche, persönliche Texte mit seinen tatsächlichen Informationen. Das Modell interagiert nie mit unverarbeiteten PII-Daten.

Umsetzung in der Produktion: NestJS und WebSocket

Das grundlegende Muster ist einfach, doch die Streaming-Ausgabe von LLMs erschwert die Umsetzung. Tokens kommen als Teile über WebSocket an, was visuelle Störungen wie Flackern von [USER_NAME] auf dem Bildschirm verursacht.

Wichtige Herausforderungen und Lösungen:

• Token-Splitting über Chunk-Grenzen hinweg. Wenn [USER_ in einem Chunk landet und NAME] in einem anderen, scheitert die Ersetzung. Gelöst durch Pufferung: Die Klasse StreamingPiiRestorer (pro Stream Instanz) sammelt Restfragmente, prüft auf abschließendes ] und emittiert dann den vollständigen Token.
• Pipeline-Bypass. Der Modul zur Schätzungserstellung las PII bisher direkt aus PostgreSQL. Jetzt gehen alle LLM-Aufrufe durch einen einzigen Eingangspunkt.
• Regex-Falschpositiven. Beträge und SKUs in Schätzungen wurden fälschlicherweise als INN oder OGRN erkannt. Getrennte Muster: Rechtliche Personen (10-stellige INN), Privatpersonen (12-stellige INN), OGRN (beginnt mit 1 oder 5), jeweils validiert mit FNS-Prüfsummenregeln.

Fünfschichtige Sicherheitsarchitektur

Das System nutzt komplementäre Schichten für robusten Schutz:

Schicht 1: Deterministische Ersetzung bekannter PII. Aus Dialogprofilen: Name, E-Mail, Telefon, Unternehmen. Genauigkeit: 99 %.

Schicht 2: Regex-Scanner für ad-hoc-Personendaten. Erkennt E-Mails, Telefonnummern, INNs, OGRNs, Passdaten, IPs, Kreditkarten. Formatvalidierung angewandt.

Schicht 3: Verschlüsselung in PostgreSQL. PII-Felder mit AES-256-GCM verschlüsselt. Schlüssel in Umgebungsvariablen gespeichert; Datenbank-Snapshots bleiben unlesbar.

Schicht 4: HMAC-Audit-Log. Protokolliert gereinigten Text + HMAC-SHA256 der Originaldaten (mit geheimem Schlüssel). Beweist keine Datenlecks ohne sensible Informationen preiszugeben.

Schicht 5: Automatische Löschung nach Retentionspolitik. Cron-Job anonymisiert PII in Dialogen älter als 90 Tage (in Batches von 500, ohne Sperrung).

Vorteile für Business und Compliance

Daten bleiben innerhalb der Unternehmensinfrastruktur. Das LLM behält den Gesprächs-Kontext, hat aber keinen Zugriff auf PII. Bei Audits durch Roskomnadzor werden kryptografische Nachweise vorgelegt.

Einschränkungen: Dritte ohne Kontaktdaten (z. B. "Rufen Sie Ivan an") werden nicht maskiert – Russisches NER erreicht 65–75 % Genauigkeit mit einigen Falschpositiven. Diese gelten nicht als handhabbare PII gemäß 152-FZ.

Technische Maßnahmen werden durch administrative Schritte verstärkt: Nutzereinwilligung, Anzeige bei Roskomnadzor und Datenschutzvereinbarung (DPA) mit Anbietern.

Wichtige Erkenntnisse

• Token-Ersatz gewährleistet null PII-Weitergabe an LLMs ohne UX-Einbußen.
• Streaming-Pufferung löst Token-Fragmentierung in WebSocket-Streams.
• Einzelner Eingangspunkt verhindert Pipeline-Bypass.
• HMAC-Logs liefern verifizierbare Compliance-Beweise.
• Retentionspolitik automatisiert die Löschung gemäß 152-FZ-Anforderungen.

— Editorial Team