A adoção de IA está se disseminando entre as equipes de operações de segurança. A pesquisa State of AI in Security Operations 2026, da Prophet Security, com mais de 250 CISOs, líderes de SOC e profissionais da área, constatou que 40% das equipes usam IA diariamente, enquanto outros 56% estão testando a tecnologia. Apenas 4% disseram não ter planos de adotar a tecnologia.
Para as equipes que ainda avaliam a IA, a questão principal é saber se seu SOC está preparado para implantar agentes. A preparação tem duas dimensões: os problemas operacionais que um agente de IA poderia resolver e as bases técnicas e de governança necessárias para investigar alertas com precisão.
Os agentes de IA são mais úteis em SOCs que lidam com escalonamentos atrasados de detecção e resposta gerenciadas, falta de contexto, cobertura limitada dos provedores, acúmulos de alertas e pouca visibilidade sobre as decisões de investigação. As equipes internas também podem ter dificuldade para responder rapidamente se são afetadas por uma nova vulnerabilidade ou campanha, investigar alertas de menor gravidade, ajustar detecções ruidosas, realizar buscas por ameaças e manter a cobertura fora do horário normal de trabalho.
A pesquisa constatou que 60% dos entrevistados já tinham visto um alerta ignorado ou perdido posteriormente se tornar um problema grave, como uma violação ou interrupção de serviço. Ela também relatou que 28% dos alertas nunca são investigados. Essas pressões fazem com que a busca proativa e a engenharia de detecção concorram com o tratamento diário de alertas.
O modelo de maturidade do SOC descrito pela Prophet Security coloca o gerenciamento de alertas na base, seguido por cobertura de detecção, conscientização sobre ameaças, busca proativa e melhorias de postura. Os agentes de IA geralmente começam com a investigação de alertas, embora plataformas mais novas também possam oferecer suporte à busca por ameaças e à engenharia de detecção. O tempo recuperado do trabalho rotineiro pode então ser redirecionado para atividades mais acima no modelo.
A preparação técnica começa pelo acesso. Um agente só pode investigar dados que consegue consultar, portanto as integrações relevantes podem incluir o SIEM, o EDR, o provedor de identidade, plataformas de nuvem, e-mail e aplicações SaaS importantes. Ele também precisa de contexto legível, como criticidade dos ativos, funções dos usuários, listas de VIPs, unidades de negócio e atividades conhecidas como benignas. Monitorar a integridade e a atualidade dos pipelines de registro também é igualmente importante, pois dados ausentes ou atrasados podem fazer uma investigação parecer concluída quando faltam evidências críticas.
Um teste prático consiste em analisar cinco incidentes recentes e listar todas as consultas usadas por um analista sênior para resolvê-los. Qualquer consulta que o agente proposto não consiga executar identifica uma lacuna de acesso ou integração. O tratamento dos dados também deve ser examinado: 44% dos entrevistados da pesquisa citaram a privacidade dos dados e o treinamento de modelos de IA como um grande obstáculo. As organizações devem perguntar aos fornecedores se os dados dos clientes são usados para treinar modelos e onde esses dados são processados.
Um piloto também precisa de uma definição escrita de investigação concluída. Esse padrão deve especificar as evidências necessárias para casos comuns, incluindo alertas de phishing e de deslocamento impossível, e o que é suficiente para classificar um alerta como benigno. As organizações devem registrar métricas de referência, como a porcentagem de alertas investigados, o tempo médio para investigar, o tempo até a primeira análise e a taxa de reabertura de alertas encerrados.
O relatório afirma que uma investigação completa leva em média 75 minutos e que os alertas frequentemente esperam quase uma hora antes de serem abertos. Ele também diz que até 40% das organizações desativaram algumas detecções porque não tinham capacidade para analisá-las. Uma lista documentada dessas detecções pode ajudar a identificar onde uma investigação automatizada adicional poderia restaurar a cobertura.
A governança deve distinguir entre investigação e resposta. Na pesquisa, 57% das equipes exigiam análise humana antes de cada decisão da IA de encerrar um alerta. Para ações de resposta, 44% usavam IA para recomendar ações a serem realizadas por pessoas, enquanto 30% permitiam remediação autônoma em casos de baixo risco. Nenhum entrevistado relatou conceder autonomia total e sem supervisão.
Antes de um piloto, as organizações devem definir quais ações sempre exigem aprovação, quem pode ampliar as permissões do agente, onde suas conclusões aparecerão e quem é responsável por revisar erros. Começar com acesso investigativo somente de leitura e ampliar as permissões gradualmente segue a mesma abordagem cautelosa usada ao introduzir um novo analista humano.
A lista de verificação de preparação proposta separa a necessidade de IA da capacidade de implantá-la. Pode haver um forte argumento para a adoção quando os alertas chegam tarde, os provedores não têm contexto, as investigações atrasam, as detecções foram desativadas ou casos difíceis dependem de apenas alguns analistas seniores. A preparação para a implantação, por sua vez, depende de acesso a APIs, contexto disponível sobre ativos e usuários, padrões de investigação escritos, regras de aprovação, monitoramento das fontes de registro, dados de desempenho de referência, um registro das detecções desativadas e um plano para usar o tempo devolvido à equipe.
Se o SOC não estiver preparado, a preparação recomendada consiste principalmente em trabalho de configuração e documentação. As equipes podem começar fechando as lacunas de acesso identificadas na análise dos cinco incidentes, documentando padrões para seus tipos de alerta de maior volume e executando um agente em paralelo aos analistas durante várias semanas. As intervenções dos analistas devem ser registradas como informações sobre contexto ausente ou comportamento incorreto. As permissões podem então ser ampliadas uma categoria de ação por vez.
Construir um agente interno é outra opção, mas a pesquisa indica riscos significativos. Entre os usuários de IA, 72% haviam tentado criar ferramentas internas de IA, e 46% desses projetos foram abandonados, não chegaram à produção ou foram substituídos por um produto comercial. Além de um protótipo, as equipes precisam manter integrações, lidar com alterações nas APIs e limites de taxa, gerenciar descontinuações de modelos, repetir avaliações e testes de injeção de prompts e preservar trilhas de auditoria que expliquem as decisões sobre os alertas.
A Prophet Security descreve sua própria plataforma Prophet AI como compatível com investigação, busca por ameaças e engenharia de detecção. Seu agente SOC Analyst consulta ferramentas de segurança e registra as perguntas, consultas e evidências por trás das decisões, enquanto as ações de resposta continuam sujeitas às permissões definidas pelo cliente e à aprovação humana padrão. Seu componente Threat Hunter foi projetado para executar buscas por ameaças recém-divulgadas e investigações agendadas, e seu componente Detection Engineer usa resultados de investigações e lacunas de cobertura para propor e testar detecções antes da aprovação.
Segundo a empresa, as conclusões dessas funções alimentam umas às outras: as investigações podem revelar detecções ruidosas ou ausentes, as buscas podem examinar essas lacunas e seus resultados podem orientar novas regras de detecção. A Prophet Security também afirma que os dados dos clientes não treinam seus modelos e que seu plano de dados pode ser executado dentro da própria nuvem privada virtual do cliente.
Fontes: The Hacker News.