AI DevOps virou uma dessas expressões que significam o que o fornecedor precisar que signifiquem. Para alguns, é um assistente de chat que escreve Terraform. Para outros, é um sistema autônomo que conserta a produção enquanto todo mundo dorme. Se você lidera engenharia em uma empresa de SaaS, nenhuma das duas imagens ajuda a decidir o que confiar a um agente de IA na segunda-feira de manhã. Este post é um relato prático do que os agentes de IA fazem bem em operações, do que não devem fazer sozinhos e de onde um humano precisa continuar no circuito.

Na Webera, trabalhamos com nove agentes de IA ao lado de engenheiros seniores, então temos interesse no assunto. Vamos tentar ser específicos tanto sobre os limites quanto sobre os usos.

O que AI DevOps e DevOps agêntico realmente significam

Duas coisas diferentes são agrupadas sob o mesmo rótulo.

DevOps assistido por IA é uma pessoa usando um modelo como ferramenta. Um engenheiro pede um workflow do GitHub Actions, uma consulta do CloudWatch ou a explicação de um stack trace, lê a resposta e decide o que fazer com ela. O humano conduz cada etapa.

DevOps agêntico é um sistema que executa ações em loop. Um agente recebe um objetivo ou um evento, chama ferramentas (ler os logs, consultar métricas, olhar o último deploy, abrir um pull request), analisa os resultados e decide o próximo passo. O agente conduz algumas das etapas, e a pergunta de projeto passa a ser quais etapas.

A maioria das decisões interessantes sobre agentes de IA para DevOps está nessa segunda categoria. Um assistente que dá uma resposta errada faz você perder alguns minutos. Um agente com acesso de escrita à produção que toma uma ação errada pode causar um incidente.

Onde um agente de AI DevOps ganha seu lugar

O trabalho de operações tem uma grande parcela de tarefas repetitivas, urgentes e bem definidas. É nelas que os agentes mais ajudam.

Monitorar

A produção gera mais sinais do que as pessoas conseguem ler. Um agente pode acompanhar métricas, logs e eventos de deploy continuamente, correlacionar um aumento de latência com a release que saiu vinte minutos antes e abrir um incidente com esse contexto anexado. Uma pessoa fazendo o mesmo às 3h da manhã primeiro precisa acordar, fazer login e achar o dashboard certo.

Direcionar

Quando algo parece errado, alguém precisa decidir a gravidade e quem deve saber. Os agentes são bons em aplicar uma política de severidade de forma consistente, acionar o engenheiro de plantão certo, anexar o runbook correspondente e suprimir alertas duplicados da mesma causa raiz. É também aqui que se combate a fadiga de alertas: um agente que filtra bem o ruído faz o alerta que chega valer a leitura.

Primeira análise

Antes de alguém consertar qualquer coisa, é preciso reunir evidências: mudanças recentes, taxas de erro por endpoint, queries lentas, saturação de recursos, incidentes parecidos do passado. Um agente pode fazer isso em paralelo e entregar ao engenheiro um resumo curto com uma hipótese, em vez de um terminal em branco. Ele também pode redigir a correção como um pull request, de modo que a primeira ação do engenheiro seja revisar uma proposta, e não escrever uma do zero.

Manutenção repetitiva

Boa parte do trabalho de DevOps é checar coisas que ninguém tem tempo de checar. Todo alerta está ligado a um runbook? Quais instâncias estão ociosas há duas semanas? Quais políticas do IAM concedem mais do que usam? Quais dependências têm vulnerabilidades conhecidas? Os agentes podem executar essas verificações de forma agendada e relatar o que mudou, o que evita que pequenos problemas se acumulem.

O que os agentes de IA não devem fazer sozinhos

As mesmas qualidades que tornam os agentes úteis (velocidade, persistência, disposição para agir) viram riscos quando a tarefa exige um contexto que o agente não tem.

Decisões que dependem do contexto do negócio. Um agente consegue ver que um banco de dados está superdimensionado para a carga média. Ele não tem como saber que o tamanho existe porque seu maior cliente roda uma importação em lote todo dia primeiro, ou que o financeiro já se comprometeu com uma Reserved Instance. Uma recomendação é aceitável. Um downsize automático, não.

