Cómo aplicar evals en agentes de IA
Evaluar un agente de IA no es lo mismo que evaluar un chatbot: la respuesta de texto puede ser perfecta y el agente puede haber llamado a la herramienta equivocada, gastado tiempo y dinero innecesarios, o tomado una acción que ningún humano aprobaría. Esta guía se basa en las prácticas documentadas por MLflow para agentes listos para producción y en los datos de la encuesta State of AI Agents de LangChain sobre lo que las empresas ya hacen - y lo que todavía no.
Paso 1: define criterios de éxito más allá de "la respuesta parece correcta"
MLflow recomienda rastrear específicamente "faithfulness" (precisión factual), completitud y suficiencia de la respuesta - tres dimensiones distintas de "se ve bien". Una respuesta puede ser factualmente precisa y aun así incompleta, o completa y aun así insuficiente para la tarea.
Paso 2: establece ground truth antes de medir el drift
Captura la distribución de calidad en el momento del lanzamiento del agente. Sin esa línea base, no hay forma de saber si una caída de calidad es real o solo ruido - MLflow recomienda establecer umbrales estadísticos que disparen una alerta cuando la desviación respecto a esa distribución inicial sea anormal.
Paso 3: prueba el uso de herramientas, no solo el texto
Un agente que responde bien pero llama a la herramienta equivocada, o pasa el parámetro equivocado, falla de una forma que la evaluación de texto no detecta. Las pruebas de uso de herramientas necesitan verificar específicamente: se llamó a la herramienta correcta, con los parámetros correctos, en el orden correcto.
Paso 4: pruebas de seguridad como categoría propia
El OWASP Agentic Skills Top 10 mapea riesgos de seguridad específicos de las capas de comportamiento de los agentes - eso no es lo mismo que probar la calidad de la respuesta. Las pruebas de seguridad evalúan si el agente resiste intentos de manipulación, respeta los límites de alcance, y falla de forma segura cuando algo sale mal.
Paso 5: regresión en cada cambio
Cada cambio en un prompt, herramienta o contexto es candidato a romper algo que ya funcionaba. Las pruebas de regresión ejecutadas en cada cambio detectan esto antes de producción, no después.
Pasos 6 y 7: costo y latencia como evals, no como métrica de infraestructura aparte
El costo y la latencia no deberían medirlos solo el equipo de infraestructura - son parte del eval, porque una respuesta correcta que cuesta 10 veces más o tarda 10 veces más puede no ser aceptable para el caso de uso.
Paso 8: trazabilidad como parte de la evaluación
Un agente que decide correctamente pero no deja rastro de por qué decidió así falla en una auditoría, incluso pasando todas las demás pruebas. Evaluar la trazabilidad significa verificar si el registro generado es suficiente para reconstruir la decisión después.
Paso 9: evaluación incorporada al flujo, con LLM-as-a-Judge para escalar
El enfoque que describe MLflow, basado en orientación del NIST, incorpora "probes de evaluación... en workflows agentic activos", con resultados en "trazas de auditoría legibles por máquina". Para no depender de la revisión humana en cada respuesta, el enfoque LLM-as-a-Judge de MLflow automatiza la mayor parte de la evaluación, reservando la revisión humana para los casos que el propio juicio automatizado marca como dudosos.
Paso 10: monitoreo continuo, no evaluación puntual
El eval no es un paso que se hace una vez antes del lanzamiento - es un proceso continuo. Los datos de LangChain muestran que las herramientas de trazabilidad y observabilidad ya son el control más citado entre las empresas con agentes en producción, precisamente porque una evaluación puntual no detecta la degradación que ocurre meses después del lanzamiento.
Fuentes
- LangChain - State of AI Agents - https://www.langchain.com/stateofaiagents
- MLflow - Building Production-Ready AI Agents in 2026 - https://mlflow.org/articles/building-production-ready-ai-agents-in-2026/