Las evaluaciones de agentes de IA deben ser parte del pipeline de CI/CD

El equipo desarrolla un agente de IA, lo pone a prueba con unas cuantas preguntas representativas y, al obtener respuestas correctas, aprueba el cambio. Semanas después, tras una actualización del modelo o un cambio en la configuración de recuperación, el agente falla: omite una cita obligatoria o llama a una herramienta equivocada. El problema no se detecta hasta que un usuario lo reporta. El mensaje es claro: una demo exitosa demuestra que el agente funcionó una vez bajo condiciones específicas, no que mantendrá ese comportamiento en versiones futuras. Para ello, las evaluaciones deben integrarse directamente en el proceso de entrega.

Definir el comportamiento correcto antes de probar

La recomendación central es documentar el comportamiento esperado antes de escribir pruebas. Frases como "la respuesta fue buena" no son requisitos testables. Hay que definir las tareas del agente, sus límites y qué resultados están fuera de los límites operativos aceptados. Por ejemplo, un agente de soporte debe responder preguntas de facturación usando los registros de la cuenta correcta y citando la política vigente, sin alterar planes ni exponer datos de otros clientes. Si falta información, debe pedir clarificación en lugar de adivinar.

Es crucial separar el resultado del proceso. Un agente puede dar la respuesta correcta recuperando el documento equivocado o llamando a herramientas innecesarias. Estas ejecuciones parecen exitosas en la transcripción pero enmasculan debilidades. Se recomienda empezar con pocas tareas reales (diez son más valiosas que un gran benchmark de prompts artificiales) construidas a partir de tickets de soporte y logs de incidentes. Los escenarios deben incluir interacciones de varios pasos, donde el agente debe mantener el contexto de la cuenta y la solicitud a través de varios turnos de conversación.

Probar el camino de ejecución completo

Evaluar solo la respuesta final es insuficiente. Un agente recupera datos, elige herramientas, lee resultados y decide si continúa; cualquier paso en ese bucle puede desviarse del camino previsto aunque la respuesta final sea convincente. La traza de ejecución debe capturar las instrucciones del sistema, el modelo exacto, la versión del prompt, la configuración de recuperación, cada fuente recuperada, cada llamada a herramienta con sus argumentos y resultados, verificaciones de permisos, latencia y consumo de tokens. Esta traza permite verificar determinísticamente que una búsqueda se mantuvo dentro del inquilino correcto o que una escritura fue confirmada por el usuario y validada por el servidor. La claridad y la utilidad siguen requiriendo revisión humana, pero los controles de seguridad y permisos son binarios: o ocurrieron o no.

Tratar los fallos de producción como casos de regresión permanentes permite que el suite de pruebas acumule los errores ya pagados. Sin un sistema de evaluación repetible que registre evidencia suficiente para decidir si una release procede, el producto no está listo para pasar el gate de lanzamiento.