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

El paso de los chatbots a los sistemas con agentes cambia el propio objeto de control. Antes bastaba con saber cuán útil y correcta era la respuesta del modelo a una consulta; ahora hay que evaluar toda la cadena de acciones que el modelo construye por sí mismo. Un agente no se limita a generar texto: planifica pasos, elige herramientas, solicita datos, puede delegar parte del trabajo en otros agentes y toma decisiones intermedias. En una arquitectura así, una respuesta final impecable ya no garantiza que el sistema haya funcionado de forma fiable, segura y económica.

Para un chatbot clásico, las métricas principales solían ser la calidad de la respuesta, la precisión de la redacción, la relevancia y la satisfacción del usuario. En un agente no es suficiente, porque el error puede aparecer mucho antes del mensaje final. El sistema puede dividir mal la tarea en etapas, elegir una herramienta inadecuada, terminar el escenario demasiado pronto, quedarse atrapado en acciones repetidas o, al contrario, dar pasos de más y gastar demasiados tokens, tiempo y peticiones externas. Por eso la atención se centra no solo en el resultado, sino también en la trayectoria que siguió el agente para llegar a él.

De ahí que el conjunto de métricas se amplíe. En primer lugar está la proporción de tareas completadas con éxito: no basta con que el agente diera una respuesta verosímil, sino que debe haber alcanzado el objetivo del usuario sin intervención manual. Junto a ella van los indicadores de calidad de la planificación: cuán lógicos son los pasos elegidos, cuántos son realmente necesarios y con qué frecuencia hay que rehacer el plan durante la ejecución.

Hay que medir aparte la corrección de las llamadas a herramientas: si el agente eligió la API correcta, pasó parámetros válidos, obtuvo el resultado esperado y supo gestionar adecuadamente un error. En los sistemas multiagente se añaden métricas de coordinación: si los agentes duplican el trabajo de los demás, pierden contexto o generan acciones contradictorias.

El coste y la observabilidad son igual de importantes. Los sistemas con agentes casi siempre salen más caros que un diálogo normal, porque cada paso adicional, cada llamada a un modelo o a un servicio externo tiene un precio. Por tanto, el control debe tener en cuenta el número medio de iteraciones por tarea, el consumo de tokens, la frecuencia de peticiones repetidas, la duración de la ejecución y la 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 apoyó, por qué eligió una herramienta concreta y en qué momento se desvió del escenario esperado. Sin esa transparencia es imposible depurar el comportamiento, investigar fallos o demostrar el cumplimiento de las políticas internas.

También cambian los requisitos de seguridad. Si un chatbot arriesgaba sobre todo generar un texto incorrecto o peligroso, un agente puede ejecutar una acción no deseada: enviar una petición al lugar equivocado, obtener acceso excesivo a datos, modificar un registro en un sistema o usar una herramienta fuera del contexto permitido. Por eso la arquitectura con agentes necesita permisos de acceso granulares, un enfoque sandbox para las herramientas, políticas estrictas de ejecución de acciones, límites a la autonomía y mecanismos de parada si el sistema adopta un comportamiento sospechoso. La seguridad deja de ser un filtro de entrada y salida y pasa a formar parte del circuito operativo.

Otro cambio afecta a la explotación. Para un sistema con agentes no basta con cumplir la tarea en el escenario ideal; también debe degradarse de forma segura ante un fallo. Resultan útiles las métricas de recuperación: con qué frecuencia el agente puede corregir su propio error, cuándo traspasa la tarea a una persona, cuántos incidentes requieren revisión manual y con qué rapidez el equipo puede reproducir un problema a partir de los registros. En la práctica, los equipos de producto y de plataforma deben diseñar no solo la inteligencia del agente, sino también sus modos de fallo, su monitorización y los procedimientos de intervención.

La conclusión principal es que los sistemas con agentes no se pueden evaluar con las mismas reglas que las interfaces de chat convencionales. Las empresas tienen que pasar de comprobar la calidad de la respuesta a una ingeniería de ejecución completa: medir la finalización de tareas, la solidez de los planes, la corrección de las llamadas a herramientas, el coste, la trazabilidad y el cumplimiento de las reglas de seguridad. Cuanto más autónomo se vuelve un LLM, más se parece su control a la monitorización de un servicio de software complejo y menos a la edición de réplicas acertadas o fallidas.