Generar confianza en los agentes de IA: un marco de evaluación listo para producción con Amazon Bedrock AgentCore

La estrella polar

Toda organización que corre para desplegar agentes de IA enfrenta la misma realidad: un agente que funciona de maravilla en las demostraciones puede degradarse silenciosamente en producción, y para cuando un humano lo nota, la confianza ya está rota. Mientras que el software tradicional falla de forma ruidosa, los agentes fallan de forma silenciosa. Devuelven una respuesta que parece segura, se lee con fluidez y es incorrecta. Cuando esa respuesta impulsa una decisión comercial real, el costo no es una función rota. Es una relación rota con el usuario.

Ese es el problema de calidad en esencia. El desafío, por lo tanto, no es construir agentes que funcionen una vez, sino demostrar que siguen funcionando, a escala, en cada subagente, cada flujo de trabajo y cada versión. Los equipos que triunfen en la era de los agentes serán aquellos que traten la calidad no como un paso final de QA, sino como el sistema operativo del propio agente: medida continuamente, defendida automáticamente y mejorada con cada interacción. En esta publicación, mostramos cómo construimos un ciclo de calidad continuo para soluciones agénticas listas para producción a escala utilizando Amazon Bedrock AgentCore.

Problema de negocio

La solución usa Amazon Bedrock AgentCore y otros servicios de AWS para uso interno, de modo que los vendedores y los líderes de ventas puedan hacer preguntas de negocios en inglés sencillo desde Amazon Quick. Detrás de esa única experiencia, varios subagentes especializados trabajan juntos: el Performance Insights Agent para ingresos y rendimiento por territorio, el Customer Insights Agent para inteligencia de clientes, el Data Insights Agent para text-to-SQL sobre conjuntos de datos fundamentales, y acceso directo a paneles. Las respuestas están delimitadas por el territorio de cada usuario y la seguridad a nivel de rol. Los equipos de campo usan estas respuestas para ayudar a planificar la estrategia de cuentas y prepararse para reuniones con clientes, por lo que las cifras deben ser correctas. La falla más dañina no es un bloqueo. Es una respuesta fluida y segura que está silenciosamente equivocada. Antes del lanzamiento, cuando evaluamos el Customer Insights Agent, encontramos exactamente eso:

• Informó 410.08 dólares de los ingresos de tres meses de un cliente en un servicio como «410.08 millones de dólares».
• Informó Sales Revenue etiquetado como Sales Revenue excluding Adjustments.
• Ofreció una estimación de Annual Recurring Revenue que no aparecía en ninguna parte de los datos.
• Presentó sus propios cálculos como hechos con fuentes.

A través de las diferentes ejecuciones, el monitoreo se mantuvo en verde. Nos decía que el sistema había respondido, no si la respuesta era correcta.

Si estos errores se hubieran enviado sin detectar, el campo habría pagado por ellos. Un vendedor que repite una cifra inflada puede perder credibilidad ante el cliente. Esto es exactamente por qué lo detectamos antes del lanzamiento. El riesgo no termina con el lanzamiento: crece con cada nuevo agente y cada cambio en los datos, los prompts, el código o los modelos. También crece sin ninguna versión, porque los flujos ascendentes actualizan los datos cada semana. Los lanzamientos coordinados introducen un riesgo relacionado: cuando un cambio de datos, un cambio de herramienta y una actualización de prompt emparejada deben enviarse juntos pero llegan por separado, el sistema ejecuta elementos que no coinciden hasta que todos los cambios se pongan al día. En una prueba de preproducción, esa ventana de discrepancia por sí sola hizo caer la tasa de aprobación de 78 percent a 38 percent. Para detectar fallas como estas, antes de cada versión y de forma continua en producción, necesitamos un marco que pueda mostrar si las respuestas están fundamentadas y son correctas, y rastrear cada falla hasta su causa raíz en los datos, el prompt o el código del agente.

En AWS, el equipo de Operaciones de Sales, Marketing, and Global Services (SMGS) desarrolló un sistema multiagente de producción que da servicio a AWS Field Sales en todo el mundo. Atiende a dos audiencias distintas. Para los equipos de ventas de campo, reemplaza horas de análisis manual de datos con inteligencia conversacional bajo demanda, ayudando a los vendedores a comprender la salud de su negocio, identificar riesgos y oportunidades, y actuar más rápido. Para el liderazgo, impulsa las cadencias de gestión empresarial, incluidas las Weekly Business Reviews (WBRs), revelando las señales que importan en toda la cartera sin requerir la preparación manual de informes. El mismo sistema agéntico sirve tanto al vendedor en primera línea como al líder que revisa el rendimiento a escala.

El sistema agéntico orquesta una cartera creciente de subagentes especializados, cada uno propietario de un dominio de capacidades distinto. Entre ellos: el Performance Insights Agent genera narrativas de inteligencia de negocios en lenguaje natural a partir de datos de ventas complejos, convirtiendo métricas en bruto en conocimientos accionables para los vendedores. El Customer Insights Agent construye una vista de 360 grados de cada cliente sintetizando señales a través del uso de productos, el historial de soporte, el estado del contrato y los datos de compromiso, ayudando a los vendedores a comprender en qué punto del recorrido se encuentra un cliente y qué necesita a continuación. El Data Insights Agent es un agente de text-to-SQL que los equipos de cuenta usan para consultar datos analíticos estructurados en inglés sencillo sin escribir una sola línea de SQL. Estos tres agentes son los que se mencionan a lo largo del resto de esta publicación.

Coordinar estos agentes de forma fiable a escala dejó clara una cosa: la calidad agéntica no era una preocupación operativa que gestionar más tarde. Era el prerrequisito para operar. Un único subagente degradado puede corromper silenciosamente cada respuesta aguas abajo, y el monitoreo tradicional no lo detectará. Esa realidad hizo que un marco de evaluación de ciclo de vida completo no fuera opcional sino necesario. AgentCore Evaluations, una capacidad de Amazon Bedrock AgentCore, es el tejido conectivo que lo impulsa, junto con Amazon Bedrock Guardrails (seguridad), Amazon CloudWatch (métricas, alarmas, rastreo), Amazon Simple Storage Service (Amazon S3) y Amazon Redshift (persistencia de evaluaciones), Amazon Quick (paneles) y AWS Lambda (evaluadores personalizados).

