Motivos por los que el marco de los agentes de inteligencia artificial no es suficiente: Siete funciones de la plataforma que faltan en producción

Tu agente funciona. Sé que es así. Lo creaste en LangChain, CrewAI o algo personalizado, lo probaste en escenarios reales y los gestionó. El problema no es el agente. El problema es todo lo que lo rodea.

En "Por qué los buenos agentes de inteligencia artificial fallan en producción: La capa de infraestructura faltante", 3 fallos afectaron una sola implementación de agente de inteligencia artificial de la noche a la mañana: 43 solicitudes de soporte duplicadas, USD 4000 cargados a la cuenta de facturación incorrecta y una política de reembolso alucinada que dio lugar a una devolución de USD 280 que la empresa tuvo que cumplir. Ese agente funcionaba perfectamente en el desarrollo, pero falló en producción porque la infraestructura de producción era insuficiente. La brecha entre un agente que funciona en desarrollo y una implementación lista para producción no es un problema del marco de trabajo, sino de la infraestructura.

Este artículo aborda esa brecha. Hablaré sobre:

• Siete funciones específicas que ningún marco ofrece actualmente
• Dónde se detiene tu marco
• Tres soluciones alternativas que suelen fallar
• Lo que realmente ayuda a cerrar la brecha sin pedirte que vuelvas a escribir tu agente

Siete cosas que tu marco no incluye

El incidente de las 6:00 a.m. expuso tres fallos. Sin embargo, esos tres fallos son síntomas de una falta de infraestructura más amplia. Cuando analizo los fallos de los agentes de producción en las empresas, siempre aparecen las mismas siete brechas.

1. Identidad criptográfica

La identidad criptográfica proporciona una prueba verificable de la carga de trabajo que realiza una solicitud, con atributos de identidad que determinan los servicios a los que puede acceder. El cargo de cuenta equivocada de USD 4000 se debió a que el agente se ejecutaba con credenciales amplias que nunca se acotaron para producción. Un modelo de lenguaje de gran tamaño (LLM) seleccionó el identificador de cuenta equivocado y no hubo nada en la infraestructura que lo detuviera. Con la identidad criptográfica, la plataforma limita los servicios a los que puede acceder el agente, y las API downstream configuradas correctamente imponen qué parámetros son válidos para un emisor determinado. Es posible que el modelo seleccione el identificador incorrecto, pero el impacto potencial es limitado: el daño se restringe a los recursos dentro del alcance autorizado del agente, no a todas las cuentas del sistema. Para los responsables de la toma de decisiones, esta es la diferencia entre "una cuenta se vio afectada" y "todas las cuentas quedaron expuestas".

2. Sandboxing de ejecución

El sandboxing de ejecución proporciona aislamiento a nivel de hardware y aplicación para que las cargas de trabajo comprometidas o con mal comportamiento no lleguen al sistema operativo host ni afecten a otras cargas de trabajo. Esto no es exclusivo de los agentes: todas las cargas de trabajo necesitan aislamiento, pero los agentes lo hacen urgente porque funcionan de manera autónoma, llaman a las API y ejecutan acciones de herramientas a la velocidad de la máquina. Sin sandboxing, el fallo de una carga de trabajo se convierte en el fallo de todas las cargas de trabajo en la misma máquina. Un agente que puede escribir en el sistema de archivos o abrir conexiones de red fuera de su alcance es un riesgo que el equipo de seguridad nunca aprobará para producción.

3. Gobernanza de herramientas

La gobernanza de herramientas es una política a nivel de infraestructura que determina a qué herramientas puede llamar un agente; se aplica en la capa de red para que ninguna inyección de peticiones (técnica donde una entrada maliciosa engaña al agente para realizar acciones no deseadas) pueda eludirla. He visto equipos que intentan imponer el acceso a las herramientas a través de la ingeniería de peticiones, pero no es suficiente. Un adversario determinado, o un modelo lo suficientemente creativo, elude las restricciones a nivel de petición. La gobernanza pertenece a la infraestructura, no a la petición.

4. Observabilidad y rastreo

La observabilidad y el rastreo incluyen seguimientos completos de la ejecución que registran cada petición, llamada a herramientas y resultado intermedio. Los tres fallos del incidente de las 6:00 a.m. no se detectaron hasta que los clientes y las facturas los sacaron a la luz. Con rastreos completos de la ejecución, cada fallo habría sido visible antes de que un cliente lo informara. Para los desarrolladores, esto significa depurar una interacción de agente de varios pasos de la misma manera que depuras una llamada de microservicio distribuido. Para la empresa, significa registros de auditoría que satisfacen a los revisores de cumplimiento.

5. Evaluación continua

