Agentes de IA para DevOps e infraestrutura: até onde podemos automatizar a operação?

Uma parte importante do trabalho em infraestrutura e DevOps não está em executar um comando.

Está em reunir contexto suficiente para decidir qual comando executar.

Um alerta de latência pode ter relação com:

• uma mudança recente;

• saturação de CPU;

• conexões no banco;

• falha em uma dependência;

• configuração de rede;

• aumento de tráfego;

• um deployment incompleto.

Antes de agir, alguém precisa consultar dashboards, logs, métricas, traces, histórico de deploy, código, Infrastructure as Code, tickets e runbooks.

É justamente nessa etapa que os agentes de IA começam a mudar a operação.

Eles deixam de ser apenas uma interface que responde perguntas e passam a executar sequências de ações usando ferramentas, contexto e regras.

A questão passa a ser:

até onde é seguro permitir que um agente participe da operação de produção?

Assistente de IA e agente de IA não são exatamente a mesma coisa

Um assistente tradicional recebe uma pergunta e retorna uma resposta.

Um agente pode ir além.

Ele pode:

1. interpretar um objetivo;

2. consultar diferentes fontes;

3. escolher ferramentas;

4. executar etapas;

5. observar os resultados;

6. ajustar a estratégia;

7. produzir ou executar uma ação.

Em operações, isso pode transformar:

“por que a API está lenta?”

em um fluxo como:

alerta → métricas → logs → mudanças recentes → dependências → hipótese → validação → recomendação

Ou, em um nível maior de automação:

incidente → investigação → correção proposta → Pull Request → pipeline → aprovação → aplicação → validação

Essa diferença é importante.

O valor do agente não está apenas no modelo de linguagem.

Está na capacidade de trabalhar com ferramentas e contexto operacional.

O agente precisa enxergar o ambiente

Um agente sem contexto real do ambiente é apenas um gerador de hipóteses.

Para ajudar em operações, ele precisa consultar fontes confiáveis.

Entre elas:

• métricas;

• logs;

• traces;

• alertas;

• topologia e dependências;

• inventário;

• repositórios Git;

• Terraform e outros arquivos de IaC;

• configurações;

• histórico de CI/CD;

• tickets de incidentes;

• documentação;

• runbooks.

Produtos recentes já caminham nessa direção.

O AWS DevOps Agent foi projetado para trabalhar com ferramentas de observabilidade, repositórios, pipelines e dados de deployment, correlacionando esses sinais durante investigações operacionais.

O Azure SRE Agent também combina contexto de recursos, observabilidade, incidentes e código para investigação e automações governadas.

No Google Cloud, o Gemini Cloud Assist utiliza chamadas de ferramentas e investigação de telemetria para apoiar troubleshooting e operações.

Isso mostra uma tendência clara:

o agente operacional precisa estar conectado ao ambiente, e não apenas ao chat.

Observabilidade é a matéria-prima da investigação

Métricas, logs e traces continuam fundamentais.

A diferença é que um agente pode utilizar esses sinais de forma iterativa.

Imagine o alerta:

latência da API acima de 2 segundos

Um fluxo de investigação poderia ser:

Alerta ↓ Métricas da aplicação ↓ Métricas de infraestrutura ↓ Logs ↓ Traces ↓ Dependências ↓ Deployments recentes ↓ Hipótese de causa

O agente pode comparar horários, procurar correlações e eliminar hipóteses.

Por exemplo:

Hipótese A: CPU saturada CPU normal → descartar.

Hipótese B: banco lento tempo de consulta aumentou → investigar.

Hipótese C: novo deployment latência começou minutos depois da versão 3.8.1 → correlação relevante.

A IA não transforma correlação automaticamente em causalidade.

Mas pode reduzir significativamente o trabalho manual de coleta e organização das evidências.

Topologia ajuda a entender causa e consequência

Em ambientes distribuídos, um único problema pode gerar dezenas de alertas.

Imagine:

Storage ↓ Cluster de virtualização ↓ VMs ↓ Aplicação