En esta publicación, compartimos cómo abordamos los desafíos operativos más difíciles al ejecutar agentes de IA a escala empresarial, y cómo Amazon Bedrock AgentCore Evaluations se convirtió en la columna vertebral de la calidad de los agentes. Específicamente, cubrimos:

• Los agentes juegan con reglas diferentes – Por qué los agentes exigen una disciplina operativa diferente, y por qué el monitoreo tradicional (latencia, tasas de error, tiempo de actividad) te deja ciego ante los fallos que más importan.
• Un mapa para todo el recorrido – El marco de evaluación de nueve etapas que construimos sobre AgentCore Evaluations, que cubre cada fase del ciclo de vida del desarrollo del agente desde el primer commit hasta la producción.
• De la teoría a la práctica – Patrones concretos (puertas de regresión de integración continua y entrega continua (CI/CD), puntuación canary, detección de deriva y bucles de retroalimentación automatizados) y exactamente cómo AgentCore Evaluations impulsa cada uno.
• Métricas que realmente importan – El impacto medible en la confianza de despliegue, la prevención de regresiones y la velocidad de iteración en todo nuestro portafolio de agentes.

Por qué los agentes necesitan un marco de evaluación estructurado

El software tradicional es determinista: la misma entrada produce la misma salida. Los modelos de aprendizaje automático (ML) introdujeron salidas probabilísticas, y MLOps surgió para gestionar su entrenamiento, versionado, monitoreo y reentrenamiento. Los agentes de IA añaden una tercera capa de complejidad operativa: razonamiento autónomo y multipaso, donde la pregunta cambia de «¿se rompió algo?» a «¿está el agente tomando decisiones acertadas a lo largo de toda su cadena de razonamiento?»

Los agentes heredan los problemas difíciles de ambos predecesores, e introducen algunos nuevos. Son no deterministas, siguiendo diferentes rutas de razonamiento para entradas idénticas. Toman decisiones en cascada en el enrutamiento, la selección de herramientas y la síntesis, donde un solo paso puede fallar silenciosamente y corromper todo lo que viene después. Lo más crítico es que se degradan silenciosamente: la latencia se mantiene baja, las tasas de error se mantienen estables, pero la calidad de la respuesta del agente se erosiona, porque el agente sigue respondiendo. Simplemente está respondiendo mal.

La evaluación de agentes es la práctica de detectar exactamente eso. Abarca cinco dimensiones: seguridad (¿se comporta dentro de los límites definidos?), calidad (¿está produciendo el agente respuestas correctas, coherentes y fundamentadas?), rendimiento (¿es lo suficientemente rápido y fiable?), costo (¿funciona de manera eficiente a escala?) y control operativo (¿podemos detectar, diagnosticar y remediar problemas rápidamente?). Una práctica de evaluación madura aborda las cinco de forma continua, a lo largo de todo el ciclo de vida del agente.

En esta publicación, compartimos cómo operacionalizamos las cinco dimensiones de evaluación en un sistema multiagente de producción. La seguridad es nuestra primera prioridad. Ningún agente se despliega, y ningún agente sigue ejecutándose, si no puede cumplir su umbral de seguridad. La calidad recibe el mayor espacio en esta publicación porque es la más difícil de lograr de las cinco y la que más se beneficia de un marco dedicado, pero no supera a la seguridad. El rendimiento, el costo y el control operativo están integrados en cada etapa del ciclo de vida junto con ambos. Fundamentalmente, este marco se aplica en todos los niveles de la jerarquía del agente. En el nivel de herramienta, cada capacidad (una herramienta de desambiguación de clientes, una herramienta de recuperación de grafos) tiene su propio contrato de evaluación. En el nivel de agente, cada subagente se evalúa de extremo a extremo. En el nivel multi-agente, se evalúan los caminos de orquestación en cuanto a coherencia, enrutamiento correcto y precisión de síntesis a través de los límites entre agentes.

Las nueve etapas se aplican en tres niveles simultáneamente, y esta jerarquía no es específica de este producto. Es el modelo mental correcto cuando construimos o integramos nuevos agentes de producción. La mayoría de los equipos empiezan evaluando a nivel de agente y se detienen ahí. Pero la calidad a nivel de agente depende de las herramientas de las que se apoya, y los sistemas multi-agente introducen una tercera superficie de fallo que ninguno de los dos niveles puede ver por sí solo. Una práctica de evaluación robusta cubre los tres, con cada nivel ejecutando su propio conjunto dorado, sus propios evaluadores y sus propios criterios de promoción a través de las nueve etapas.

El marco de evaluación de agentes: nueve etapas, un circuito cerrado

Estas nueve etapas trazan el ciclo de vida del agente desde el primer commit hasta la producción en vivo, y cada una responde a una pregunta que los equipos enfrentan a medida que sus agentes maduran.

El ciclo de vida del agente y las nueve preguntas comunes

Cada equipo que construye agentes de producción encuentra las siguientes preguntas a medida que su agente madura:

Etapa 1: La Fundación: “¿Qué aspecto tiene algo bueno?”

Etapa 2: El Experimento: “¿Qué versión es mejor?”

Etapa 3: La Fusión (CI): “¿Rompí algo?”

Etapa 4: La Compuerta (CD): “¿Es seguro para producción?”

Etapa 5: El Canary: “¿Se rompió algo silenciosamente?”

Etapa 6: El Adversario: “¿Qué pasa si alguien intenta romperlo?”

Etapa 7: La Deriva: “¿La calidad está derivando en producción?”

Etapa 8: El Pulso: “¿Cómo sabemos que funciona en este momento?”

Etapa 9: El Bucle de Retroalimentación: “¿Cómo mejora automáticamente?”

Construimos un único framework para cada etapa del ciclo de vida del agente usando AgentCore Evaluations. Las nueve etapas no son herramientas separadas cosidas después. Son nueve puntos sobre una única superficie de evaluación continua, impulsada por AgentCore Evaluations desde el primer commit hasta la respuesta en producción, como se muestra en Figura 1.

