RHETRA / Guías / PII y LLM

Evite fugas de PII a los LLM

La PII se fuga a los LLM en el momento del prompt: un empleado pega una ficha de cliente, un contrato o un log en la ventana de chat, y los datos están en la infraestructura de un tercero antes de que ningún control de red los vea. Las políticas no lo impiden, y el DLP de red casi nunca puede. Lo que funciona es llevar la detección a donde ocurre la fuga: al dispositivo, antes de enviar el prompt, con un escáner que bloquea en caso de duda.

1 · IA en la sombra: el modelo de amenaza real

Los empleados usan IA porque funciona. Las prohibiciones producen rodeos, no cumplimiento: móviles privados, cuentas personales, navegadores sin supervisión. El modelo de amenaza realista no es «insider malicioso», sino empleado diligente, canal equivocado: PII de clientes en un prompt de traducción, código fuente con claves API incrustadas en una consulta de depuración, cifras financieras en un «resúmeme esto».

Lo que lo hace peor que el shadow IT clásico: los datos pegados no quedan en una aplicación no aprobada que luego pueda auditarse — entran en el modelo de un tercero, donde la retención, el registro y el uso para entrenamiento dependen de las condiciones, el plan y la configuración del proveedor en ese momento.

2 · Por qué los controles clásicos no lo ven

• Los documentos de política gobiernan intenciones, no pulsaciones de teclado. Nadie relee la política de uso de IA antes de pegar.
• El DLP de red se enfrenta a tráfico cifrado con TLS; inspeccionarlo significa romper el cifrado a escala, e incluso así los prompts en texto libre derrotan a las reglas rígidas de patrones — demasiados falsos positivos para mantenerlo estricto, demasiados fallos para fiarse.
• Los controles del lado del proveedor (acuerdos enterprise, planes sin retención) importan, pero solo cubren el canal autorizado. La IA en la sombra es, por definición, el no autorizado.
• El tiempo: todo control que actúa después de que el prompt salió del dispositivo es forense, no prevención.

3 · Detección en el dispositivo: la arquitectura que funciona

El único punto donde la prevención sigue siendo posible es el propio dispositivo, entre teclear y enviar. Eso implica una arquitectura concreta:

• Análisis local: el detector se ejecuta en el navegador o el endpoint e inspecciona el prompt antes del envío — tarjetas de crédito, IBAN, documentos de identidad, claves API, nombres, direcciones.
• Zero-egress por diseño: el propio escáner no debe «llamar a casa». Un escáner de PII que sube texto para clasificarlo es una segunda fuga, no un control. La detección se queda en el dispositivo; nada se transmite al fabricante — el Shield de RHETRA está construido exactamente así.
• Enmascarar, no solo avisar: sustituir el valor detectado (⟨IBAN⟩, ⟨TARJETA⟩) mantiene productivo al empleado — el prompt sigue funcionando, los datos se quedan en casa. Las herramientas que solo alertan enseñan al usuario a hacer clic en «continuar».

4 · Fail-safe vs. fail-open: el detalle decisivo

Todo escáner acabará encontrando una entrada que no puede procesar. La pregunta de diseño es qué pasa entonces. Fail-open interpreta el fallo del escáner como «no hay PII» y deja pasar el prompt — cada bug se convierte en una fuga silenciosa. Fail-safe bloquea cuando el escáner no puede emitir un veredicto — cada bug se convierte en una molestia visible. Con datos personales, la elección no es estética: ante el RGPD usted responde por la fuga, no por la molestia. Haga esta única pregunta a cualquier proveedor; la respuesta ordena el mercado.

5 · De un navegador a toda la organización

El escudo en el dispositivo protege el endpoint. La capa organizativa es una pasarela de aplicación de políticas delante de cada llamada de IA autorizada: clasifica cada petición, aplica BLOCK / SANITIZE / ALLOW de forma central, enruta las cargas sensibles a modelos locales y firma cada decisión en un registro de auditoría — que es también como se cumplen las obligaciones de registro del EU AI Act como efecto colateral. La arquitectura completa, incluida la forma de probar dónde se ejecuta realmente su IA, está en la guía pilar: ¿Qué es la IA soberana?

La capa del endpoint puede probarla ahora mismo: el OSI Shield Community Edition es gratuito — instálelo, pegue un número de tarjeta de prueba en cualquier chatbot y compruebe que nunca llega.