Mudanças de alto impacto ou irreversíveis. Excluir recursos, alterar permissões do IAM, executar migrações de dados, rotacionar credenciais usadas por outros sistemas e mudar o DNS de domínios de produção têm um raio de impacto grande. O projeto OWASP lista Excessive Agency entre os principais riscos para aplicações de LLM e aponta três causas: funcionalidade demais, permissões demais e autonomia demais. A principal mitigação é exigir que um humano aprove as ações de alto impacto antes que aconteçam.

Falhas inéditas. Os agentes são mais fortes em problemas parecidos com os que já viram ou que um runbook descreve. Quando a falha é realmente nova, como um provedor externo se comportando de um jeito não documentado, um engenheiro experiente raciocinando a partir dos primeiros princípios ainda é a melhor ferramenta. O papel do agente, nesse caso, é reunir evidências rapidamente e sair do caminho.

Responsabilização. Quando um incidente afeta clientes, alguém precisa assumir a decisão, explicá-la ao cliente e conduzir a revisão depois. Esse é um papel humano. “O agente fez isso” não é uma resposta que um cliente, um auditor ou seu conselho vão aceitar.

Onde os humanos continuam no circuito

Uma forma útil de desenhar AI DevOps é classificar as ações por risco e atribuir a cada classe um responsável padrão. Este é o modelo que, para nós, funciona para a maioria dos times de SaaS:

Ação	Agente	Humano
Ler métricas, logs, traces e configuração	Faz continuamente	Revisa os resumos
Abrir um incidente e acionar o plantão	Faz, usando a política de severidade	É dono da política
Investigar e propor uma causa	Faz a primeira passada	Confirma ou rejeita
Redigir uma correção como pull request	Escreve	Revisa e aprova
Aplicar uma mudança em produção	Executa pelo pipeline após a aprovação	Aprova
Excluir recursos, alterar o IAM, migrar dados	Apenas recomenda	Decide e aprova
Falar com clientes sobre um incidente	Redige as notas	Comunica e assume a responsabilidade

Dois princípios sustentam a tabela. Primeiro, os agentes recebem acesso de leitura amplo e acesso de escrita restrito, e toda mudança passa pelo mesmo pipeline, code review e trilha de auditoria de uma mudança feita por uma pessoa. Segundo, o nível de exigência para a autonomia sobe conforme o custo de errar. Acionar alguém sem necessidade custa alguns minutos. Apagar uma tabela custa uma empresa.

Os riscos que vale a pena planejar

Mais mudança, menos estabilidade. O programa de pesquisa DORA, do Google, estudou isso diretamente. Seu relatório de 2025 sobre desenvolvimento de software assistido por IA constatou que a adoção de IA ainda tem uma relação negativa com a estabilidade da entrega de software e que, sem testes automatizados sólidos, boas práticas de controle de versão e ciclos de feedback rápidos, mais volume de mudanças leva a mais instabilidade. O resumo do relatório é direto: a IA “doesn’t fix a team; it amplifies what’s already there” (não conserta um time; amplifica o que já existe). Os agentes em operações estão sujeitos à mesma regra. Se seus deploys são frágeis, agentes que aceleram a mudança vão expor essa fragilidade mais depressa.

A confiança precisa ser conquistada. O mesmo relatório DORA constatou que 30% dos respondentes tinham pouca ou nenhuma confiança em código gerado por IA. Esse ceticismo é saudável. Trate a saída do agente como o trabalho de um novo contratado competente: revise, meça e amplie o escopo só à medida que ele provar ser confiável.

Proliferação de permissões. Dê a cada agente sua própria role, com o mínimo de permissões para a função dele, registre cada ação (o AWS CloudTrail cobre as chamadas de API nas suas contas) e revise essas roles como qualquer outro acesso privilegiado.

Ruído em vez de sinal. Um agente com habilidades, mas sem julgamento, produz dashboards que ninguém lê e alertas em que ninguém confia. Escrevemos sobre essa falha, e sobre como a resolvemos, em Intent Over Instructions: nossos agentes partem de um conjunto compartilhado de crenças sobre o que importa para o cliente antes de receber qualquer instrução técnica.

Perguntas para fazer sobre ferramentas e fornecedores de AI DevOps

