Agentes de IA en producción: seis errores de arquitectura que les impiden llegar al lanzamiento

Habr ha publicado un análisis de seis errores de arquitectura que hacen fallar a los agentes de IA cuando pasan a producción real, aunque funcionen sin problemas en las demostraciones.

Qué se ve en la demo y qué ocurre en producción

En una demostración, un agente de IA parece fiable: llama a las herramientas adecuadas, compone la respuesta final e informa de que la tarea se completó con éxito. Esa imagen es la que con más frecuencia convence al equipo y al cliente de que la arquitectura está lista para su uso real, y el proyecto pasa a la fase de lanzamiento sin pruebas adicionales de robustez.

En un sistema real, las cosas son distintas. El autor enumera varios tipos de fallos que aparecen rápidamente tras el despliegue en producción y que casi nunca se manifiestan en los escenarios controlados de una demo:

• respuestas vacías del agente sin explicación de la causa del fallo
• bucles: el agente repite las mismas llamadas a herramientas sin avanzar hacia un resultado
• pérdida de contexto en sesiones largas y en cadenas de llamadas consecutivas
• restricciones de presupuesto: se superan los límites de tokens o el coste por solicitud
• problemas de permisos de acceso cuando el agente se conecta a sistemas externos y API

El análisis de Habr gira en torno a seis causas de arquitectura que provocan precisamente estos fallos: el escenario de prueba de una demo es deliberadamente estrecho y predecible, mientras que el comportamiento del sistema en explotación real no lo es.

Por qué una demo no garantiza estabilidad en producción?

Un escenario de demostración suele seguir un único camino conocido de antemano: un conjunto limitado de datos de entrada, un entorno limpio y ninguna solicitud concurrente de otros usuarios. Ese entorno oculta debilidades de arquitectura que solo se manifiestan con solicitudes de usuario variadas, diálogos prolongados y las limitaciones reales de la infraestructura: cuotas de API, tiempos de espera de servicios externos y permisos de acceso a datos sensibles.

Por eso, pasar del prototipo a producción resulta más complicado para los agentes de IA que para los servicios de software convencionales. El agente toma decisiones de forma dinámica en cada paso, y cualquier carencia en la gestión de errores o del estado no se manifiesta de inmediato, sino solo después de acumular cierto número de pasos, volumen de contexto o cantidad de sesiones paralelas. Un error imperceptible en una demostración breve de cinco pasos se vuelve sistémico ya en el paso cincuenta de un diálogo real con el usuario.

Qué piezas de la arquitectura conviene revisar primero

A juzgar por las categorías de fallos enumeradas, el análisis de Habr no se centra en la calidad del modelo en el que se basa el agente, sino en la ingeniería que lo rodea: cómo gestiona el sistema los errores de las herramientas, cómo limita el número de reintentos, cómo conserva y recorta el contexto, cómo contabiliza el presupuesto consumido y cómo verifica los permisos en cada llamada a una API externa. Son justamente los puntos que un escenario de demo no suele poner a prueba, porque la demostración dura unos minutos y sigue siempre el mismo camino preparado de antemano.

Para los equipos que preparan un agente para su lanzamiento, esto implica añadir una fase específica de pruebas de carga y de escenarios, distinta de la validación funcional habitual: hay que provocar deliberadamente respuestas vacías de servicios externos, diálogos largos con acumulación de contexto y situaciones de falta de permisos para ver cómo se comporta el agente fuera del happy path.

Qué significa esto

El artículo recuerda que el buen funcionamiento de un agente de IA en una demo no dice nada sobre su robustez en producción. Antes de desplegar un agente en un sistema real, conviene comprobar por separado la gestión de respuestas vacías, la protección contra bucles, la gestión del contexto en sesiones largas, los límites de presupuesto y los permisos de acceso: es decir, precisamente las piezas de la arquitectura donde, según las observaciones del autor, se producen los fallos con más frecuencia. Los equipos que se saltan esta fase se arriesgan a tener un agente que brilla en la presentación al cliente, pero que deja de funcionar ya en la primera semana de explotación real.