Un pipeline de saneamiento de privacidad por capas para aplicaciones con LLM
Combine reglas de Presidio, detección de entidades con NLP y clasificación con LLM junto a un motor de políticas para enmascarar datos sensibles en apps con LLM sin destruir su utilidad para los logs.
Las aplicaciones de IA actuales procesan enormes cantidades de datos no estructurados y semiestructurados, y buena parte de ellos son sensibles: datos personales, credenciales, registros financieros, información empresarial confidencial. Antes de que algo de eso se registre, se almacene, se analice, se envíe a otro sitio o se pase a un sistema posterior, hace falta una forma fiable de encontrar las partes sensibles y protegerlas sin arruinar la utilidad de los datos.
Dónde se queda corto el enmascaramiento simple
El enmascaramiento clásico se apoya en expresiones regulares y patrones predefinidos. Funciona bien con valores estructurados como correos, teléfonos y números de tarjeta. Le cuesta cuando la sensibilidad depende del contexto. Tome esta frase:
La respuesta de recuperación del cliente es BlueMountain.
Para un buscador de patrones, la cadena BlueMountain no tiene nada de sensible. Los modelos de NLP reconocen mejor las entidades, pero aun así pueden pasar por alto secretos propios de un dominio. Los LLM entienden el contexto, pero pasar cada entrada por uno añade latencia, coste y un comportamiento impredecible. La respuesta sensata es detectar por capas.
Tres capas y un motor de políticas
El diseño combina tres mecanismos de detección:
- Reglas, para los patrones predecibles.
- NLP, para las entidades y el reconocimiento a nivel de lenguaje.
- Un LLM, que clasifica la información sensible contextual y propia del dominio.
Todo lo que encuentran va a un motor de políticas que elige la acción de protección adecuada. El objetivo no es que todas las capas sean igual de listas, sino usar el mecanismo fiable más sencillo para cada tipo de dato.
Arquitectura
Constrúyalo como una capa reutilizable de saneamiento situada entre las aplicaciones que producen los datos y los sistemas que los consumen.
Reglas con Presidio
Microsoft Presidio es una buena base para encontrar valores sensibles estructurados y conocidos. Trae reconocedores basados en patrones, otros basados en NLP y una forma de escribir los suyos propios. Los objetivos típicos son correos, números de teléfono y de tarjeta, direcciones IP, identificadores oficiales, claves de API y cualquier identificador interno de negocio que defina. La detección por reglas es rápida, determinista y fácil de explicar, así que es la primera capa adecuada.
Detección de entidades con NLP
Hay entidades que no se pueden capturar de forma fiable con una regex: nombres de personas, lugares, organizaciones, fechas y entidades propias del dominio. Por ejemplo: "Rahul Sharma se mudó de Bombay a Bengaluru." Un modelo de NLP identifica los nombres y los lugares aunque no sigan un formato fijo.
Ahora bien, encontrar una entidad no la convierte en sensible. Una capa de políticas sigue teniendo que decidir si necesita protección.
Clasificación con LLM para el contexto
Cierta información solo se delata por lo que la rodea. Con "La respuesta de seguridad del cliente es BlueMountain", un reconocedor tradicional quizá no marque la palabra, mientras que un LLM puede deducir su función por el texto que la rodea. Lo ideal es que el modelo actúe como clasificador y no como reescritor libre. Su salida podría ser así:
{
"text": "BlueMountain",
"category": "SECURITY_ANSWER",
"action": "MASK",
"confidence": 0.96
}
Los hallazgos estructurados son más fáciles de validar, auditar y pasar a una lógica de anonimización determinista.
Anonimización guiada por políticas
La detección solo saca a la luz candidatos. El motor de políticas decide qué pasa con cada uno, y la acción depende de la categoría:
- Los correos se enmascaran y los teléfonos solo en parte
- Las claves de API se eliminan por completo
- Los identificadores de cliente se sustituyen por tokens
- Las respuestas de seguridad se tachan
- El nombre de una empresa pública puede pasar sin cambios
Mantener este mapeo por separado permite cambiar las reglas de privacidad sin reentrenar ni sustituir ningún modelo de detección.
En secuencia o en paralelo
Hay dos formas habituales de ejecutar las capas. En una configuración secuencial, el LLM solo ve texto que las capas anteriores ya han limpiado. Eso limita cuántos datos sensibles le llegan, aunque puede eliminar contexto que el clasificador necesitaba. En una configuración en paralelo, todos los detectores trabajan a la vez sobre la entrada en bruto. El contexto se conserva, pero los datos en bruto pueden llegar al clasificador LLM.
Cuál encaja depende del perímetro de confianza del modelo, del entorno de despliegue, de los requisitos de latencia y de las restricciones de privacidad. Una forma de no exponer datos en bruto es usar modelos on-premise.
Coste, seguridad y utilidad
Enviar cada entrada a un LLM no es asequible ni necesario. Una configuración por niveles es más eficiente:
- Los campos estructurados van a la detección por reglas
- Las entidades conocidas van a Presidio o a NLP
- El texto libre ambiguo va al LLM para su clasificación
- Los datos de alto riesgo quedan sujetos a políticas de enmascaramiento estrictas
El sistema también tiene que evitar enmascarar de más. Eliminarlo todo protege la privacidad, pero deja los logs y las trazas casi sin valor. Un buen diseño equilibra la protección de la privacidad, la precisión de la detección, el rendimiento y la utilidad de los datos.
Un ejemplo completo
Un registro en bruto:
{
"email": "rahul@example.com",
"customer_name": "Rahul Sharma",
"recovery_answer": "BlueMountain",
"transaction_id": "TXN-123456"
}
Y la versión saneada:
{
"email": "<EMAIL>",
"customer_name": "<PERSON>",
"recovery_answer": "<SECURITY_ANSWER>",
"transaction_id": "<TRANSACTION_ID>"
}
Evalúe el sistema por precisión y exhaustividad, tasas de falsos negativos y falsos positivos, latencia del saneamiento, frecuencia con la que las entradas escalan al LLM, coste por registro procesado y cuánto valen todavía los datos después del enmascaramiento.
Por qué por capas
Ninguna técnica por sí sola detecta datos sensibles de forma fiable. Las reglas aportan velocidad y determinismo, el NLP mejora el reconocimiento de entidades, los LLM añaden comprensión del contexto y el motor de políticas convierte las detecciones en la acción de protección correcta. Juntas, protegen lo que importa y mantienen útil el resto de los datos, y ese es el objetivo real, porque enmascararlo todo nunca lo fue.