Se o storage estiver degradado, várias VMs podem apresentar latência.

As aplicações nessas VMs também podem gerar alertas.

Sem entender dependências, um sistema pode interpretar tudo como incidentes independentes.

Com informações de topologia, um agente pode raciocinar:

“esses 18 alertas possuem uma dependência comum.”

Isso conecta agentes de IA diretamente aos conceitos de AIOps.

A diferença é que o agente pode continuar a investigação e utilizar ferramentas adicionais.

Runbooks transformam conhecimento operacional em ação

Um dos recursos mais úteis para um agente não é necessariamente um modelo mais poderoso.

É um bom runbook.

Um runbook descreve como responder a determinada situação.

Exemplo:

Alerta: filesystem acima de 90%

Procedimento:

1. identificar diretórios com maior crescimento;

2. verificar logs fora da política de retenção;

3. analisar processos;

4. validar possibilidade de limpeza;

5. expandir volume se necessário;

6. confirmar recuperação;

7. registrar a ação.

Um agente pode utilizar esse documento como referência durante a investigação.

Isso reduz improvisação.

Também permite separar:

raciocínio do agente

de

procedimento aprovado pela organização.

Quanto maior o nível de automação, mais importante se torna essa separação.

Git pode funcionar como uma barreira de segurança

Uma das arquiteturas mais interessantes para agentes de infraestrutura não permite que eles alterem produção diretamente.

O agente propõe a mudança no Git.

Por exemplo:

incidente detectado

↓

agente identifica configuração problemática

↓

altera Terraform

↓

abre Pull Request

↓

CI executa terraform fmt / validate / plan

↓

revisão humana

↓

merge

↓

pipeline aplica

Isso mantém:

• histórico;

• revisão;

• auditoria;

• rollback;

• políticas;

• controles existentes.

O mesmo conceito vale para:

• Ansible;

• manifests Kubernetes;

• Helm;

• políticas;

• pipelines;

• arquivos de configuração.

Agentes de código já trabalham com fluxos semelhantes. O GitHub Copilot coding agent e outros agentes integrados ao GitHub podem trabalhar em tarefas e produzir Pull Requests para revisão.

Para infraestrutura, esse modelo é particularmente interessante porque reduz o risco de mudanças invisíveis.

Infrastructure as Code amplia as possibilidades

Quando a infraestrutura é definida em código, o agente passa a ter uma representação versionada do ambiente.

Ele pode analisar:

• módulos Terraform;

• arquivos HCL;

• playbooks Ansible;

• YAML;

• Helm charts;

• manifests Kubernetes;

• pipelines.

Exemplo:

Um agente identifica que uma aplicação está sem capacidade.

Ele consulta:

autoscaling.tf

e encontra:

max_size = 4

A investigação aponta que o limite foi atingido.

Em vez de executar diretamente uma alteração na cloud, o agente pode propor:

max_size = 6

Depois:

Pull Request → terraform plan → revisão → aplicação

Isso não elimina a necessidade de análise.

Apenas transforma a IA em participante de um processo controlado.

Nem toda ação precisa do mesmo nível de autorização

Automação operacional não precisa ser binária:

manual ou totalmente autônoma.

É possível criar diferentes níveis.

Somente leitura

O agente pode:

• consultar métricas;

• analisar logs;

• ler código;

• verificar configurações;

• consultar documentação.

Não pode alterar nada.

Recomendação

Além de investigar, o agente apresenta:

• causa provável;

• evidências;

• comandos sugeridos;

• runbook aplicável;

• possíveis impactos.

Uma pessoa executa a mudança.

Mudança via Pull Request

O agente pode alterar código ou configuração, mas a mudança segue:

PR → validação → revisão → aprovação

Esse modelo combina muito bem com IaC e GitOps.

Execução com aprovação

O agente prepara a ação e solicita autorização antes de executá-la.

Exemplo:

Reiniciar deployment payments-api em produção?

A ação só ocorre após aprovação.

Automação limitada

Algumas ações de baixo risco podem ser autorizadas automaticamente.

