PII Protection in LLMs for 152-FZ Compliance: Token Substitution with NestJS
Developing an AI assistant for lead processing at a construction company revealed a critical risk: every user message containing personal data (PII) was being sent directly to Google Gemini API. Names, phone numbers, emails, and client company details were routed to foreign servers—violating Russia’s 152-FZ law. This cross-border data transfer requires notification to Roskomnadzor and explicit consent from the data subject, with fines reaching up to 3 million rubles.
Solution: Replace PII with tokens before sending data to the model. The LLM processes anonymized text but generates personalized responses. Real data is only restored at the final output stage.
Token Substitution Principle
The process involves four stages:
- Intercept user messages before they reach the API.
- Replace PII with placeholders:
[USER_NAME],[USER_EMAIL],[USER_COMPANY],[PHONE]. - Send the masked text to the LLM and receive a response containing tokens.
- Restore real data before displaying the result to the user.
The LLM sees: "Great, [USER_NAME]! I'll prepare a quote for [USER_COMPANY] at [USER_EMAIL]." The user receives natural-sounding text with their actual information. The model never interacts with raw PII.
Production Implementation: NestJS and WebSocket
The basic pattern is simple, but streaming LLM responses complicates execution. Tokens arrive in chunks via WebSocket, causing visual artifacts like flickering [USER_NAME] on screen.
Key challenges and solutions:
- Token splitting across chunks. If
[USER_lands in one chunk andNAME]in another, substitution fails. Fixed with buffering: theStreamingPiiRestorerclass (per-stream instance) accumulates trailing fragments, checks for closing], then emits the full token. - Pipeline bypass. The estimate generation module previously read PII directly from PostgreSQL. Now, all LLM calls go through a single entry point.
- Regex false positives. Amounts and SKUs in estimates were incorrectly flagged as INN or OGRN. Separated patterns: legal entity INNs (10 digits), individual INNs (12 digits), OGRN (starts with 1 or 5), each validated using FNS checksum rules.
Five-Layer Security Architecture
The system uses complementary layers for robust protection:
Layer 1: Deterministic substitution of known PII. From dialog profiles: name, email, phone, company. Accuracy: 99%.
Layer 2: Regex scanner for ad-hoc PII. Detects emails, phone numbers, INNs, OGRNs, passports, IPs, credit cards. Format validation applied.
Layer 3: Encryption in PostgreSQL. PII fields encrypted with AES-256-GCM. Key stored in environment variables; database snapshots remain unreadable.
Layer 4: HMAC-audit log. Logs cleaned text + HMAC-SHA256 of original data (using secret key). Proves no leaks without exposing sensitive info.
Layer 5: Auto-removal by retention policy. Cron job anonymizes PII in dialogs older than 90 days (batches of 500, no locks).
Business & Compliance Benefits
Data stays within the company’s infrastructure. The LLM retains conversational context without access to PII. During Roskomnadzor audits, cryptographic proofs are provided.
Limitations: Third-party names without contact info (e.g., "call Ivan") aren’t masked—Russian NER achieves 65–75% accuracy with some false positives. These aren’t actionable PII under 152-FZ.
Technical safeguards are reinforced with administrative measures: user consent, Roskomnadzor notification, and Data Processing Agreement (DPA) with providers.
Key Takeaways
- Token substitution ensures zero PII leakage to LLMs without harming UX.
- Streaming buffering resolves token fragmentation in WebSocket streams.
- Single entry point prevents pipeline bypasses.
- HMAC logs provide verifiable compliance proof.
- Retention policy automates deletion per 152-FZ requirements.
— Editorial Team
No comments yet.