Aprovisionar un ambiente por consola es rápido la primera vez y caro para siempre después. Nadie recuerda quién abrió aquel puerto, por qué la base de datos quedó en otra subred, ni qué cambia exactamente si el ambiente tiene que levantarse de nuevo en otra región. Terraform resuelve eso al convertir la infraestructura en código versionado. Y los asistentes de IA cambiaron la economía de esa escritura: lo que era un mes de módulos y refactorización pasó a ser una semana de conversación técnica con revisión.

En este artículo mostramos qué acelera realmente la IA en infraestructura como código, qué sigue sin hacer sola, el método en cinco pasos que usamos en campo y los guardarraíles que no negociamos. El telón de fondo es concreto: levantamos la infraestructura de nube de una aseguradora brasileña con Terraform asistido por IA, y aplicamos la misma lógica al parque de estaciones Windows con un framework propio de Intune as Code.

Por qué la IaC dejó de ser opcional

Tres exigencias mataron el aprovisionamiento manual. La primera es la reproducibilidad: si producción y homologación no nacen del mismo código, la prueba no demuestra nada. La segunda es la auditabilidad — en sectores regulados, «quién cambió qué y cuándo» necesita respuesta, y el historial del repositorio es la respuesta más barata que existe. La tercera es la reversibilidad: un ambiente descrito en código vuelve al estado anterior con un revert, no con memoria y suerte.

Además, hay un efecto colateral que nadie anticipa: el código se convierte en la documentación. Cuando alguien pregunta cómo está diseñada la red, la respuesta no es una planilla desactualizada: es el archivo. Por eso tratamos la IaC como parte de la disciplina de infraestructura, y no como una preferencia del equipo de desarrollo.

Lo que la IA cambia de verdad

Aparecen cuatro ganancias de forma consistente. Ninguna de ellas es «la IA lo hizo sola».

• Generación de módulos. Describir «VPC con tres zonas, subredes pública y privada, NAT gateway y etiquetas de centro de costo» y recibir el módulo estructurado ahorra el trabajo mecánico. La mayor ganancia no es la digitación: es que la IA ya entrega variables, outputs y un README que un humano dejaría para después.
• Revisión del plan. Un terraform plan de un cambio grande arroja cientos de líneas. Pedirle a un asistente que resuma qué será destruido, qué cambia de nombre y qué fuerza recreación convierte la lectura del diff en una conversación. Es aquí donde la IA detecta el replace silencioso de una base de datos que nadie había visto.
• Detección de drift. Alguien siempre toca la consola en una madrugada de incidente. Pasar la salida de plan -refresh-only a análisis separa rápido el drift inofensivo (una etiqueta) del drift peligroso (una regla de security group abierta).
• Documentación viva. Diagramas, tablas de recursos y notas de cambio generados a partir del código real. La documentación que nace del estado actual no envejece de la misma manera.

Lo que la IA no hace sola

No conoce su topología de red, ni los bloques de IP ya reservados, ni el contrato con el proveedor. Tampoco sabe qué base de datos tiene datos de producción y cuál es descartable — y un asistente confiado propone destroy con la misma naturalidad con que propone create. Además, se equivoca en atributos de provider que cambiaron de versión, generando código que parece correcto y falla en el validate.

El método en cinco pasos

1. Inventariar antes de escribir. Relevar lo que ya existe e importarlo al state, en lugar de recrear por encima. Un recurso huérfano fuera de Terraform es deuda garantizada.
2. Definir el esqueleto a mano. Convención de nombres, etiquetas obligatorias, estructura de carpetas y separación de ambientes. Ese contrato es corto y humano — y es justamente lo que hace que la IA genere código coherente después.
3. Generar por módulo, no por ambiente entero. Red, cómputo, base de datos, identidad, observabilidad. Cada módulo con validate, lint y plan limpio antes de pasar al siguiente.
4. Revisar el plan con IA y con gente. La IA resume y plantea la hipótesis; el ingeniero decide. Toda línea de destroy o force replacement necesita una justificación explícita.
5. Cerrar el ciclo con pipeline. plan automático en el pull request, apply solo después de la aprobación y verificación periódica de drift. Sin eso, el repositorio se vuelve ficción en tres meses.

Guardarraíles innegociables

• State remoto con lock. El state en la máquina de alguien es un accidente esperando ocurrir. Backend remoto, versionado, cifrado y con locking — dos apply simultáneos corrompen el estado.
• Secretos fuera del código. Contraseñas, llaves y tokens viven en una bóveda gestionada, referenciados por identidad. Conviene recordar: una variable marcada como sensible no deja de aparecer en el archivo de state.
• Revisión humana del plan. Ningún apply automático en producción. El plan aprobado es el que corre, y la aprobación queda registrada.
• Policy as code. Reglas que frenan el pipeline: bucket público, puerto 22 abierto al mundo, recurso sin etiqueta de centro de costo, región fuera de la permitida. Una política que depende de que alguien recuerde no es política — y, sin etiqueta de costo, el trabajo de FinOps empieza a ciegas.
• Menor privilegio para el pipeline. La credencial que aplica infraestructura es la más poderosa del ambiente. Merece el mismo rigor que cualquier control de seguridad: alcance mínimo, rotación y traza de auditoría.

Antes y después: el caso de una aseguradora

El ambiente de nube de una aseguradora brasileña se aprovisionaba a mano. Levantar un ambiente nuevo tomaba días y producía divergencias entre homologación y producción — el clásico «en homologación funcionaba». No había inventario confiable, y cada auditoría se convertía en una búsqueda de capturas de pantalla de la consola.

Con Terraform asistido por IA, la base fue reescrita en módulos: red, cómputo, base de datos, identidad y observabilidad. Después de eso, levantar un ambiente equivalente pasó a ser cuestión de horas, con el mismo código y solo variables distintas. La ganancia relevante, sin embargo, no fue la velocidad: fue que la auditoría se convirtió en un diff, y el drift en alerta en lugar de descubrimiento tardío.

Extendimos la misma idea a las estaciones Windows con un framework de Intune as Code en PowerShell sobre la API de Microsoft Graph: exportar las políticas del tenant a archivos versionados y aplicarlas de vuelta de forma controlada. El efecto es el de Terraform en otro dominio — la configuración deja de ser un clic de portal y se vuelve código revisable. No por casualidad, ese inventario se convirtió en insumo directo del trabajo de FinOps: un recurso etiquetado es un recurso que se explica en la factura.

Si su ambiente todavía no está en código, el paso anterior suele ser el diseño de la nube. En Inove Academy ponemos a disposición la guía rápida de migración a la nube, que ayuda a decidir qué va por lift-and-shift y qué merece rediseño antes de volverse Terraform. Y, para dimensionar el retorno, la calculadora FinOps muestra dónde se concentra el desperdicio — normalmente en los mismos recursos que nadie sabe quién creó.

Una salvedad de método, para cerrar. Llevar sistemas no SAP a la nube, mover SAP a la nube y convertir a S/4HANA son tres conversaciones diferentes, con riesgos y cronogramas propios. Terraform asistido por IA acelera la fundación de infraestructura de las tres, pero no sustituye a ninguna — y tratar todo como un solo proyecto sigue siendo la forma más rápida de atrasar las tres.