Motivos por los que los buenos agentes de inteligencia artificial fallan en producción: La capa de infraestructura que falta

Eran las 6:00 a.m. cuando se disparó la primera alerta. Luego, la segunda. Luego, la tercera.

La ingeniera de turno abrió su portátil y encontró tres fallos no relacionados de un solo agente de inteligencia artificial. El agente gestionaba los tickets de soporte, procesaba los ajustes de facturación y respondía a las preguntas de los clientes. Se ejecutaba en LangChain. Había superado todas las pruebas en la fase de preparación y funcionaba... hasta que dejó de hacerlo.

He visto a equipos dedicar meses a la ingeniería de peticiones (prompt engineering) y a la selección de modelos, solo para perder un fin de semana solucionando un incidente que no tenía nada que ver con ninguna de las dos cosas. Los fallos que siguieron no son hipotéticos. Son el tipo de cosas que suceden la primera vez que un agente llega a producción sin la infraestructura necesaria para respaldarlo adecuadamente. Y aún no he visto ningún marco que incluya esa infraestructura: los límites de identidad, la aplicación de la seguridad y el control operativo que exige la implementación en producción.

43 tickets de soporte duplicados

El agente (un sistema de inteligencia artificial que razona sobre los objetivos, selecciona herramientas y realiza acciones de varios pasos de forma autónoma) supervisaba una cola de soporte. Un cliente envió un caso. El agente llamó a la API de tickets para crear un registro, y la API aceptó la solicitud y creó el ticket. Pero luego se agotó el tiempo de espera de la respuesta.

Desde la perspectiva del agente, la llamada falló. LangChain hizo lo que cualquier marco bien diseñado hace ante una llamada a una herramienta fallida: volvió a intentarlo. El reintento creó un segundo ticket. Se agotó de nuevo el tiempo de espera de la respuesta. Otro reintento. Otro ticket.

A las 6:00 a.m. había 43 tickets duplicados en el sistema. Cada uno activó un correo electrónico de confirmación automático, lo que supuso 43 mensajes en las bandejas de entrada de los clientes. El equipo de soporte pasó la mañana cerrando duplicados manualmente y pidiendo disculpas en lugar de dedicarse a su trabajo real.

Quiero detallar con precisión qué falló aquí, porque es importante. LangChain gestionó esto correctamente. El marco detectó una respuesta fallida y reintentó la llamada. Eso es exactamente lo que la lógica de reintento está diseñada para hacer. El problema no fue el reintento, sino que ningún elemento de la infraestructura comprobó si la solicitud original se había completado con éxito. No había una cobertura de idempotencia (un mecanismo que garantiza que una solicitud repetida produzca el mismo resultado que la original, lo que evita duplicados). Sin capa de deduplicación. La plataforma no reconocía que se trataba de un reintento de una operación ya completada.

Para cualquier responsable de la toma de decisiones que haga cálculos: el coste no fue solo una mañana bochornosa. Fueron horas del personal de soporte dedicadas a solucionar el error, pérdida de la confianza de los clientes por los correos electrónicos automáticos duplicados y un sistema en el que no se podía confiar hasta que alguien auditara manualmente cada ticket abierto. Para cualquier desarrollador que lea la lógica de reintento, el código era correcto. La brecha estaba debajo.

El marco cumplió con su función. La infraestructura a su alrededor simplemente no existía.

4000 USD cargados a la cuenta incorrecta

Las brechas de infraestructura pueden ser ruidosas (tan ruidosas como 43 tickets), pero también pueden ser silenciosas. El mismo agente de inteligencia artificial procesaba los ajustes de facturación. Tenía acceso a una API de facturación aprovisionada con una cuenta de servicio durante la implementación. La cuenta de servicio podía acceder a múltiples cuentas de facturación porque era la forma más rápida de poner en funcionamiento el agente en desarrollo. Nadie limitó el alcance de las credenciales antes de pasar el agente a producción porque nadie había creado un límite de identidad: la capa de infraestructura que controla a qué recursos puede acceder una carga de trabajo determinada en función de la identidad verificada, no solo de la configuración.

