Ochrona PII w LLM zgodnie z 152-FZ bez utraty UX

Ochrona danych PII w LLM zgodnie z ustawą 152-FZ: implementacja podmiany tokenów w NestJS

Rozwój asystenta AI do obsługi leadów w firmie budowlanej wykazał krytyczne ryzyko: każde wiadomość użytkownika zawierająca dane osobowe (PII) wysyłana była bezpośrednio do API Google Gemini. Imię, numer telefonu, adres e-mail i firma klienta trafiały na serwery za granicą, naruszając ustawę 152-FZ. To transgraniczna przesyłka danych wymagająca zgłoszenia do Roskomnadzoru oraz zgody podmiotu danych, z karą nawet do 3 milionów złotych.

Rozwiązanie: podmiana PII na tokeny przed wysłaniem do modelu. LLM działa na anonimizowanym tekście, ale generuje spersonalizowane odpowiedzi. Dane rzeczywiste są wstawiane dopiero na ostatnim etapie.

Zasada podmiany tokenów

Proces składa się z czterech etapów:

• Przechwytywanie wiadomości użytkownika przed wysłaniem do API.
• Zamiana PII na tokeny: [USER_NAME], [USER_EMAIL], [USER_COMPANY], [PHONE].
• Wysłanie do LLM, otrzymanie odpowiedzi z tokenami.
• Odzyskanie rzeczywistych danych przed wyświetleniem użytkownikowi.

LLM widzi: «Świetnie, [USER_NAME]! Przygotuję szacunek dla [USER_COMPANY] na [USER_EMAIL]». Użytkownik otrzymuje naturalny tekst z jego danymi. Model nie ma kontaktu z PII.

Implementacja w środowisku produkcyjnym: NestJS i WebSocket

Podstawowy wzorzec jest prosty, ale strumieniowanie odpowiedzi LLM komplikuje zadanie. Tokeny przychodzą fragmentami przez WebSocket, co prowadzi do artefaktów: [USER_NAME] pojawia się na ekranie w sposób niekontrolowany.

Główne problemy i rozwiązania:

• Przecięcie tokenów między fragmentami. [USER_ w jednym, NAME] w drugim — podmiana nie działa. Wprowadzona buforowanie: klasa StreamingPiiRestorer (instancja na strumień) zbiera końcówki fragmentu, sprawdza zamknięcie ], a następnie emituje.
• Bypass pipeline. Moduł generowania ofert odczytywał PII bezpośrednio z PostgreSQL. Wprowadzono jedno miejsce wejścia dla wszystkich wywołań LLM.
• Fałszywe wykrycia regex. W ofertach kwoty i kody produktów były maskowane jako NIP/REGON. Oddzielone wzorce: NIP firmy (10 cyfr), osoby fizycznej (12), REGON (zaczyna się od 1 lub 5), z walidacją sum kontrolnych FNS.

Pięciopoziomowa architektura ochrony

System opiera się na wzajemnie uzupełniających się warstwach:

Warstwa 1: Deterministyczna podmiana znanych PII. Z profilu rozmowy: imię, e-mail, telefon, firma. Dokładność 99%.

Warstwa 2: Skaner regex do PII ad-hoc. Wykrywa e-maile, numery telefonów, NIP, REGON, paszporty, IP, karty płatnicze. Walidacja formatu.

Warstwa 3: Szyfrowanie w PostgreSQL. Pola z PII szyfrowane algorytmem AES-256-GCM. Klucz w zmiennej środowiskowej, kopie zapasowe bazy danych nie są czytelne.

Warstwa 4: Logi HMAC-audit. Rejestrowany jest oczyszczony tekst + HMAC-SHA256 oryginału (z tajnym kluczem). Potwierdza brak wycieków bez ujawniania danych.

Warstwa 5: Automatyczne usuwanie po retention. Cron-job anonimizuje PII w rozmowach starszych niż 90 dni (partie po 500, bez blokad).

Korzyści biznesowe i compliance

Dane pozostają w obrębie firmy. LLM zachowuje kontekst rozmowy bez dostępu do PII. Podczas audytu Roskomnadzoru można przedstawić dowody kryptograficzne.

Ograniczenia: imiona osób trzecich bez kontaktów («zadzwoń do Iwana») nie są maskowane — NER w języku polskim osiąga 65–75% dokładności z ryzykiem fałszywych pozytywów. Nie są to dane actionable z punktu widzenia ustawy 152-FZ.

Ochrona techniczna wspierana jest środkami administracyjnymi: zgoda użytkowników, powiadomienie RKN, DPA z dostawcą.

Co ważne

• Podmiana tokenów zapewnia zerowy wyciek PII do LLM bez utraty jakości UX.
• Buforowanie strumienia rozwiązuje problem przecięcia tokenów w WebSocket.
• Jedno miejsce wejścia zapobiega bypassom.
• Logi HMAC to dowód zgodności.
• Polityka retention automatyzuje usuwanie zgodnie z ustawą 152-FZ.

— Editorial Team