Figura 1: El recorrido de nueve etapas de AgentCore Evaluations, desde Define hasta Improve

Así abordamos cada una: el patrón que funciona, los servicios de AgentCore detrás de este, y cómo se ve en ejecución en producción, mostrado en el diseño del sistema en la Figura 2.

Figura 2: Diseño del sistema del framework de evaluación de AgentCore

Etapa 1: La Base. Definir calidad

La base de evaluar un agente no consiste en elegir las herramientas correctas. Consiste en hacer la pregunta correcta: ¿cómo se ve el éxito para este agente, y cómo sabemos cuándo está fallando? La respuesta debe venir del cliente, no del modelo. Este es un proceso iterativo. Nuestra definición de éxito se ha afinado a medida que observamos lo que el agente realmente hace en producción. Todo lo definido aquí (umbrales de fallo, pila de evaluadores, conjunto dorado, reglas de seguridad, presupuestos de latencia y objetivos de costo) es el contrato que cada etapa posterior hace cumplir. Si la Etapa 1 es vaga, cada puerta posterior es una adivinanza.

Etapa 1.1: Defina primero sus métricas de negocio. Comience preguntando qué debe entregar el agente. Las dos personas usuarias finales definen el éxito de manera diferente:

• Para los vendedores, el éxito significa entrar a una conversación con un cliente con inteligencia precisa y actualizada, al nivel de detalle correcto y en el momento adecuado.
• Para el liderazgo, el éxito significa insumos confiables para revisiones semanales y entre negocios sin una larga preparación manual. Estos son resultados de negocio, no propiedades del modelo.

Etapa 1.2: Traduzca esas métricas de negocio en métricas de evaluación. Para cada resultado, identifique la señal que confirma que el agente lo entregó. Cada señal se convierte en una métrica rastreada con un umbral explícito y una condición de alarma. La inteligencia precisa de cuentas se mapea a la precisión de resolución de entidades y la tasa de grounding. La confianza del vendedor se mapea a faithfulness y la tasa de alucinación. La acción del vendedor se mapea a helpfulness y la adherencia al alcance. La confiabilidad de la revisión del liderazgo se mapea a la tasa de aprobación de precisión y la cobertura de respuestas. Esta traducción debe cubrir cinco dimensiones: junto con umbrales de calidad, defina políticas de barreras de seguridad, establezca objetivos de latencia p50, p90 y p99 por herramienta y por agente, establezca presupuestos de costo por consulta, y defina los acuerdos de nivel de servicio (SLAs) que determinan cuándo se dispara una alarma y qué runbook activa.

Para la precisión específicamente, dado que la solución informa directamente decisiones de ingresos, estrategias de renovación y revisiones ejecutivas, el estándar es alto. Una respuesta incorrecta pero segura no solo desperdicia el tiempo de un vendedor. Lleva a una decisión incorrecta en un momento real de negocio. Definimos seis tipos de fallos derivados de errores reales de producción, cualquiera de los cuales marca una respuesta como inexacta:

• Intercambio de métrica: cliente y período correctos, métrica incorrecta devuelta. Se rastrea como ocurrencias por 100 respuestas.
• Período incorrecto: datos de una ventana de tiempo etiquetados como otra, por ejemplo una cifra interanual (YoY) presentada al vendedor como mensual (MoM), o al revés. Se rastrea como % que cita la ventana correcta.
• Entidad incorrecta: nombres de cuentas o subsidiarias confundidos. Se rastrea como precisión de resolución de entidades %.
• Alucinación pura: cifras sin fundamento y sin fuente rastreable. Se rastrea como tasa de grounding %.
• Símbolos incorrectos: métrica correcta, símbolo de moneda o unidad incorrecto. Se rastrea como tasa de adherencia al alcance %.
• Cálculo no autorizado: cifras derivadas no sancionadas que no están presentes en los datos de origen. Se rastrea como ocurrencias por 100 respuestas.

La tasa de aprobación de precisión general es la métrica principal. El rastreo por dimensión es lo que la hace accionable. Más allá de la precisión, también rastreamos Relevancia de la respuesta, Faithfulness, Helpfulness, Seguimiento de instrucciones,Precisión de selección de herramientas. Una respuesta correcta enterrada en tres párrafos, o que llega demasiado tarde, también ha fracasado para el vendedor.

Etapa 1.3: Construir una pila de evaluadores que refleje esas métricas. Ningún tipo de evaluador cubre por sí solo los diversos modos de fallo posibles. Combinamos cuatro tipos:

• Evaluadores integrados de AgentCore para una cobertura de referencia amplia. La relevancia, la fidelidad y la utilidad se corresponden directamente con plantillas de evaluación disponibles de forma nativa en AgentCore Evaluations.
• Evaluadores personalizados, uno por cada tipo de fallo en nuestra taxonomía: un evaluador de intercambio de métricas, un evaluador de período incorrecto, un evaluador de cliente incorrecto, un evaluador de alucinación pura, un evaluador de símbolos incorrectos y un evaluador de cálculo no autorizado. Ninguno de los seis está cubierto por las plantillas nativas. Son señales específicas del dominio que construimos sobre el framework AgentCore. Saber de antemano qué métricas ya cubre una plantilla nativa y cuáles requieren un evaluador personalizado es en sí mismo parte de la decisión de diseño.
• Evaluadores de terceros, desplegamos los evaluadores administrados de las bibliotecas open source de terceros DeepEval y AutoEval.
• Evaluadores deterministas para comprobaciones de ground truth donde la respuesta correcta se conoce exactamente, como ingresos, fecha de renovación y estado del contrato.

Donde la calidad del razonamiento y la utilidad no tienen una única respuesta correcta, usamos en cambio rúbricas de LLM-as-judge, con rúbricas integradas para relevancia, fidelidad y utilidad, además de soporte para rúbricas completamente personalizadas. AgentCore Evaluations proporciona de forma nativa tanto evaluación de ground truth como LLM-as-judge, lo que nos permitió poner en marcha ambas rutas de evaluación sin construir ningún motor de puntuación nosotros mismos. El enfoque determinista da precisión en los hechos. LLM-as-judge da amplitud en el razonamiento.