El agente debía procesar un cargo en la cuenta A. En su petición, se incluía el identificador de la cuenta. El modelo seleccionó la cuenta B, un error plausible para cualquier modelo de lenguaje de gran tamaño (LLM). La API de facturación aceptó la llamada y se cobraron 4000 USD al cliente equivocado.

No fue un fallo del modelo. Los LLM generan resultados plausibles, pero a veces son erróneos. La causa probable fue la misma API de facturación con el parámetro de cuenta incorrecto: un error de selección plausible.

En el software tradicional, el impacto potencial de una llamada a la API mal dirigida está limitado por 2 capas: el alcance de las credenciales restringe los servicios a los que puede acceder una carga de trabajo y la API downstream valida qué parámetros son válidos para un emisor determinado. Ningún desarrollador lanzaría una aplicación web en la que un único conjunto de credenciales pudiera escribir en el registro de facturación de todos los clientes, pero eso es exactamente lo que ocurrió aquí.

El agente se había aprovisionado con credenciales lo suficientemente amplias como para acceder a cualquier cuenta del sistema, y ningún elemento del stack (ni la plataforma ni la API downstream) limitaba ese alcance. Actualmente, ningún marco incluye la delimitación del alcance de las credenciales. Ninguno proporciona una identidad de carga de trabajo criptográfica ni determina a qué servicios puede acceder un agente en función de las políticas de infraestructura, en lugar del contenido de la petición.

Nadie se dio cuenta hasta el lunes siguiente, cuando alguien revisó la factura. He visto variaciones de este fallo a todas las escalas: los detalles cambian, pero la causa principal siempre es la misma. El agente tenía credenciales que no debería haber tenido y ningún elemento del stack aplicaba ese límite.

Una política de reembolsos que la empresa nunca redactó

La falta de límites causó un error de 4000 USD esa noche, pero el tercer fallo costó algo más difícil de cuantificar. Un cliente preguntó al agente sobre el plazo de devolución para la compra de un producto. El modelo generó una respuesta clara y segura: la política de reembolsos permite devoluciones en un plazo de 90 días. La política real era de 30 días. La respuesta fue elocuente, útil y totalmente errónea.

LangChain envió el resultado del modelo al canal de respuesta orientado al cliente. Una vez más, el marco hizo exactamente lo que debía hacer: dirigir los resultados del modelo al siguiente paso de la cadena. No había ninguna medida de seguridad en el límite de inferencia (el punto en el que el resultado de un modelo entra en el mundo real, ya sea enviándolo a un cliente, escribiéndolo en una base de datos o usándolo para activar una acción). Ninguna capa de validación comparaba el resultado con la política documentada. Ningún mecanismo comprobaba si la respuesta del agente contradecía hechos conocidos antes de que llegara al cliente. El resultado pasó del modelo al cliente en línea recta, sin nada de por medio.

El cliente devolvió un producto de 280 USD el día 47 basándose en la respuesta del agente. El equipo aceptó la devolución. El costo no fue solo el reembolso en sí, sino la exposición legal: un agente de inteligencia artificial había hecho una declaración contractual no autorizada a un cliente y la empresa no disponía de un registro de auditoría que demostrase qué controles existían para evitarlo.

El error de facturación tiene un importe en dólares. Los tickets duplicados tienen un recuento. Una política inventada enviada a un cliente es más difícil de cuantificar y de controlar. Es una responsabilidad que se acumula: cada respuesta que el agente envía sin validación es otro posible compromiso contractual que tu equipo legal nunca aprobó. Toda empresa que utiliza un agente que se comunica con los clientes se enfrenta a este riesgo, y la mayoría lo hace sin saberlo.

El agente funcionaba bien

