53% de Recall: Por Que o Próprio AIOps da Microsoft Confirma que o Engenheiro Continua a Ser Imprescindível

A Microsoft acabou de publicar um paper de engenharia sobre o ActionNex, um "Virtual Outage Manager" desplegado em piloto no Azure que ingere sinais operacionais multimodais, comprime-os em eventos críticos e recomenda ações de mitigação. É exatamente o tipo de sistema que a indústria há anos vende como o fim do on-call humano: um agente que vê o incidente, recorda incidentes passados, e diz-te o que fazer.

O aspeto interessante do paper não é a arquitetura — a perception layer, a hierarchical memory, o reasoning agent são essencialmente já o estado da arte para sistemas agênticos sérios. O que importa são os números reportados sobre oito outages reais do Azure, 8M de tokens, 4.000 eventos críticos:

• Precision: 71,4%
• Recall: 52,8–54,8%

E aqui é onde, como CTO e como alguém que levou o on-call a produção a escala enterprise, paro e digo: esta é a prova empírica mais clara que se pode dar em 2026 de que a IA em operações é implementável, mas não é substitutiva.

O que estes números significam na trincheira

Traduzo os números para a linguagem do on-call:

Precision de 71,4% quer dizer que de cada 10 ações que o ActionNex recomenda, aproximadamente 3 são erradas. Não marginalmente subótimas — erradas. Num outage real, onde cada ação modifica o estado do sistema, executar 3 de cada 10 recomendações sem filtro humano é como ter um engenheiro de on-call recém-chegado a quem ainda não darias permissões de production no primeiro mês.

Recall de 53% é o número mais consequente. Quer dizer que quase metade das ações corretas que uma equipa humana executou durante esses outages, o sistema não as propôs. Não se trata de erros — trata-se de não as ver. Metade do judgment de mitigação necessário para resolver um incidente do Azure fica fora da saída do modelo.

Se és o CTO e a postura do fornecedor é "deixa que a IA leve o on-call", a leitura imediata é: a IA levará a primeira metade. A segunda metade — aquela que distingue uma mitigação parcial de um service restoration completo — continua a ser levada pelo engenheiro.

Porque estes números não escalam com mais tempo

O argumento otimista é "sim, mas são números de um sistema em piloto, vão melhorar". Sou cético por três razões concretas que vejo cada semana fazendo DevOps numa empresa com infraestrutura não trivial.

Primeiro: a cauda longa de incidentes não se repete. O ActionNex tem um episodic memory de prior incidents. Tudo o que cai em padrões conhecidos tem alta probabilidade de acertar. Mas em sistemas complexos, uma parte importante dos outages que importam são combinações novas — o incidente que a tua infraestrutura nunca tinha visto nesta combinação de regiões, dependências, e estado de deploy. Os números agregados escondem que a precision e o recall sobre incidentes novos são sistematicamente piores do que sobre padrões recorrentes. Os SREs senior não custam o que custam porque recordam runbooks; custam o que custam porque reconhecem padrões que não estavam no runbook.

Segundo: os incentivos do modelo não se alinham com o custo assimétrico de uma ação errada. Em produção, uma ação errada durante um outage não é uma predição errada — é uma mitigação que potencialmente piora o blast radius. O custo de um falso positivo (executar uma ação desnecessária ou prejudicial) e o custo de um falso negativo (não ver a ação correta) não são simétricos, e os objetivos de treino da maioria dos modelos reasoning não os distinguem bem. Podes otimizar a precision subindo o threshold, mas então o recall desce ainda mais. Não há saída fácil só com mais dados.

Terceiro: a verificação em runtime não é grátis. Uma das descobertas implícitas do paper é que as "human-executed actions" são o feedback que melhora o sistema. Em modo simples: o sistema melhora porque o engenheiro continua a julgar cada recomendação. Se tiras o engenheiro do loop, tiras também o sinal de aprendizagem. A IA em operações precisa do engenheiro não só como safety net, mas como fonte de gradiente.

O contraste com o paper de visão "self-managing"

Tenho estado a ler em paralelo um paper de visão do IEEE de finais de 2025, AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), que descreve o futuro da disciplina assim:

"...emerging technologies such as generative AI enable fully automated pipeline capable of code generation, error detection, deployment, and performance monitoring with minimal human intervention. ... a future where software systems evolve into self managing, self improving ecosystems."

É a linguagem que ouço cada trimestre nos comités de fornecedores. Minimal human intervention. Self-managing. Self-improving. E, como CTO, tens de saber traduzi-la.

Quando colocas o paper do ActionNex e o paper do IEEE um ao lado do outro, a assimetria é inevitável: um é a realidade empírica do melhor sistema em piloto numa das maiores nuvens do mundo, o outro é a visão aspiracional. A distância entre os dois é exatamente o espaço onde vivem os teus engenheiros. E é grande. Um recall de 53% não é um sistema "self-managing"; é um sistema que precisa de um humano para os 47% restantes de qualquer decisão não trivial.

