IA acelera descoberta de vulnerabilidades e transforma remediação no novo gargalo

A inteligência artificial está acelerando a descoberta de falhas de segurança, mas esse ganho pode criar um problema operacional inesperado: encontrar vulnerabilidades em uma velocidade muito maior do que as equipes conseguem validar, priorizar e corrigir. Um novo relatório da Bain & Company mostra que, em grandes organizações que já usam IA na defesa, o volume de alertas de vulnerabilidade pode crescer em até oito vezes — deslocando o gargalo da detecção para a remediação.

Durante anos, uma parte importante da estratégia de gestão de vulnerabilidades esteve concentrada em ampliar cobertura de varredura, melhorar inventário e reduzir o tempo necessário para identificar falhas. A adoção de inteligência artificial começa a mudar essa equação. Ferramentas capazes de analisar código, configurações, ativos e dependências em grande escala estão aumentando a capacidade de descoberta, mas a correção continua dependente de contexto, responsáveis, janelas de mudança, testes, validação e capacidade de engenharia.

É esse descompasso que a Bain descreve no relatório Cybersecurity’s New AI Imperative: Attacking the Backlog of Vulnerability Alerts, publicado em 29 de setembro de 2026. Segundo a consultoria, organizações que estão entre as primeiras a aplicar modelos de IA à defesa relatam aumentos de até oito vezes no volume de alertas. O número não deve ser interpretado como uma média universal, mas como um sinal do que pode acontecer quando a capacidade de descoberta cresce mais rápido do que a capacidade operacional de resposta.

Mais alertas não significam necessariamente menos risco

O efeito é paradoxal. Uma empresa pode melhorar significativamente a visibilidade de suas vulnerabilidades e, ainda assim, permanecer exposta porque a fila de correções cresce mais rapidamente do que a capacidade de reduzi-la. Nesse cenário, o indicador “quantidade de vulnerabilidades encontradas” deixa de representar apenas eficiência de detecção e passa também a revelar pressão sobre a operação.

A própria infraestrutura pública de vulnerabilidades enfrenta um problema semelhante de escala. Em abril de 2026, o NIST informou que as submissões de CVEs cresceram 263% entre 2020 e 2025 e que, somente nos três primeiros meses de 2026, estavam quase um terço acima do mesmo período do ano anterior. Como resposta, a National Vulnerability Database passou a adotar um modelo de enriquecimento baseado em risco, priorizando, entre outros critérios, vulnerabilidades presentes no catálogo Known Exploited Vulnerabilities da CISA.

Essa mudança ajuda a explicar por que uma fila baseada apenas em severidade técnica tende a perder eficiência. O CVSS continua útil, mas não responde sozinho a perguntas decisivas: a vulnerabilidade é explorável no ambiente real? O ativo está acessível ao atacante? Existe exploração conhecida? Quais privilégios seriam obtidos? Há dependências que ampliam o alcance da falha? Qual seria o impacto sobre serviços críticos?

O gargalo muda da descoberta para a decisão

Na prática, uma vulnerabilidade descoberta por uma ferramenta precisa atravessar uma cadeia de decisões antes de ser realmente tratada. O achado deve ser validado, associado ao ativo correto, enriquecido com contexto de ameaça e exposição, atribuído a um responsável, convertido em mudança técnica, testado e implantado sem criar indisponibilidade ou regressão.

Quando a IA multiplica a primeira etapa e as demais continuam praticamente no mesmo ritmo, surge um backlog crescente. A Bain aponta que organizações mais maduras estão mudando a priorização para considerar fatores como explorabilidade, alcance, dependências sistêmicas e potencial de impacto — o chamado blast radius — em vez de tratar cada vulnerabilidade como um evento isolado.

Essa lógica é coerente com a recomendação da CISA de usar o catálogo Known Exploited Vulnerabilities Catalog como uma das entradas para a priorização. A presença de exploração conhecida não elimina a necessidade de avaliar o contexto do ativo, mas ajuda a distinguir uma exposição teórica de uma vulnerabilidade que já está sendo usada por atacantes.

Os riscos de uma fila que cresce sem capacidade de remediação

O primeiro risco é uma falsa sensação de maturidade. A organização passa a enxergar mais problemas, mas pode interpretar o aumento de detecção como redução equivalente do risco. Se o tempo entre identificação e correção continuar elevado, a exposição permanece — apenas ficou mais visível.

Outro risco é a priorização automática sem contexto suficiente. Modelos podem ajudar a correlacionar informações e estimar relevância, mas decisões que afetam produção precisam considerar criticidade do serviço, dependências, controles compensatórios, possibilidade de exploração e impacto de uma mudança. Automatizar a classificação sem qualidade de dados pode apenas acelerar uma decisão ruim.