La evaluación continua proporciona una puntuación en producción de los resultados de los agentes frente a las políticas y la realidad de los datos, de modo que las regresiones surjan antes de que los clientes las informen. La política de reembolso alucinada (donde el agente decía al cliente que el plazo de devolución era de 90 días en lugar de los 30 reales) llegó al cliente porque ninguna capa de evaluación comparó el resultado con la política real. Los conjuntos de pruebas estáticas detectan lo que anticipaste; la evaluación continua detecta lo que no.

6. Aplicación de medidas de seguridad

La aplicación de medidas de seguridad proporciona protecciones en el límite de la inferencia que interceptan los resultados antes de que lleguen a los clientes, bases de datos o agentes downstream. En el ejemplo en el que un agente falló tres veces en un día, el marco envió la respuesta inventada del modelo directamente al cliente sin ninguna verificación. La aplicación de medidas de seguridad convierte el límite de la inferencia en un punto de control, no en una vía de acceso libre.

7. Gestión del ciclo de vida

La gestión del ciclo de vida incluye implementar, actualizar, escalar y retirar agentes en una flota con una postura operativa y de seguridad uniforme. Un agente es un proyecto, pero 10 agentes en 3 equipos representan un desafío operativo. Sin la gestión del ciclo de vida, cada equipo inventa su propio proceso de implementación, su propio modelo de seguridad y su propia frecuencia de actualización. La coherencia desaparece.

Dónde se detiene tu marco

La coherencia en esas siete funciones es lo que exige la producción. Entonces, ¿en qué punto te dejan realmente los marcos que ya utilizas? LangChain y LangGraph ofrecen cadenas, agentes, llamadas a herramientas, resultados estructurados, orquestación basada en gráficos, memoria de sesión e integración de recuperación. La capacidad de composición es realmente sólida. CrewAI ofrece coordinación multiagente, diseño de agentes basado en roles, delegación de tareas y orquestación de equipos; los patrones multiagente están bien pensados. Google ADK se integra perfectamente con el ecosistema de Google. Claude Agents aportan profundidad de razonamiento. Strands (AWS) ofrece integración de flujos de trabajo nativos de AWS.

Cada marco destaca en el ciclo del agente: el ciclo de percibir, razonar y actuar que convierte a un agente en tal. Ninguno proporciona identidad criptográfica ni sandboxing de ejecución. La gobernanza de herramientas en la capa de red no existe. El rastreo distribuido de nivel de producción, la evaluación continua, la aplicación de medidas de seguridad en el límite de la inferencia y la gestión del ciclo de vida de la flota no existen en ninguno de ellos.

Esto no es una crítica, es simplemente una distinción de categoría. Los marcos son herramientas de la capa de aplicación, pero las siete funciones que mencioné corresponden a la capa de plataforma. Esperar que tu marco las incluya es como esperar que Django incluya Kubernetes: la orquestación de contenedores es infraestructura, no lógica de aplicación, y no sería razonable esperar que un marco web la incorpore. Lo mismo se aplica aquí. Las capas son simplemente diferentes.

Si has intentado implementar un agente de LangChain con la identidad, el rastreo y la gobernanza adecuados, ya habrás notado esto. Terminas escribiendo más código de integración de plataforma que código de agente. El agente era la parte fácil.

Tres enfoques que no escalan

Si el agente era la parte fácil, los equipos aún deben resolver la parte difícil. Todos los equipos con los que he hablado han probado al menos uno de estos enfoques antes de buscar una respuesta de plataforma.

Construirlo tú mismo. Los equipos escriben sus propios scripts de inyección de identidad, integración de rastreo e implementación. Para un solo agente, esto funciona. Incluso resulta satisfactorio porque entiendes cada pieza. Con 10 agentes en 3 equipos, cada equipo tiene su propio modelo de seguridad, su propio formato de rastreo y su propio proceso de implementación. No hay coherencia ni gobernanza, solo una carga de mantenimiento creciente que aleja a los ingenieros sénior de los propios agentes. He visto equipos dedicar más tiempo a mantener su plataforma de creación propia que a desarrollar capacidades para los agentes.

Plataformas de agentes alojadas como Salesforce Agentforce, AWS Bedrock Agents o Azure AI Agent Service eliminan la brecha de producción al ser propietarios de todo el stack. La desventaja es que también controlan la ruta de los datos. Cada prompt, cada llamada a herramientas y cada artefacto de razonamiento se enruta a través de un servicio de terceros. En industrias reguladas, donde los datos no deben salir de tu red, esto es inviable. Y cuando la plataforma cambia los precios o retira una función, tus agentes deben cambiar con ella.

