Cómo afecta la limpieza de datos personales a los agentes LLM: el experimento de Hivetrace Dataclean

Limpiar los datos personales antes de enviarlos a un agente LLM suele parecer un paso obvio hacia la seguridad, pero el coste de esta decisión no siempre está claro. En un artículo publicado en Habr AI, los autores comprobaron cuánto cambia el funcionamiento de un agente bancario cuando, en lugar de nombres reales y otros identificadores, recibe máscaras o seudónimos.

Dónde surge el conflicto

Los agentes LLM trabajan cada vez más con escenarios de usuario en los que los datos personales son imprescindibles: consultas bancarias, soporte, seguros, documentos, historial de operaciones. En ese punto, el equipo siempre tiene que elegir entre dos riesgos. El primero es pasar los datos sensibles al modelo tal cual y enfrentarse a dudas de privacidad, cumplimiento normativo y seguridad interna. El segundo es limpiar la entrada, pero perder parte del contexto en el que el agente apoya la lógica de su respuesta, la búsqueda de entidades relacionadas y la precisión de sus acciones.

«¿Cuánto se degrada el agente si, en lugar de "Iván

Ivanov", ve "PERSON_1" o "XXXXXXXX"?»

En la práctica, no se trata de un debate académico, sino de un problema de ingeniería. Si el sistema deja de entender que un mismo cliente aparece en varios puntos de la consulta, no solo se resiente la calidad del texto, también la lógica de negocio: el enrutamiento del caso, la verificación de datos bancarios, la interpretación de estados y la comprobación de la secuencia de pasos. Por eso lo importante no es la tesis general de que «la anonimización ayuda» o «la anonimización estorba», sino una respuesta medible para una clase concreta de agentes y un método de limpieza concreto.

Cómo se puso a prueba la hipótesis

Para comprobarlo, los autores montaron un agente bancario minimalista y le conectaron Hivetrace Dataclean. Después enviaron al agente 102 consultas sintéticas en cada una de las tres variantes de entrada: sin cambios, con enmascaramiento y con seudónimos.

Este diseño tiene la ventaja de eliminar el ruido de las historias reales de usuarios y ofrecer una comparación controlada. En todos los casos, el agente resuelve la misma tarea, pero ve de forma distinta los identificadores, los nombres y otros atributos personales.

El método de evaluación también es relevante. Los autores usaron DeepEval en modo LLM-as-a-judge: en lugar de comparar impresiones subjetivas sobre un par de respuestas, intentaron formalizar la calidad mediante un circuito de verificación único. Para un estudio aplicado y rápido, es una decisión razonable: no convierte las conclusiones en una «verdad absoluta», pero permite ver dónde la degradación se nota de inmediato y dónde el agente sigue siendo útil incluso después de limpiar los campos sensibles.

Tres modos de datos

La clave del experimento no es solo comprobar si el agente «funciona o no» tras la anonimización, sino comparar distintos niveles de pérdida de contexto. Esto es especialmente importante en sistemas LLM que se apoyan no solo en el significado de las palabras, sino también en relaciones estables entre entidades dentro de un mismo diálogo o documento. La máscara completa y la seudonimización solo se parecen a primera vista desde el punto de vista del modelo: en una tarea real, son señales distintas.

• Datos limpios: el escenario base, sin distorsiones.
• Máscara del tipo XXXXXXXX: máxima privacidad, mínima semántica.
• Seudónimos del tipo PERSON_1: ocultan la identidad, pero conservan las relaciones.
• 102 consultas sintéticas por modo: posibilidad de una comparación justa.

De una prueba así, los equipos no suelen obtener una prohibición o un permiso universal, sino un mapa de compromisos. Si al agente solo le importa la intención general del usuario, una máscara estricta puede resultar aceptable. Si, en cambio, la lógica depende de que un mismo objeto se repita en varios fragmentos, los seudónimos suelen ser una opción más práctica. Por eso este tipo de pruebas resulta especialmente útil antes de desplegar agentes en banca, fintech, medicina o cualquier proceso en el que los errores con datos personales salen caros rápidamente.

Qué significa

La principal conclusión del artículo es que la anonimización en agentes LLM no puede decidirse por intuición. Antes de pasar a producción, hay que medir por separado cómo afecta un método de limpieza concreto a un escenario concreto: la comprensión de la consulta, la conservación de las relaciones entre entidades y la calidad final de la respuesta. Para los equipos que construyen agentes de AI en dominios sensibles, esto ya no es una opción, sino una parte básica de la arquitectura y del circuito de pruebas.