Etapa 1.4: Construir un golden set para ejercitar tus métricas de evaluación. A nivel de herramienta, cada herramienta crítica tiene sus propios pares deterministas de ground truth: la identificación del cliente debe resolver a la entidad canónica exacta o fallar. A nivel de agente, el análisis de temas sobre consultas reales de usuarios produce un conjunto de datos con cuatro tipos de preguntas (comprensivas, de generación de informes, de razonamiento y ambiguas), cada una de las cuales requiere una estrategia de evaluación diferente, revisada mensualmente. A nivel de multi-agente, los escenarios de orquestación de extremo a extremo detectan errores que solo surgen cuando los agentes interactúan. El golden set no es solo un conjunto de datos de calidad. También incluye casos de prueba de seguridad, casos de referencia de latencia y casos de referencia de costos, de modo que las Etapas 3 y 4 puedan verificar cinco dimensiones contra el mismo conjunto de datos curado.

El golden set es un documento vivo, construido a partir de tres fuentes. Los casos derivados de producción se muestrean de consultas reales de vendedores y liderazgo, incluidas las sesiones en vivo de baja puntuación promovidas en la Etapa 7. Los casos derivados de fallos provienen de cada regresión detectada en staging o producción, incluidos los casos centinela promovidos en la Etapa 3 y los guardianes de regresión permanentes promovidos en la Etapa 9. Los casos límite sintéticos se construyen deliberadamente para garantizar la cobertura de escenarios que sabemos que importan pero que no podemos esperar a encontrar en la naturaleza, como los cuatro tipos de preguntas anteriores y los casos de desambiguación matriz-filial y de símbolo bursátil en la Etapa 4. El conjunto está bajo control de versiones, se revisa y se extiende continuamente a partir de las tres fuentes.

Etapa 2: El Experimento. Saber qué versión gana

Cada cambio (una actualización de prompt, una nueva herramienta, una actualización de modelo, una actualización de conjunto de datos) plantea la misma pregunta: ¿esta versión es realmente mejor? En un sistema que sirve al campo de AWS a escala global, la intuición no es una respuesta aceptable.

Antes de que un cambio se fusione, ejecutamos una AgentCore On-Demand Evaluation, puntuada contra el mismo golden set con el mismo conjunto de evaluadores. El equipo de desarrollo usa las métricas de calidad, latencia, costo y tokens de contexto para curar comparaciones posteriores, que se evalúan a través de cinco dimensiones simultáneamente, como se muestra lado a lado en la Figura 3. Un modelo que mejora la precisión en un 5 por ciento pero duplica la latencia y triplica el costo no gana automáticamente.

Figura 3: Comparación lado a lado de dos respuestas candidatas de un agente en una AgentCore On-Demand Evaluation a lo largo de calidad, latencia y costo. Los números y valores de la figura son ilustrativos.

Seguimos la calidad como un cuadro de mando integral, no como un solo número. Una tasa de aprobación por sí sola no te dice lo suficiente. Cada ejecución de evaluación produce un desglose completo de todas las categorías de fallo de nuestra taxonomía: no solo si mejoró la calidad, sino dónde y por qué, tal como se captura en el cuadro de mando de la Figura 4. Cada evaluación también se registra por completo: las entradas, salidas, contexto recuperado, puntuaciones y razones de evaluación se almacenan en S3 y en nuestro data lake, lo que nos da una capa persistente de observabilidad para rastrear un fallo hasta su causa raíz: qué vio el agente, qué generó y por qué salió mal. Durante tres meses de iteración dirigida, este cuadro de mando llevó la tasa de aprobación del 93 por ciento a un estable 96 por ciento: las alucinaciones puras cayeron de 138 a menos de 52 por cada 10,000 respuestas, y los cálculos no autorizados bajaron de 59 a menos de 44, lo que confirmó que la recuperación era sólida y que las mejoras vinieron de correcciones en la generación. Sin el desglose por categoría y los datos de traza detallados que hay detrás, habríamos estado iterando a ciegas.

Figura 4: Cuadro de mando de evaluación con desglose de fallos por categoría y tendencia de la tasa de aprobación. Los números y valores de la figura son ilustrativos.

Etapa 3: La Fusión (CI). Prevenir regresiones en el momento de la fusión

La Etapa 3 es una compuerta de preproducción. Se ejecuta en el entorno de staging, activada por cambios de código y configuración, y su trabajo es bloquear un cambio defectuoso antes de que llegue a producción. Si la Etapa 3 detecta una regresión, nada se publica.

Los ingenieros o científicos cambian el sistema de muchas maneras: el prompt, los datos subyacentes, las herramientas o el modelo. El cambio se ve limpio localmente, las pruebas pasan, pero un prompt que mejora las respuestas para cuentas de tecnología podría degradar silenciosamente las respuestas para cuentas de servicios financieros. Sin una compuerta automatizada, esto se publica.

Nuestra evaluación de CI se activa automáticamente en cada despliegue a staging utilizando AgentCore On-Demand Evaluation. Los ingenieros no necesitan recordar ejecutar una evaluación. Ningún despliegue puede omitir silenciosamente la compuerta. La ejecución se completa en minutos porque evalúa solo el conjunto centinela, no el conjunto dorado completo. La velocidad es intencional: el centinela es lo suficientemente estrecho para ejecutarse en cada despliegue, pero lo suficientemente representativo para detectar los fallos que más importan.