Las extensiones especificas del marco ofrecen complementos orientados a producción dentro de un único ecosistema; LangSmith para el rastreo es un buen ejemplo y es realmente útil. Pero una organización que ejecuta LangChain, CrewAI y agentes personalizados ahora necesita tres estrategias de producción independientes. Eso significa tres formatos de rastreo, tres modelos de seguridad y tres conjuntos de herramientas que los equipos deben aprender. La infraestructura de producción debe ser independiente del marco de trabajo, no otro elemento bloqueado en el ecosistema de un solo proveedor.

Cada enfoque resuelve una parte del problema mientras introduce una nueva restricción. El primero no escala. El segundo cambia soberanía por conveniencia. El tercero fragmenta la estrategia de producción entre los límites de los marcos.

Tu agente, la plataforma de Red Hat

La restricción que comparten todos los enfoques es la suposición de que la infraestructura de producción debe provenir del mismo lugar que el marco del agente o construirse desde cero. Creo que esa suposición es errónea. BYOA (trae tu propio agente): el enfoque de Red Hat AI donde la plataforma proporciona infraestructura de producción para cualquier marco de agentes sin cambios en el código, parte de la premisa opuesta.

Red Hat no compite en la capa del marco. Ya sea que tu agente se ejecute en LangChain, CrewAI, Claude Agents, Google ADK, Strands o Python personalizado, Red Hat AI lo operacionaliza. El código de agente que tu equipo escribió en desarrollo es el mismo que se ejecuta en producción. La identidad, el sandboxing, la gobernanza de herramientas, el rastreo, la evaluación y la gestión del ciclo de vida los incorpora la plataforma, no el desarrollador del agente. Y la infraestructura de producción es coherente en todos los marcos de la organización.

Para los responsables de la toma de decisiones, esto significa que la inversión de la organización en el marco elegido no se pierde. Los equipos no tienen que elegir entre su marco preferido y una infraestructura de producción que cumpla con las restricciones normativas; obtienen ambos. La plataforma lleva la infraestructura de producción al marco, no al revés.

BYOA también es el cambio de alquilar infraestructura de inteligencia artificial a poseerla. Red Hat identifica cuatro pilares de la soberanía digital: soberanía de datos, soberanía tecnológica, soberanía operativa y soberanía de garantía. La plataforma BYOA aborda los cuatro, de los cuales hablaremos en próximos artículos.

La misma infraestructura de plataforma que impulsa a un agente autónomo de ingeniería de confiabilidad del sitio (SRE) puede dar soporte a un asistente de incorporación de recursos humanos (RR. HH.), un flujo de trabajo de aprobación de compras o un bot de derivación de atención al cliente; la infraestructura es independiente del dominio incluso cuando los casos de uso difieren.

Red Hat ofrece kits de inicio para LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK y más, con la integración de la plataforma ya configurada: autenticación, conexión al protocolo de Contexto de Modelos (MCP) e inicialización del rastreo. Los equipos comienzan a construir desde el día 0, no después de semanas de trabajo de integración.

La decisión que ya sabes tomar

Día 0 en lugar de semanas: ese planteamiento debería resultarte familiar. Hace una década, las organizaciones se enfrentaron a la misma pregunta con los contenedores: cada equipo podía crear un contenedor, pero nadie podía ejecutar contenedores en producción con seguridad, redes y gestión del ciclo de vida coherentes en toda la organización. La respuesta no fue "elegir un mejor tiempo de ejecución de contenedores", la respuesta fue Red Hat OpenShift: una plataforma que operacionalizó cualquier tiempo de ejecución de contenedores con la infraestructura que estos no incluían. Lo que estamos analizando aquí suena familiar porque Red Hat AI se ejecuta sobre ello.

La brecha de los agentes tiene la misma forma. La pregunta no es "qué marco debería usar". Ya has tomado esa decisión y probablemente fue la correcta. La pregunta es "quién proporciona la infraestructura de producción que mi marco no incluye", y la primera brecha que hay que cerrar es aquella donde la distancia entre desarrollo y producción es mayor. Eso es la seguridad, y nuestro próximo artículo continúa ahí.

Primeros pasos

¿Todo listo para cerrar la brecha de producción de tus agentes?

• Prueba OpenShift AI gratis en el Developer Sandbox: crea y prueba agentes en un entorno preconfigurado sin costo alguno.
• Explora los kits de inicio para agentes BYO: Plantillas preconfiguradas para LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK y más.
• Realiza el curso gratuito Red Hat AI Foundations: Laboratorios prácticos que cubren los fundamentos de la creación sobre Red Hat AI.
• Más información sobre Red Hat AI: Descripción general de la plataforma y capacidades de la infraestructura de producción.
• Operacionalización de BYOA en Red Hat AI: La edición OpenClaw: Mira el BYOA en la práctica con el despliegue de un agente real.