O exploit era o gargalo: como a IA acelera a transformação de falhas em ataques

A tese da a16z é que, por vinte anos, o gargalo do ataque era transformar uma vulnerabilidade em exploit funcional. Um estudo da RAND de 2017, com mais de 200 zero-days, apontou mediana de 22 dias para um profissional construir um exploit. Agora esse trabalho caiu para minutos ou horas. O caso citado: em 31 de agosto, um único operador apontou algumas centenas de agentes de IA para um servidor de gerenciamento de impressão, e 395 organizações em 48 países foram comprometidas, metade delas escolas. O modelo usado era open-weight e barato.

Os dados de Mandiant mostram o tempo médio entre divulgação e ataque caindo de 63 dias em 2018-19 para cinco em 2023. Em 2024, o ataque veio em média um dia antes da divulgação, e em 2025, sete dias antes. A ressalva do texto: essas linhas se cruzaram antes dos agentes de IA. O que a IA muda é quem consegue operar nessa janela e a velocidade com que N-days (bugs que já têm patch) são transformados em arma. Do outro lado, o patching não acelerou: o Verizon DBIR 2026 traz mediana de 43 dias para corrigir uma falha explorada conhecida, contra 32 no ano anterior.

A cobertura do CEVIU já vinha tratando do tema. Em 15 de abril de 2026, em "Preparando seu Programa de Segurança para o Ataque Acelerado por IA", o foco era a pressão sobre as janelas de correção. Em 28 de maio de 2026, o CEVIU noticiou que o CERT-In sugeria patching em 12 horas para ataques assistidos por IA. Em 11 de junho de 2026, "Mensurando o impacto de LLMs em exploits N-day" explicava o risco dos bugs já divulgados. Em 27 de agosto de 2026, "Ataques com IA encurtam janela de patch, exigindo novo plano de controle de segurança" falava em janela de horas. Em 2 de outubro de 2026, veio a análise do Grupo de Inteligência de Ameaças do Google. A novidade agora é o enquadramento histórico (o exploit como gargalo por 23 anos) e os casos de campo com números concretos, como a campanha de 395 vítimas e os bugs do PHP.

Para quem opera infraestrutura, a leitura é que um SLA de 7 ou 30 dias para patch parte de uma premissa que, segundo o CISO da Amazon citado no texto, já não vale. Para quem cuida de sistemas que não podem ser atualizados rápido (controladores industriais, appliances sem suporte), o caminho passa por reduzir exposição e segmentar, não por esperar o patch. A própria a16z não prevê catástrofe, e sim surtos como os da era dos worms e do WannaCry, mais pesados onde a atualização é lenta.