La evaluación continua de agentes de IA en producción es el problema que AWS aborda en una guía técnica sobre Amazon Bedrock AgentCore. Su caso es un sistema interno al que vendedores y responsables comerciales hacen preguntas de negocio, y que falla como fallan casi todos los agentes: sin avisar. Responde con fluidez y seguridad, pero a veces se equivoca. Antes del lanzamiento, por ejemplo, convirtió 410,08 dólares en «410,08 millones». Para cualquier empresa que piense poner un agente delante de sus datos, ese detalle pesa más que el anuncio.
Qué ha publicado AWS y por qué la evaluación continua de agentes de IA importa
AWS describe cómo construyó un ciclo continuo de calidad para un agente que ya funciona en producción. El sistema es interno: vendedores y responsables comerciales le hacen preguntas de negocio desde Amazon Quick. Detrás hay varios sub-agentes especializados, y las respuestas están limitadas por territorio y por rol, de modo que cada persona recibe solo lo que le corresponde ver. No es un chatbot de demostración, sino una herramienta que se consulta para trabajar.
El argumento central es incómodo y conviene tomarlo en serio: los agentes fallan de forma silenciosa. Dan respuestas fluidas, bien redactadas y con tono seguro, pero erróneas. La monitorización básica, la que mide disponibilidad, latencia o errores de ejecución, solo indica que el sistema respondió. No dice si acertó. Un panel en verde puede convivir con un agente que da cifras equivocadas a un directivo comercial, y nadie se entera hasta que alguien toma una decisión con ese dato.
AWS ilustra el riesgo con dos fallos detectados antes del lanzamiento del Customer Insights Agent. El primero fue de formato y de escala: mostró 410,08 dólares de ingresos como «410,08 millones». El segundo fue más serio: ofreció una estimación de Annual Recurring Revenue que no aparecía en los datos. Es decir, presentó como información algo que el agente se había inventado. Ninguno de los dos errores habría saltado en una métrica de disponibilidad.
Implicaciones técnicas de la evaluación continua de agentes de IA en producción
El primer cambio de enfoque es que la calidad deja de ser una prueba previa al lanzamiento y pasa a ser un proceso permanente. Un agente no es una función determinista: depende de un modelo, de las instrucciones que recibe, de los datos a los que accede y, en este caso, de la coordinación entre varios sub-agentes. Cualquiera de esas piezas puede cambiar, y cada cambio puede alterar el comportamiento sin que ningún test clásico lo detecte. Por eso AWS habla de un ciclo, no de una validación puntual.
El segundo punto es la arquitectura. Con sub-agentes especializados, un error puede nacer en una pieza y manifestarse en la respuesta final de otra. Evaluar solo el resultado final dice que algo va mal, pero no dónde. Y las restricciones por territorio y rol añaden otra dimensión: no basta con que la respuesta sea correcta, tiene que ser correcta para ese perfil y limitarse a su ámbito. La evaluación debe cubrir ambas cosas.
Los dos errores del Customer Insights Agent marcan además dos categorías distintas. Una es el fallo de interpretación o presentación de un dato que sí existe, como la escala de una cifra. La otra es la invención de un dato que no existe, como el ARR. Cada una exige comprobaciones diferentes: contrastar el valor mostrado con el original en el primer caso, y verificar que la respuesta se apoya en datos recuperados en el segundo. Quien monte evaluación continua de agentes de IA debería definir de entrada qué tipos de fallo le preocupan, porque un único indicador de «calidad» global esconde justo estos casos.
AWS construye este ciclo sobre Amazon Bedrock AgentCore, la plataforma con la que opera el agente en producción. La guía interesa a quien ya trabaja en ese entorno, pero el planteamiento sirve como referencia general, con independencia del proveedor: medir lo que el agente dice, no solo que responde.
Cómo pueden aplicar esto las empresas hoy
Si ya tienes un agente en producción, o lo vas a lanzar pronto, la primera acción es sencilla: reúne un conjunto de preguntas reales de tus usuarios con la respuesta correcta conocida y pásalas por el agente cada vez que cambies algo. Incluye casos con cifras, porque los errores de escala y de unidades son baratos de detectar y caros de ignorar. Incluye también preguntas cuya respuesta no está en los datos, para comprobar que el agente reconoce que no lo sabe en lugar de rellenar el hueco.
Para el ROI, haz la cuenta al revés: cuánto cuesta que un comercial o un directivo use una cifra equivocada en una reunión o en una oferta. Si ese coste es mayor que el tiempo de preparar y mantener un conjunto de pruebas, la evaluación se paga sola. Y revisa algo que en una PYME se suele olvidar: si tu agente filtra respuestas por rol o departamento, incluye pruebas que verifiquen que cada perfil ve solo lo suyo.
Qué evitar: confiar en que el panel de monitorización básico te cubre. Mide disponibilidad, no acierto. Y evita lanzar un agente sin ninguna revisión humana de respuestas reales durante las primeras semanas. No hace falta la infraestructura de AWS para empezar; hace falta la disciplina de medir el contenido de las respuestas desde el primer día.
Análisis Blixel
Lo más valioso de esta guía no es la herramienta, sino que AWS admita por escrito que un agente puede estar mal aunque todo parezca ir bien. Es una confesión útil porque desmonta la idea de que lanzar un agente es el final del proyecto. Es el principio del trabajo de verdad.
Los dos ejemplos elegidos son reveladores. Una cifra con la escala equivocada y un dato inventado no son fallos exóticos: son lo que cualquier PYME encontrará en cuanto conecte un agente a sus datos de ventas. Y lo peor no es el error en sí, sino el tono. Un agente que se equivoca con aplomo es más peligroso que uno que duda, porque quien lo consulta no tiene motivos para desconfiar.
Mi posición es clara: la evaluación continua de agentes de IA debería ser un requisito de entrada, no un extra para cuando haya presupuesto. Si no puedes medir si tu agente acierta, no estás en condiciones de ponerlo delante de un comercial, y menos de un directivo. Muchas empresas piden primero la demo y dejan la medición para después, y es justo el orden contrario al que defiende este caso.
Con una salvedad: es un ejemplo de una gran compañía con un equipo y una plataforma propios. Una PYME no necesita replicar esa escala, pero sí su principio. Un cuaderno con cien preguntas y sus respuestas correctas, ejecutado tras cada cambio, ya es un primer ciclo de calidad. Lo caro no es medir, es descubrir el error por boca de un cliente.
¿Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido común. Hablemos.