Agentes de IA estão causando falhas que empresas ainda não conseguem rastrear

Você sabia que existe um tipo de incidente em produção que as equipes de engenharia ainda não estão monitorando? Isso acontece porque não se encaixa em nenhum modelo de análise de falhas que já conhecemos. Aqui está a questão: um agente de IA toma uma ação que parece correta com base no contexto que ele tinha, mas se o contexto estiver incompleto, a infraestrutura inteira pode ser afetada. Na hora de revisar o incidente, três times diferentes podem discutir se a falha foi do agente ou da infraestrutura, porque nunca conectamos esses dois conceitos.

O problema é real e não está mais só no campo das ideias. Hoje, uma grande parte das organizações já usa algum tipo de agente de IA em produção, e muitas planejam expandir isso. Isso nos leva a um ponto crucial que ninguém está capturando: falhas que ocorrem no meio desses números. Agentes estão funcionando, não são cancelados, mas estão gerando eventos na infraestrutura que ninguém classificou como risco.

Tenho experiência construindo sistemas de automação de infraestrutura em larga escala, começando pela Cisco e depois na Splunk. Durante esse tempo, patenteei uma metodologia de engenharia do caos baseada em intenção. E sabe o que vi repetidamente? Empresas tratando agentes autônomos e engenharia do caos como disciplinas separadas. Elas não são. Essa separação está gerando a próxima onda de grandes incidentes em produção.

A decisão que os agentes não tomam

Para entender por que isso é importante, precisamos ver o que está quebrado na governança do caos pelas empresas antes de adicionar agentes à equação. Equipes maduras de engenharia já investiram em programas de engenharia do caos, com simulações e controle de impacto. Quando um engenheiro humano inicia um experimento de caos, ele faz uma avaliação crítica: verifica se o sistema pode absorver a perturbação naquele momento. Ele checa dashboards, analisa o consumo do orçamento de erros e avalia se as dependências estão estáveis. Não é perfeito, mas pelo menos alguém faz a pergunta certa antes de qualquer ação.

Agora, introduza um agente autônomo que pode reiniciar serviços, redirecionar tráfego ou escalar recursos automaticamente. Aquele questionamento humano desaparece. O agente vê uma anomalia e age. Essa ação é um evento de caos. Não há verificação do consumo do SLO, cálculo de impacto ou julgamento humano sobre se aquele é o melhor momento para estressar o sistema, que já pode estar sobrecarregado.

Um exemplo clássico: um agente detecta alta latência em um microserviço e decide reiniciar o cluster de serviços. A ação parece correta com base nos dados de treinamento do agente. Mas ele não vê que outros serviços estão lidando com picos de tráfego, a pool de conexão está em alta utilização e um banco de dados dependente está em reconstrução de índice. O reinício desencadeia um efeito dominó no serviço que estava se recuperando. O que começou como um pico de latência, que o agente foi projetado para resolver, vira uma cascata que ele nunca foi projetado para modelar.

Capacidade de absorção é um recurso que a maioria dos sistemas ignora

O problema é que sistemas empresariais não têm uma linguagem comum para capacidade de absorção — a estimativa em tempo real de quanto estresse adicional um sistema pode suportar antes de quebrar compromissos de SLO. Programas de engenharia do caos gerenciam isso implicitamente, com julgamento humano e limites estáticos que disparam tarde demais. Agentes não gerenciam isso de forma alguma.

Através de pesquisa com engenheiros de confiabilidade de sites e engenheiros de plataforma, desenvolvi um modelo de orçamento de resiliência. A ideia central é tratar a capacidade de absorção como um recurso consumível, continuamente recalculado, em vez de um limite estático que não deve ser ultrapassado.

Este orçamento de resiliência se baseia em quatro sinais ao vivo: a taxa de consumo do SLO, a tendência de latência P99, o estado de saturação das dependências e sinais comportamentais da aplicação. Cada experimento de caos consome esse orçamento. Cada ação de agente também. Em organizações onde múltiplos times podem estar realizando experimentos simultaneamente, o orçamento é compartilhado. Sem um registro compartilhado de consumo, dois times podem criar um raio de impacto combinado que nenhum dos dois planejou. Adicione agentes autônomos agindo fora desse registro, e a contabilidade colapsa.

Onde modelos de linguagem ajudam, e onde eles falham

Algumas organizações estão experimentando usar modelos de linguagem para gerar hipóteses de caos a partir de gráficos de dependência e relatórios de incidentes. O problema é que, mesmo com essa ajuda, ainda lidamos com um vácuo de comunicação entre o que esses modelos conseguem prever e o que realmente acontece quando um agente autônomo toma uma decisão. E é aí que precisamos ficar atentos, porque é exatamente onde mora o perigo.