Las empresas continúan enfrentándose a un cuello de botella en la nube autónoma que impide operaciones completamente automáticas y provoca fallos. Esta limitación arquitectónica deja a los agentes de inteligencia artificial (IA) sin un contexto completo y multidominio que abarque la Infraestructura como Código (IaC), la topología de aplicaciones, la seguridad, los costes y las políticas, generando lo que se conoce como infraestructura en la sombra.
En env zero han identificado que el remedio no consiste en desarrollar modelos de IA más inteligentes, sino en implementar una capa de contexto compartido que conecte la intención declarada con lo que realmente se ejecuta en la nube. Para ello, combinan las capacidades de gestión de Infraestructura como Código con las funcionalidades de inventario y contexto en la nube de CloudQuery, una arquitectura integrada que ya está siendo adoptada por sus primeros clientes.
El siguiente paso en esta evolución es EZ Control, un bucle de control autónomo que correlaciona el estado declarado con el descubierto, recomienda o ejecuta correcciones bajo controles de políticas, y verifica que el cambio ha solucionado el problema inicial. Su lanzamiento general está previsto para finales de diciembre de 2026 y actualmente está en fase de acceso anticipado. 
Este bucle incluye reconciliar la intención de infraestructura con los recursos reales en la nube, asociar esos recursos con entornos y políticas, proponer cambios en el código, ejecutar verificaciones, aplicar o fusionar modificaciones, y realizar un nuevo escaneo para asegurarse de que se ha resuelto cualquier desviación o incidencia.
Los agentes de IA que consultan continuamente las APIs de la nube incrementan lo que se denomina “tasa API”, un coste adicional para la empresa que incluye la limitación de número de llamadas (rate limits), fallos en secuencias de consultas y posibles interrupciones en pipelines de Integración y Entrega Continuas (CI/CD) o autocontenimiento (autoscaling). Más allá del límite de consultas, este sondeo constante provoca elevados costes y retrasos que reducen la velocidad de respuesta de estos agentes y pueden ralentizar o frenar proyectos en la nube.
La incorporación de una capa de contexto permite optimizar las secuencias de consultas y eliminar llamadas redundantes, equilibrando información almacenada con consultas en tiempo real sólo cuando se requiere el estado actual exacto. Esto reduce significativamente la presión sobre las APIs y limita los riesgos operativos.
El estado de la infraestructura en la nube suele estar fragmentado entre archivos de estado, etiquetas, hojas de cálculo y el conocimiento tácito. La clave para la automatización inteligente de IA radica en unificar la intención declarada mediante IaC con la realidad detectada a través de herramientas de gestión de postura de seguridad en la nube (CSPM), algo que sólo es posible mediante una capa ontológica y un control continuo.
El ciclo completo abarca seis pasos: la intención declarada, el descubrimiento, la reconciliación, la verificación de políticas, la generación de solicitudes de extracción (pull requests) para revisión y ejecución, y un escaneo posterior para validar la corrección.
Inteligencia del modelo frente a contexto arquitectónico
En esta etapa temprana de sistemas de IA, es habitual culpar a los modelos por los cuellos de botella, alentados por el auge mediático del potencial de la IA. Sin embargo, la realidad apunta a que estos problemas son de arquitectura y que por mucho que se mejore la inteligencia del modelo, no se resolverán sin un diseño correcto del sistema.
Los equipos deben ser conscientes de que los agentes de IA y los pipelines CI/CD están acelerando los cambios en la infraestructura a una velocidad que supera la capacidad humana de adaptación. Mientras aumenta esta velocidad, las herramientas tradicionales muestran sólo fragmentos de IaC y pierden información sobre la topología de aplicaciones, gobernanza y costes asociados.
Por ejemplo, una herramienta de seguridad como Wiz puede imponer una política estricta de alta disponibilidad que exige múltiples instancias. Sin embargo, un agente de IA que sólo interpreta el IaC puede detectar una única instancia EC2 aislada y no percibir la infracción de la política. La adición de una capa de contexto integra IaC con aplicaciones, políticas y gobernanza, actuando como el cerebro central necesario para decisiones autónomas que eviten que los equipos tengan que intervenir constantemente para solucionar problemas.
Los grandes modelos de lenguaje (LLMs) sólo son tan efectivos como el contexto que reciben. Dado que las organizaciones manejan múltiples cuentas y herramientas en la nube, la conexión gobernada de estos elementos es fundamental.
La tasa API y las responsabilidades de las consultas en vivo
La capa de contexto no elimina las llamadas a las APIs cloud, pero modifica la frecuencia necesaria para realizar esas consultas. Combinan contexto sincronizado con consultas en vivo específicas, almacenando información relativamente estable, como propiedad, y reservando las consultas en tiempo real para estados que requieren precisión inmediata. Esto reduce el tráfico redundante y minimiza la probabilidad de alcanzar los límites impuestos por los proveedores cloud.
Este riesgo no afecta únicamente al agente, sino a toda la operativa. Por ejemplo, APIs operativas usadas repetidamente para inventarios pueden consumir capacidad crítica que otros procesos esenciales, como CI/CD o autoscaling, también necesitan. Esto puede provocar retrasos o riesgos operativos.
Un problema común es que los agentes exploran sistemas con múltiples consultas, frente a humanos que suelen plantear preguntas más directas. El CEO de env zero, Steve Corndell, señala un fallo frecuente: «Un agente puede completar 90 consultas, fallar en la número 91 y tener que reiniciar toda la secuencia, aumentando así la tasa API porque repite trabajo ya realizado.»
Transicionar a una capa de contexto permite alternar entre sincronizaciones de datos en caché y consultas selectivas en vivo, mitigando el riesgo de límite de tasa y garantizando continuidad operativa.
Estado declarado versus realidad en vivo
Las plataformas tradicionales de IaC y las herramientas CSPM suelen tener dificultad para cruzar la frontera entre la intención declarada y la realidad en ejecución. Una capa de contexto central que combine la intención IaC con el descubrimiento en tiempo real sistematiza la asignación de propiedad de recursos, contexto de políticas y límites de aplicaciones en entornos multiplataforma.
Según la experiencia con clientes, el estado de la infraestructura es el mayor contexto sin gobernar en la empresa. Mientras el código tiene Git, la identidad un IDP y el dinero un ERP, la infraestructura se apoya sólo en convenciones de etiquetado sin un único sistema controlador.
«El código tiene Git, la identidad tiene un IDP, el dinero tiene un ERP y la infraestructura sólo una convención de etiquetas», recuerdan en env zero. Si no puedes identificar a un responsable, no puedes aplicar políticas. La propiedad de la infraestructura suele ser oscura, dispersa en archivos, cambios manuales, etiquetas, APIs, hojas de cálculo y conocimiento tácito. Al reunir este contexto en un grafo de conocimiento, es posible automatizar el control dentro de límites seguros.
Arquitectura de un plano de control autónomo en la nube
El diseño de un plano de control autónomo consiste en un ciclo completo que abarca:
- Captura de la intención declarada
- Descubrimiento del estado real en la nube
- Reconciliación de recursos no codificados con conceptos unificados
- Aplicación de chequeos de políticas
- Propuesta de cambios mediante solicitudes de extracción para revisión
- Revisión posterior para validar la resolución y evitar desviaciones futuras
Al conectar la ingestión de datos de CloudQuery con una capa ontológica centralizada, se crea el motor de inteligencia que mueve la automatización y se integra con herramientas de ejecución como Terraform, OpenTofu o Pulumi.
Este enfoque amplía las funciones del plano de control autónomo más allá de la simple detección: debe entender la intención, descubrir el estado real, reconciliar, gobernar, remediar y verificar para ofrecer detección y corrección completas y automáticas.
Una herramienta que se limita a detectar deja la parte más compleja para los humanos. Por eso, en env zero valoran la categoría en función del tiempo hasta la remediación (TTR): el tiempo transcurrido desde que se identifica un problema en la infraestructura que requiere acción hasta que se confirma que la solución aplicada lo ha resuelto.
El ciclo integral que proponen va desde el descubrimiento y reconciliación, pasando por la política, la propuesta e implementación de cambios, hasta un escaneo final que confirma que la desviación o incidencia original ha desaparecido. Además, su plataforma sugiere automáticamente políticas preventivas para evitar que problemas similares vuelvan a ocurrir.
Incorporando una capa de control sin reemplazar IaC
Esta arquitectura plantea una forma de superar las limitaciones de los flujos tradicionales de IaC sin sustituirlos. CloudQuery, que se fusionó con env zero en marzo de 2026, integra datos de cuentas cloud y sistemas externos como Wiz, ServiceNow y Datadog; luego, una capa ontológica relaciona infraestructura, política, propiedad y contexto de aplicación.
Mientras CloudQuery obtiene y organiza los datos, env zero se encarga de la ejecución. Utilizan este contexto para impulsar automatización, gobernanza, autoservicio y cumplimiento en toda la infraestructura, sin necesidad de reemplazar herramientas IaC existentes como Terraform. Su plataforma se posiciona encima de la cadena de herramientas actual, conectando intención declarada con estado descubierto para proporcionar a los flujos autónomos el contexto necesario para decidir y actuar.