Também há o problema da dívida técnica. Sistemas legados, componentes sem suporte, aplicações difíceis de alterar e arquiteturas com dependências antigas tendem a concentrar vulnerabilidades que não podem ser corrigidas com um simples patch. A Bain destaca justamente essas exposições estruturais, além de riscos em redes, SaaS e terceiros, como áreas que exigem tratamento além da rotina tradicional de atualização.

O impacto chega ao negócio quando a fila começa a disputar capacidade com desenvolvimento, operações e transformação digital. Entre as organizações analisadas pela Bain, há casos em que uma parcela relevante dos recursos humanos de cibersegurança foi redirecionada para remediação, além de aumento de orçamento e uso de terceiros. O ponto central não é transformar esses percentuais em benchmark, mas reconhecer que a descoberta automatizada gera uma demanda real de engenharia.

Como preparar a operação para o aumento dos achados

O primeiro passo é evitar ampliar a capacidade de varredura isoladamente. Antes de acelerar a descoberta, a organização precisa saber como os achados serão validados, quem será responsável por cada classe de ativo, quais SLAs de correção fazem sentido e quais janelas de mudança, testes e mecanismos de rollback estarão disponíveis. A automação deve ser planejada de ponta a ponta, não apenas na entrada da fila.

A priorização precisa combinar severidade com contexto. Exploração conhecida, exposição à Internet, caminhos de ataque, alcance lateral, privilégios, criticidade do ativo, dependências e impacto potencial devem influenciar a ordem da remediação. Em ambientes maduros, o objetivo deixa de ser “corrigir primeiro o maior CVSS” e passa a ser reduzir primeiro a exposição com maior probabilidade e consequência.

Correções repetitivas e de baixo risco podem ser automatizadas, mas com controles. Testes prévios, implantação gradual, monitoramento pós-mudança, rollback e aprovação humana em alterações sensíveis ajudam a impedir que a busca por velocidade produza indisponibilidade. O princípio de human in the loop é particularmente importante quando a IA participa da decisão ou da execução de mudanças.

Para ativos que não podem ser corrigidos rapidamente, a resposta deve incluir medidas compensatórias. Segmentação, redução de exposição, restrição de privilégios, controles de acesso, monitoramento adicional, bloqueios específicos e até retirada de serviço podem reduzir o risco enquanto a correção definitiva não é viável. Em alguns casos, a solução mais segura é substituir ou aposentar a tecnologia que mantém a dívida de vulnerabilidades ativa.

A gestão de terceiros também precisa ser contínua. Uma dependência SaaS, biblioteca ou fornecedor pode mudar mais rapidamente do que os ciclos tradicionais de assessment. Inventário de dependências, requisitos contratuais, monitoramento de exposição e evidências atualizadas de segurança tornam-se parte do mesmo problema de vulnerabilidade.

Métricas precisam medir redução de risco, não volume de alertas

Se a IA aumenta a quantidade de achados, contar vulnerabilidades abertas pode se tornar uma métrica ainda mais enganosa. Indicadores mais úteis incluem o tempo entre detecção, validação e correção; idade do backlog crítico; percentual de vulnerabilidades exploráveis e alcançáveis ainda abertas; violações de SLA; concentração de exposição em sistemas legados; e volume de riscos sem proprietário definido.

Essas métricas ajudam a liderança a enxergar se a capacidade de remediação acompanha a capacidade de descoberta. O NIST já reconheceu, na própria operação da NVD, que o crescimento do volume exige priorização baseada em risco e automação para manter sustentabilidade. Para as empresas, o desafio é semelhante: a tecnologia precisa aumentar a capacidade de decisão e execução, não apenas produzir uma fila maior.

Referências

Cybersecurity’s New AI Imperative: Attacking the Backlog of Vulnerability Alerts

NIST Updates NVD Operations to Address Record CVE Growth

Known Exploited Vulnerabilities Catalog

Conclusão

A inteligência artificial pode tornar a gestão de vulnerabilidades mais rápida e abrangente, mas não elimina a parte mais difícil do processo: decidir o que corrigir primeiro e executar a correção com segurança. Se a descoberta cresce oito vezes e a capacidade de remediação permanece praticamente igual, a organização não resolveu o problema — apenas o tornou mais visível.

O avanço real acontece quando visibilidade, priorização, engenharia e governança evoluem juntas. A próxima etapa da gestão de vulnerabilidades não será medida pela quantidade de alertas que uma ferramenta consegue produzir, mas pela velocidade e consistência com que a empresa transforma esses alertas em redução comprovável de risco.