3 fallos en una sola noche de un agente que funcionaba a la perfección en desarrollo.

Observa el patrón. En todos los casos, el marco funcionó correctamente. LangChain organizó las llamadas a las herramientas, dirigió los resultados y reintentó en caso de fallos. El bucle del agente (razonamiento, planificación, llamada a herramientas, organización) funcionó según lo previsto.

Todos los fallos ocurrieron debido a la ausencia de infraestructura de producción. El primer fallo requería idempotencia y deduplicación a nivel de plataforma. El segundo requería un límite de identidad con credenciales de alcance definido e identidad criptográfica de carga de trabajo. El tercero requería medidas de seguridad en el límite de inferencia: validación de los resultados frente a los hechos documentados antes de que la respuesta llegara al cliente.

Estos aspectos no son responsabilidad del marco. La identidad, el control de herramientas (controlar a qué herramientas puede acceder un agente y en qué condiciones), la observabilidad (hacer un seguimiento de cada acción que realiza un agente para que puedas auditar y depurar) y la aplicación de la seguridad son responsabilidades de la plataforma, y ningún marco se diseñó para resolverlas.

He hablado con equipos que ejecutan agentes en LangChain, CrewAI, LangGraph y marcos personalizados. La elección del marco varía. La brecha no. Todos chocan con el mismo obstáculo: la distancia entre «funciona en desarrollo» y «se ejecuta en producción» no es un problema del marco, sino de infraestructura, y cuesta dinero real, confianza de los clientes y tiempo de ingeniería mientras siga sin resolverse.

Qué cierra la brecha

Ese problema de infraestructura tiene una forma específica. Los marcos de agentes resuelven el bucle del agente. Nunca se diseñaron para resolver la infraestructura de producción, ni deberían tener que hacerlo. No esperaría que un marco web incorporase su propia autoridad de certificación de Transport Layer Security (TLS). Son categorías de ingeniería diferentes.

Red Hat AI proporciona la infraestructura de producción que los marcos no ofrecen. Red Hat OpenShift AI actúa como base. El principio operativo es BYOA (Bring Your Own Agent o «trae tu propio agente»), donde la plataforma pone en funcionamiento el tiempo de ejecución de cualquier agente, ya sea LangChain, CrewAI, LangGraph o código personalizado, sin requerir cambios en el agente. Se preserva tu inversión en el marco. El código de tu agente no cambia. La plataforma inyecta las capas subyacentes de identidad, seguridad, gobernanza y observabilidad.

La brecha que ya tienes

El agente que falló a las 6:00 a.m. no era un mal agente. Era un buen agente que se ejecutaba sin una base debajo. Cada marco te proporciona el bucle de razonamiento, las llamadas a herramientas y la organización. Ninguno te ofrece la infraestructura que determina si es seguro ejecutar esas funciones en el mundo real. Esa distinción (entre lo que gestiona el marco y lo que debe gestionar la plataforma) es la brecha de producción. No es una brecha que tu marco se haya diseñado para cerrar.

Si tienes agentes en desarrollo ahora mismo, seguro que carecen de esa misma base. No porque los hayas creado mal, sino porque esa base no viene con el marco. En nuestro siguiente artículo presentamos las piezas específicas que componen esa base y lo que se necesita para implementarlas.

Primeros pasos

¿Quieres ver cómo es una infraestructura de agentes lista para producción? Empieza aquí:

• Prueba OpenShift AI gratis en Developer Sandbox: un entorno preconfigurado para experimentar con cargas de trabajo de inteligencia artificial
• Explora las demostraciones interactivas de Red Hat AI: introducciones prácticas a Red Hat AI
• Empieza con los kits de inicio para agentes BYO: plantillas preconfiguradas para LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK y más
• Lee la documentación de Red Hat AI: documentación completa de la plataforma
• Operacionalización de BYOA en Red Hat AI: La edición OpenClaw: un artículo práctico sobre la implementación de un agente real en la plataforma