Agentes de operação

Um agente de operação é um sistema que decide e age na sua infraestrutura: lê sinais, escolhe uma ação e executa. É diferente de automação tradicional em um ponto essencial — a automação executa um roteiro que alguém escreveu; o agente escolhe o roteiro.

Isso muda a natureza do risco. Automação falha de formas previstas; agente falha de formas que ninguém enumerou. A pergunta certa não é “o agente consegue fazer isso?”, e sim “o que acontece quando ele fizer errado, e quanto isso custa?”.

O espectro de autonomia

Nível	O agente…	Uso adequado
1 — Observa	descreve e resume o estado	qualquer ambiente
2 — Sugere	propõe a ação, com justificativa	produção, desde o começo
3 — Executa com aprovação	prepara e espera um “sim”	produção, ações reversíveis
4 — Executa e avisa	age sozinho dentro de limites estreitos	ações ensaiadas, raio pequeno
5 — Autônomo	decide e age livremente	nenhum ambiente de produção

Comece no nível 2. Suba um nível por vez, por tipo de ação, com dados de acerto acumulados. Um agente confiável para reiniciar um Pod não é, por isso, confiável para alterar um Security Group.

Ação sugerida e ação executada

Sugestão errada custa a atenção de quem lê. Ação errada custa produção. Por isso a promoção de nível deve depender de três respostas:

1. É reversível? Reiniciar Pod, sim. Apagar volume, não.
2. Qual é o raio de alcance? Um Pod, um serviço, um cluster, a conta inteira.
3. O acerto foi medido? Registre as sugestões e o resultado de cada uma por semanas antes de deixar executar.

A classificação prática:

• Pode executar (com limites): reiniciar réplica, escalar dentro de faixa, limpar disco temporário, reabrir circuito, criar ticket, coletar diagnóstico.
• Só com aprovação: rollback de deploy, alterar configuração, desviar tráfego, aumentar cota.
• Nunca: apagar dado, alterar permissão ou política de segurança, mexer em backup, tocar em produção financeira, desligar auditoria.

Permissão, auditoria e reversibilidade

Um agente é um principal como qualquer outro — e merece o mesmo rigor da página de identidade, com um cuidado a mais: as ações dele não passam por revisão prévia.

# RBAC do agente: verbos e recursos mínimos, escopo de namespace
rules:
  - apiGroups: [""]
    resources: [pods]
    verbs: [get, list, delete]        # delete de Pod = reiniciar; sem tocar em Deployment
  - apiGroups: [apps]
    resources: [deployments/scale]
    verbs: [get, update]              # escalar, dentro do que a política permitir
# nada de secrets, nada de clusterrolebindings, nada em kube-system

Complete com o que torna o erro recuperável:

• Registro de tudo: entrada observada, raciocínio, ação, resultado — em log imutável, fora do alcance do agente.
• Limite de taxa: no máximo N ações por hora. Laço de agente é o modo de falha mais perigoso: ele escala, reinicia, escala de novo, e derruba o serviço tentando salvá-lo.
• Botão de desligar, conhecido por todo o plantão e testado.
• Notificação imediata de cada ação executada, no canal do time.

Ambiente de teste antes de produção

Rode o agente em modo sombra por semanas: ele observa produção e registra o que faria, sem executar. Compare com o que as pessoas fizeram. Esse registro é a única evidência honesta de que ele está pronto — e costuma revelar padrões de erro que nenhuma avaliação teórica pega.

Depois, exercite no ambiente de teste com falhas injetadas (o caos controlado serve exatamente para isso): o agente reage bem à falha parcial, ao sinal ambíguo, à métrica ausente? O que ele faz quando não sabe?

Falhar em modo seguro

O comportamento padrão diante de incerteza tem que ser parar e chamar gente, não tentar o melhor palpite. Escreva isso na política do agente e teste-o:

• Sinal ausente ou contraditório → escala para humano.
• Ação já tentada e sem efeito → não repete; escala.
• Fora do horário/limite configurado → só sugere.
• Erro de permissão → registra e para, nunca busca outro caminho.

E mantenha o humano capaz de assumir: se o agente cuida de tudo por meses, ninguém do plantão lembra como se faz manualmente. Documente o procedimento manual equivalente e exercite-o no game day — a degradação de competência do time é um risco tão real quanto a falha do agente.

Próximo passo: feche a trilha com as ameaças específicas dessas ferramentas em Riscos de IA na infraestrutura.