El agente funciona. Lo has probado cien veces en local. Los tests de unit pasan, el dataset de evaluación devuelve puntuaciones decentes, el flujo end-to-end completa los pasos definidos sin errores. Lo despliegas. Y entonces, con usuarios reales, en regiones distintas, con cargas variables y datos que nadie había pensado en incluir en los fixtures, empieza a fallar de maneras que ningún test predijo.
Esto no es mala suerte. Es una consecuencia estructural de cómo la industria está aprendiendo —deprisa y mal— a testear sistemas que no se comportan como el software clásico. Un agente de IA no es una función determinista que devuelve el mismo output dado el mismo input. Es un sistema probabilístico acoplado a infraestructura externa, dependiente del contexto, sensible a la latencia y capaz de degradarse de formas sutiles que no levantan ninguna alerta en tu dashboard.
El problema no está en tus prompts. Está en lo que tu estrategia de testing decidió ignorar porque era difícil de medir.
La mayoría de los equipos testan el comportamiento del agente pero no la infraestructura sobre la que corre.
Los fallos más costosos en producción no son errores: son degradaciones silenciosas que el sistema no reporta como problema.
Hay una brecha sistemática entre el entorno donde se testa y el entorno donde se usa, y esa brecha es donde viven los bugs que más duelen.
Testing: Lo que mides y lo que ignoras
El repertorio estándar de testing para agentes de IA se ha consolidado con bastante rapidez alrededor de tres capas: unit tests sobre los esquemas de tool calling, datasets de evaluación para calificar outputs de prompts, y flujos end-to-end que verifican que el agente completa tareas predefinidas. Es una base razonable. El problema es que esas tres capas comparten un supuesto implícito devastador: que el entorno de ejecución es estable, uniforme y predecible.
En local, ese supuesto se cumple casi siempre. En producción, nunca del todo.
Cuando un agente llama a una herramienta externa —una API de terceros, un servicio de recuperación vectorial, un sistema de base de datos— el test local suele trabajar contra un mock o contra una instancia controlada con latencia cero y disponibilidad perfecta. Ese mock no simula timeouts reales, no reproduce variaciones de respuesta entre regiones de un proveedor cloud, no introduce los errores intermitentes que aparecen bajo carga sostenida. El agente aprende a operar en un mundo que no existe.
Testear un agente solo en local es como entrenar a un piloto exclusivamente en simulador de escritorio y mandarlo a cruzar el Atlántico. La mecánica básica es correcta. Todo lo demás es distinto.
Hay una segunda capa de invisibilidad que afecta especialmente a equipos que despliegan en múltiples mercados o con usuarios distribuidos geográficamente: la variabilidad regional de infraestructura. Un agente que funciona impecablemente con latencias de 80ms hacia un endpoint puede empezar a tomar decisiones erróneas cuando esa latencia sube a 400ms, no porque el modelo falle, sino porque el sistema de orquestación no está diseñado para manejar respuestas lentas de forma coherente. Nadie lo testó porque nadie introdujo esa variable en el entorno de pruebas.
El mapa de puntos ciegos habitual
En los proyectos que acompañamos, el inventario de lo que no se testa se parece mucho a este:
Degradación de herramientas externas: ¿Qué hace el agente cuando una API de la que depende responde con errores 429 intermitentes? ¿Reintenta bien? ¿Propaga el error al usuario o entra en un bucle silencioso?
Variabilidad del modelo en el tiempo: Los modelos que sirven los proveedores cloud no son fijos. Actualizaciones silenciosas, cambios en cuantización o ajustes internos pueden alterar comportamientos que tus evaluaciones antiguas no detectan porque no se re-ejecutan con suficiente frecuencia.
Contextos de usuario reales: Los datasets de evaluación se construyen con ejemplos limpios, bien formados, representativos del caso ideal. Los usuarios reales escriben de otra manera, interrumpen flujos a mitad, pasan datos en formatos inesperados.
Concurrencia y estado compartido: Muchos agentes en producción no se ejecutan en serie sino en paralelo, con múltiples usuarios activos simultáneamente. Las condiciones de carrera en sistemas con estado son casi imposibles de reproducir en tests unitarios.
Esto no es una lista de reproches. Es un mapa de trabajo. Cada punto ciego es una decisión de ingeniería pendiente, no un descuido moral del equipo.
Infraestructura: El layer que tus evaluaciones de prompts no alcanzan
Existe una tendencia comprensible —y peligrosa— a tratar los problemas de los agentes de IA como problemas de prompt. Si el agente falla, se ajusta el sistema prompt. Si los outputs son inconsistentes, se añaden instrucciones más precisas. Si el flujo se rompe, se reescribe la cadena de razonamiento.
Hay casos donde eso funciona. Pero hay una categoría entera de fallos que el prompt no puede resolver porque el origen está debajo del modelo: en la infraestructura que lo rodea.
Pensemos en un agente de soporte que consulta una base de conocimiento vectorial para recuperar contexto relevante antes de responder. El equipo ha optimizado exhaustivamente el prompt y las evaluaciones muestran que, dado el contexto correcto, el agente responde bien. Pero en producción, bajo carga, el servicio de recuperación empieza a devolver resultados con mayor latencia y, ocasionalmente, sets incompletos. El agente no recibe el contexto adecuado, pero tampoco recibe un error. Simplemente trabaja con información parcial y genera respuestas que suenan plausibles pero son incorrectas. Ninguna alerta se dispara. El sistema reporta disponibilidad del 100%.
Este patrón —fallo silencioso con apariencia de funcionamiento— es el más costoso en sistemas de agentes. No porque sea difícil de resolver una vez identificado, sino porque es extraordinariamente difícil de detectar. Ya escribimos sobre esta categoría de fallos al hablar de consistencia en sistemas de IA: el sistema no se rompe, simplemente deja de ser fiable de maneras que nadie está midiendo.
La validación de infraestructura como práctica sistemática implica ir más allá del "¿está el servicio respondiendo?" y preguntar "¿está respondiendo de la manera que el agente necesita, en las condiciones que el usuario real crea?". Eso requiere inyectar caos controlado, simular latencias variables, testear comportamientos de degradación parcial y —esto es crítico— hacerlo de forma continua en entornos que repliquen producción, no solo en el pipeline de CI antes del despliegue.
Environments: El abismo entre staging y producción
La brecha entre el entorno de staging y el entorno de producción es, en casi todos los equipos que vemos, mucho más grande de lo que nadie reconoce abiertamente. Staging suele tener menos tráfico, datos más limpios, servicios externos configurados de forma distinta y, en muchos casos, versiones de dependencias que ya no coinciden exactamente con producción.
Para el software clásico, esa brecha es gestionable. Para un agente de IA, puede ser la diferencia entre un sistema que funciona y uno que engaña al equipo durante semanas antes de que alguien conecte los puntos.
La solución no es perfecta paridad entre entornos —eso es una aspiración costosa y parcialmente imposible— sino una estrategia explícita de qué diferencias son aceptables y cuáles son riesgos activos. Documentar las divergencias conocidas entre staging y producción, y tener tests diseñados específicamente para ejercitar esas divergencias, es más honesto y más útil que fingir que los entornos son equivalentes.
Monitorización: Cuando los logs no dicen lo que necesitas saber
Asumir que los logs son suficientes para entender cómo se comporta un agente en producción es uno de los errores más comunes y más caros. Los logs capturan lo que el sistema decide registrar. No capturan lo que el sistema no sabe que está haciendo mal.
Un agente puede registrar que completó cada paso de un flujo con éxito —llamada a herramienta ejecutada, respuesta recibida, output generado— y aun así estar produciéndole una experiencia desastrosa al usuario porque la calidad de cada uno de esos pasos se ha degradado de formas que ningún log binario de éxito/fallo puede reflejar. Ya profundizamos en este problema desde el ángulo de la observabilidad en nuestro análisis sobre lo que los logs no te cuentan en sistemas de agentes.
Lo que se necesita no es más logging. Es una capa de evaluación continua en producción: métricas que midan la calidad de los outputs, no solo su presencia. Eso implica, en la práctica, tener alguna forma de evaluación automatizada —ya sea un modelo evaluador, heurísticas específicas del dominio o muestras revisadas manualmente— que opere sobre tráfico real de forma continua, no solo en el pipeline de pre-despliegue.
Esta práctica —llamada a veces "evals en producción" o simplemente monitorización de calidad— es todavía minoritaria en equipos que no tienen una madurez de MLOps consolidada. La mayoría confía en señales indirectas: métricas de satisfacción de usuario, tickets de soporte, NPS. Esas señales son demasiado tardías y demasiado ruidosas para detectar degradaciones sutiles antes de que hagan daño.
Si tu única señal de que el agente está fallando es que los usuarios se quejan, ya has perdido demasiado tiempo.
El diseño de la estrategia de monitorización debe hacerse antes del despliegue, no como reacción al primer incidente. Y debe incluir explícitamente qué constituye "degradación" para ese sistema concreto: no basta con definir el éxito en abstracto, hay que tener umbrales operativos que el equipo pueda accionar.
Madurez: De testear features a testear sistemas
El salto conceptual que necesitan dar la mayoría de los equipos que trabajan con agentes de IA en producción es dejar de pensar en el testing como una actividad que precede al despliegue y empezar a pensarlo como una práctica continua que acompaña al sistema durante toda su vida operativa.
Eso no es una metáfora nueva: es el principio que lleva años consolidado en ingeniería de sistemas distribuidos. Lo que cambia con los agentes de IA es que la superficie de comportamiento posible es mucho mayor —el espacio de inputs y outputs no está acotado de la misma manera que en una API clásica— y que los modos de fallo son cualitativamente distintos. Un agente puede fallar siendo educado, coherente y completamente equivocado al mismo tiempo. Eso no tiene equivalente en el software clásico.
La madurez en testing de agentes pasa por varias etapas que pocas organizaciones han completado. La primera —tests de comportamiento del modelo— ya la tienen casi todos. La segunda —validación de infraestructura y entornos— está ausente en la mayoría. La tercera —evaluación continua en producción— es todavía territorio de los equipos más avanzados. Y la cuarta, que es la que distingue a las organizaciones que realmente operan agentes en producción de las que simplemente los mantienen vivos, es la capacidad de aprender sistemáticamente de los fallos: crear mecanismos para que los incidentes de producción retroalimenten los datasets de evaluación y mejoren la cobertura de los tests futuros.
Esta última etapa cierra el bucle. Sin ella, el equipo está condenado a descubrir los mismos tipos de fallos una y otra vez, simplemente con variaciones distintas en cada ocasión.
Vale la pena recordar también que los agentes no se despliegan en el vacío. Viven sobre una base de arquitectura y decisiones de infraestructura que condicionan todo lo que viene después. Los equipos que tienen problemas crónicos con el testing de agentes suelen tener debajo un problema anterior: una arquitectura diseñada para escalar antes de entender, donde las decisiones se tomaron por inercia o por imitación, no por análisis de lo que el sistema realmente necesitaba.
Si tu agente pasa todos los tests y sigue fallando a tus usuarios, el problema no es tu agente. Es el marco en el que lo estás evaluando. En Room 714 trabajamos con equipos para construir ese marco desde cero o para auditar el que ya tienen: qué cubre, qué ignora, y cuánto está costando esa ignorancia en producción real. La conversación suele ser más corta de lo que los equipos esperan. Las consecuencias de no tenerla, no.