O que os agentes podem alterar sem a aprovação de um humano? Peça uma lista específica, não uma garantia genérica.
Como as permissões dos agentes são delimitadas e auditadas? Peça para ver as roles e os logs.
As mudanças dos agentes passam por code review e pelo mesmo pipeline das mudanças humanas? Se os agentes podem clicar no console, é um sinal de alerta.
Quem responde quando algo dá errado? Deve ser uma pessoa com nome, não um produto.
O que acontece quando o agente não tem certeza? Bons sistemas escalam. Os ruins chutam.
Quem é dono do código, dos runbooks e da configuração que os agentes produzem? Deveria ser você.

Se você também está reforçando o lado humano da resposta a incidentes, nosso post sobre gestão de incidentes para times de SaaS trata de runbooks, plantão e post-mortems.

Perguntas frequentes

O que é AI DevOps?

AI DevOps é o uso de modelos de IA na entrega e na operação de software. Vai do trabalho assistido por IA, em que um engenheiro pede a um modelo um workflow ou uma consulta e decide o que fazer com a resposta, até o DevOps agêntico, em que um agente chama ferramentas em loop para monitorar, investigar e propor mudanças. A pergunta útil é quais etapas o agente tem permissão para executar sozinho.

A IA vai substituir o DevOps?

As evidências até agora indicam que a IA muda o trabalho de DevOps em vez de substituí-lo. Os agentes assumem boa parte do monitoramento, do direcionamento, da primeira análise e das verificações de rotina, enquanto as decisões de julgamento, as mudanças de alto impacto, as falhas inéditas e a responsabilização continuam com as pessoas. A pesquisa DORA de 2025 também constatou que a IA amplifica as práticas que o time já tem, então bases sólidas de DevOps importam mais, não menos.

Qual é a melhor ferramenta de IA para DevOps?

Não existe uma única melhor ferramenta, porque a escolha certa depende do que você quer que o agente faça e no que ele pode mexer. Avalie as ferramentas de AI DevOps pelo que elas podem alterar sem aprovação, por como suas permissões são delimitadas e auditadas, por suas mudanças passarem ou não por code review e pelo que fazem quando têm dúvida. Uma ferramenta que responde bem a essas perguntas vale mais do que a que tem a lista de recursos mais longa.

Como a Webera usa agentes de IA em DevOps

A Webera é uma assinatura de DevOps para times de SaaS na AWS. Engenheiros seniores trabalham ao lado de nove agentes de IA, cada um com uma única função: Sentinel para observabilidade, Guardian para segurança, Conductor para CI/CD, Dispatcher para incidentes, Optimizer para FinOps, Navigator para redes, Keeper para bancos de dados, Forge para prontidão de aplicações e Warden para padrões.

A divisão segue o modelo acima. Os agentes fazem o monitoramento, o direcionamento e a primeira análise o dia todo e a noite toda. Os engenheiros tomam as decisões e entregam as correções. Na noite de exemplo da nossa página inicial, o Sentinel associa um pico de latência ao deploy do fim da tarde e abre um incidente, o Dispatcher aciona o engenheiro de plantão com o runbook anexado, o Keeper rastreia as queries lentas até um índice ausente e propõe a mudança, e o engenheiro a revisa e cria o índice online. A recomendação de custo que sai dessa noite espera a decisão do cliente.

Todos os planos incluem os nove agentes:

Pro, US$ 4.999 por mês. Solicitações ilimitadas, duas em andamento por vez, monitoramento 24/7 e resposta a incidentes, e prazo de entrega médio de 36 horas.
Elite, US$ 9.999 por mês. Um engenheiro designado e um gerente de sucesso do cliente, um concierge de compliance para SOC 2, HIPAA e PCI, e prazo de entrega médio de 24 horas.
Platform, US$ 14.999 por mês. Um time trabalhando dentro das suas sprints, operação multi-conta e de Kubernetes, e transferência de conhecimento para os seus engenheiros.

Cada plano tem mínimo de três meses, cobrado mensalmente, e depois segue mês a mês, e todo o código e a configuração são seus. Você pode saber mais sobre os agentes na página de agentes ou comparar os planos na nossa página de preços.

DevOps com IA agêntica: o que os agentes de IA fazem (e não fazem) em operações