Cómo la Limpieza de Datos Personales Afecta a los Agentes LLM: Experimento Hivetrace Dataclean

La limpieza de datos personales antes de enviar a un agente LLM normalmente parece un paso obvio hacia la seguridad, pero el costo de esta solución no siempre es claro. En un artículo de Habr AI, los autores probaron cuánto cambia el funcionamiento de un agente bancario si en lugar de nombres completos reales y otros identificadores, recibe máscaras o pseudónimos.

Dónde surge el conflicto de los agentes LLM

Los agentes LLM trabajan cada vez más con escenarios de usuario donde los datos personales son indispensables: solicitudes bancarias, soporte, seguros, documentos, historial de transacciones. En este punto, todo equipo enfrenta una elección entre dos riesgos. Primero — pasar datos sensibles al modelo tal como están y enfrentar preguntas de privacidad, cumplimiento y seguridad interna. Segundo — limpiar la entrada pero perder parte del contexto en el que el agente basa su lógica, descubrimiento de relaciones entre entidades y precisión de acciones.

"¿Cuánto se degrada un agente si en lugar de 'Ivanov

Ivan' ve 'PERSON_1' o 'XXXXXXXX'?"

En la práctica, esto no es un debate académico sino una tarea de ingeniería. Si el sistema deja de entender que el mismo cliente aparece en varios lugares en una solicitud, afecta no solo la calidad del texto sino la lógica empresarial: enrutamiento de casos, verificación de credenciales, interpretación de estados, validación de secuencia de pasos. Por lo tanto, la pregunta no es una tesis general "la anonimización es útil" o "la anonimización interfiere", sino una respuesta mensurable para una clase específica de agentes y un método específico de limpieza.

Cómo se probó la hipótesis

Para probar la hipótesis, los autores implementaron un agente bancario minimalista e integraron Hivetrace Dataclean con él. Luego enviaron al agente 102 solicitudes sintéticas en tres variantes de datos de entrada: sin modificaciones, enmascaradas y con pseudónimos. Este diseño es útil porque elimina ruido de historiales de usuarios reales y proporciona una comparación controlada. En cada caso, el agente resuelve la misma tarea pero ve diferentes formas de identificadores, nombres y otros atributos personales.

El método de evaluación es particularmente importante. Los autores utilizaron DeepEval en modo LLM-as-a-judge, es decir, compararon no impresiones subjetivas de un par de respuestas sino intentaron formalizar la calidad a través de un único circuito de validación. Para investigación aplicada rápida, este es un enfoque razonable: no hace conclusiones como "verdad absoluta" pero permite ver dónde la degradación es inmediatamente perceptible y dónde el agente retiene utilidad incluso después de que se limpian campos sensibles.

Tres modos de datos

La esencia del experimento no es simplemente verificar si el agente "funciona o no funciona" después de la anonimización, sino comparar diferentes niveles de pérdida de contexto. Esto es especialmente importante para sistemas LLM que se basan no solo en el significado de las palabras sino en relaciones estables entre entidades dentro de un diálogo o documento único. El enmascaramiento completo y la pseudonimización se parecen a un modelo solo a primera vista: en una tarea real, estas son señales diferentes.

• Datos limpios — escenario de línea base sin distorsiones.
• Máscara como XXXXXXXX — máxima privacidad, mínima semántica.
• Pseudónimos como PERSON_1 — ocultan identidad pero preservan relaciones.
• 102 solicitudes sintéticas por modo — oportunidad para comparación honesta.

De tal prueba, los equipos normalmente obtienen no una prohibición o permiso universal sino un mapa de compromisos. Si el agente solo necesita la intención general del usuario, el enmascaramiento rígido puede resultar aceptable. Si la lógica depende del mismo objeto repitiéndose en varios fragmentos, los pseudónimos a menudo se ven como una opción más práctica. Es precisamente por esto que tales verificaciones son especialmente útiles antes de implementar agentes en banca, fintech, medicina y cualquier proceso donde los errores en datos personales rápidamente se vuelven costosos.

Lo que esto significa

La conclusión principal del artículo es que la cuestión de la anonimización para agentes LLM no puede resolverse al nivel de la intuición. Antes de la producción, necesita medir por separado cómo un método de limpieza específico afecta un escenario específico: comprensión de consultas, preservación de relaciones entre entidades y calidad general de respuesta. Para equipos que construyen agentes de IA en dominios sensibles, esto ya no es una opción sino una parte fundamental de la arquitectitetura y el circuito de prueba.