La mayoría de los equipos que construyen agentes de AI chocan con la misma pared: el modelo nunca fue la parte difícil. Un prototipo encadena tres llamadas a herramientas en una laptop. La versión en producción ejecuta miles de loops impredecibles, mantiene estado durante minutos u horas y llama APIs externas con credenciales reales. La infraestructura de AI agéntica es la capa que hace posible esa transición.
McKinsey pone la brecha en números. Cerca del 62% de las organizaciones está experimentando con agentes de AI o ejecutando pilotos. En cualquier función de negocio, no más del 10% de los encuestados dice que su organización los está escalando. La distancia entre esas dos cifras es sobre todo operativa, y ahí es donde se enfoca este artículo.
¿Qué es la infraestructura de AI agéntica?
La infraestructura de AI agéntica es el conjunto de capacidades de cómputo, orquestación, datos, seguridad y operaciones que se necesita para ejecutar agentes de AI como sistemas de producción.
La distinción que importa es de comportamiento. Un modelo predictivo recibe una entrada, devuelve una salida y se detiene. Un agente usa su propia salida para decidir el siguiente paso. Recibe un objetivo, toma contexto de memoria y de sistemas de retrieval, elige una acción, llama una herramienta o una API, lee el resultado y decide si continúa, escala o se detiene.
Ese loop cambia el contrato de infraestructura en tres formas fundamentales. Primero, una solicitud deja de ser una solicitud: es una sesión que puede abarcar muchas llamadas al modelo y muchos efectos secundarios externos. Segundo, la misma entrada produce caminos de ejecución distintos, así que planificar capacidad por costo promedio de solicitud deja de funcionar. Tercero, los agentes escriben en sistemas. Una inferencia fallida devuelve un string malo; una acción de agente fallida puede crear un registro, enviar un pago o borrar datos.
“Agéntico” aquí no significa totalmente autónomo. Los agentes en producción operan con autonomía acotada: alcances definidos, restricciones explícitas y umbrales donde el control vuelve a una persona. Mirantis describe toda la disciplina como un problema de infraestructura y no de modelo.
Infraestructura para agentes vs. infraestructura operada por agentes
El término tiene dos definiciones, y los proveedores rara vez aclaran cuál están usando.
Infraestructura para agentes. El stack que ejecuta cargas de trabajo de agentes: orquestación, inferencia, retrieval, herramientas, aislamiento y gobernanza. Es el sentido que usan Mirantis, Vercel y Fireblocks, y es el tema de este artículo.
Infraestructura operada por agentes. Agentes que aprovisionan y gestionan infraestructura por su cuenta, mediante infrastructure-as-code y APIs de plataforma. Pulumi reporta que los agentes ya realizan más del 20% de todas las operaciones en su plataforma, frente a casi cero un año antes.
Las dos convergen. Un agente que despliega infraestructura necesita credenciales acotadas, vista previa de los cambios y trazas de auditoría. Un agente que responde preguntas de clientes necesita los mismos controles antes de tocar un sistema de pedidos. La lectura de Pulumi aplica a ambos: un agente capaz sigue necesitando guardrails, trazas de auditoría y aplicación de políticas antes de que alguien le confíe producción.
Al leer material de proveedores, fíjate en qué definición están usando. Una herramienta que hace que los agentes escriban buen Terraform resuelve un problema distinto al de una plataforma que mantiene a un agente de cara al cliente dentro de su presupuesto.
¿Por qué los agentes de AI requieren una infraestructura diferente?
El modo de falla en la mayoría de los despliegues estancados no es la precisión del modelo. Es el sistema alrededor: orquestación, latencia de retrieval, observabilidad, aislamiento entre tenants, rollback, identidad y control de costos bajo carga sostenida.
Tres restricciones aparecen una y otra vez.
La demanda de inferencia se genera, no se solicita. Un solo objetivo de usuario puede expandirse en decenas de llamadas al modelo mientras el agente razona, reintenta y verifica. El volumen de entrada ya no predice el volumen de inferencia. Los loops de razonamiento sin límite son una fuente común de picos de costo inesperados, porque nada en el camino de la solicitud limita cuántas veces el agente decide volver a pensar.
El razonamiento es difícil de inspeccionar. El camino de decisión de un agente no se lee directamente como se lee un call stack. Cuando un agente toma una acción equivocada, el log suele mostrar la acción y no la cadena que la produjo. Las llamadas a herramientas que no emiten telemetría se vuelven puntos ciegos, y el análisis de causa raíz se detiene justo donde ocurrió el razonamiento.
Cada herramienta es una superficie de ataque. Cada capacidad que un agente puede invocar es también una forma de causar daño. El disparador puede ser una entrada comprometida, una instrucción mal leída o un permiso más amplio de lo que la tarea requería. El exceso de permisos es un riesgo práctico, no teórico. Tratar a los agentes como insiders digitales con privilegios acotados es un default más útil que tratarlos como servicios de confianza.
La presión de costos agrava las tres. McKinsey proyecta que los costos de infraestructura de TI se multiplicarán por dos o tres hacia 2030 mientras los presupuestos se mantienen planos.
Los diseños multiagente suman una cuarta restricción. Cuando los agentes llaman a otros agentes, tienes un sistema distribuido con los problemas de siempre: estado compartido, particiones de red, versiones incompatibles entre agentes y cadenas de dependencia que fallan en un orden poco obvio. La gestión de estado suele ser lo primero que se degrada a medida que sube la concurrencia. Los logs de comunicación entre agentes son, además, la telemetría que los equipos más olvidan capturar, lo que hace de los incidentes multiagente los más difíciles de reconstruir.
¿Cuáles son las capas de la infraestructura de AI agéntica?
El stack tiene ocho capas, y cada una responde a una pregunta operativa concreta:
1. Orquestación de agentes. Descompone un objetivo en tareas, gestiona dependencias y reintentos, y aplica gates de aprobación. Aquí viven los límites de loop y los umbrales de escalamiento.
2. Model serving e inferencia. Aloja los modelos que el agente llama, con batching, autoescalado y controles de costo. La latencia aquí se multiplica: una llamada de inferencia de 400 ms dentro de un loop de doce pasos son unos cinco segundos de demora visible para el usuario, antes de cualquier trabajo de herramientas.
3. Datos y retrieval. Bases de datos vectoriales, pipelines de RAG y conectores de streaming que aportan contexto. La latencia de retrieval está dentro del loop, así que se acumula igual que la inferencia.
4. Frameworks de herramientas e integración. API gateways, registries de herramientas y servidores Model Context Protocol (MCP). MCP se consolidó como la interfaz común para exponer herramientas a los agentes, lo que convierte al registry de herramientas en un punto de control gobernable en vez de código disperso en los clientes.
5. Entornos de ejecución. Donde corre el código del agente. Las cargas de agentes piden ejecución de larga duración, pausa y reanudación, y aislamiento lo bastante fuerte para contener código generado no confiable.
6. Seguridad y control de acceso. Identidad por agente, alcances de mínimo privilegio y políticas aplicadas por la infraestructura y no por las instrucciones del agente. Fireblocks deja explícito el punto de aplicación: cuando un agente intenta una acción fuera de su alcance permitido, la infraestructura la bloquea.
7. Observabilidad. Logging estructurado, tracing distribuido entre llamadas al modelo y a herramientas, y telemetría de costo por token. Sin trazas que cubran la cadena de razonamiento, depurar un agente es adivinar.
8. Gestión del ciclo de vida. Versionado, despliegue, rollback y dashboards de costo para los agentes y para los prompts, herramientas y modelos de los que dependen.
Las capas 1 a 4 determinan si el agente funciona. Las capas 5 a 8 determinan si sigue siendo confiable bajo carga de producción.
¿Cuáles son los beneficios de la infraestructura de AI agéntica?
Sacar estos controles del código de aplicación y llevarlos a la plataforma cambia a qué se pueden comprometer los equipos.
- Gasto predecible. Límites de loop, presupuestos de tokens y telemetría de costo por agente convierten la inferencia de una variable abierta en una línea de costo que puedes proyectar.
- Respuesta a incidentes más rápida. Trazas que cubren razonamiento, llamadas a herramientas y resultados reducen el tiempo hasta la causa raíz cuando un agente se comporta mal.
- Radio de impacto contenido. Alcances por agente y aislamiento de cargas hacen que un agente mal configurado no se convierta en un incidente de toda la organización.
- Reglas reutilizables. Una política definida una vez en la capa de infraestructura aplica a todos los agentes que el equipo despliegue, en lugar de reimplementarse proyecto por proyecto. McKinsey estima que la AI agéntica aplicada a operaciones de infraestructura puede automatizar entre 60 y 80% del trabajo rutinario, con una reducción de 20 a 40% en el costo recurrente en los primeros despliegues. Llegar ahí exige poner primero los controles de arriba. Los agentes que operan infraestructura necesitan los mismos guardrails que los agentes que operan cualquier otra cosa.
Infraestructura de AI agéntica vs. model serving tradicional
Los dos se confunden con frecuencia porque ambos implican desplegar modelos. Los perfiles operativos son muy distintos.
| Dimensión | Model serving tradicional | Infraestructura agéntica |
|---|---|---|
| Unidad de trabajo | Una solicitud, una respuesta | Una sesión con muchas llamadas |
| Duración | Milisegundos a segundos | Segundos a horas |
| Estado | Sin estado | Memoria de trabajo entre pasos |
| Modelo de costo | Predecible por solicitud | Variable por objetivo |
| Modo de falla | Salida incorrecta | Acción incorrecta con efectos secundarios |
| Necesidad de observabilidad | Latencia y tasa de error | Traza completa de razonamiento y llamadas a herramientas |
| Alcance de seguridad | Autenticación del endpoint | Identidad y permisos por agente |
Los supuestos del serverless tradicional no aguantan esta forma. Las funciones cortas y sin estado encajan bien con caching y manejo de solicitudes. Encajan mal con una sesión de agente de varios minutos. Vercel plantea el mismo argumento con datos de su propia plataforma y nombra cuatro requisitos que imponen las cargas de agentes: ejecución de larga duración, pausa y reanudación, ejecución de código en sandbox y estado que sobrevive entre solicitudes.
El cómputo con alcance de solicitud no va a desaparecer. La mayoría de las arquitecturas de agentes usa ambos: orquestación durable para el loop y ejecución rápida por solicitud para las llamadas a herramientas dentro de él.
¿Cuándo una aplicación no necesita infraestructura agéntica?
No toda funcionalidad de AI justifica el stack completo. Tres preguntas ayudan a decidir.
- ¿El modelo llama a algo? Una funcionalidad de prompt y respuesta, sin acceso a herramientas, es model serving. Despliégala como tal.
- ¿Una respuesta equivocada puede cambiar estado? Los asistentes de solo lectura fallan barato. En cuanto un agente puede escribir, los permisos por agente y las trazas de auditoría dejan de ser opcionales.
- ¿El número de llamadas al modelo por acción del usuario está acotado? Una cadena fija de dos pasos es predecible. Un loop abierto que decide su propia profundidad necesita controles de costo antes de llegar a producción. Si la respuesta es no a las tres, un endpoint de inferencia estándar alcanza. Si es sí a las dos últimas, las capas de gobernanza importan más que las de orquestación.
Ejemplo de infraestructura para agentes de AI en producción
El ejemplo de producción más claro viene de Axur, una empresa de ciberseguridad que monitorea riesgo digital para organizaciones en marketplaces globales y canales web.
La plataforma de Axur agrega 450 millones de sitios nuevos a su cola de verificación cada mes y los contrasta con modelos de AI entrenados para detectar phishing, productos falsificados y suplantación de marca. Antes de Azion, correr eso a escala significaba gestionar y pagar infraestructura dedicada: costo alto, mucho esfuerzo de ingeniería y un techo en la velocidad de respuesta de los modelos.
Pasar a Azion AI Inference cambió el modelo de costo. Axur reemplazó infraestructura gestionada fija por escala serverless: paga por lo que usa, el despliegue está automatizado de punta a punta y el equipo se enfoca en mejorar la detección de amenazas en vez de mantener servidores. El fine-tuning con LoRA le permite adaptar modelos base a su dominio sin reentrenar por completo.
El resultado: cinco minutos desde la detección hasta la solicitud de takedown, y más de 30.000 takedowns automatizados por mes. Según Fabio Ramos, CEO de Axur, hoy es el takedown automático más rápido del mercado.
Ese resultado es un agente de verificación continua en producción. Observa un flujo de datos, ejecuta inferencia sobre cada ítem y actúa: a velocidad de máquina, dentro de un alcance definido, sin humano en el loop hasta que hace falta escalar. La infraestructura que lo hace posible es exactamente la que describe este artículo.
Lee el caso de éxito completo.
Cómo Azion ofrece infraestructura para agentes de AI
Azion ejecuta la llamada al modelo y la lógica de aplicación sobre la misma arquitectura distribuida, lo que corta la acumulación de latencia descrita antes.
AI Inference ejecuta LLMs, VLMs, embeddings, reranking y modelos multimodales sobre una arquitectura distribuida con escala serverless, así los equipos suman capacidad de inferencia sin aprovisionar clusters de GPU. La API es compatible con OpenAI, lo que mantiene funcionando los frameworks y clientes de agentes existentes con un cambio de base URL y credenciales.
Functions ejecuta la lógica de herramientas del agente cerca de los usuarios y de la llamada de inferencia, en lugar de enviar cada paso de vuelta a una región centralizada.
SQL Database aporta búsqueda vectorial para la capa de retrieval, así el contexto de RAG se obtiene en la misma plataforma que sirve el modelo.
LoRA Fine-Tune adapta un modelo a un dominio sin reentrenamiento completo, que suele ser la diferencia entre un agente que lee tus documentos correctamente y uno que solo se aproxima a ellos.
Real-Time Events da visibilidad a nivel de solicitud para investigar qué hizo un agente.
En la capa de seguridad, WAF, Bot Manager y Network Shield aplican la misma inspección y los mismos controles de tasa que se usan para cualquier otro tráfico. Eso importa en los endpoints expuestos a agentes, porque el tráfico de agentes llega a velocidad de máquina.
Cómo empezar a operar agentes de AI en producción
La infraestructura de AI agéntica es la diferencia entre un agente que demuestra bien y uno que ejecuta un proceso de negocio sin supervisión. El modelo determina sobre qué puede razonar el agente. La infraestructura determina si se mantiene dentro de su alcance, dentro de su presupuesto y deja un rastro auditable.
Si estás empezando, ataca primero las capas que fallan más fuerte. Eso significa límites de loop y de costo en la orquestación, tracing que cubra razonamiento y llamadas a herramientas, y permisos por agente lo bastante estrechos para contener una decisión equivocada.
El próximo post de esta serie cubre la capa de ejecución en detalle: cómo correr infraestructura agéntica en producción, incluyendo economía de inferencia, manejo de estado y observabilidad de caminos de razonamiento.
Explora la documentación de AI Inference para ver cómo la inferencia distribuida encaja en una arquitectura de agentes.
