Como avaliar as alegações do agente SOC de IA: solicite o registro de falhas.

Como avaliar as alegações do agente SOC de IA: solicite o registro de falhas.

Todo SOC de IA As demonstrações dos fornecedores que vi, incluindo a nossa, são ótimas. As demonstrações são executadas com alertas selecionados, integrações funcionais e sem adversários. A questão que diferencia plataformas reais de meras demonstrações não é "consegue fechar um alerta?", mas sim "mostre-me o que deu errado no último trimestre e como você descobriu".“

Os agentes de IA para SOCs prometem automatizar a camada de investigação — o trabalho de triagem, enriquecimento e veredicto — e a avaliação estruturada é como você verifica se essa automação realmente funciona no seu ambiente. A orientação da Gartner sobre esse mercado começa com uma projeção que deve nortear toda avaliação: 701 mil, 3 trilhões de grandes SOCs testarão agentes de IA para trabalhos de Nível 1/Nível 2 até 2028, e apenas 151 mil, 3 trilhões verão uma melhoria mensurável em suas operações de segurança da informação sem uma avaliação estruturada. A avaliação estruturada não é uma simples comparação de respostas de fornecedores. É um conjunto de exigências de evidências. Aqui está o conjunto que eu usaria.

1. Solicite o registro de falhas.

Um sistema de IA em produção, ao realizar trabalho investigativo, comete erros. Isso não é motivo para desqualificação; analistas humanos também cometem erros. O que desqualifica é um fornecedor que não consegue caracterizá-los.

Perguntar: Qual é a sua taxa de falsos negativos medida em alertas fechados, como você a mede e quais foram suas três últimas falhas relevantes? Um fornecedor experiente realiza controle de qualidade contínuo, incluindo amostragem de alertas fechados por agentes para revisão humana, rastreamento das taxas de reversão de veredictos e testes de regressão do comportamento do agente quando os modelos mudam. Eles podem responder com números. Um fornecedor que responde com marketing de precisão ("precisão 99%") mas não consegue descrever a metodologia de medição está dizendo que não possui uma. Em todas as avaliações que realizei, os fornecedores que não conseguem fornecer um registro de falhas ou não medem ou não querem que você saiba.

2. Exija investigações reproduzíveis

Para qualquer veredicto, você deve poder ver: cada consulta executada pelo agente, cada resultado obtido, o raciocínio em cada etapa, o nível de confiança final e a ação tomada. Não um parágrafo resumido; o histórico completo, preservado de forma imutável.

Isso é importante por três razões distintas:

1. Operacionalmente, trata-se de como seus analistas calibraram a confiança e detectaram desvios. 
2. Contratualmente, trata-se de como você responsabiliza o fornecedor pelas suas reivindicações. 
3. E, institucionalmente, trata-se de como você defende uma decisão automatizada posteriormente, perante um auditor, um órgão regulador, uma seguradora cibernética ou seu próprio conselho administrativo. 

Se você opera sob FedRAMP, Em conformidade com as normas PCI, DORA ou equivalentes do setor, um veredicto inexplicável é uma constatação prestes a acontecer. O Gartner inclui governança e explicabilidade como uma de suas sete categorias de avaliação exatamente por esse motivo: um agente que não consegue articular um raciocínio auditável é uma caixa-preta.

3. Tornar os limites da autonomia explícitos e tecnicamente definidos.

Obtenha a resposta precisa para: quais ações este sistema pode executar sem intervenção humana, onde isso é garantido e posso configurá-lo por tipo de ação e nível de risco?

O ponto de aplicação é a parte que a maioria das avaliações ignora. "O agente está instruído a não desativar contas" é um aviso, não um controle. Um controle é uma lógica de fluxo de trabalho externa ao modelo que torna a ação impossível sem uma etapa de aprovação, funcionando como salvaguardas determinísticas em torno do raciocínio probabilístico. A estrutura da Gartner enfatiza essa mesma distinção: como as salvaguardas são aplicadas para ações de alto impacto, como desativação de contas ou isolamento de rede, e o sistema prioriza a escalação em vez da ação em situações de ambiguidade?

O projeto do mecanismo de proteção é crucial quando o sistema está lidando com uma ameaça ativa; é justamente nesse momento que os agentes estão sob maior pressão para agir e com maior probabilidade de agir incorretamente. Se um fornecedor não consegue demonstrar o mecanismo, não a política, mas o mecanismo em si, considere que ele não existe.

4. Teste a profundidade da integração, não a quantidade de integrações.

Selecione as cinco ferramentas mais importantes do seu conjunto de ferramentas e teste três níveis de cada uma: 

1. O agente consegue ler isso? 
2. É possível realizar consultas durante uma investigação (extrair uma árvore de processos, pesquisar registros de identidade, limpar uma caixa de correio)? 
3. Ele pode agir através disso, sujeito às suas restrições? 

Uma página de integração com 300 logotipos frequentemente se torna somente leitura nas ferramentas que você utiliza. É por isso que você não deve aceitar a quantidade de logotipos como verdade absoluta. Além disso, questione a arquitetura da plataforma: ela exige a centralização dos seus dados ou permite consultar onde os dados estão armazenados? Os custos e as implicações de migração variam bastante.

5. Meça os resultados em relação à sua linha de base, no seu ambiente.

Defina o sucesso antes do início da perspectiva do usuário (POV), com base em seus alertas e em seus números atuais. As métricas que valem a pena usar como referência são:

1. Tempo médio para contenção (MTTC): A métrica principal recomendada pela Gartner, pois a contenção é onde o risco é reduzido.
2. Redução de falsos positivos: Entrar em contato com os analistas, com precisão na escalação (do que se trata e o quanto se justifica).
3. Taxa de falsos negativos amostrada: Seus analistas seniores revisam uma amostra aleatória de alertas fechados por agentes. Esta é a etapa que a maioria das equipes ignora e a única que valida os fechamentos que você nunca analisaria de outra forma.
4. Custo por alerta resolvido em cargaSimule um dia de tempestade de alertas. A precificação por alerta e por token pode transformar um ataque em um evento de faturamento.

Execute o teste em um fluxo de trabalho específico e de alto volume, como triagem de phishing ou de endpoints, por 30 a 60 dias. Métricas de volume como "40.000 alertas investigados" representam atividade, não resultados; considere-as como marketing. 

6. Avalie o fornecedor, não apenas o produto.

Este mercado é jovem, saturado e está em processo de consolidação. Listas compiladas em 2026 listam quinze ou mais fornecedores, muitos com menos de cinco anos de existência. Alguns serão adquiridos; outros desaparecerão. A Gartner recomenda tratar a viabilidade do fornecedor como uma questão de risco de terceiros e priorizar contratos de assinatura mais curtos enquanto o mercado se movimenta. Questione sobre a conformidade com SOC 2 e FedRAMP, as políticas de tratamento e treinamento de modelos para seus dados e o que acontecerá com seus fluxos de trabalho e histórico de auditoria caso o produto deixe de existir.

Resumo Incômodo

A maioria das avaliações de SOC com IA falha porque são estruturadas como demonstrações e chamadas de referência, os dois canais que os fornecedores controlam melhor. Reestruture a sua em torno de evidências que o fornecedor não controla: seus alertas, sua linha de base, seus analistas seniores analisando casos encerrados e um registro de falhas que o fornecedor possui ou não.

Os fornecedores que já desenvolveram para produção receberão bem essa novidade. Os que ainda não a desenvolveram dirão que é desnecessária. Essa reação, por si só, já é a avaliação mais rápida que se pode fazer.