Evaluación continua de agentes de IA: método práctico

Los agentes de IA confiables se miden por el resultado que producen, no por la fluidez de sus respuestas. Esta distinción parece simple, pero cambia la forma de diseñar automatizaciones. Un agente puede redactar una respuesta convincente, llamar herramientas sin errores técnicos y aun así cancelar el pedido equivocado, clasificar un lead de forma imprecisa o abrir un ticket en el sistema incorrecto.

La presión por llevar agentes a producción ha hecho este problema más visible. En el informe State of Agent Engineering 2026, de LangChain, el 57% de los encuestados afirmó tener ya agentes en producción. Sin embargo, aunque el 89% reporta algún nivel de observabilidad, solo el 52,4% ejecuta evaluaciones offline con conjuntos de pruebas. La brecha es crítica: registrar eventos no es lo mismo que demostrar calidad.

La evaluación continua es el sistema que conecta la intención de negocio, el comportamiento del agente y el resultado operativo. Debe operar antes, durante y después de cada cambio relevante: modelo, prompt, herramienta, política, integración, base de conocimiento o regla de derivación.

Qué debe evaluarse en un agente de IA

La respuesta concreta es: evalúe la tarea, la trayectoria y el efecto en el proceso. Una respuesta final aislada rara vez es suficiente.

Un agente actúa en una secuencia. Interpreta una solicitud, selecciona contexto, decide si debe usar una herramienta, ejecuta acciones, gestiona retornos parciales y cierra o transfiere el caso. Cada etapa puede introducir fallos. Por eso, la unidad de análisis no es solo el texto generado. Es la ejecución completa.

Hay tres capas útiles:

• Calidad de resultado: ¿se alcanzó el objetivo? En un agente de soporte, la solicitud se resolvió correctamente. En un agente comercial, el lead se calificó con los criterios correctos.
• Calidad de trayectoria: ¿el agente utilizó las fuentes, herramientas y permisos correctos? Una trayectoria es el registro ordenado de decisiones, llamadas a herramientas, mensajes y estados intermedios.
• Calidad operativa: ¿el agente cumplió los límites de costo, latencia, seguridad y volumen de intentos?

El estudio Monitoring Agentic Systems Before They're Reliable, publicado en junio de 2026, propone observar sistemas agénticos según calidad, adecuación y eficiencia, en tres alcances: dentro de una ejecución, entre ejecuciones y en la estructura del sistema. La implicación práctica es directa: un panel de errores de API no detecta, por sí solo, decisiones inadecuadas que fueron ejecutadas correctamente desde el punto de vista técnico.

Defina el éxito con criterios observables. “Atender bien” es una ambición. “Clasificar correctamente la intención, registrar el pedido en el CRM y derivar excepciones a un humano en un plazo de hasta dos minutos” es una especificación evaluable.

Cómo transformar objetivos de negocio en casos de prueba

La respuesta concreta es: construya un conjunto de evaluación a partir de decisiones reales y excepciones relevantes, no solo de ejemplos ideales.

Un conjunto de evaluación es una colección versionada de casos que representa situaciones que el agente debe resolver. Cada caso debe incluir entrada, contexto disponible, herramientas permitidas, criterios de aprobación y, cuando corresponda, el estado esperado después de la ejecución.

Comience por cinco grupos:

1. Casos frecuentes: representan el volumen principal y protegen la eficiencia del proceso.
2. Casos críticos: tienen baja frecuencia, pero alto impacto financiero, jurídico o reputacional.
3. Casos ambiguos: requieren confirmación, búsqueda de contexto adicional o derivación humana.
4. Casos adversariales: incluyen instrucciones conflictivas, datos incompletos e intentos de inducir un uso indebido de herramientas.
5. Fallos de producción: todo incidente comprendido debe convertirse en un caso permanente de regresión.

Este último grupo es el más valioso. Transforma un fallo aislado en memoria operativa. Si un agente aplicó una política comercial desactualizada, el caso no debe desaparecer después de la corrección. Debe incorporarse a la suite que se ejecutará antes de los próximos cambios.