El conjunto centinela es una selección curada de los escenarios de mayor riesgo en cinco dimensiones. Las regresiones de calidad que superan la tolerancia bloquean el despliegue. Una violación de un límite de seguridad bloquea con la misma firmeza. Un cambio que duplica la latencia p90 no procede sin una decisión deliberada. Los picos de coste de tokens se señalan antes de que se agraven a escala. Cada ejecución centinela publica sus puntuaciones en CloudWatch como métricas personalizadas; junto con las puntuaciones de calidad, la latencia, el coste por consulta y la tasa de aprobación de seguridad se emiten todos después de cada ejecución, y las alarmas de CloudWatch están configuradas para dispararse si alguna métrica incumple su umbral de Stage 1. Cada ejecución también se registra y almacena, alimentando la pista de auditoría de la que dependen Stage 8 y Stage 9. Mantenemos un centinela separado en cada nivel: herramienta, agente y multiagente. Un cambio que mejora la calidad a nivel de agente pero degrada una herramienta crítica también bloquea. El centinela se revisa mensualmente, y una regresión que se escapa a producción se promueve inmediatamente a un caso permanente para que no llegue dos veces a los usuarios.

Un ejemplo de lo que esto detecta. Después de una actualización de normalización de datos, una herramienta de desambiguación comenzó a devolver entidades no resueltas para un subconjunto de formatos de nombre de cuenta. El agente, al recibir una entidad no resuelta, respondía con una coincidencia de mejor suposición, devolviendo datos reales del cliente equivocado. Nuestro centinela a nivel de herramienta incluye exactamente esta clase de caso límite: la verificación de ground truth de resolución de entidades falló para los formatos de nombre de cuenta afectados, y el despliegue se bloqueó automáticamente. El cambio nunca llegó a producción.

Stage 4: La Compuerta (CD). Envíe con confianza cuantitativa

El centinela cubre 15 casos. Producción cubre decenas de miles de patrones de consulta a través de cientos de tipos de cuenta, geografías y segmentos de vendedores. Superar el centinela es necesario. No es suficiente.

Antes de que un candidato se envíe, ejecutamos una AgentCore On-Demand Evaluation contra el conjunto dorado completo en todas las dimensiones del evaluador. Llamamos a esto la Quality Gate. Reemplaza el «parece estar bien» con una decisión de envío cuantitativa.

Ejecución en sandbox y simulación de herramientas. Piense en ello como una repetición (replay), no una llamada en vivo. Con antelación, congelamos un conjunto de datos conocido y versionado del comportamiento correcto de las herramientas. Cada llamada a una herramienta que el candidato realice durante la compuerta se intercepta y se responde desde ese conjunto de datos congelado en lugar de un sistema real. Construimos ese conjunto de datos congelado en dos pasos. Primero, probamos cada herramienta por sí misma: le enviamos un conjunto de entradas retenidas de nuestro conjunto dorado donde la respuesta correcta ya se conoce, y puntuamos lo que realmente devuelve contra esa respuesta conocida. Esto nos indica si la herramienta en sí funciona (resolución de entidades, recuperación, generación de SQL) antes de que siquiera participe el agente. Segundo, después de confirmar que las respuestas de una herramienta son correctas, congelamos esas mismas respuestas validadas en el conjunto de datos de repetición que el agente ve durante la evaluación de la compuerta. Esto significa que el agente se prueba puramente en su propio razonamiento, no en la velocidad o disponibilidad de las herramientas en vivo, y como cada candidato repite desde el mismo conjunto de datos congelado, cualquier diferencia de puntuación cara a cara se debe al agente, no a la varianza de las herramientas.

Puntuación agregada de extremo a extremo. La compuerta también ejecuta una pasada holística: el agente candidato completo responde 200 preguntas retenidas de extremo a extremo, puntuadas por una rúbrica de LLM-as-judge en todas las dimensiones del evaluador. Cualquiera de tres condiciones cierra la compuerta automáticamente: la puntuación agregada retrocede respecto a la ejecución previa del propio candidato, no logra superar la línea base actual de producción, o más de un porcentaje definido de las 200 preguntas queda por debajo del umbral por pregunta. Un candidato debe superar las tres, lo cual detecta lo que un promedio simple puede ocultar: un modelo que mejora la media mientras falla silenciosamente una proporción mayor de preguntas individuales no pasa.

Un ejemplo de lo que esto detecta. Aquí es donde la simulación prueba el razonamiento propio del agente, no solo las herramientas que tiene debajo. Nuestro conjunto dorado incluye un caso de discrepancia de jerarquía: el Customer Insights Agent y el Data Insights Agent devuelven cifras de ingresos diferentes, cada una correcta por sí misma, para el mismo cliente, una delimitada a la cuenta principal y la otra a una filial. Ninguna de las dos cifras es errónea. El caso prueba si el agente infiere el alcance correcto de la semántica de la consulta y la persona del solicitante (un vendedor probablemente quiere la filial, mientras que una consulta de liderazgo probablemente quiere el agregado de la cuenta principal), en lugar de recurrir por defecto, promediar o pedir al vendedor que desambigüe. El candidato falló, devolviendo la cifra a nivel principal para una pregunta delimitada a la filial. El ground truth del conjunto dorado para este caso especifica qué alcance espera la pregunta, por lo que la Quality Gate señaló la discrepancia de inmediato: no era un número equivocado, sino el número correcto para el alcance equivocado.

Stage 5: El Canary. Detectar fallos silenciosos posteriores al despliegue

Stage 5 es un monitor de posproducción. Se ejecuta continuamente en el entorno de producción contra tráfico en vivo y casos de evaluación sintéticos, y su trabajo es detectar problemas que ningún cambio de código provocó y que Stage 3, por lo tanto, no vio. Stage 3 protege contra lo que los ingenieros cambian. Stage 5 protege contra todo lo demás, como cambios en datos aguas arriba, comportamiento evolutivo del modelo, cambios en dependencias de terceros, u otras condiciones como mayor latencia o patrones de tráfico cambiantes que solo se manifiestan bajo carga del mundo real.

El producto opera sobre un patrimonio de datos alimentado por miles de esquemas y canalizaciones de datos de origen. En un día determinado, docenas de esas canalizaciones se actualizan sin activar un despliegue ni una puerta de CI. El código del agente no cambia, el modelo no cambia, pero los datos sobre los que razona sí han cambiado, y la calidad puede degradarse silenciosamente como resultado. Lo aprendimos de la manera difícil: una canalización de origen se actualizó con un cambio de esquema, el agente comenzó a citar datos de la ventana temporal equivocada, y la primera señal llegó a través de una consulta de un vendedor en lugar de una alerta automatizada. La etapa 5 es cómo detectamos esto en la ventana de evaluación de 30 minutos.

