Habr AI: Por qué los sistemas de agentes necesitan nuevas métricas de control y seguridad

La transición de chatbots a sistemas de agentes cambia fundamentalmente qué necesita ser controlado: mientras que antes era suficiente entender cuán útil y correcta era la respuesta de un modelo a una consulta, ahora es necesario evaluar toda la cadena de acciones que el sistema construye por sí mismo. Un agente no simplemente genera texto, sino que planifica pasos, selecciona herramientas, solicita datos, puede delegar trabajo a otros agentes y tomar decisiones intermedias. En tal arquitectura, una respuesta final elegante ya no garantiza que el sistema haya funcionado de manera confiable, segura y económica.

Para un chatbot clásico, las métricas principales eran típicamente calidad de respuesta, precisión de formulación, relevancia y satisfacción del usuario. Para un agente, esto es insuficiente, porque un error puede aparecer mucho antes del mensaje final. El sistema puede descomponer incorrectamente una tarea en etapas, seleccionar una herramienta inadecuada, terminar el escenario prematuramente, quedar atrapado en acciones repetitivas u, por el contrario, tomar pasos innecesarios y gastar demasiados tokens, tiempo y solicitudes externas.

Por lo tanto, el enfoque cambia no solo al resultado, sino también a la trayectoria por la cual el agente llegó a él. Por esto, el conjunto de métricas se expande. En primer lugar viene la proporción de tareas completadas exitosamente: no simplemente si el agente proporcionó una respuesta plausible, sino si logró el objetivo del usuario sin intervención manual.

A continuación vienen los indicadores de calidad de planificación—cuán lógicamente se eligieron los pasos, cuántos de ellos son realmente necesarios, con qué frecuencia debe revisarse el plan durante la ejecución. Por separado, es importante medir la corrección de la invocación de herramientas: ¿seleccionó el agente la API correcta, pasó parámetros válidos, obtuvo el resultado esperado y manejó adecuadamente los errores? Para sistemas multiagente, se añaden métricas de coordinación: ¿no duplican los agentes el trabajo entre sí, no pierden contexto y no crean acciones conflictivas?

Igualmente importantes son el costo y la observabilidad. Los sistemas de agentes son casi siempre más costosos que un diálogo regular, porque cada paso adicional, llamada al modelo o servicio externo tiene un costo. Por lo tanto, el control debe considerar iteraciones promedio por tarea, consumo de tokens, frecuencia de reintentos, duración de ejecución y proporción de acciones sin sentido.

En paralelo, crecen los requisitos de trazabilidad: el equipo necesita ver qué decisión tomó el agente en cada etapa, en qué datos se basó, por qué seleccionó una herramienta particular y en qué momento se desvió del escenario esperado. Sin tal transparencia, es imposible depurar comportamiento, investigar fallos o probar cumplimiento con políticas internas. De aquí surge un cambio en los requisitos de seguridad.

Si un chatbot principalmente arriesgaba producir texto incorrecto o peligroso, un agente ya puede ejecutar una acción indeseable: enviar una solicitud al lugar equivocado, obtener acceso no intencional a datos, modificar un registro en un sistema o usar una herramienta fuera de su contexto permitido. Por lo tanto, la arquitectura de agentes requiere control de acceso granular, enfoque de sandbox para herramientas, políticas estrictas en la ejecución de acciones, límites de autonomía y mecanismos de parada si el sistema exhibe comportamiento sospechoso. La seguridad aquí deja de ser un filtro en la entrada y salida y se convierte en parte del bucle operacional.

Otro cambio concierne a las operaciones. Para un sistema de agente, es importante no solo ejecutar una tarea en un escenario ideal, sino también degradarse de manera segura en caso de fallo. Las métricas de recuperación resultan útiles: ¿con qué frecuencia puede el agente corregir su propio error, cuándo transfiere una tarea a un humano, cuántos incidentes requieren investigación manual y con qué rapidez puede el equipo reproducir el problema a partir de los registros?

En la práctica, esto significa que los equipos de producto y plataforma necesitan diseñar no solo la inteligencia del agente, sino también sus modos de fallo, monitoreo y procedimientos de intervención. La conclusión principal es que los sistemas de agentes no pueden ser evaluados por las mismas reglas que las interfaces de chat ordinarias. Las empresas deben hacer la transición de verificar la calidad de respuesta a una ingeniería de ejecución completa: medir conclusión de tareas, robustez de planes, corrección de invocación de herramientas, costo, trazabilidad y cumplimiento de reglas de seguridad.

Cuanto más autónoma se vuelve una LLM, más se aproxima su control al monitoreo de un servicio de software complejo en lugar de la edición de enunciados exitosos o fallidos.