Evaluación de agentes de IA en producción: el día que el agente de AWS confundió $410 con $410 millones

Un agente de IA reportó $410,08 de ingresos de un cliente como «$410,08 millones». El monitoreo seguía en verde. Ese error, descubierto antes del lanzamiento, es el origen de uno de los marcos de evaluación de agentes de IA en producción más detallados que ha publicado un gran proveedor: el que el equipo de Operaciones de Ventas, Marketing y Servicios Globales (SMGS) de AWS construyó sobre Amazon Bedrock AgentCore.

El equipo opera un sistema multiagente que da servicio a la fuerza de ventas de AWS en todo el mundo. Los vendedores hacen preguntas de negocio en lenguaje natural desde Amazon Quick. Detrás hay varios subagentes especializados: uno de rendimiento (Performance Insights), uno de inteligencia de clientes (Customer Insights) y uno de texto a SQL (Data Insights). Las respuestas se limitan al territorio y al rol de cada usuario, y se usan para preparar reuniones y planificar cuentas, así que los números tienen que ser correctos. Antes del lanzamiento, el agente de clientes cometió cuatro fallos: inflió una cifra por un millón, etiquetó mal una métrica de ventas, ofreció una estimación de ingresos recurrentes anuales que no existía en los datos y presentó cálculos propios como hechos con fuente. Los paneles de latencia y errores no detectaron nada, porque el sistema había respondido, aunque mal.

El equipo describe también un riesgo más sutil. Cuando un cambio de datos, uno de herramientas y una actualización de prompt debían salir juntos pero llegaron por separado, la tasa de aciertos en una prueba preproducción cayó del 78% al 38%. Los datos, además, se refrescan cada semana sin que haya ningún despliegue. La conclusión de AWS es que la calidad de los agentes no es una tarea de QA final, sino el «sistema operativo» del agente: se mide de forma continua y cada fallo debe poder rastrearse hasta su causa, sea el dato, el prompt o el código.

El marco tiene nueve etapas que cubren desde el primer commit hasta producción. Usa AgentCore Evaluations como eje, junto con Bedrock Guardrails, CloudWatch, S3, Redshift, Amazon Quick y funciones Lambda para evaluadores personalizados. AWS destaca patrones como compuertas de regresión en CI/CD, puntuación en despliegues canario, detección de deriva y ciclos de retroalimentación automáticos. Una reseña de n1n.ai detalla varias etapas: validación estática de prompts y esquemas, pruebas con conjuntos de datos de referencia, auditorías de fundamentación semántica, validación de razonamiento multipaso, chequeos de ejecución de herramientas, perfilado de latencia y costo, red teaming adversarial y despliegues canario con pruebas en sombra. Conviene leer esa fuente con cautela, ya que n1n.ai promociona sus propios endpoints de LLM. Y como señala Techseen, se trata de un marco publicado por el propio proveedor, sin validación independiente.

Cómo aplicar la evaluación de agentes de IA en tu empresa

No necesitas ser AWS ni usar AgentCore para llevarte las lecciones. El caso demuestra que el éxito de un piloto no prueba nada sobre su comportamiento en producción. Estos son los pasos prácticos:

Mide la corrección, no solo la disponibilidad. Latencia, uptime y tasa de errores no ven una respuesta fluida pero falsa. Define métricas de fundamentación: ¿el dato citado existe en la fuente?, ¿la unidad es correcta?, ¿la métrica etiquetada es la que se consultó?

Construye un conjunto de casos de referencia con tus errores reales. El fallo de «$410,08 millones» debería convertirse en un test permanente. Cada incidente alimenta la suite.

Bloquea los despliegues con compuertas de regresión. Si la tasa de aciertos cae por debajo de un umbral, el cambio no sale. El caso del 78% al 38% muestra que hay que probar los cambios acoplados (datos, herramientas y prompts) como una sola versión.

Evalúa también sin despliegues. Si tus datos se actualizan cada semana, programa evaluaciones continuas sobre tráfico real o muestreado para detectar deriva.

Instrumenta cada subagente. En un sistema multiagente, un componente degradado contamina todo lo que viene después. Necesitas trazabilidad para saber si el culpable es el enrutamiento, la herramienta o la síntesis final. Si estás diseñando algo así, las lecciones de Spotify sobre arquitectura multiagente ofrecen un contrapunto útil.

Cuándo invertir en evaluación continua de agentes

La respuesta de AWS es contundente: antes del primer usuario real. Si las respuestas influyen en decisiones comerciales, de cumplimiento o de relación con el cliente, la evaluación es un requisito previo y no una mejora posterior. El costo de no hacerlo se mide en credibilidad: un vendedor que repite una cifra inflada pierde la confianza del cliente.

Otros casos van en la misma dirección. Elastic pasó del caos de tests aislados a un único framework de evaluación tras casi dos años en producción. Y un retailer redujo las alucinaciones del 15% al 1,5% sin cambiar de modelo, lo que sugiere que buena parte de la mejora viene de la disciplina de medición y no del modelo.

Una salvedad: AWS no publicó, en la parte del texto disponible, cifras de ahorro ni retorno de inversión, aunque promete medir el impacto en confianza de despliegue, prevención de regresiones y velocidad de iteración. Lo que sí queda claro es el tipo de error que esta práctica evita.

La pregunta para tu equipo no es si tus agentes funcionan en la demo, sino qué pasaría si dejaran de acertar el martes y nadie lo supiera hasta el viernes. Si no tienes una respuesta, la evaluación de agentes de IA en producción debería ser la próxima prioridad de tu hoja de ruta.