Ejecutamos AgentCore Batch Evaluation en dos programaciones complementarias, y la elección de la cadencia fue deliberada.

Nos decidimos por ciclos de 30 minutos tras aprender en ambas direcciones: 15 minutos generaba demasiadas falsas alarmas; 60 minutos permitía que pasaran dos horas antes de que se registrara una degradación real. Llamamos a cada ciclo de 30 minutos una ventana de evaluación. Treinta minutos detecta una tendencia real dentro de 90 minutos (tres ventanas consecutivas) mientras filtra el ruido de consultas aisladas. Cada ventana puntúa una selección round-robin del conjunto dorado, logrando cobertura completa en 24 horas.

Los umbrales son deliberadamente más bajos que las puertas de CI/CD. Un fallo en una sola ventana es una señal operativa, no un incidente. Solo llamamos a on-call después de tres ventanas consecutivas que incumplan el umbral. Aprendimos esta regla de la manera difícil: el primer mes usamos un umbral de ventana única, y on-call dejó de confiar completamente en el sistema. Una vez al día, el conjunto dorado completo se ejecuta con umbrales de puerta como la tarjeta de puntuación diaria autoritativa. Las ventanas de 30 minutos revelan la tendencia. La ejecución diaria la confirma y crea un ticket.

Cada ejecución publica en CloudWatch (precisión, tasas de alucinación, tasa de anclaje, latencia y costo), con lógica de alarmas que distingue entre las dos cadencias. El canary se ejecuta en tres niveles: las puntuaciones a nivel de herramienta revelan una herramienta de recuperación degradada antes de que corrompa las respuestas a nivel de agente.

Otro ejemplo de lo que esto detecta. Después de una actualización de un índice de origen, una herramienta de recuperación comenzó a devolver fragmentos vagamente relevantes en lugar del contexto preciso necesario para responder la consulta. La latencia era nominal. La tasa de error era cero. El agente seguía produciendo respuestas fluidas y seguras razonando sobre un contexto débilmente anclado, generando respuestas que parecían correctas pero citaban cifras equivocadas. No se disparó ninguna alarma de infraestructura. El canary lo detectó en la primera ventana de 30 minutos: la tasa de anclaje y la precisión de recuperación cayeron en el centinela a nivel de herramienta, activando una alarma de CloudWatch antes de que los vendedores actuaran sobre las respuestas degradadas. La baja puntuación del evaluador señalizó el trace exacto responsable. A partir de ahí, el ingeniero de guardia abrió ese trace en AgentCore y rastreó el contexto degradado hasta la herramienta de recuperación en cuestión de minutos.

Etapa 6: El adversario. Proteger contra el uso indebido

No toda salida incorrecta proviene de un modelo degradado. Las consultas diseñadas para extraer datos de cuentas no autorizados y las inyecciones de instrucciones incrustadas en documentos recuperados son patrones predecibles en un sistema que sirve a miles de usuarios con datos comerciales sensibles.

La seguridad no es una etapa. Atraviesa las nueve etapas. Aplicamos Amazon Bedrock Guardrails en dos puntos de cada interacción. En la entrada, validamos el alcance de la consulta y filtramos inyecciones de instrucciones. En la salida, verificamos que no se expongan datos sensibles a usuarios no autorizados y que el agente no haya sido manipulado para violar una política. Estas comprobaciones se ejecutan sobre el 100 por ciento del tráfico, de forma síncrona, antes de que una respuesta llegue al usuario.

Configuramos dos capas de guardrails, cada una cubriendo una clase de amenaza distinta:

Los filtros de contenido detectan y bloquean contenido dañino o inapropiado tanto en las entradas como en las salidas. Aplicamos filtros en categorías que incluyen VIOLENCE, HATE, SEXUAL, MISCONDUCTy INSULTS. Una solicitud o respuesta que active estos filtros se bloquea antes de llegar al vendedor o de exponerse al usuario.

Los filtros de seguridad de instrucciones protegen al agente de la manipulación adversarial bajo una sola PROMPT_ATTACK categoría de guardrail, que cubre tres subtipos: JAILBREAK (intentos de anular las instrucciones del sistema del agente o eludir sus límites operativos), PROMPT_INJECTION (instrucciones no intencionadas incrustadas en documentos recuperados, salidas de herramientas o consultas de usuario), y PROMPT_LEAKAGE (intentos de extraer el prompt del sistema o la configuración interna). En un sistema multiagente que utiliza Generación Aumentada por Recuperación (RAG), la inyección de instrucciones a través del contenido recuperado es un riesgo real. Un documento no intencionado en los datos de la cuenta de un vendedor podría intentar redirigir el comportamiento del agente a mitad del razonamiento.

Las reglas de seguridad se definen en la etapa 1, se comprueban para detectar regresiones en las etapas 3 y 4, y se aplican de forma continua en producción.

Etapa 7: La deriva. Sostener la calidad y validar con tráfico real

La calidad se degrada desde múltiples direcciones: los datos de origen cambian sin activar un despliegue, los modelos envejecen, y los usuarios presionan los límites con consultas que ningún conjunto dorado anticipa por completo. La etapa 7 lo detecta antes que los vendedores, y valida a los candidatos contra tráfico real de usuarios antes del despliegue completo.

Detección de deriva. Usando AgentCore Online Evaluation, muestreamos el 10 por ciento del tráfico real de forma continua a través de los diferentes evaluadores definidos en la etapa 1, de modo que la deriva sea inmediatamente visible como una desviación de las líneas base establecidas sin conexión. Las puntuaciones alimentan una Quality-State Calculator que monitorea la calidad, la latencia y el costo en la misma ventana.

