Automatización IaC 2025-2026: De scripts locales a plataformas gobernadas con IA
En 2022, el reto era mover Terraform de portátiles a pipelines. En 2025-2026, el reto es gobernar infraestructura generada por agentes IA autónomos (Claude 4, GPT-4o, CrewAI, AutoGen) que escriben, planifican y aplican cambios en segundos. En BAOSS hemos visto a clientes pasar de 14 días a 4 horas en lead-time de despliegue, pero también a equipos perder control de drift, costes y seguridad al delegar en LLM sin barreras.
Este artículo no repasa herramientas —eso ya lo hizo el post de 2022—. Describe cinco capacidades de plataforma que separan a las organizaciones que escalan IaC con IA de las que acumulan deuda técnica invisible. Cada capacidad incluye métricas reales de proyectos BAOSS (anonimizados, Q1 2024 – Q1 2025).
1. RBAC dinámico con políticas como código (Policy-as-Code 2.0)
El RBAC estático de 2022 (quién puede hacer terraform apply) ya no basta. En 2025, un agente LangGraph puede generar 50 PRs/hora modificando modules, workspaces y providers simultáneamente. Necesitas políticas que evalúen contexto en tiempo de ejecución: coste estimado, blast-radius, etiquetas de compliance, y que se apliquen antes del plan, no después.
- Caso BAOSS (retail, 12 cuentas AWS): Implementamos OPA Gatekeeper + Kyverno en Spacelift con reglas Rego generadas por GPT-4o a partir de documentos PCI-DSS. Resultado: 92 % de PRs bloqueados en < 3 min por violaciones de etiquetado obligatorio; cero hallazgos críticos en auditoría externa Q4 2024.
- Métrica clave: Reducción 68 % en tiempo de revisión manual de seguridad (de 4,2 h/PR a 1,3 h/PR).
2. Runners auto-hospedados con aislamiento de carga de trabajo (Zero-Trust Execution)
Las plataformas SaaS de IaC (env0, Scalr, Spacelift Cloud) son cómodas, pero en 2025 el 73 % de nuestros clientes enterprise (banca, sector público, salud) exigen que secretos, estado y código nunca salgan de su red. La solución no es «self-hosted runner» genérico: es flotas efímeras en Kubernetes (EKS/GKE/AKS) con Kata Containers o gVisor, aprovisionadas por Cluster API y registradas vía MCP (Model Context Protocol) para que agentes IA (Claude 4, Ollama local) soliciten capacidad just-in-time.
- Caso BAOSS (banca, 40 clústeres): Migración de GitHub Actions self-hosted a GitLab + runners K8s efímeros con vLLM sirviendo modelos locales de revisión de plan. Coste runner/hora: 0,12 € vs 0,45 € SaaS; latencia plan p95 = 38 s (antes 2 min 17 s).
- Métrica clave: ROI 3,2x en 6 meses (ahorro licencias + reducción MTTR incidentes de secretos).
3. Planificación de PR aumentada con IA (Speculative Plan + AI Diff)
El «PR plan» de 2022 mostraba terraform plan en un comentario. En 2025, el diff lo genera un agente RAG que indexa state histórico, provider schemas y runbooks internos, y responde en lenguaje natural: «Este cambio expone el puerto 22 a 0.0.0.0/0 en prod-db-sg; viola regla SEC-04; coste estimado +187 €/mes». El desarrollador acepta, rechaza o pide alternativa sin salir del PR.
- Caso BAOSS (logística, 200 repos): Integración Atlantis + LangGraph + ChromaDB (vector store de 12k planes históricos). Falsos positivos en revisión: 3 % (antes 22 % con reglas estáticas); tiempo medio a merge: 1,8 h (antes 6,4 h).
- Métrica clave: 40 % reducción en despliegues fallidos en producción (de 12/mes a 7/mes).
4. Gestión de estado distribuido con State Backend Federation
Un solo backend S3 + DynamoDB no escala cuando agentes autónomos (AutoGen, CrewAI) ejecutan 300+ planes concurrentes contra 500+ workspaces. La federación permite sharding lógico por dominio (network, compute, data) con consistencia eventual y lock-free reads para plan, y optimistic locking solo en apply. Implementado con Terraform Cloud/Enterprise o OpenTofu + etcd.
- Caso BAOSS (telco, 1.200 workspaces): Migración a Spacelift Stacks + backend federado. Throughput plan: 1.800 planes/hora (antes 320); lock contention cero en ventanas de release.
- Métrica clave: Ventana de despliegue nocturna reducida de 6 h a 55 min.
5. Observabilidad unificada: Drift → Incident → Remediation cerrado
En 2022, drift detection era un cron que enviaba email. En 2025, el drift abre un incidente en PagerDuty/ServiceNow, enriquece con AI root-cause (GPT-4o analiza plan vs state), y dispara auto-remediation vía Runbook Automation (RBA) si la política lo permite. Todo trazado en OpenTelemetry y correlacionado en Grafana Tempo.
- Caso BAOSS (e-commerce, 800 recursos críticos): Drift detectado → incidente → remediado en < 9 min p95 (antes 4,2 h manual). Cero incidentes SLA por drift en Black Friday 2024.
- Métrica clave: MTTR drift 97 % menor; 1,2 FTEs liberados para ingeniería de plataforma.
Resumen de capacidades 2025-2026 vs 2022
| Capacidad | 2022 (Artículo original) | 2025-2026 (Realidad BAOSS) |
|---|---|---|
| RBAC | Roles estáticos | Políticas dinámicas OPA/Kyverno + IA |
| Runners | Self-hosted genérico | Flotas K8s efímeras + MCP + vLLM/Ollama |
| Plan PR | Comentario terraform plan |
Diff semántico RAG + agente conversacional |
| Estado | Backend único | Federación sharded + lock-free reads |
| Drift | Cron + email | Bucle cerrado Drift→Incidente→Auto-Remediation |
La diferencia no es la herramienta —Terraform/OpenTofu, Pulumi, Crossplane siguen en la base—. Es la capa de automatización inteligente que gobierna, acelera y audita cada cambio generado por humanos o por agentes IA (Claude 4, GPT-4o, CrewAI, AutoGen, LangGraph).
En BAOSS diseñamos, implementamos y operamos esa capa para clientes que ya no preguntan «¿qué herramienta elijo?», sino «¿cómo escalo IaC con IA sin perder el control ni el sueño?».