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 documento de identidad, 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.
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, y 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. Ambos son problemas solucionables sin bloquear la request.
Redacción y rehidratación
El patrón que funciona en producción es redactar-ejecutar-rehidratar. El flujo es: el input del usuario llega a tu pipeline, la capa de detección encuentra PII y lo reemplaza con placeholders estructurados, el modelo recibe la request con los placeholders (nunca ve el dato real), la respuesta vuelve con los mismos placeholders intactos, y antes de devolverla al usuario los placeholders se sustituyen de nuevo por los valores originales.
Input usuario
→ Detectar PII
→ Redactar con placeholders
→ Ejecutar modelo (sin PII real)
→ Rehidratar respuesta
→ Devolver al usuario
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.
Ejecutar normalmente. El modelo recibe la request redactada. Procesa los placeholders como si fueran valores reales. Genera una respuesta referenciando los mismos placeholders.
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 como nombres, emails, teléfonos y direcciones; identificadores gubernamentales como DNI, NIE, pasaporte o número de la seguridad social; datos financieros como números de tarjeta, cuentas bancarias e IBANs; datos de salud como diagnósticos, nombres de medicamentos en contexto e IDs de pacientes; y credenciales como claves API, contraseñas y tokens, que 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 o incompletas.
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, y el resultado de la request. Lo que no deben registrar son 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 → [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 que ningún equipo quiere gestionar.
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. Si tu pipeline hace lo primero pero no lo segundo, tienes visibilidad sobre el problema pero no lo estás resolviendo.
Lo que significa en la práctica
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. El modelo trabaja con placeholders que tienen la misma estructura semántica que los datos reales. La respuesta es igual de útil. El riesgo legal y de seguridad desaparece.
El objetivo no es hacer que tu sistema de IA ignore los datos sensibles. Es hacer que los maneje de forma que nunca salgan de donde deben estar.