Un ejemplo de producción. Nuestro conjunto dorado para la identificación de clientes se construyó a partir de casos límite sintéticos: variaciones de nombres, búsquedas de filiales, abreviaturas. Funcionaba bien fuera de línea. Pero en tráfico en vivo, los vendedores consultaban con símbolos bursátiles (“¿qué pasa con AMZN?”), nombres abreviados y errores tipográficos que los casos sintéticos no ejercitaban. La Calculadora de Estado de Calidad detectó la deriva a lo largo de tres ventanas consecutivas de 30 minutos: 98 por ciento a la 1:30am, 81 por ciento a las 2:00am, 80 por ciento a las 2:30am. CloudWatch avisó al personal de guardia cuando se cruzó el umbral móvil. El ingeniero de guardia consultó al agente: “¿Qué pasó con la precisión de identificación de clientes entre la 1am y las 3am?” y recibió un resumen de tendencia que señalaba las búsquedas por símbolo bursátil y los nombres abreviados como causa del fallo. La traza del agente hizo que la causa raíz fuera visible de inmediato. La corrección: ampliar el conjunto dorado con las sesiones en vivo de baja puntuación, y actualizar la herramienta de desambiguación para normalizar los formatos de entrada antes de la resolución. La precisión se recuperó hasta el nivel base en el siguiente ciclo de evaluación.

El tráfico en vivo alimenta dos bucles de mejora continua: las sesiones de baja puntuación se promueven al conjunto dorado como nuevos casos límite, y los grupos de trazas de baja puntuación informan las revisiones de prompts, actualizaciones de herramientas y ajustes de enrutamiento.

Pruebas A/B: Después de que un candidato supera una puerta de calidad, AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, enruta una porción del tráfico real entre los agentes actuales y el candidato. Las pruebas bajo demanda confirman que no hay regresión en los casos conocidos. Las pruebas en línea confirman que se mantiene frente a las entradas de cola larga y las formulaciones novedosas que solo los usuarios reales producen. Un candidato debe ganar o empatar en todas las dimensiones del evaluador antes del despliegue completo.

Etapa 8: El Pulso. Visibilidad de calidad en tiempo real

Una sola llamada al agente puede tocar tres subagentes, cinco herramientas y dos rutas de recuperación. Cuando se dispara una alarma de calidad, “algo en el pipeline del agente” no es un runbook. La Etapa 8 es donde las señales de las Etapas 5, 6 y 7 convergen en una capa de observabilidad con suficiente resolución para actuar.

AgentCore Observability, una capacidad de Amazon Bedrock AgentCore, es la base. Para los agentes alojados en el runtime de AgentCore, una capacidad de Amazon Bedrock AgentCore, cada ejecución se instrumenta automáticamente mediante OpenTelemetry, emitiendo telemetría estructurada para cada paso de razonamiento: herramientas llamadas, orden, entradas y salidas, latencia y consumo de tokens, publicados directamente en CloudWatch como métricas y logs personalizados, después de habilitar CloudWatch Transaction Search (un paso de configuración único). Las puntuaciones de los evaluadores son un pipeline separado: provienen de configuraciones de evaluación, no de la instrumentación de ejecución, y llegan a su propio grupo de logs de CloudWatch. Cada ejecución de evaluación también persiste sus salidas completas en S3 y en nuestro data lake, alimentando dos paneles:

• Un panel conversacional para consultar los resultados de evaluación y observabilidad.
• Un panel de Amazon Quick para análisis de tendencias, seguimiento de tarjetas de puntuación y comparaciones entre agentes a lo largo de todo el historial.

Vistas apropiadas para cada rol se sitúan encima. Los ingenieros de guardia obtienen una vista centrada en trazas: un clic desde una alarma de CloudWatch hasta la traza de AgentCore Observability que la activó. La traza muestra cada herramienta llamada, en qué orden, con latencia por paso, consumo de tokens, costo y el contexto completo de razonamiento: todo lo necesario para pasar de “se disparó la alarma” a “causa raíz identificada” sin abrir una segunda herramienta, como se muestra en la Figura 5.

Figura 5: Traza de ejecución de AgentCore para el Customer Insights Agent, mostrando el árbol de spans, la trayectoria y las métricas a nivel de span. Los números y valores de la figura son ilustrativos.

Los gerentes de producto obtienen paneles de tendencias de Amazon Quick: puntuaciones de calidad por subagente y característica, de versión en versión. El liderazgo obtiene un resumen de salud de una sola página alineado con las revisiones semanales y entre negocios en las cinco dimensiones, una verificación rápida de un minuto que responde a “¿cómo se desempeñan nuestros agentes?”

La Figura 6 muestra la vista principal de nuestro panel semanal de evaluación: una tasa de aprobación combinada obtenida tanto de evaluadores personalizados como de los evaluadores integrados de AgentCore, junto con la latencia, para la ejecución de la semana. Los números y valores de la figura son ilustrativos.

Figura 6: Panel semanal de evaluación principal con tasa de aprobación combinada y latencia. Los números y valores de la figura son ilustrativos.

La Figura 7 profundiza en esa misma ejecución a nivel de evaluador personalizado y categoría de fallo, desglosando exactamente qué tipos de error (intercambios de métricas, alucinaciones, fallos de ID de cliente y otros) están impulsando la brecha y cuántas preguntas afecta cada uno. Los números y valores de la figura son ilustrativos.

Figura 7: Panel semanal de reporte de errores que desglosa los fallos por categoría. Los números y valores de la figura son ilustrativos.

Antes de la Etapa 8, el tiempo medio de detección (MTTD) era de días a semanas. Después de la Etapa 8, es de menos de cuatro horas, y la primera señal es una alarma de CloudWatch con una traza de AgentCore adjunta.

Etapa 9: El Bucle de Retroalimentación. Mejora continua

Esta etapa convierte las observaciones en acciones. El sistema compone calidad con el tiempo. Usamos AgentCore optimization, una capacidad de Amazon Bedrock AgentCore, para cerrar el bucle.

• Recomendación de system prompt: Analiza las trazas del agente y genera un system prompt optimizado basado en datos que mejora el desempeño en el evaluador objetivo. La solución usa patrones de fallo y agrega instrucciones conductuales específicas.
• Recomendación de descripciones de herramientas: Analiza las trazas del agente y genera descripciones de herramientas más precisas que reducen la confusión en la selección de herramientas. Particularmente cuando un agente selecciona la herramienta equivocada para solicitudes ambiguas.