O que muda (e o que não) numa prática DevOps madura

Sou claro: o ActionNex e sistemas semelhantes são úteis. Implementá-los-ia. Mas com as juntas que a maturidade operacional exige.

O que muda:

• A primeira triagem pode-se acelerar significativamente. As recomendações corretas são corretas; num outage o relógio é caro, e ter um agente que te oferece as hipóteses mais prováveis antes de abrires o dashboard é valor real.
• A descoberta de padrões históricos deixa de depender da memória humana. O episodic memory é exatamente a coisa que os humanos fazemos pior — recordar que incidente semelhante ocorreu há dezasseis meses e que mitigação funcionou. Aqui a IA bate o humano claramente.
• A documentação post-mortem pode ser gerada com muito menos atrito. O que antes eram três dias de redação pode ser um draft revisto numa hora.

O que não muda:

• A autoridade de tomar a ação continua humana. Nenhum mecanismo de governança sério em 2026 deveria autorizar um agente a executar ações com grande blast radius sem aprovação humana explícita para 100% dos casos com confidence < 99%, e a confidence calibrada a 99% sobre incidentes novos é uma fantasia.
• O ownership do incidente continua humano. Alguém tem de responder ao postmortem. A IA não responde a postmortems. Essa é a fronteira que não se atravessa com um upgrade de modelo.
• O judgment sobre o que é aceitável degradar continua humano. A pergunta "o que deixamos cair para que o resto sobreviva" depende do contexto de negócio, do cliente, do contrato. A IA pode propor candidatos; o humano decide.

A pergunta a fazer quando alguém te vende um AIOps "autónomo"

Quando um fornecedor ou consultor te apresenta um sistema AIOps com o discurso de "self-healing", a pergunta não é "que precision tens?". A pergunta é:

"Na tua amostra de validação, dos casos onde o sistema decidiu não atuar, em quantos a ação correta era não atuar?"

Isso é o recall sobre o complemento. A maioria dos fornecedores não te dará o número, porque não é bonito. O ActionNex, mérito da Microsoft, publica-o indiretamente: 47% dos casos onde havia uma ação correta, o sistema não a propôs. Não "não atuar" — não a ver. É um número honesto. A maioria das demos comerciais mostra-te o subset onde o sistema brilha.

Essa é a pergunta diagnóstica: se o fornecedor não te a pode responder, não estás a comprar um sistema de operações, estás a comprar uma demo.

O que recomendaria este trimestre

Três ações concretas para um CTO ou head de DevOps que está a receber pressão para "automatizar o on-call com IA":

1. Implementa AIOps como copilot, não como operator. O agente sugere; o engenheiro aprova e executa. Nenhuma ação com blast radius maior do que um cambio reversível se delega autonomamente. Essa linha escreve-se na política, não no runbook.
2. Mede o recall sobre incidentes novos, não sobre o conjunto agregado. Se o teu fornecedor só te reporta números agregados, exige a separação entre padrões recorrentes e casos novos. A diferença costuma ser dramática.
3. Investe no engenheiro como fonte de gradiente. Trata cada decisão humana de mitigação como dado de treino. O valor da tua equipa de SRE não é só resolver incidentes; é gerar o corpus que faz o copilot melhorar. Se o tratas como substituível, perdes também o fluxo de melhoria.

A linha que defendo é simples e, parece-me, agora está empiricamente apoiada: a IA em DevOps é implementável e tem ROI claro como augmentação. Não é substitutiva. O paper do ActionNex não é a prova do fracasso da IA — é a prova de que os fornecedores de AIOps mais capazes do mundo, com os melhores dados e os melhores engenheiros, ainda constroem sistemas que precisam do engenheiro para os 47% restantes. Se isto é verdade para a Microsoft sobre Azure, é verdade para a tua infraestrutura, quase de certeza com números mais modestos.

O engenheiro não se está a substituir. Está-se a alavancar. As equipas e os CTOs que entendem a diferença são os que enviarão sistemas fiáveis nesta década.

---

Fontes:

• Lin, Z., Hu, H., Hao, M., et al. ActionNex: A Virtual Outage Manager for Cloud Computing. arXiv:2604.03512 (2026). arxiv.org/abs/2604.03512
• Kiran Raj K M, Karthik K Poojary, Abhay, Aishwarya R S, Lathesh Kumar S R. AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines. ICECMSN 2025. DOI:10.1109/ICECMSN68058.2025.11382867

Estás a construir capacidade DevOps/SRE e precisas de engenheiros senior que saibam onde a IA aumenta e onde não? Fala com um CTO sobre desplegar um squad nearshore com maturidade operacional real, não só certificações de fornecedor.