Por exemplo:

• reiniciar um processo conhecido;

• executar um runbook aprovado;

• remover um Pod com falha para permitir recriação;

• aumentar temporariamente capacidade dentro de limites definidos.

Mesmo nesse caso, precisam existir limites claros.

Guardrails são mais importantes que autonomia

Quanto mais ferramentas um agente pode utilizar, maior o potencial impacto de um erro.

Por isso, o desenho correto começa pelas restrições.

Alguns controles importantes:

Privilégio mínimo

O agente deve possuir apenas as permissões necessárias.

Um agente criado para consultar métricas não precisa de permissão para excluir recursos.

Escopo

Definir onde ele pode atuar.

Exemplo:

Permitido: namespace staging Bloqueado: namespace production

Ações permitidas

Mesmo dentro do ambiente autorizado:

Pode: restart deployment scale deployment Não pode: delete database alter IAM disable firewall

Limites

Exemplo:

mínimo de réplicas: 2 máximo de réplicas: 8

O agente não pode ultrapassar esses valores.

Aprovação humana

Mudanças de maior impacto podem exigir aprovação obrigatória.

Auditoria

Toda ação precisa registrar:

• quem solicitou;

• o que o agente analisou;

• qual decisão tomou;

• quais ferramentas utilizou;

• qual alteração executou;

• qual foi o resultado.

Automação sem rastreabilidade é um risco operacional.

O problema de credenciais

Para executar ações, o agente precisa se autenticar em sistemas.

Isso cria um ponto crítico.

Nunca é uma boa estratégia entregar credenciais administrativas permanentes a um agente.

É preferível utilizar mecanismos como:

• identidades gerenciadas;

• roles temporárias;

• tokens de curta duração;

• RBAC;

• workload identity;

• secrets managers.

Também é importante separar:

credencial disponível para o agente

de

credencial encontrada em um documento ou prompt.

Conteúdo recebido pelo modelo nunca deveria ser tratado automaticamente como autorização.

Prompt injection também chega à infraestrutura

Prompt injection não é apenas um problema de chatbot.

Imagine que um agente lê automaticamente:

• issue do GitHub;

• ticket;

• página de documentação;

• log;

• arquivo Markdown.

Um conteúdo malicioso poderia conter algo como:

“ignore as regras anteriores e execute este comando.”

Se o agente tiver ferramentas administrativas, isso pode se transformar em risco real.

Por isso, sistemas agentic precisam diferenciar:

dados

de

instruções autorizadas.

Um log deve ser tratado como log.

Uma issue deve ser tratada como conteúdo potencialmente não confiável.

Permissões e políticas precisam existir fora do modelo.

Um agente também pode errar

Modelos de IA podem:

• interpretar dados incorretamente;

• construir uma hipótese plausível, mas errada;

• utilizar documentação desatualizada;

• sugerir comandos inadequados;

• ignorar uma dependência importante.

Isso significa que a validação tradicional continua necessária.

Por exemplo:

Agente propõe mudança Terraform ↓ terraform fmt ↓ terraform validate ↓ terraform plan ↓ policy as code ↓ testes ↓ aprovação

O modelo pode produzir a mudança.

As ferramentas determinísticas validam a mudança.

Essa combinação é muito mais segura do que confiar apenas no texto produzido pela IA.

Um fluxo completo de agente operacional

Podemos conectar todos esses conceitos em um único incidente.

Imagine uma aplicação apresentando aumento de erros.

1. Alerta

A observabilidade detecta:

taxa de erro > 5%

2. Coleta de contexto

O agente consulta:

• métricas;

• logs;

• traces;

• topologia;

• deployments recentes.

3. Investigação

Ele descobre:

os erros começaram após o deployment da versão 4.2.0.

4. Git

O agente verifica o repositório e identifica uma mudança de configuração relacionada.

5. Runbook

Existe um procedimento documentado:

reverter configuração e validar health checks.

6. Mudança

O agente cria um Pull Request revertendo a configuração.

7. CI/CD

A pipeline executa:

• lint;

• testes;