Evite pruebas que acepten cualquier texto “razonable”. En tareas transaccionales, el criterio debe alcanzar el estado final. Si el agente afirma que actualizó un registro, valide que el campo se haya modificado en el sistema correcto. Si dice que envió una propuesta, valide el destinatario, el documento y la regla comercial aplicada.

La investigación AlphaEval: Evaluating Agents in Production, de abril de 2026, refuerza esta diferencia al evaluar productos agénticos completos, y no solo modelos. El desempeño percibido depende del conjunto formado por modelo, instrucciones, herramientas, interfaz, permisos y entorno.

Qué métricas revelan si el agente está mejorando

La respuesta concreta es: combine métricas de negocio, calidad, riesgo y eficiencia. Una única tasa de acierto crea puntos ciegos.

La primera métrica debe reflejar la finalidad del flujo. Puede ser resolución en el primer contacto, tasa de conversión calificada, plazo de atención, recuperación de ingresos, reducción de retrabajo o cumplimiento documental. Esta es la métrica de resultado.

A continuación, siga métricas de calidad:

• tasa de finalización correcta;
• tasa de derivación humana adecuada;
• cumplimiento de políticas y reglas de negocio;
• uso correcto de fuentes y herramientas;
• recurrencia de fallos conocidos.

Incluya también métricas de riesgo. Mida acciones bloqueadas por guardrails, intentos de acceso fuera de alcance, cambios revertidos, casos con datos sensibles y decisiones que requirieron revisión posterior. Guardrail es una regla técnica o de proceso que limita acciones peligrosas, como aprobar descuentos por encima de un nivel de autorización o acceder a datos fuera de una finalidad autorizada.

Por último, siga la eficiencia: latencia de extremo a extremo, costo por tarea completada, número de llamadas a herramientas, número de intentos y tasa de abandono. Un agente que resuelve más casos, pero triplica su costo y su latencia, puede degradar el proceso en su conjunto.

No establezca una meta universal de “95% de acierto”. La tolerancia debe variar según la acción. Un agente que resume reuniones puede admitir una evaluación más subjetiva. Un agente que actualiza registros, libera pagos u orienta a clientes sobre contratos necesita criterios más estrictos, confirmación de estado y límites de autonomía.

Cómo evaluar respuestas subjetivas sin confiar ciegamente en otro modelo

La respuesta concreta es: use evaluadores automáticos para escalar, pero calíbrelos con revisión humana recurrente.

No toda tarea tiene una respuesta única. El tono, la claridad, la completitud, la utilidad y la adecuación al contexto son dimensiones subjetivas. En estos casos, un LLM como juez puede comparar la salida del agente con una rúbrica estructurada. La rúbrica debe indicar exactamente qué se evaluará, qué evidencias importan y qué condiciones desaprueban la respuesta.

Pero el evaluador también se equivoca. Puede privilegiar respuestas largas, confundir confianza con precisión o reproducir sesgos del propio modelo. Por eso, el juicio automatizado no debe tratarse como una verdad autónoma.

La práctica robusta tiene cuatro controles:

1. Use criterios específicos por tarea, en lugar de solicitar una evaluación genérica de calidad.
2. Separe la evaluación de contenido, seguridad y ejecución. Un único juez para todo reduce la capacidad de diagnóstico.
3. Realice muestreo humano periódico para comparar el veredicto automático con el juicio de especialistas.
4. Mida la discrepancia. Si los evaluadores humanos difieren entre sí, la regla de calidad sigue siendo vaga.

Anthropic informó, en un post-mortem de abril de 2026, que los problemas de calidad en productos agénticos fueron inicialmente difíciles de distinguir de la variación normal en el feedback de los usuarios y no se reprodujeron de inmediato en las evaluaciones internas. La lección es importante: las evaluaciones deben evolucionar cuando la producción revela señales que el laboratorio no capturó.

Cómo monitorear agentes sin convertir la observabilidad en ruido

La respuesta concreta es: monitoree por excepción, por cambio de distribución y por impacto de negocio.

Observabilidad es la capacidad de reconstruir qué hizo un sistema y por qué llegó a determinado resultado. Para los agentes, esto exige rastrear la versión del modelo, el prompt, el contexto recuperado, las llamadas a herramientas, los permisos, las salidas intermedias, el resultado final y el feedback posterior.

