La IA Ya Escribe Tu Terraform. El Problema Ya No Es Escribir — Es Aprobar.

El cuello de botella se movió#

Durante años, escribir Terraform fue el trabajo lento: entender el proveedor, mapear dependencias, probar en un entorno de staging. Eso cambió. HashiCorp está posicionando ahora su plataforma HCP Terraform como el plano de control para una nueva generación de infraestructura dirigida por IA, argumentando que la rápida adopción de agentes de código está desplazando el mayor desafío de infraestructura de escribir configuración a verificarla y ejecutarla con seguridad.

La razón es simple: el código que antes tomaba días ahora toma segundos, así que el cuello de botella se movió de la autoría a la verificación y aprobación — exactamente donde viven los controles empresariales de HCP Terraform. Para un equipo de plataforma, esto no es una mejora de velocidad. Es un cambio de rol completo.

Agentes proponen, la plataforma decide#

El modelo operativo que propone HashiCorp es directo: el agente puede proponer. No debería decidir. Un ingeniero humano revisaba un cambio de Terraform antes de aplicarlo; un agente puede generar configuración, ejecutar un plan, observar el resultado, modificar su enfoque e intentarlo de nuevo en un ciclo continuo. Eso rompe el supuesto sobre el que se construyó la revisión tradicional de infraestructura como código.

La respuesta no es vigilar cada acción del agente. Es asegurar que cada cambio generado por IA pase por el mismo plano de control gobernado que cualquier otro cambio de infraestructura, con identidades de credenciales dinámicas y de corta duración, en lugar de credenciales permanentes en la nube: el modelo usa identidades de alcance limitado por proyecto y credenciales basadas en OIDC emitidas para ejecuciones individuales y revocadas después, lo que limita el radio de impacto si un agente es comprometido.

Esto no es nuevo: Pinterest ya resolvió una versión sin IA#

El patrón de gobernanza que describe HashiCorp para agentes ya existe, construido para ingenieros humanos. Pinterest reveló recientemente su Resource Provisioner Pipeline (RPP), un motor de ejecución de Terraform propio: asegura acceso de mínimo privilegio y exige revisiones de doble control, algo clave para la infraestructura AWS de la compañía, ya que añade salvaguardas estrictas a los flujos de GitHub Actions. El sistema gobierna miles de recursos en cientos de repositorios propiedad de equipos distintos.

• Encadenamiento de roles vía OIDC: un flujo de trabajo asume primero un rol central limitado a flujos de GitHub pre-autorizados, antes de escalar a un rol específico del equipo propietario
• Validación de backend antes de actuar: el pipeline verifica que la ruta del código de Terraform corresponda exactamente al backend de S3 y la clave KMS de ese workspace, evitando que un error de configuración apunte al state file equivocado
• Control dual real: una aprobación humana de código y un comentario explícito en el pull request son necesarios para disparar el apply, manteniendo planificación y ejecución como pasos separados y auditables

El punto no es que Pinterest use o no agentes de IA. El punto es que el mismo patrón — identidad acotada, validación antes de actuar, aprobación separada de la ejecución — es exactamente lo que una organización necesita antes de dejar que un agente autónomo toque su infraestructura. La gobernanza no se improvisa cuando llega la IA: se extiende.

El otro riesgo: proveedores que crecen más rápido que tu gobernanza#

Hay una segunda fuente de riesgo, independiente de la IA, que agrava el problema: el ecosistema de proveedores de Terraform crece sin pausa. AWS continúa expandiendo su portafolio de infraestructura a un ritmo que convierte al proveedor en una capa de abstracción cada vez más importante; Terraform ya no solo aprovisiona instancias EC2, redes y buckets de S3, sino capacidades de más alto nivel en IA, resiliencia, seguridad, bases de datos y servicios de aplicación.

Ese crecimiento tiene un costo de gobernanza. Las actualizaciones de proveedor pueden afectar esquemas, valores por defecto, state y comportamiento de recursos — la retirada de la versión 6.57.0 a principios de este año demostró que incluso una herramienta madura puede introducir riesgo de actualización, por lo que el versionado de proveedores debería tratarse como gestión de dependencias de aplicación: fijar versiones, probar actualizaciones, revisar changelogs y promover cambios a través de entornos controlados.

Qué cambia para los equipos de plataforma#

La implicación más importante no es técnica. A medida que la IA reduce el tiempo necesario para escribir configuración de infraestructura, el trabajo del equipo de plataforma se desplaza cada vez más hacia crear los límites dentro de los cuales la IA puede operar con seguridad: proveer módulos aprobados, definir políticas, establecer límites de identidad y determinar qué puede cambiar un agente, mientras los equipos de aplicación consumen esas capacidades sin saltarse los estándares de la organización.

• El trabajo de revisión no desaparece: se traslada de revisar cada línea de código a diseñar las políticas que todo cambio — humano o de agente — debe cumplir
• Los módulos aprobados dejan de ser una buena práctica opcional y se convierten en la única fuente de verdad que un agente puede consumir
• La auditoría deja de ser documentación posterior: se vuelve la evidencia que explica por qué un cambio pasó, quién lo aprobó y qué política lo permitió

El mensaje de fondo, tanto en el modelo de HCP Terraform como en el pipeline de Pinterest, es el mismo: la infraestructura como código fue siempre, en esencia, un problema de gobernanza disfrazado de problema de herramientas. Resolverlo bien — con la identidad, las políticas y la experiencia adecuadas trabajando como un sistema conectado en Build, no como un proyecto aislado — es lo que separa a un pipeline que escala de uno que acumula riesgo en silencio. Temas que ya tocamos desde otro ángulo en nuestras notas sobre deriva de infraestructura y agentes y sobre gobernanza de agentes de IA en la empresa.