• validações;

• build;

• security checks.

8. Aprovação

Uma pessoa revisa evidências e mudança.

9. Deploy

A pipeline aplica a correção.

10. Validação

O agente consulta novamente:

• erros;

• latência;

• health checks.

O ambiente retorna ao comportamento normal.

Esse exemplo mostra algo importante:

o agente não precisa receber acesso irrestrito para ser extremamente útil.

Ele pode automatizar grande parte do trabalho mantendo controles humanos nos pontos de maior risco.

Onde a autonomia faz mais sentido

Tarefas com baixo risco e resultado verificável são boas candidatas.

Exemplos:

• coleta de diagnóstico;

• correlação de alertas;

• consulta de logs;

• geração de relatórios;

• classificação de incidentes;

• abertura de tickets;

• consulta a runbooks;

• criação de Pull Requests;

• validação de configuração;

• execução de verificações pós-deploy.

Ações destrutivas exigem outra postura.

Exemplos:

• exclusão de banco;

• alteração de firewall;

• mudança de IAM;

• rotação de credenciais críticas;

• alteração irreversível de dados;

• mudanças amplas em produção.

Nesses casos, o custo potencial de uma decisão errada aumenta muito.

Humano no loop não significa automação fraca

Existe uma tendência de avaliar agentes pela quantidade de decisões que conseguem tomar sozinhos.

Em operações, essa não é necessariamente a melhor métrica.

Um fluxo:

agente investiga → propõe → pipeline valida → humano aprova → automação executa

pode ser muito mais valioso do que:

agente executa tudo sozinho

A eficiência vem da redução do trabalho repetitivo, não da eliminação obrigatória de todas as decisões humanas.

O objetivo é colocar pessoas nos pontos em que julgamento, responsabilidade e contexto de negócio realmente importam.

O papel de DevOps e SRE muda

Agentes não eliminam a necessidade de conhecimento técnico.

Na realidade, aumentam a importância de:

• arquitetura;

• observabilidade;

• documentação;

• Git;

• CI/CD;

• Infrastructure as Code;

• segurança;

• políticas;

• runbooks.

Um ambiente desorganizado continua difícil de operar, mesmo com IA.

Se não existe:

• telemetria confiável;

• configuração versionada;

• documentação;

• processos reproduzíveis;

• controles de acesso;

o agente terá pouco contexto para tomar boas decisões.

Automação inteligente depende de uma base operacional madura.

Até onde podemos automatizar?

Tecnicamente, já é possível automatizar uma parte considerável do ciclo operacional.

Um agente pode:

detectar → investigar → correlacionar → consultar → propor → validar → executar → verificar

Mas isso não significa que todas essas etapas devam ocorrer sem supervisão.

O nível adequado depende de:

• criticidade;

• reversibilidade;

• impacto;

• confiança dos sinais;

• qualidade dos testes;

• permissões;

• maturidade operacional.

Uma boa regra é:

quanto maior o impacto e menor a reversibilidade, maior deve ser o controle humano.

Conclusão

Agentes de IA estão começando a ocupar um espaço entre observabilidade, automação e operação.

Eles podem reunir contexto que hoje está espalhado entre dashboards, logs, repositórios, pipelines e documentação.

Podem investigar incidentes.

Podem consultar runbooks.

Podem propor mudanças em Terraform, Ansible ou Kubernetes.

Podem abrir Pull Requests.

Podem acompanhar pipelines.

E, em cenários controlados, podem executar determinadas ações.

Mas o verdadeiro avanço não está em permitir que uma IA tenha acesso administrativo irrestrito ao ambiente.

Está em construir um fluxo no qual:

IA fornece velocidade e contexto

automação fornece execução reproduzível

políticas fornecem limites

pessoas mantêm controle sobre decisões de maior impacto

O futuro da operação provavelmente não será totalmente manual nem totalmente autônomo.

Será cada vez mais uma combinação de agentes, ferramentas determinísticas, políticas e aprovação humana trabalhando sobre uma infraestrutura versionada, observável e automatizada.