Voltemos um pouco na história, antes de entrar no artigo de hoje. Em 25 de janeiro de 2003, um programa minúsculo começou a circular pela internet. Chamava-se Slammer, explorava uma falha já conhecida e já corrigida no banco de dados SQL Server da Microsoft, e não pedia nada a ninguém: nem clique, nem anexo, nem senha. A análise do CAIDA, centro de pesquisa de tráfego de internet da Universidade da Califórnia em San Diego, registrou o resto. A população de máquinas infectadas dobrava a cada 8,5 segundos. Em dez minutos, mais de 90% dos servidores vulneráveis do mundo estavam tomados.
O detalhe que interessa não é a velocidade. É o que ela quebrou. Até ali, corrigir software era assunto de calendário humano: o fornecedor publicava quando dava, a equipe testava quando podia, o diretor aprovava a parada quando a operação permitia. O Slammer e, meses depois, o Blaster, mostraram que esse ritmo tinha deixado de existir. E a resposta do setor não foi ferramenta nova, foi processo: em outubro de 2003 a Microsoft passou a concentrar correções num dia fixo do mês, o que o mercado apelidou de Patch Tuesday, para que a empresa do outro lado conseguisse se organizar (histórico publicado pelo Microsoft Security Response Center em outubro de 2013).
Vinte e três anos depois, a conta voltou a não fechar. E agora não existe terça-feira que resolva.
O número que mudou a física do problema
A Microsoft publicou em 1º de outubro de 2026 a edição deste ano do Relatório de Defesa Digital (Microsoft Digital Defense Report), levantamento que ela monta a partir do que vê na própria operação, hoje em 165 trilhões de sinais de segurança por dia.
Três números explicam o aperto. O prazo mediano entre a descoberta de uma vulnerabilidade e o início da exploração dela em ataque real caiu para menos de 24 horas. A correção da mesma falha, quando ela está num sistema exposto na internet, leva de 30 a 60 dias na empresa típica. E quase 40 mil vulnerabilidades novas foram catalogadas só no primeiro semestre de 2026, com projeção de 72 mil no ano fechado.
Junte os três. O atacante leva menos de um dia. Nós levamos de um a dois meses. E a fila de falhas à disposição dele dobrou de tamanho. A própria Microsoft resume dizendo que a Inteligência Artificial (IA) está mudando a física da cibersegurança. Não é retórica de fornecedor.
É aritmética de relógio.
Mudou também a porta de entrada. O phishing, aquela mensagem fraudulenta que imita remetente confiável, saltou de 7% para 23% das invasões em um ano, puxado por textos personalizados em escala por modelos de linguagem. A exploração de aplicações expostas na internet subiu de 15% para 24% no mesmo levantamento.
Mas o ataque já roda sozinho de verdade?
Aqui precisa de honestidade, porque a expressão “ransomware autônomo” circula com mais confiança do que os dados sustentam.
O caso concreto existe e tem nome. Em julho de 2026, a equipe de pesquisa de ameaças da Sysdig documentou a campanha apelidada de JADEPUFFER, descrita como a primeira extorsão por ransomware conduzida de ponta a ponta por um sistema de IA: escolha do alvo, entrega da cobrança e condução do processo rodaram com participação humana mínima. A Microsoft cita o episódio e diz ter observado depois outras invasões parecidas, em volume baixo.
E a mesma Microsoft faz a ressalva que vale mais do que a manchete: a maioria das campanhas continua com humano no comando, e autonomia completa segue rara na operação real. Não estamos diante de um exército de máquinas agindo por conta própria. Estamos diante de uma prova de conceito que funcionou em produção, o que é bem diferente de ameaça teórica e bem diferente de epidemia.
Tem um sinal mais incômodo no meio técnico. O PromptLock, ransomware experimental, não carrega código malicioso: carrega instruções em texto e gera o código na hora de rodar. Estranho, né?. Mas vamos lá: se a arma só passa a existir no disparo, a defesa que procura assinatura de arquivo fica com pouco nas mãos.
Onde isso aperta para nós, do mundo real?
No Brasil, o relógio do ataque encontrou um segundo relógio, o do regulador. O Regulamento de Comunicação de Incidente de Segurança da Autoridade Nacional de Proteção de Dados (ANPD), publicado em abril de 2024, dá três dias úteis, contados do conhecimento do incidente, para avisar a autoridade e os titulares afetados. E manda guardar o registro de cada incidente por no mínimo cinco anos, inclusive dos que a empresa decidiu não comunicar.
Três dias úteis já pareciam apertados em 2024. Com invasão que vai do acesso inicial ao dado exfiltrado em minutos, virou o prazo para explicar por escrito algo que você talvez ainda não tenha entendido.
E a cobrança mudou de lugar. Análise publicada em setembro de 2026 na Capital Aberto, assinada pelo escritório Freitas Ferraz, mostra a ANPD olhando para o pós-incidente: não apenas o que aconteceu, mas o que a organização afirmou depois e o que consegue comprovar. Em julho de 2026 a autoridade abriu processo sancionador contra uma organização de saúde que administra unidades públicas, por um ataque de ransomware em 2025 que atingiu cerca de 500 mil registros de pacientes. Entre as falhas apontadas: aviso genérico no site sem detalhe do incidente, nenhuma evidência de avaliação de risco e ausência do contato do encarregado no portal.
O regulamento de dosimetria da ANPD permite reduzir a sanção para quem demonstra boa-fé, política de governança implantada e correção rápida. Demonstra. O ônus da prova é nosso, não da autoridade.
O que dá para decidir antes do incidente?
Se o ataque chega em minutos e a prova é cobrada em dias, a decisão não pode nascer no dia do incidente. Quatro coisas dão para resolver antes, e nenhuma é compra de plataforma.
A primeira é autorização prévia de contenção. Isolar máquina, revogar sessão, derrubar integração e bloquear conta de serviço costumam esperar o aval de quem está em reunião. Quem autoriza derrubar o sistema às duas da manhã? O analista de plantão? O diretor que está dormindo? Ou ninguém, que é o que acontece na maioria das vezes? Vale definir por escrito quem pode mandar derrubar o quê e em que cenário, sem ligar para ninguém. As famosas “reuniões de reuniões”, que tanto conhecemos no mundo corporativo, não cabem numa janela de minutos.
A segunda é identidade. O relatório coloca credencial comprometida e permissão excessiva no centro das invasões, e recomenda autenticação multifator resistente a phishing, aquela que não depende de código digitado e por isso não é repassável por quem caiu no golpe. Código por mensagem de texto não entra nessa categoria.
A terceira é o seu próprio agente de IA. O relatório trata sistema autônomo como superfície de ataque, e não só como defesa: credencial de agente, permissão ampla demais, acesso que ninguém revisa. Se há um agente lendo e-mail, abrindo chamado ou consultando banco de dados, ele tem crachá, e alguém responde pelo que ele fizer.
A quarta é a trilha de evidência, a que quase ninguém prepara. Não é log guardado por acaso. É registro com hora, decisão tomada, responsável e avaliação de risco, no formato que a ANPD pede, pronto para sair em três dias úteis. Montar isso durante a crise não funciona. Deixar o modelo em branco pronto, com os campos definidos e o encarregado sabendo onde ele está, funciona.
O que esperar daqui para frente?
Voltando à história: em 2003, quem tratou o susto do Slammer como defeito de produto seguiu apagando incêndio por anos. Quem entendeu que o problema era o calendário mudou o processo e passou a década seguinte em outro patamar. A tecnologia era a mesma para os dois. A diferença estava em quem havia decidido antes.
Agora o calendário encurtou de mês para minuto, e a diferença volta a não ser de ferramenta. Automação de defesa existe e vale ser avaliada. Só que ela não decide quem tem autoridade para desligar um sistema produtivo de madrugada, não escolhe as permissões do seu agente de IA, e não escreve por você a avaliação de risco que a ANPD vai pedir.
A pergunta que fica, e que eu faria antes de qualquer discussão sobre ferramenta: se um ataque desses começar hoje à noite, quem na sua empresa tem autorização para derrubar o que precisar sem pedir licença, e em quanto tempo vocês provariam, por escrito, o que foi feito?
Até o próximo Café com Bytes, com ceticismo saudável e café bem passado.
Ricardo Brasil | Especialista em IA Responsável e Diretor de TI na GWS Engenharia — Colunista Café com Bytes | Tecnologia | Inteligência Artificial
Sobre o Autor
Ricardo Brasil é Diretor de TI e Gestão Corporativa da GWS Engenharia, especialista em IA Responsável, transformação digital e governança de TI. É colunista da série Café com Bytes, onde escreve semanalmente sobre tecnologia, inteligência artificial e seus impactos no ambiente corporativo brasileiro.
