Provisionar ambiente por console é rápido na primeira vez e caro para sempre depois. Ninguém lembra quem abriu aquela porta, por que o banco ficou em outra sub-rede, ou o que exatamente muda se o ambiente precisar subir de novo em outra região. Terraform resolve isso transformando a infraestrutura em código versionado. E os assistentes de IA mudaram a economia dessa escrita: o que era um mês de módulos e refatoração virou uma semana de conversa técnica com revisão.

Neste artigo mostramos o que a IA realmente acelera em infraestrutura como código, o que ela continua não fazendo sozinha, o método em cinco passos que usamos em campo e os guarda-rails que não abrimos mão. O pano de fundo é concreto: levantamos a infraestrutura de nuvem de uma seguradora brasileira com Terraform assistido por IA, e aplicamos a mesma lógica ao parque de estações Windows com um framework próprio de Intune as Code.

Por que IaC deixou de ser opcional

Três exigências mataram o provisionamento manual. A primeira é reprodutibilidade: se produção e homologação não nascem do mesmo código, o teste não prova nada. A segunda é auditabilidade — em setores regulados, “quem mudou o quê e quando” precisa ter resposta, e o histórico do repositório é a resposta mais barata que existe. A terceira é reversibilidade: um ambiente descrito em código volta ao estado anterior com um revert, não com memória e sorte.

Além disso, há o efeito colateral que ninguém antecipa: o código vira a documentação. Quando alguém pergunta como está desenhada a rede, a resposta não é uma planilha desatualizada — é o arquivo. Por isso tratamos IaC como parte da disciplina de infraestrutura, e não como preferência de time de desenvolvimento.

O que a IA muda de verdade

Quatro ganhos aparecem de forma consistente. Nenhum deles é “a IA fez sozinha”.

• Geração de módulos. Descrever “VPC com três zonas, subnets pública e privada, NAT gateway e tags de centro de custo” e receber o módulo estruturado economiza o trabalho mecânico. O ganho maior não é a digitação: é a IA já sair com variáveis, outputs e um README que um humano deixaria para depois.
• Revisão do plan. Um terraform plan de mudança grande cospe centenas de linhas. Pedir a um assistente que resuma o que será destruído, o que muda de nome e o que força recriação transforma leitura de diff em conversa. É aqui que a IA pega o replace silencioso de um banco que ninguém tinha visto.
• Detecção de drift. Alguém sempre mexe no console em uma madrugada de incidente. Jogar a saída do plan -refresh-only para análise separa depressa o drift inofensivo (uma tag) do drift perigoso (uma regra de security group aberta).
• Documentação viva. Diagramas, tabelas de recursos e notas de mudança gerados a partir do código real. Documentação que nasce do estado atual não envelhece do mesmo jeito.

O que a IA não faz sozinha

Ela não conhece a sua topologia de rede, os blocos de IP já reservados nem o contrato com o provedor. Também não sabe qual banco tem dado de produção e qual é descartável — e um assistente confiante propõe destroy com a mesma naturalidade com que propõe create. Além disso, ela erra em atributos de provider que mudaram de versão, gerando código que parece correto e falha no validate.

O método em cinco passos

1. Inventariar antes de escrever. Levantar o que já existe e importar para o state, em vez de recriar por cima. Recurso órfão fora do Terraform é dívida garantida.
2. Definir o esqueleto na mão. Convenção de nomes, tags obrigatórias, estrutura de pastas e separação de ambientes. Esse contrato é curto e humano — e é justamente o que faz a IA gerar código coerente depois.
3. Gerar por módulo, não por ambiente inteiro. Rede, computação, banco, identidade, observabilidade. Cada módulo com validate, lint e plan limpo antes de passar para o próximo.
4. Revisar o plan com IA e com gente. A IA resume e levanta a hipótese; o engenheiro decide. Toda linha de destroy ou force replacement precisa de justificativa explícita.
5. Fechar o ciclo com pipeline. plan automático no pull request, apply só depois da aprovação e verificação periódica de drift. Sem isso, o repositório vira ficção em três meses.

Guarda-rails inegociáveis

• State remoto com lock. State na máquina de alguém é acidente esperando acontecer. Backend remoto, versionado, criptografado e com locking — dois apply simultâneos corrompem o estado.
• Secrets fora do código. Senha, chave e token vivem em cofre gerenciado, referenciados por identidade. Vale lembrar: variável marcada como sensível não deixa de aparecer no arquivo de state.
• Revisão humana do plan. Nenhum apply automático em produção. O plan aprovado é o que roda, e a aprovação fica registrada.
• Policy as code. Regras que barram o pipeline: bucket público, porta 22 aberta para o mundo, recurso sem tag de centro de custo, região fora da permitida. Política que depende de alguém lembrar não é política — e, sem tag de custo, o trabalho de FinOps começa cego.
• Menor privilégio para o pipeline. A credencial que aplica infraestrutura é a mais poderosa do ambiente. Ela merece o mesmo rigor de qualquer controle de segurança: escopo mínimo, rotação e trilha de auditoria.

Antes e depois: o caso de uma seguradora

O ambiente de nuvem de uma seguradora brasileira era provisionado à mão. Subir um ambiente novo levava dias e produzia divergências entre homologação e produção — o clássico “em homologação funcionava”. Não havia inventário confiável, e cada auditoria virava garimpo de capturas de tela no console.

Com Terraform assistido por IA, a base foi reescrita em módulos: rede, computação, banco, identidade e observabilidade. Depois disso, subir um ambiente equivalente passou a ser questão de horas, com o mesmo código e apenas variáveis diferentes. O ganho relevante, porém, não foi a velocidade — foi a auditoria virar um diff, e o drift virar alerta em vez de descoberta tardia.

Estendemos a mesma ideia às estações Windows com um framework de Intune as Code em PowerShell sobre a API do Microsoft Graph: exportar as políticas do tenant para arquivos versionados e aplicá-las de volta de forma controlada. O efeito é o do Terraform em outro domínio — configuração deixa de ser clique de portal e vira código revisável. Não por acaso, esse inventário virou insumo direto do trabalho de FinOps: recurso etiquetado é recurso que se explica na fatura.

Se o seu ambiente ainda não está em código, o passo anterior costuma ser o desenho da nuvem. Na Inove Academy disponibilizamos o guia rápido de migração para nuvem, que ajuda a decidir o que vai por lift-and-shift e o que merece redesenho antes de virar Terraform. E, para dimensionar o retorno, a calculadora FinOps mostra onde o desperdício se concentra — normalmente nos mesmos recursos que ninguém sabe quem criou.

Uma ressalva de método, para fechar. Levar sistemas não SAP para a nuvem, mover o SAP para nuvem e converter para S/4HANA são três conversas diferentes, com riscos e cronogramas próprios. Terraform assistido por IA acelera a fundação de infraestrutura das três, mas não substitui nenhuma delas — e tratar tudo como um projeto só continua sendo o jeito mais rápido de atrasar os três.