El error más común es guardar todas las trazas y no definir prioridades. Una operación madura necesita alertas asociadas a hipótesis de fallo. Ejemplos:

• aumento repentino de transferencias a atención humana;
• crecimiento de respuestas sin fuente en temas que exigen evidencia;
• uso de una herramienta fuera del patrón histórico;
• caída en la tasa de finalización después de un cambio de modelo;
• aumento de intentos por ejecución;
• discrepancia entre lo que el agente declara y el estado confirmado en el sistema.

También monitoree el drift, o desvío de comportamiento a lo largo del tiempo. Puede surgir por un cambio en el mix de solicitudes, una actualización de la base de conocimiento, una nueva versión de modelo, una integración modificada o el deterioro de una API externa. El agente puede seguir “funcionando” y, aun así, entregar peores resultados.

La observabilidad debe permitir la comparación entre versiones. Sin versionar prompt, política, herramienta y conjunto de datos, el equipo no puede atribuir una regresión a una causa probable. El objetivo no es acumular logs. Es reducir el tiempo entre detectar una anomalía, comprender su origen y aplicar una corrección segura.

Cuál es el ciclo operativo para corregir fallos sin crear nuevas regresiones

La respuesta concreta es: trate cada cambio como una hipótesis comprobable y avance mediante una liberación progresiva.

El ciclo comienza con una línea de base. Antes de optimizar, registre el desempeño actual por tipo de tarea, segmento de usuario, herramienta utilizada, costo, latencia y tasa de intervención humana. Sin línea de base, las mejoras son solo una impresión.

Luego, siga una cadencia disciplinada:

1. Clasifique el fallo

Determine si fue un fallo de comprensión, recuperación de contexto, política, herramienta, permiso, integración o experiencia. “El agente se equivocó” no es un diagnóstico útil.

2. Cree o actualice el caso de evaluación

Reproduzca el fallo con datos seguros. Defina el resultado correcto y las señales que demuestran la aprobación. El caso pasa a proteger la operación contra la recurrencia.

3. Cambie una variable a la vez cuando sea posible

Modificar prompt, modelo, herramienta y regla de forma simultánea dificulta la atribución causal. En flujos críticos, prefiera experimentos controlados.

4. Ejecute evaluaciones offline y pruebas de integración

La evaluación offline verifica el comportamiento en casos conocidos. La prueba de integración confirma que las herramientas, permisos y estados externos funcionan en un entorno realista.

5. Libere gradualmente

Use una porción limitada del tráfico, un alcance de acción reducido o una supervisión humana ampliada. La autonomía debe crecer junto con la evidencia de desempeño, no por confianza declarada.

6. Reevalúe el efecto en el proceso

Una mejora local puede empeorar la operación. Reducir las transferencias humanas, por ejemplo, es negativo si el agente comienza a resolver menos casos correctamente.

Este método acerca a los agentes a una disciplina ya conocida en sistemas críticos: la calidad es una propiedad que se verifica de forma continua. Para operaciones que orquestan múltiples etapas, plataformas como Centriu Flow pueden centralizar reglas, aprobaciones y puntos de control, pero la gobernanza sigue dependiendo de criterios claros de resultado y de un ciclo de evaluación activo.

Por dónde empezar en los próximos 30 días

La respuesta concreta es: elija un flujo delimitado, defina una métrica de resultado y construya una suite pequeña, pero representativa.

En la primera semana, mapee la decisión que toma el agente y el efecto esperado en el proceso. Identifique dónde una decisión incorrecta genera mayor costo. En la segunda, reúna de 30 a 50 casos reales, incluidos errores, excepciones y solicitudes ambiguas. En la tercera, implemente criterios automáticos para resultado, política, costo y latencia. Reserve la revisión humana para los casos subjetivos y de mayor impacto.

En la cuarta semana, ejecute la suite con cada cambio y establezca un ritual de análisis de los fallos de producción. No intente medirlo todo de una vez. El beneficio inicial proviene de hacer explícito lo que antes era implícito: qué decisión puede tomar el agente, bajo qué condiciones y cómo sabe la empresa que fue correcta.

Los agentes confiables no son los que parecen más autónomos. Son los que acumulan evidencia de que operan bien, reconocen sus límites y mejoran sin repetir los mismos errores.