Cómo Evitar Fuga de Datos Sensibles Sin Romper la Experiencia del Usuario

Cuando los equipos piensan por primera vez en la protección de PII en pipelines de IA, suelen recurrir a la solución más obvia: bloquear requests que contengan datos sensibles. Un usuario menciona una dirección de email o un número de la seguridad social, la request se rechaza, y los datos nunca llegan al modelo.

Limpio. Simple. Y terrible para la experiencia del usuario.

El enfoque correcto no es bloquear requests que contengan PII. Es proteger los datos en tránsito preservando la experiencia en ambos extremos.

En 30 segundos

No necesitas elegir entre seguridad y UX. Si redactas antes del modelo y rehidratas después, puedes proteger PII sin romper la respuesta final.

Qué te llevas en este artículo:

• El flujo operativo correcto para PII en runtime
• Qué registrar en logs sin exponerte legalmente
• Cómo reducir falsos positivos sin bajar protección

El problema con el bloqueo naíve

Bloquear requests con PII crea una categoría de cosas con las que tu sistema de IA simplemente no puede ayudar, que suele ser exactamente la categoría donde los usuarios más necesitan ayuda.

Un asistente de IA sanitario que no puede hablar de síntomas de pacientes. Un asistente financiero que no puede referenciar números de cuenta. Un asistente legal que no puede procesar documentos con nombres. No son casos extremos. Son los casos de uso principales.

El problema no es que los datos estén en la request. El problema es que los datos sensibles no deberían salir de tu infraestructura en texto claro, ni almacenarse en logs de terceros.

Son problemas solucionables sin bloquear la request.

Redacción y rehidratación

El patrón que funciona en producción es redactar-ejecutar-rehidratar:

Input usuario
  -> Detectar PII
  -> Redactar con placeholders
  -> Ejecutar modelo (sin PII real)
  -> Rehidratar respuesta
  -> Devolver al usuario

Paso 1, Detectar y redactar antes de la ejecución Antes de que la request llegue a cualquier modelo externo, escanéala en busca de PII. Reemplaza cada entidad detectada con un placeholder estructurado: [NOMBRE_PERSONA_1], [EMAIL_1], [NSS_1]. Almacena el mapeo entre placeholder y valor real en un store seguro y efímero con scope a esa request.

La request que sale de tu infraestructura no contiene PII real. Solo placeholders.

Paso 2, Ejecutar normalmente El modelo recibe la request redactada. Procesa los placeholders como si fueran valores reales. Genera una respuesta referenciando los mismos placeholders.

Paso 3, Rehidratar tras la ejecución La respuesta del modelo vuelve con los placeholders intactos. Antes de devolverla al usuario, reemplaza cada placeholder con el valor original del mapeo.

El usuario ve una respuesta que referencia sus datos reales. El modelo nunca los vio. Los logs de terceros solo contienen placeholders.

Qué detectar

Una capa de detección de PII en producción debería cubrir como mínimo:

• Identificadores directos: Nombres, direcciones de email, teléfonos, direcciones físicas
• Identificadores gubernamentales: DNI/NIE, números de pasaporte, permisos de conducir, NIF
• Datos financieros: Números de tarjeta de crédito, números de cuenta bancaria, IBANs
• Datos de salud: Diagnósticos, nombres de medicamentos en contexto, IDs de pacientes
• Credenciales: Claves API, contraseñas, tokens (son tanto PII como riesgos de seguridad)

La calidad de la detección importa más que la cobertura. Un sistema que detecta el 90% del PII de forma fiable es más útil que uno que pretende 100% de cobertura pero genera falsos positivos que rompen requests legítimas.

Ajuste para falsos positivos

Los falsos positivos son el mayor problema operativo con la detección de PII en producción. Un patrón demasiado agresivo redactará cosas que no son sensibles, nombres de productos, términos técnicos, frases comunes, y producirá respuestas que parecen rotas.

Una buena detección de PII es configurable por tenant y por contexto. Un tenant de servicios financieros necesita detección agresiva de identificadores financieros. Un asistente de propósito general necesita umbrales más conservadores.

El enfoque correcto es empezar de forma conservadora y ajustar basándose en tráfico real. Instrumenta tu capa de detección para revelar candidatos sobre los que tuvo incertidumbre. Revísalos. Ajusta los umbrales. Itera.

Auditoría sin exposición

Un requisito que a menudo se pasa por alto: tu audit trail necesita registrar que se detectó y gestionó PII, sin almacenar el PII en sí.

Esto significa que los registros de auditoría deben registrar:

• Que se detectó PII en la request
• Qué tipos se encontraron (categorías, no valores)
• Que se produjo la redacción
• El resultado de la request

Lo que no deben registrar: los valores sensibles reales, ni siquiera en el sistema de auditoría.

Campos mínimos recomendados de log:

• request_id
• tenant_id
• pii_detected (true/false)
• pii_types (ej. email, phone, id_number)
• redaction_applied (true/false)
• policy_decision (allow / block / review)
• timestamp

Esto es especialmente importante para sanidad (HIPAA) y usuarios europeos (GDPR), donde almacenar PII en sistemas de auditoría crea sus propias obligaciones de compliance.

La diferencia entre "detectado" y "redactado"

Vale la pena ser preciso con la terminología, porque la distinción importa operativamente.

PII detectado significa que el sistema encontró datos sensibles en la request. No dice qué ocurrió con ellos.

PII redactado significa que el sistema encontró datos sensibles y los reemplazó con un placeholder antes de reenviar la request.

Ambos generan eventos de auditoría. Pero solo "redactado" garantiza que los datos no llegaron al modelo. Detección sin redacción es una herramienta de monitorización. Detección con redacción es protección.

El Checklist

Revisa tu pipeline de IA actual contra estos puntos:

• La detección de PII se ejecuta antes de que las requests lleguen a cualquier modelo externo
• El PII detectado se reemplaza con placeholders estructurados, no solo se marca
• Los mapeos placeholder-valor son efímeros y con scope a la request
• Las respuestas del modelo se rehidratan antes de devolverlas al usuario
• Los umbrales de detección son configurables por tenant
• Los registros de auditoría registran eventos de detección sin almacenar los valores sensibles reales
• Tu sistema distingue entre "detectado" y "redactado" en logs y métricas

Qué hacer esta semana

1. Activa redacción de PII en modo observación sobre tráfico real.
2. Revisa falsos positivos por tipo y ajusta umbrales por tenant.
3. Pasa a modo enforcement solo cuando el ratio de falsos positivos esté controlado.

La protección de PII no tiene por qué costar la experiencia del usuario. Con el pipeline correcto, los usuarios obtienen respuestas que referencian sus datos, y esos datos nunca salen de tu control.