Por que Mudanças em Infraestrutura com IA Precisam de Provas, Não Só de Permissões

Antigamente, alterar uma infraestrutura era algo direto. Um engenheiro sênior acessava o servidor via SSH, executava um comando e torcia para que a documentação estivesse em dia. Hoje isso mudou. Estamos entregando tarefas complexas a agentes de IA — migrações, ajustes de capacidade, correções de segurança — e precisamos garantir que essas operações sejam realmente seguras antes de serem executadas.

O modelo tradicional de segurança já não é suficiente.

O Problema do Controle de Acesso Baseado em Funções na Era da IA

Os mecanismos atuais de proteção em produção geralmente funcionam assim:

RBAC define: "Este usuário pode escrever em produção."
GitOps define: "Este é o estado desejado."

Mas nenhuma dessas abordagens responde à pergunta mais importante: "Por que esta mudança específica é segura neste momento?"

Quando um humano executa um comando, ele traz contexto, experiência e discernimento. Já um agente de IA que solicita uma alteração em produção — especialmente algo como uma migração de banco de dados — não oferece essa camada explicativa. Estamos apenas verificando permissões, sem validar o raciocínio por trás da decisão.

Isso se torna ainda mais crítico em operações com estado. Uma migração de schema, uma transferência de dados ou uma alteração de configuração não é apenas "aplicar um arquivo YAML". São etapas irreversíveis, com dependências, necessidade de rollback e restrições de tempo. O sistema de controle de acesso não enxerga nada disso.

Como Funciona o Controle de Mudanças Baseado em Evidências

A solução envolve envolver cada mudança proposta em uma prova criptográfica antes da execução. É como assinar alterações de infraestrutura.

O fluxo funciona da seguinte forma:

1. O agente propõe a mudança — com todos os detalhes e justificativas
2. O sistema gera a prova — evidência criptográfica de que a mudança é segura
3. O motor de políticas avalia — a mudança está de acordo com as regras?
4. A prova é verificada — as assinaturas estão intactas? Houve alguma alteração?
5. A mutação é executada — só se todas as verificações passarem
6. O registro é criado — um histórico completo e reproduzível do que aconteceu e por quê

Essa prova é abrangente. Ela inclui:

• Validação em dry-run contra a infraestrutura real
• Detecção de drift em tempo de execução
• Varredura de segurança e SBOM
• Digests de imagens e procedência de builds
• Previsões de impacto em SLOs
• Verificações de integridade da cadeia de eventos

Tudo isso é assinado, carimbado com data/hora e armazenado junto com os artefatos de release.

Exemplo Prático: Migração de Oracle para PostgreSQL

Imagine migrar um sistema Oracle/APEX para PostgreSQL rodando em Kubernetes — não um teste, mas uma operação real com dados em produção.

O processo inclui:

• Verificar se o cluster Kubernetes está pronto
• Registrar aprovações da janela de mudança
• Congelar o sistema de origem
• Exportar os dados
• Criar pontos de restauração no destino
• Expandir o schema e configurar shadow tables
• Verificar linha por linha
• Realizar o roteamento do cutover
• Validar após a migração
• Exportar o log completo de auditoria

Isso vai muito além de um simples kubectl apply. É um programa com estado, passos irreversíveis e nenhuma margem para erro.

Quando um agente de IA solicita essa sequência, a prova captura:

• 23 validações entre infraestrutura, schema, segurança e compliance
• 20 eventos documentando cada etapa
• 20 artefatos de prova que verificam independentemente cada fase
• 100% de score indicando que todos os gates foram aprovados

A prova é assinada com uma chave ed25519 e pode ser verificada depois com torque proof verify --require-signature. Nada foi falsificado. Nada foi alterado.

O Gate Identifica o Que os Humanos Não Vêem

Mesmo com a prova em vigor, o sistema ainda exige autorização explícita. Uma prova válida não significa liberação automática.

Em testes, a mesma solicitação do agente foi negada duas vezes:

1. Primeira negação: não havia entrada na allow-list para essa operação. A prova passou, mas a política não permitia.
2. Segunda negação: alguém alterou a prova (mudou uma evidência do verificador). A allow-list estava configurada, mas a assinatura criptográfica falhou. A mutação foi bloqueada.

É uma defesa em camadas para a era da IA. Você tem prova e política — nenhum dos dois sozinho é suficiente.

Por Que Isso Importa para Sua Infraestrutura

Ferramentas tradicionais de GitOps e RBAC, como Argo CD e Crossplane, foram criadas antes das operações autônomas ganharem força. Elas ainda são úteis, mas não foram projetadas para agentes que realizam mutações em produção. Elas informam quem pode escrever e qual é o estado desejado, mas não explicam por que esta mudança específica é segura agora.

À medida que avançamos para:

• Implantações assistidas por IA — agentes gerenciando a infraestrutura em nuvem
• Escalonamento e remediação autônomos — sistemas que corrigem problemas sem intervenção humana
• Migrações multi-cloud — operações complexas e sequenciais entre várias plataformas
• Cargas com alta exigência de compliance — onde trilhas de auditoria e provas são obrigatórias

...você precisa de uma infraestrutura capaz de explicar, em detalhes criptográficos, cada mudança em produção.

Próximos Passos Práticos

Se você usa Kubernetes em produção e lida com migrações complexas ou operações guiadas por IA, vale considerar:

1. Geração de provas — seu sistema de deployment consegue criar evidências criptográficas de que uma mudança é segura?
2. Políticas como código — allow-lists explícitas definindo quais operações os agentes podem executar e em quais contextos
3. Trilhas de auditoria — registros assinados e reproduzíveis de cada mutação, incluindo o raciocínio
4. Pontuação de gates — nível de confiança quantificado de que uma mudança pode ser executada com segurança

O mundo da infraestrutura está migrando para operações autônomas. Seu controle de mudanças também precisa evoluir — de "você tem permissão?" para "aqui está a prova de que é seguro, e aqui está o porquê".

Essa é a única forma de dormir tranquilo enquanto seu agente de IA executa migrações em produção às 3 da manhã.