Ochrana osobních údajů v LLM podle zákona 152-FZ: implementace náhrady tokenů v NestJS
Vývoj AI-assistenta pro zpracování zájemců v stavební firmě odhalil kritické riziko: každá uživatelská zpráva obsahující osobní údaje (PII) je přímo odesílána do Google Gemini API. Jméno, telefon, e-mail a firma klienta se posílají na zahraniční servery, což porušuje zákon 152-FZ. Jedná se o mezinárodní přenos dat vyžadující upozornění Rospotrebnadzoru a souhlas subjektu, s pokuty až do 3 milionů rublů.
Řešení: Náhrada PII tokeny před odesláním do modelu. LLM pracuje s anonymizovaným textem, ale generuje personalizované odpovědi. Skutečné údaje se vkládají až na konci procesu.
Princip náhrady tokenů
Proces se skládá ze čtyř kroků:
- Zachycení uživatelské zprávy před voláním API.
- Nahrazení PII tokeny:
[USER_NAME],[USER_EMAIL],[USER_COMPANY],[PHONE]. - Odeslání do LLM a získání odpovědi s tokeny.
- Obnovení skutečných údajů před zobrazením uživateli.
LLM vidí: «Skvělé, [USER_NAME]! Připravím výpočet pro [USER_COMPANY] na [USER_EMAIL]». Uživatel vidí přirozený text s jeho údaji. Model nemá žádný kontakt s PII.
Implementace v produkci: NestJS a WebSocket
Základní vzor je jednoduchý, ale streamování odpovědi LLM tento problém komplikuje. Tokeny přicházejí po částech prostřednictvím WebSocket, což může vést ke špatnému zobrazení: [USER_NAME] se objeví na obrazovce.
Klíčové problémy a jejich řešení:
- Rozdělení tokenů mezi částmi.
[USER_v jedné části,NAME]v druhé – náhrada selže. Byla zavedena bufferizace: třídaStreamingPiiRestorer(instancí na stream) shromažďuje zbytek části, ověřuje uzavření], pak emituje. - Bypass pipeline. Modul pro generování cenovek četl PII přímo z PostgreSQL. Byla implementována jediná vstupní bod pro všechna volání LLM.
- Neúspěšné regex. V cenovkách byly částky a kódy maskovány jako IČO/ROK. Rozděleny vzory: IČO právnické osoby (10 číslic), fyzické osoby (12), ROK (začíná 1 nebo 5), s ověřením kontrolních součtů FNS.
Pětiúrovňová architektura ochrany
Systém je postaven na navzájem doplňujících vrstvách:
Úroveň 1: Deterministická náhrada známých PII. Z profilu rozhovoru: jméno, e-mail, telefon, firma. Přesnost 99 %.
Úroveň 2: Regex-skener pro ad-hoc PII. Detekuje e-maily, telefony, IČO, ROK, pasy, IP adresy, karty. Ověření formátu.
Úroveň 3: Šifrování v PostgreSQL. Pole s PII jsou šifrována pomocí AES-256-GCM. Klíč je v proměnné prostředí, zálohy databáze jsou nečitelné.
Úroveň 4: HMAC-audit log. Zaznamenává se čistý text + HMAC-SHA256 originálu (s tajným klíčem). Dokazuje absence úniku bez zveřejnění dat.
Úroveň 5: Automatické odstranění podle retention. Cron-job anonymizuje PII v rozhovorech starších než 90 dní (batches po 500, bez zamčení).
Podnikatelské a compliance výhody
Data zůstávají v firemním kontextu. LLM zachovává kontext rozhovoru bez přístupu k PII. Při auditech Rospotrebnadzoru lze předložit kryptografické důkazy.
Omezení: jména třetích osob bez kontaktů («zavolejte Ivanovi») nejsou maskována – NER v ruštině dosahuje 65–75 % přesnosti s rizikem falešných pozitivních výsledků. Toto není actionable PII podle 152-FZ.
Technická ochrana je doplněna administrativními opatřeními: souhlas uživatelů, upozornění RKP, DPA s poskytovatelem.
Co je důležité
- Náhrada tokenů zaručuje nulový únik PII do LLM bez poškození uživatelského zážitku.
- Bufferizace streamování řeší rozdělení tokenů v WebSocket.
- Jednotný vstupní bod zabrání bypassům.
- HMAC-logy jsou důkazem souladu.
- Politika retention automaticky řeší odstranění podle 152-FZ.
— Editorial Team
Zatím žádné komentáře.