Para evaluar un agente de IA, comprueba si alcanza objetivos explícitos durante todo el recorrido —incluidas sus decisiones y llamadas a herramientas—, no solo si su respuesta final parece convincente. Una guía publicada por Google el 15 de octubre de 2026 propone convertir recorridos reales de usuario en escenarios, revisar las trazas y automatizar las comprobaciones que detecten fallos. Google detalla ese flujo en su guía de evaluación de agentes.

Un flujo que conecta objetivos, pruebas y producción

Cómo evaluar agentes de IA más allá de su respuesta final

El proceso tiene que permitir comparar ejecuciones y convertir los fallos observados en nuevas pruebas. Empieza por definir qué significa tener éxito; después, prueba escenarios, revisa cómo actuó el agente y añade controles que se mantengan útiles cuando el sistema cambie.

1. Define el éxito desde el recorrido del usuario

Google recomienda describir un recorrido crítico del usuario (CUJ, por sus siglas en inglés) con cuatro piezas: quién utiliza el agente, qué quiere conseguir, qué restricciones debe respetar y cómo se comprobará el resultado. Cada condición concreta puede convertirse en un punto de evaluación.

Por ejemplo, para un agente que ayuda a tramitar una incidencia, no basta con que redacte una respuesta convincente. La evaluación puede comprobar si identificó la operación discutida, consultó el registro pertinente y preparó una respuesta que respete las restricciones del caso. Así, el equipo distingue un resultado correcto por casualidad de un proceso que cumplió los pasos necesarios.

2. Simula escenarios y revisa las trazas

Prueba tanto el recorrido esperado como los casos límite: información incompleta, errores de escritura o una conversación que cambia de rumbo. Google recomienda empezar con escenarios simulados y añadir progresivamente casos de producción cuando los haya.

Antes de automatizar un fallo, revisa la traza: el registro de la ejecución, que puede incluir las instrucciones recibidas, los pasos intermedios, los argumentos enviados a las herramientas y la respuesta final. La guía de Google propone inspeccionar estas trazas para detectar patrones y convertirlos en comprobaciones repetibles. Si un agente responde bien, pero consulta una herramienta incorrecta, la traza ayuda a localizar ese desvío en lugar de quedarse con la impresión que deja la respuesta.

3. Haz comparables las ejecuciones

Cuando el comportamiento del agente varía entre intentos, una sola ejecución puede dar una imagen engañosa. Braintrust recomienda repetir cada tarea y controlar las dependencias externas, por ejemplo, con servicios simulados o datos guardados en instantáneas. También plantea usar entornos aislados e introducir fallos como tiempos de espera agotados, respuestas mal formadas o campos ausentes para comprobar cómo reacciona el sistema. Braintrust explica estas prácticas para evaluar agentes.

La idea práctica es sencilla: si cambian a la vez el agente y los datos que recibe, cuesta saber qué provocó una diferencia en la puntuación. Mantén las condiciones externas bajo control y compara varios intentos de la misma tarea; así puedes separar mejor la variación entre ejecuciones de los cambios en el entorno.

4. Combina comprobaciones y calibra al evaluador

IBM Technology explica cómo evaluar respuestas con jueces basados en modelos de lenguaje; el vídeo está en inglés.

Google agrupa las comprobaciones en cuatro tipos: pruebas unitarias, métricas deterministas, rúbricas evaluadas por un modelo de lenguaje y pruebas de integración. Se complementan: una métrica automática puede comprobar una condición concreta, mientras que una rúbrica puede valorar una respuesta según criterios definidos. Google también recomienda contrastar las puntuaciones automáticas con trazas revisadas por personas y formular preguntas de sí o no cuando sea posible.

Un evaluador basado en un modelo de lenguaje también puede favorecer una respuesta por su posición, por ser más larga o porque la haya generado él mismo. IBM Technology describe invertir el orden de dos respuestas candidatas y comprobar si cambia el juicio: esta prueba sondea el sesgo de posición. No comprueba por sí sola los otros sesgos.

5. Conserva una base estable y aprende de producción

Para saber si un cambio mejora el agente o rompe algo que ya funcionaba, Google recomienda mantener fijo el conjunto de pruebas de referencia durante las comparaciones y cambiar una variable cada vez. En una integración continua (CI/CD), las comprobaciones pueden combinar un umbral global de aprobación con la ausencia de regresiones en las métricas principales que ya se superaban. Conviene seguir también el comportamiento operativo: latencia, uso de tokens, coste de API y número de llamadas a herramientas, además de la calidad de las respuestas.

La evaluación puede continuar cuando el agente llega a producción. Microsoft describe observar interacciones reales y usar los hallazgos para actualizar los conjuntos de pruebas offline. Así, un caso inesperado que aparece en uso real puede convertirse en un escenario que el equipo vuelva a ejecutar antes de futuros cambios. Microsoft explica el ciclo entre evaluación online y pruebas offline.

Cuando una persona y el evaluador automático discrepan, participantes de una conversación en r/AI_Agents proponen registrar la resolución y la versión de la regla aplicada, aclarar el criterio y añadir casos contrastados a las pruebas de regresión. Es una propuesta de profesionales en una conversación comunitaria, no una norma general. La discusión aborda cómo tratar esos desacuerdos.