Veamos un ejemplo:

AgentCore optimization en acción

Qué mejorar:
Evaluador objetivo: hallucination: el modelo reproduce valores predefinidos de ejemplos few-shot textualmente en contextos no relacionados.

Por qué ocurrió esto: Los ejemplos few-shot contienen cifras reales en dólares y nombres de clientes (por ejemplo, "$4.2M", "Acme Corp") que el modelo memoriza y filtra en consultas no relacionadas.

Cómo solucionarlo: Reemplazar los valores codificados en los ejemplos few-shot con marcadores de posición genéricos (por ejemplo, $[AMOUNT], [CUSTOMER_NAME]) para que el modelo aprenda la estructura de la respuesta sin memorizar puntos de datos específicos.

Impacto y resultado: Corrección aplicada. Las ocurrencias de pura alucinación disminuyeron de 138 a menos de 52 por cada 10,000 respuestas, y la tasa general de fundamentación mejoró del 93 por ciento al 96 por ciento.

La optimización de AgentCore usa recomendaciones para producir cambios en el system prompt y en las descripciones de herramientas basados en datos, a partir de trazas reales de agentes y un evaluador objetivo. AgentCore optimization se basa en AgentCore Evaluations . Las trazas con puntuación baja se promueven al conjunto dorado como protecciones permanentes contra regresiones, de modo que cada fallo no llegue a los usuarios dos veces.

Métricas clave de evaluación de agentes de un vistazo

Las métricas de evaluación se definen en la Etapa 1, se aplican en las nueve etapas y se monitorean continuamente en producción. Este conjunto no es estático. A medida que aprendemos del agente en producción, surgen nuevos patrones de fallo, se vuelven medibles nuevas dimensiones y las métricas evolucionan en consecuencia. A continuación se muestra por dónde empezamos y qué rastreamos hoy.

Conclusión

El impacto del marco de evaluación de agentes de nueve etapas fue concreto y medible. Las regresiones de calidad que antes tardaban días o semanas en manifestarse, y que generalmente llegaban a través de una queja de un vendedor, ahora se detectan en menos de cuatro horas mediante la evaluación automatizada. Las decisiones de despliegue que antes dependían de un juicio subjetivo ahora exigen que cada evaluador supere un umbral cuantitativo. Los ciclos de iteración de prompts pasaron de días a minutos. La seguridad pasó de auditorías periódicas a una cobertura de guardarraíles del 100 por ciento en cada solicitud. Las regresiones de latencia se detectan en la compuerta de CI antes de llegar a producción. Las sorpresas de costo que antes aparecían semanas después en la facturación ahora se evalúan en la Etapa dos y se aplican mediante la compuerta de calidad antes de que un cambio se publique. Y «algo en el pipeline del agente» pasó a estar a un solo clic de una alarma de CloudWatch hasta un rastro completo de ejecución del agente con cada paso de razonamiento visible.

La lección más amplia es una que la industria ya ha aprendido antes. DevOps nos enseñó que publicar código sin pruebas automatizadas es imprudente. MLOps nos enseñó que desplegar modelos sin monitoreo es peligroso. AgentOps nos enseña lo mismo sobre los agentes de IA: operarlos sin una evaluación continua y de múltiples niveles es volar a ciegas.

El marco de nueve etapas descrito aquí no es específico de los agentes de inteligencia de ventas. Los equipos que despliegan sistemas multiagente que razonan, invocan subagentes, herramientas y sintetizan respuestas enfrentarán estas mismas preguntas a lo largo del mismo ciclo de vida. Su taxonomía de fallos será diferente. Su conjunto dorado (golden set) reflejará su dominio. Su pila de evaluadores estará ajustada a sus usuarios. Lo que permanece constante es el principio: la evaluación no es un paso final de control de calidad. Es el sistema operativo del propio agente, medido continuamente, defendido automáticamente y mejorado con cada interacción.

Si está creando agentes de producción y desea incorporar este tipo de disciplina de evaluación a su sistema, Amazon Bedrock AgentCore Evaluations le ofrece la plataforma para hacerlo: evaluación bajo demanda para experimentos, evaluación por lotes para monitoreo continuo, evaluación en línea para tráfico en vivo, evaluadores integrados y personalizados, evaluación de conjuntos de datos (en vista previa pública), integración con CloudWatch y las funciones de optimización de AgentCore con recomendaciones y pruebas A/B para cerrar el ciclo de retroalimentación. Comience con la etapa uno, defina cómo es un buen rendimiento para su agente, y deje que el marco haga el resto.

¿Listo para empezar? Consulte Evaluación del rendimiento de los agentes en la documentación de Amazon Bedrock AgentCore. Y si está creando agentes de producción y desea conversar sobre cómo aplicar este marco a su sistema, estaremos encantados de ayudarle. Comuníquese con nosotros directamente o a través de su equipo de cuentas de AWS.

Para obtener más información sobre Amazon Bedrock AgentCore Evaluations, consulte Evaluación del rendimiento de los agentes en la documentación de AWS. Para una introducción técnica, lea Cree agentes de IA confiables con AgentCore Evaluations. Para ver cómo construimos el Performance Insights Agent, lea Cómo AWS SMGS utiliza un asistente conversacional con IA para transformar la gestión empresarial con Amazon Bedrock AgentCore. Para obtener información sobre las recomendaciones y la optimización de AgentCore, lea Optimización de AgentCore: Mejore el ciclo de calidad de los agentes con recomendaciones y pruebas A/B​

Reconocimiento

Extendemos nuestro sincero agradecimiento a nuestros patrocinadores ejecutivos y mentores, cuya visión y orientación hicieron posible esta iniciativa: Damien Forthomme, Manager III, Applied Science; Akhand Singh, Jefe de Ingeniería de Datos; Sujit Narapareddy, Director de AWS Insights; Monica Jain, Sr. Product Manager – Tech y Norman Braddock, Senior Manager de AI Product Management en AWS; Muhammad Umar Javed, Applied Scientist III, L6.

Sobre los autores