GUÍA TÉCNICA
Cómo evaluar un agente de IA antes y después de producción
Un agente puede dar una respuesta impecable y haber hecho mal el trabajo.
Puede afirmar que actualizó un pedido cuando la API devolvió un error, generar un informe convincente con la fuente equivocada o completar una tarea saltándose una aprobación obligatoria. Por eso evaluar un agente exige algo más que leer su respuesta final.
RESPUESTA RÁPIDA
Un eval es una evaluación sistemática del comportamiento de un agente sobre casos definidos. Para un agente que utiliza herramientas o modifica sistemas, hay que comprobar el outcome o estado real del entorno, la trayectoria seguida, los controles respetados y el coste operativo. Además, un solo intento no basta para medir fiabilidad y la evaluación no termina al desplegar.
La pregunta útil no es «¿el agente responde bien?», sino qué evidencia demuestra que hizo correctamente el trabajo dentro de los límites que habíamos definido.
Qué significa evaluar un agente de IA
Una demostración y una evaluación no son lo mismo.
En una demo solemos elegir un caso que conocemos, observar una ejecución y comprobar que el resultado parece razonable.
Una evaluación sistemática necesita algo más estructurado:
caso → ejecución → traza → comprobaciones → resultado
Anthropic propone una terminología especialmente útil para ordenar este proceso:
- task: el caso o tarea que queremos evaluar;
- trial: una ejecución concreta de ese caso;
- trajectory o trace: la secuencia de acciones, herramientas y observaciones;
- outcome: el estado final real producido por la ejecución;
- grader: la lógica que decide si un criterio se cumple;
- eval suite: el conjunto de casos y criterios utilizados para medir el sistema.
Esto evita una confusión muy común: tratar la respuesta escrita por el agente como si fuera sinónimo de resultado.
En sistemas puramente conversacionales, la respuesta puede ser una parte importante del resultado. Pero cuando el agente consulta herramientas, cambia datos, genera archivos, reserva recursos o activa procesos, hay otra realidad que también debemos observar: qué ocurrió realmente fuera del modelo.
La evaluación convierte una impresión —«parece funcionar»— en evidencia repetible.
Una respuesta correcta puede esconder una ejecución incorrecta
Ejemplo orientativo — no es un caso de cliente.
Imaginemos un agente que gestiona cambios de citas.
El usuario pide: «Cambia mi cita del jueves al martes por la tarde».
Después de unos segundos, el agente responde: «Listo. Tu cita ha sido trasladada al martes a las 17:00».
La respuesta puede parecer perfecta.
Pero podrían haber ocurrido varias cosas:
- La herramienta cambió correctamente la cita.
- La API devolvió un error, pero el agente respondió como si hubiera funcionado.
- El agente modificó la cita de otra persona.
- Creó una segunda cita sin cancelar la anterior.
- Ejecutó dos veces la misma operación.
- Eligió una hora incompatible con una restricción.
- No hizo ningún cambio.
Si la evaluación solo inspecciona el texto, todos esos casos pueden recibir una valoración similar.
Por eso Anthropic define el outcome como el estado final real del entorno. Si un agente afirma que ha reservado algo, el éxito no se demuestra por la frase: se demuestra comprobando que la reserva existe correctamente.
La respuesta es una salida; el outcome es el estado real
Cuando el agente actúa sobre herramientas o sistemas, la confirmación textual no demuestra que el efecto se haya producido correctamente.
Equivalente textual del diagrama
El usuario envía una tarea al agente. El agente utiliza herramientas que modifican o consultan sistemas reales.
La respuesta textual del agente es una salida paralela; el outcome se comprueba en el estado final del sistema.
Cuatro capas para evaluar un agente
Una forma práctica de organizar la evaluación es separar cuatro capas.
Estas capas responden a preguntas distintas.
Un agente puede producir el outcome correcto y seguir teniendo un problema de trayectoria. Por ejemplo, podría completar correctamente una devolución pero haber consultado datos a los que no debía acceder.
También puede seguir un proceso aparentemente correcto y fallar en el outcome porque una integración no modificó realmente el sistema.
Y un agente puede superar ambas capas, pero necesitar tantos reintentos, llamadas y revisiones humanas que la solución no sea operativamente razonable.
Evaluar bien significa evitar que una única puntuación o una impresión general esconda esas diferencias.
Cuatro capas para evaluar un agente
Una única puntuación puede ocultar diferencias importantes entre resultado, proceso, límites y operación.
Equivalente textual del diagrama
- OUTCOME: ¿El sistema quedó como debía?
- TRAYECTORIA: ¿Cómo llegó hasta allí?
- CONTROLES: ¿Respetó permisos y límites?
- OPERACIÓN: ¿A qué coste y con qué estabilidad?
Evalúa el resultado real, no la declaración del agente
Siempre que sea posible, el outcome debería comprobarse contra la fuente de verdad del proceso.
Si el agente crea un ticket, comprueba el sistema de tickets. Si modifica un CRM, comprueba el registro. Si genera un archivo, comprueba que existe, que es válido y que contiene lo requerido. Si actualiza una cita, comprueba calendario, identidad, hora y ausencia de duplicados.
Si la acción no debía ocurrir, comprueba que no ocurrió.
Este último caso es especialmente importante.
Una evaluación no debería medir únicamente lo que el agente debe hacer. También necesita escenarios donde el comportamiento correcto sea detenerse, pedir información, escalar o no actuar.
Por ejemplo: «Cancela todas las citas de este cliente».
Si el agente no tiene permiso para una operación masiva, el resultado correcto puede ser rechazarla o solicitar una aprobación. Una prueba que premie únicamente «tarea ejecutada» estaría incentivando exactamente el comportamiento equivocado.
Las comprobaciones de outcome suelen ser buenos candidatos para evaluadores deterministas: valor en base de datos, recurso creado, estado actualizado, campo exacto, ausencia de duplicado, acción no ejecutada, estructura válida o ID correcto.
Cuando podemos verificar algo directamente, no necesitamos pedir a otro modelo que adivine si sucedió.
Evalúa la trayectoria, pero no la conviertas en un guion
La trayectoria muestra cómo trabaja el agente: qué herramienta eligió, con qué argumentos, qué resultado recibió, qué hizo después, cuántas veces reintentó, si entró en un bucle, cuándo se detuvo y si escaló correctamente.
Google ADK incorpora precisamente la trayectoria y el uso de herramientas como parte de la evaluación de agentes. Anthropic también insiste en que, en tareas agénticas, el camino puede contener información que la respuesta final no revela.
Pero existe un peligro: convertir la evaluación en un guion exacto que el agente deba imitar.
Supongamos que una tarea puede resolverse consultando primero el CRM y después el ERP, o en el orden contrario. Si ambas rutas respetan permisos y producen el mismo resultado correcto, exigir una secuencia exacta puede penalizar una solución válida.
Por eso conviene diferenciar entre invariantes y preferencias de recorrido.
Una invariante puede ser: «Debe comprobar la identidad antes de modificar una cuenta».
Otra: «Nunca debe utilizar la herramienta delete_customer».
Otra: «Una devolución superior al límite autorizado requiere aprobación».
En cambio, una preferencia podría ser: «Normalmente consulta primero el CRM».
Si ese orden no es necesario para la seguridad o el resultado, quizá no debería convertirse en requisito rígido.
Evalúa resultados e invariantes; fija el camino exacto solo cuando el recorrido forma parte del requisito.
Evaluadores deterministas, LLM-as-judge y revisión humana
No todos los criterios deberían medirse del mismo modo.
Evaluadores deterministas
Son la primera opción cuando existe una respuesta verificable mediante código o reglas.
Funcionan bien para estado final, valores exactos, JSON válido, herramienta llamada o no llamada, argumentos, límites, permisos, número máximo de reintentos, presencia de una aprobación o ausencia de una acción prohibida.
Tienen una ventaja importante: si la regla está bien diseñada, sabemos exactamente por qué una ejecución pasa o falla.
LLM-as-judge
Un modelo evaluador resulta útil cuando el criterio es semántico y no puede reducirse con facilidad a una comprobación exacta.
Por ejemplo: claridad, relevancia, exhaustividad, tono, calidad de una explicación o adecuación a una rúbrica compleja.
Pero un judge también es un modelo. Puede variar, tener sesgos, preferir determinados estilos o interpretar de forma distinta una rúbrica ambigua.
Por eso conviene evaluar dimensiones separadas, escribir rúbricas concretas, proporcionar ejemplos cuando sea necesario, permitir «evidencia insuficiente» si aplica, calibrar contra expertos humanos y revisar periódicamente sus decisiones.
Revisión humana
Los humanos siguen siendo especialmente valiosos para calibrar jueces, evaluar dominios subjetivos, revisar casos de alto impacto, descubrir fallos que la suite no anticipó, analizar desacuerdos y validar que el propio criterio de evaluación tiene sentido.
La combinación suele ser más fuerte que convertir todo en LLM-as-judge.
No uses un modelo para juzgar algo que puedes verificar exactamente con una regla.
Cómo construir un buen conjunto de casos
Un dataset de evaluación no debería estar formado únicamente por ejemplos fáciles en los que sabemos que el agente funciona.
Tiene que representar las fronteras del proceso.
Una suite inicial para el agente de citas podría contener:
- Cambio normal con disponibilidad.
- Falta información imprescindible.
- Usuario ambiguo.
- Herramienta devuelve un error.
- La herramienta devuelve un dato inesperado.
- La acción requiere aprobación.
- El agente intenta una acción fuera de permiso.
- El comportamiento correcto es no actuar.
- Existe un reintento permitido.
- Se agotan los reintentos y debe escalar.
- La cita ya fue modificada y hay que evitar duplicar la operación.
- Un caso real que produjo un fallo en producción.
La suite debe incluir tanto «debería hacer» como «no debería hacer», porque un agente que completa muchas tareas puede parecer muy capaz mientras viola silenciosamente límites importantes.
Las fuentes de casos pueden ser pruebas que el equipo ya realiza manualmente, procedimientos operativos, tickets, bugs, ejemplos de expertos, excepciones conocidas, trazas reales e incidentes anteriores.
El objetivo no es acumular miles de ejemplos por defecto. Es conseguir suficiente cobertura de los comportamientos que importan.
Un solo intento no mide fiabilidad
Los agentes que dependen de modelos generativos pueden variar entre ejecuciones.
El mismo caso puede producir una trayectoria diferente y, en ocasiones, un resultado diferente.
Por eso una sola ejecución responde «¿funcionó esta vez?», pero no responde bien «¿con qué consistencia funciona?».
Anthropic propone ejecutar múltiples trials por tarea y utiliza dos medidas que responden a preguntas distintas.
pass@k pregunta si existe al menos un éxito entre varios intentos. Es útil cuando podemos intentar varias veces y nos interesa saber si el sistema tiene capacidad de encontrar una solución.
pass^k pregunta si todas las ejecuciones tienen éxito. Es una señal mucho más exigente de consistencia.
No hace falta convertir toda evaluación empresarial en estadística avanzada para entender la diferencia.
Para un sistema creativo puede ser aceptable que varios intentos produzcan resultados distintos. Para un agente que modifica datos de clientes, «funciona alguna vez» tiene mucho menos valor que «se comporta correctamente de forma consistente».
Capability evals y regression evals
No todas las evaluaciones cumplen la misma función.
Capability evals
Preguntan: ¿hasta dónde llega actualmente el agente?
Suelen incluir tareas difíciles que el sistema todavía no resuelve con fiabilidad. Sirven para descubrir fronteras y medir progreso.
Una tasa de éxito baja no significa necesariamente que el eval esté mal: puede significar que estamos midiendo una capacidad aún inmadura.
Regression evals
Preguntan: ¿sigue funcionando aquello que ya funcionaba?
Protegen comportamientos conocidos frente a cambios en prompts, modelos, herramientas, recuperación, permisos, código o arquitectura.
Un patrón razonable es:
capacidad nueva → capability eval → mejora → comportamiento estable → regression suite
Así, cuando un problema ya está resuelto, queda protegido para que un cambio futuro no lo introduzca de nuevo.
Antes de producción: define el listón antes de mirar el resultado
Evaluar antes de desplegar no consiste en ejecutar el agente muchas veces y decidir después qué puntuación parece suficiente.
Es mejor definir primero qué significa éxito.
- Describir la tarea.
- Definir el outcome correcto.
- Identificar invariantes y acciones prohibidas.
- Construir casos representativos.
- Elegir el grader adecuado para cada criterio.
- Ejecutar varios trials.
- Establecer un baseline.
- Definir qué fallos bloquean el despliegue.
- Leer trazas.
- Comparar versiones.
Los umbrales deben derivarse del proceso.
No existe un porcentaje universal que convierta automáticamente un agente en «listo para producción».
Un 95 % puede ser excelente para una función y completamente inaceptable para otra. Tampoco todos los fallos tienen el mismo peso.
Una respuesta algo más larga de lo deseado no debería evaluarse igual que ejecutar una acción prohibida o modificar la cuenta equivocada.
Antes de lanzar, la pregunta no es solo «¿cuántos casos pasan?». También: ¿qué tipo de caso falla?
Después de producción: convertir trazas reales en aprendizaje
La evaluación no termina cuando el agente empieza a utilizarse.
Producción contiene algo que ningún dataset inicial puede reproducir por completo: usuarios reales, datos reales, combinaciones inesperadas, integraciones inestables y situaciones que nadie incluyó en el diseño original.
Por eso las trazas de producción deberían alimentar el sistema de evaluación.
OpenAI describe este enfoque en su agente interno de datos y en trabajos publicados sobre agentes especializados: el feedback de expertos, las trazas reales y los evals específicos forman un ciclo continuo de mejora.
Supongamos que aparece un fallo: «Cuando la API devuelve dos registros con el mismo nombre, el agente modifica el primero sin confirmar identidad».
Después de corregirlo, ese caso debería poder convertirse en una prueba que impida que la misma regresión reaparezca meses después.
Pero no todo incidente debe transformarse automáticamente en un eval.
Primero hay que entender si fue fallo del agente, dato corrupto, integración caída, requisito no soportado, proceso mal definido, error humano o incluso un fallo de la propia evaluación.
La producción produce evidencia. El equipo decide cómo convertirla en aprendizaje del sistema.
Producción alimenta la suite de regresión
Los casos reales permiten ampliar una suite que, de otro modo, terminaría representando únicamente los supuestos del diseño inicial.
Equivalente textual del diagrama
- PRODUCCIÓN
- TRAZA
- INCIDENCIA
- CASO
- EVAL
- CORRECCIÓN
- REGRESIÓN
- NUEVA VERSIÓN
Coste, latencia y revisión humana también son calidad
Un agente que completa correctamente una tarea después de cuarenta llamadas, cinco reintentos y diez minutos no es equivalente a otro que obtiene el mismo resultado con una trayectoria más contenida.
Eso no significa que menos llamadas sea siempre mejor. A veces una tarea compleja necesita más trabajo.
Pero la operación debe medirse.
Señales útiles pueden incluir:
- tasa de tareas completadas;
- reintentos;
- llamadas a herramientas;
- latencia;
- consumo de modelo;
- errores de herramientas;
- handoffs;
- aprobaciones humanas;
- tiempo de revisión;
- coste por resultado aceptado.
Esta última idea es especialmente útil.
El coste de una ejecución aislada no dice tanto como: ¿cuánto nos cuesta producir un resultado correcto y aceptado?
Un agente barato que necesita muchas repeticiones puede terminar siendo más costoso operativamente. Y uno más caro por ejecución puede ser razonable si reduce fallos o intervención humana en un proceso donde esos fallos son costosos.
La métrica debe estar conectada con el trabajo, no con una cifra técnica aislada.
El eval también puede estar equivocado
Hay otra posibilidad incómoda: el agente puede estar bien y la evaluación mal.
Un caso de prueba puede contener requisitos ocultos, instrucciones ambiguas, una respuesta esperada demasiado rígida, datos obsoletos, un entorno contaminado, una integración inestable, cobertura insuficiente o un judge mal calibrado.
OpenAI publicó en 2026 una auditoría de SWE-Bench Pro en la que identificó problemas graves en una parte considerable de las tareas analizadas, incluyendo tests demasiado estrictos, prompts insuficientemente especificados y cobertura deficiente. La cifra corresponde a ese benchmark concreto y no debe extrapolarse a todas las evaluaciones, pero ilustra perfectamente el problema.
Anthropic documenta también casos donde leer las trayectorias reveló errores en el grader o en la propia tarea.
Por eso, cuando un caso falla repetidamente, la pregunta no debería ser automáticamente «¿qué le pasa al agente?».
También debemos preguntar:
- ¿Está bien definido el caso?
- ¿El grader comprueba realmente el requisito?
- ¿Existe más de una solución válida?
- ¿El entorno es reproducible?
Un framework para decidir si el agente está listo
Antes de desplegar, intenta responder estas preguntas para cada proceso importante.
La salida de este framework no debería ser un único score.
Debería ser una definición operativa de calidad para ese agente: qué resultado debe producir, qué límites no puede cruzar, qué variabilidad aceptamos y qué evidencia necesitamos para demostrarlo.
Preguntas frecuentes
¿Qué es un eval de un agente de IA?
Es una evaluación sistemática que ejecuta al agente sobre casos definidos y comprueba criterios de éxito. Puede observar la respuesta, el estado final, la trayectoria, herramientas, controles, coste y otras señales relevantes.
¿Basta con medir la respuesta final?
No cuando el agente interactúa con sistemas o herramientas. Una respuesta convincente no demuestra que la acción se haya ejecutado correctamente. Conviene verificar el outcome real.
¿Qué es una trayectoria en un agente?
Es la secuencia de acciones, llamadas a herramientas, observaciones, decisiones, reintentos y otros pasos que ocurren durante una ejecución.
¿Hay que definir una trayectoria exacta?
No siempre. Si varias rutas son válidas, una comparación exacta puede penalizar comportamientos correctos. El orden debería fijarse cuando forma parte del requisito, la seguridad o la lógica del proceso.
¿Qué es LLM-as-judge?
Es utilizar un modelo para valorar otra salida o ejecución mediante una rúbrica. Es útil para criterios semánticos, pero debe calibrarse y no sustituye comprobaciones deterministas cuando existe una verdad exacta.
¿Cuántas veces hay que ejecutar un caso?
No existe un número universal. Depende de la variabilidad, el riesgo y la precisión que necesitemos. Lo importante es entender que una sola ejecución no caracteriza bien la consistencia de un sistema probabilístico.
¿Qué diferencia hay entre capability eval y regression eval?
Un capability eval explora qué es capaz de hacer el agente y dónde están sus límites. Un regression eval protege un comportamiento que ya funciona para detectar si un cambio posterior lo rompe.
¿Cómo se evalúa un agente después de desplegarlo?
Observando trazas y resultados reales, clasificando incidencias, convirtiendo los fallos relevantes en nuevos casos de evaluación y ejecutando regresiones antes de publicar cambios posteriores.
Fuentes y lecturas recomendadas
Estas fuentes sostienen las distinciones entre outcome, trayectoria y graders, el uso de múltiples trials, las suites de regresión y la evaluación continua a partir de trazas de producción.
- 01Anthropic — Demystifying evals for AI agents (enlace externo)anthropic.com
Marco de tareas, trials, graders, trayectorias, outcomes, capability evals y regression evals.
- 02Google Agent Development Kit — Evaluate (enlace externo)google.github.io
Documenta evaluación de respuesta final, trayectoria y uso de herramientas.
- 03Microsoft Foundry — Evaluate your AI agents (enlace externo)learn.microsoft.com
Describe datasets, criterios, evaluadores, baselines y comparación de versiones.
- 04Microsoft Foundry — Agent evaluators (enlace externo)learn.microsoft.com
Separa evaluación del sistema y del proceso, incluyendo task completion, tool use y eficiencia del workflow.
- 05OpenAI — How evals drive the next chapter in AI for businesses (enlace externo)openai.com
Expone el ciclo Specify → Measure → Improve y la necesidad de continuar evaluando tras el lanzamiento.
- 06OpenAI Developers — Probar sistemáticamente las habilidades de agentes con evaluaciones (enlace externo)developers.openai.com
Trata outcomes, pasos observables, aserciones deterministas y trazas.
- 07OpenAI — Inside our in-house data agent (enlace externo)openai.com
Muestra cómo las evaluaciones forman parte del ciclo continuo de desarrollo de un agente en producción.
- 08OpenAI — Separating signal from noise in coding evaluations (enlace externo)openai.com
Auditoría que muestra cómo tareas o graders defectuosos pueden distorsionar una evaluación.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Cómo sabes que tu agente sigue haciendo bien el trabajo después de cada cambio?
Antes de desplegar conviene convertir el proceso real en casos verificables y definir qué resultado, límites y coste hacen aceptable una ejecución. Después, las trazas reales deberían ampliar esa suite para evitar que los problemas conocidos reaparezcan.
En Agentes Como Servicio diseñamos la evaluación como parte del sistema: outcomes verificables, trazas, controles, regresiones y criterios alineados con el proceso que el agente debe operar.
Solicitar acceso