Protección de PII en LLM según 152-FZ sin pérdida de UX

Protección de Datos Personales en LLMs para Cumplir con la Ley 152-FZ: Sustitución de Tokens con NestJS

El desarrollo de un asistente de IA para el procesamiento de leads en una empresa constructora reveló un riesgo crítico: cada mensaje del usuario que contenía datos personales (PII) se enviaba directamente a la API de Google Gemini. Nombres, números de teléfono, correos electrónicos y detalles de empresas cliente eran transmitidos a servidores extranjeros, violando la ley rusa 152-FZ. Esta transferencia transfronteriza requiere notificación a Roskomnadzor y consentimiento explícito del titular de los datos, con multas que pueden alcanzar hasta 3 millones de rublos.

Solución: Reemplazar los datos personales por tokens antes de enviarlos al modelo. El LLM procesa texto anonimizado pero genera respuestas personalizadas. Los datos reales solo se restauran en la etapa final de salida.

Principio de Sustitución de Tokens

El proceso consta de cuatro etapas:

• Intercepta los mensajes del usuario antes de que lleguen a la API.
• Reemplaza los PII con marcadores: [USER_NAME], [USER_EMAIL], [USER_COMPANY], [PHONE].
• Envía el texto enmascarado al LLM y recibe una respuesta que contiene tokens.
• Restaura los datos reales antes de mostrar el resultado al usuario.

El modelo ve: "¡Genial, [USER_NAME]! Prepararé un presupuesto para [USER_COMPANY] en [USER_EMAIL]." El usuario recibe un texto natural con sus datos reales. El modelo nunca interactúa con PII sin procesar.

Implementación en Producción: NestJS y WebSocket

El patrón básico es sencillo, pero el streaming de respuestas del LLM complica su ejecución. Los tokens llegan en fragmentos mediante WebSocket, causando artefactos visuales como parpadeos de [USER_NAME] en pantalla.

Desafíos clave y soluciones:

• Fragmentación de tokens entre trozos. Si [USER_ cae en un fragmento y NAME] en otro, la sustitución falla. Se resuelve con bufferización: la clase StreamingPiiRestorer (instancia por flujo) acumula fragmentos finales, verifica si hay cierre con ], y luego emite el token completo.
• Bypass en la cadena de procesamiento. El módulo de generación de estimaciones anteriormente leía PII directamente desde PostgreSQL. Ahora, todas las llamadas al LLM pasan por un único punto de entrada.
• Falsos positivos en expresiones regulares. Montos y códigos SKU en estimaciones se marcaban incorrectamente como INN o OGRN. Se separaron los patrones: INNs de entidades legales (10 dígitos), INNs individuales (12 dígitos), OGRN (empieza con 1 o 5), validados cada uno con reglas de checksum del FNS.

Arquitectura de Seguridad de Cinco Capas

El sistema utiliza capas complementarias para una protección robusta:

Capa 1: Sustitución determinista de PII conocidos. Desde perfiles de diálogo: nombre, correo, teléfono, empresa. Precisión: 99%.

Capa 2: Escáner regex para PII ad hoc. Detecta correos, teléfonos, INNs, OGRNs, pasaportes, IPs, tarjetas de crédito. Se aplica validación de formato.

Capa 3: Cifrado en PostgreSQL. Campos de PII cifrados con AES-256-GCM. La clave se almacena en variables de entorno; las copias de seguridad de la base permanecen ilegibles.

Capa 4: Registro auditado con HMAC. Registra texto limpio + HMAC-SHA256 de los datos originales (con clave secreta). Prueba sin exposición de información sensible.

Capa 5: Eliminación automática por política de retención. Tarea cron anónima PII en diálogos anteriores a 90 días (lotes de 500, sin bloqueos).

Beneficios Empresariales y de Cumplimiento

Los datos permanecen dentro de la infraestructura de la empresa. El LLM conserva el contexto conversacional sin acceso a PII. Durante auditorías de Roskomnadzor, se presentan pruebas criptográficas.

Limitaciones: Nombres de terceros sin información de contacto (por ejemplo, "llama a Iván") no se enmascaran — el NER ruso logra entre 65–75% de precisión con algunos falsos positivos. Estos no constituyen PII accionable bajo la 152-FZ.

Las medidas técnicas se refuerzan con acciones administrativas: consentimiento del usuario, notificación a Roskomnadzor y Acuerdo de Procesamiento de Datos (DPA) con proveedores.

Conclusiones Clave

• La sustitución de tokens garantiza cero fuga de PII a LLMs sin afectar la experiencia de usuario.
• El buffer de streaming resuelve la fragmentación de tokens en flujos WebSocket.
• Un único punto de entrada evita bypasses en la cadena.
• Los registros con HMAC ofrecen prueba verificable de cumplimiento.
• La política de retención automatiza la eliminación según requisitos de la 152-FZ.

— Editorial Team