A Orientação de Segurança de IA da Ivanti Reduziu Horas, mas Sua Skill do Claude Inventou Detalhes

A Ivanti revelou que sua skill de análise de patches baseada em Claude inventou detalhes, apesar de reduzir um fluxo de trabalho recorrente de horas para minutos. O sistema de orientação de segurança de IA da Ivanti confundiu edições do Microsoft Office e interpretou incorretamente, de forma repetida, o ritmo de lançamentos da Adobe durante o desenvolvimento.

Essa admissão é importante porque o resultado ajuda equipes de segurança a priorizar vulnerabilidades após o Patch Tuesday mensal da Microsoft. Uma fabricação plausível pode distorcer quais sistemas recebem atenção primeiro, mesmo quando toda vulnerabilidade citada é real.

A Ivanti respondeu com uma etapa de aprovação humana e identificou publicamente o papel do Claude em um gráfico de junho. CrowdStrike e Palo Alto Networks também mantêm pessoas envolvidas em automações de segurança consequentes, mas nenhuma das duas descreveu publicamente ter detectado uma fabricação comparável.

A história, portanto, é maior do que um único modelo cometendo erros. É um teste de se os fornecedores divulgarão como a IA molda orientações operacionais, o que seus revisores realmente verificam e quais erros permanecem invisíveis.

A Orientação de Segurança de IA da Ivanti Entrou em Produção Após Meses de Correções

A Ivanti colocou sua skill do Claude em produção somente depois que seus desenvolvedores detectaram repetidamente detalhes fabricados ou confundidos durante o treinamento.

Chris Goettl, vice-presidente de gerenciamento de produtos para segurança de endpoints da Ivanti, construiu a skill em torno de um processo que executava manualmente havia aproximadamente uma década. Ela ingere avisos publicados por fornecedores e as próprias planilhas da Ivanti, depois aplica o método de priorização de risco de ameaças da empresa.

Uma skill, neste contexto, é um conjunto reutilizável de instruções, fontes e regras de fluxo de trabalho fornecido a um modelo de IA. Isso não significa que o modelo compreenda de forma independente o sistema de divulgação de todos os fornecedores.

Goettl treinou o sistema, um fornecedor por vez. A Microsoft veio primeiro porque suas planilhas para download ofereciam entradas relativamente estruturadas. A Adobe exigiu uma abordagem diferente, pois o modelo precisava interpretar páginas individuais e seus layouts variáveis.

Essa diferença expôs uma fraqueza importante. A skill produziu repetidamente o ritmo errado de lançamentos da Adobe. Ela também confundiu edições do Microsoft Office, que a Microsoft separa em diversas famílias de produtos.

Essas não eram falhas estilísticas. O ritmo de lançamentos e a identidade do produto afetam a forma como analistas interpretam atividades incomuns, softwares afetados e a urgência de aplicar patches. Um resumo bem elaborado com o padrão errado ainda pode levar uma equipe na direção errada.

Goettl descreveu ter confrontado o sistema quando uma resposta pareceu obviamente sem suporte. Segundo seu relato no pipeline assistido por IA, Claude reconheceu que o material inventado não tinha uma base referenciável.

A Ivanti afirma que a skill usa apenas avisos públicos de fornecedores e planilhas controladas pela empresa. Ela não processa dados de clientes, e todo resultado gerado permanece como rascunho até que uma pessoa o aprove.

O gerente sênior de produto Todd Schell reexecutou o sistema com base em dois meses de briefings anteriormente montados à mão. A Ivanti relatou 98 por cento de alinhamento, reconhecendo, ao mesmo tempo, que ainda havia casos de borda.

Esse número exige interpretação cuidadosa. A VentureBeat não auditou de forma independente os dados-fonte, o método de pontuação, a taxonomia de erros ou os resultados da reexecução. O alinhamento também não estabelece que todas as vulnerabilidades relevantes apareceram no resultado gerado.

A primeira execução em produção ocorreu em agosto de 2026, enquanto Goettl estava de férias. Uma planilha que antes exigia cerca de quatro horas de cada um de dois funcionários teria sido concluída em menos de 30 minutos.

O fluxo de trabalho mensal mais amplo consumia cerca de 48 horas combinadas em torno de cada Patch Tuesday. A Ivanti estimou que esse esforço representava pelo menos 5 por cento do tempo de trabalho combinado de Goettl e Schell.

O ganho operacional é fácil de entender. Uma máquina pode coletar, normalizar e ordenar uma grande atualização mais rapidamente do que dois especialistas conseguem copiar manualmente campos entre planilhas.

No entanto, a Ivanti não retirou o especialista do processo. A empresa mudou o trabalho do especialista, que passou de montar cada linha para revisar um rascunho produzido por máquina.

Essa distinção define o conflito central. A automação economiza tempo ao reduzir a construção manual, enquanto uma orientação de segurança confiável ainda depende de julgamento humano e verificação no nível da fonte.

A Ivanti também deixou uma divulgação visível antes de a história mais ampla surgir. Sua publicação sobre o Patch Tuesday de junho identificou um gráfico como gerado com Claude, usando prompts criados pelo autor e o conjunto de dados de Goettl.

Nenhuma regulamentação exigia essa legenda. Nenhum padrão comum do setor ditava sua redação. A divulgação permaneceu disponível publicamente por cerca de três meses antes de receber escrutínio mais amplo.

Essa legenda discreta tornou-se significativa quando as falhas de desenvolvimento vieram à tona. Ela conectou um artefato gerado por IA a um modelo identificado, um autor humano, uma data e um conjunto de dados definido.

Isso é mais transparência do que um rótulo genérico de “assistido por IA”. Ainda assim, não revela quais linhas foram verificadas, como a completude foi medida ou se os níveis de risco publicados receberam validação independente.

O Problema dos Dados do Patch Tuesday Tornou a Automação Atraente

A pressão imediata veio de um processo de Patch Tuesday que se tornou maior, menos padronizado e mais dependente da interpretação de cada fornecedor.

Em 8 de setembro de 2026, a Microsoft lançou o que vários pesquisadores de segurança descreveram como seu maior Patch Tuesday. Ainda assim, os totais publicados diferiram substancialmente entre organizações que analisavam o mesmo lançamento.

A Tenable contou 964 vulnerabilidades, incluindo 104 classificadas como críticas e 860 como importantes. Sua análise de setembro também identificou duas vulnerabilidades exploradas ativamente antes de os patches se tornarem disponíveis.

A Ivanti contou 973. A Senserva contou 1.169 porque mapeou vulnerabilidades em relação a artigos da base de conhecimento, em vez de usar o mesmo método centrado em avisos adotado por outros rastreadores.

A diferença entre os totais da Tenable e da Senserva foi de 205 vulnerabilidades. Essa lacuna superou o recorde anterior de Patch Tuesday citado pela Ivanti, que foi de 175 vulnerabilidades em outubro de 2025.

Essas diferenças não provam que um modelo de IA cometeu um erro. Elas podem resultar de escolhas legítimas sobre escopo, entradas duplicadas, variantes de produtos, limites de avisos e mapeamentos de bases de conhecimento.

Elas mostram por que um único total mensal não pode ser tratado como um fato neutro. Cada contagem publicada agora reflete um método de análise e uma definição do que pertence ao conjunto.

A Microsoft intensificou esse problema quando deixou de apresentar uma lista mensal consolidada de CVEs em seu Security Update Guide. A Rapid7 documentou a mudança enquanto preparava sua revisão de patches de julho.

Agora, cada fornecedor de segurança precisa reconstruir o lançamento a partir dos dados disponibilizados pela Microsoft. Essa reconstrução pode envolver código determinístico, análise manual, um modelo de IA ou uma combinação dos três.

Um analisador determinístico segue regras explícitas e produz o mesmo resultado quando recebe entradas idênticas. Um modelo de linguagem de grande porte pode interpretar páginas inconsistentes com mais flexibilidade, mas também pode gerar relações sem suporte.

Essa compensação se torna especialmente importante quando o resultado não é apenas uma contagem. As equipes de segurança precisam de priorização baseada em exploração ativa, divulgação pública, gravidade, exposição de ativos e importância para o negócio.

Uma contagem incorreta pode confundir relatórios. Uma prioridade incorreta pode redirecionar capacidade escassa de aplicação de patches para longe de uma ameaça que invasores já estão explorando.

O briefing em webinar da Ivanti supostamente alcança entre 500 e 700 participantes todos os meses. Esses participantes não necessariamente copiam cada recomendação diretamente para produção, mas o público dá a cada decisão de priorização um alcance significativo.

A pressão de tempo também é real. As equipes de segurança não podem examinar calmamente quase mil entradas antes que os invasores ajam.

A CrowdStrike relatou que 88 por cento da exploração observada envolvendo uma prova de conceito pública começou em até 48 horas. Uma prova de conceito é código ou documentação técnica disponível publicamente que demonstra como uma vulnerabilidade pode ser explorada.

Os requisitos federais podem ser ainda mais rigorosos. A Binding Operational Directive 26-04 da CISA estabeleceu uma janela de três dias para remediação das vulnerabilidades de maior risco em agências civis federais.

Nessas condições, os fornecedores têm um forte incentivo para automatizar a coleta e a classificação preliminar. Esperar por uma revisão manual perfeita pode, por si só, criar risco.

A questão não é se as organizações devem usar IA. É se elas conseguem provar que a aceleração não removeu vulnerabilidades críticas, corrompeu mapeamentos de produtos ou elevou sinais fracos.

A experiência da Ivanti mostra por que essa prova não pode vir da fluência. O resultado incorreto do modelo parecia suficientemente convincente para exigir reconhecimento especializado e confronto direto.

Os compradores de segurança, portanto, sofrem pressão de ambos os lados. Eles precisam de orientação mais rápida, mas não podem presumir que um briefing mais rápido e bem escrito contém um conjunto completo ou corretamente priorizado.

A Verdadeira Inversão É a Divulgação, Não a Fabricação

A parte surpreendente não é que Claude tenha fabricado detalhes; é que a Ivanti descreveu as falhas e preservou uma etapa humana visível.

Modelos de linguagem de grande porte geram texto prevendo sequências prováveis a partir de seu treinamento e do contexto fornecido. Eles não garantem inerentemente que cada afirmação corresponda a uma fonte fornecida.

A fabricação, frequentemente chamada de alucinação, ocorre quando um modelo apresenta informações sem suporte como se estivessem fundamentadas. Nesse fluxo de trabalho, a falha apareceu como padrões incorretos de fornecedores e famílias de software confundidas.

Essas fraquezas já são conhecidas em sistemas de IA de uso geral. O que eleva os riscos é sua inserção em um pipeline que produz recomendações de segurança.

Um erro de chatbot para consumidores pode desperdiçar o tempo de um leitor. Uma linha de vulnerabilidade ausente em uma orientação operacional pode atrasar a remediação em um sistema exposto.

A divulgação da Ivanti não eliminou esse risco. Ela tornou o risco inspecionável.

A empresa vinculou o nome de um modelo e a responsabilidade humana a pelo menos um gráfico publicado. Goettl também explicou quais problemas surgiram durante o treinamento e por que a etapa de revisão continuou necessária.

Esse nível de especificidade ajuda clientes a fazer perguntas melhores. Eles podem distinguir a coleta assistida por modelo da priorização autônoma e perguntar qual etapa recebe verificação humana.

A admissão também complica as mensagens convencionais de confiança. Fornecedores normalmente destacam ganhos de precisão, velocidade de processamento ou produtividade de analistas ao anunciar recursos de IA.

Falhas de desenvolvimento raramente recebem atenção equivalente. Esse desequilíbrio incentiva compradores a avaliar um fluxo de trabalho usando seu melhor benchmark, em vez de seus modos de falha conhecidos.

Os 98 por cento de alinhamento relatados pela Ivanti ilustram o perigo. O número parece tranquilizador, mas seu significado prático depende do que ficou dentro da diferença restante.

Uma discrepância de formatação sem importância e uma vulnerabilidade explorada ativamente omitida não deveriam receber o mesmo peso. Uma avaliação útil deve classificar erros pela consequência operacional.

A completude merece tratamento separado da correção. Um revisor pode detectar uma gravidade incorreta ou uma descrição malformada em uma linha visível, mas não consegue perceber facilmente uma linha ausente.

Este é o desafio mais contundente à narrativa da revisão humana. Ler conteúdo gerado não é o mesmo que conciliá-lo com um inventário autoritativo de fontes.

Kayne McGladrey, diretor virtual independente de segurança da informação e membro sênior do IEEE, argumentou que os clientes precisam de uma descrição escrita do pipeline. Ele disse que os fornecedores deveriam explicar onde o modelo opera, como os CVEs são analisados, quem revisa o conteúdo e quanto dele recebe verificação na fonte.

Sua crítica foi além de pedir uma assinatura humana. Uma reexecução em meses anteriores produzidos por humanos pode medir a similaridade sem provar a correção do mês atual.

Um revisor humano também pode compartilhar o ponto cego do modelo. Se ambos se concentrarem nas entradas visíveis, nenhum descobrirá um item que desapareceu antes do início da revisão.

O padrão relevante é, portanto, a rastreabilidade. Cada recomendação publicada deve estar ligada a uma entrada autoritativa, enquanto cada entrada autoritativa deve ter um destino registrado.

Essa segunda direção é a mais importante. Ela transforma a revisão de “Este rascunho parece razoável?” em “Cada item de origem pode ser contabilizado?”

É aqui que a combinação de conhecimento disciplinada se torna relevante além do processo de correção de falhas. Combinar fontes só é útil quando o fluxo de trabalho preserva a proveniência e expõe conflitos, em vez de suavizá-los.

A divulgação da Ivanti fornece um ponto de partida, não um padrão concluído. Ela informa aos compradores que a IA participou e que alucinações conhecidas moldaram o processo de revisão.

Ela não estabelece publicamente a linhagem em nível de linha, testes independentes de níveis de risco, taxas de falsos negativos ou a porcentagem do material de origem conciliada automaticamente.

Ainda assim, a admissão pressiona os concorrentes. Um fornecedor que comercializa orientações de segurança assistidas por IA sem descrever sua cadeia de validação agora oferece aos clientes menos informações do que a Ivanti.

A inversão é desconfortável, mas construtiva. Reconhecer publicamente as falhas de um modelo pode se tornar evidência de maturidade de processo, enquanto o silêncio pode ocultar controles excelentes ou a ausência total de controles.

A Revisão Humana Só Funciona Quando Consegue Encontrar Evidências Ausentes

Um revisor só agrega valor quando o desenho da revisão visa omissões, alegações sem respaldo e erros de classificação de alto impacto.

O fluxo de trabalho da Ivanti mantém uma pessoa entre o rascunho do Claude e o boletim publicado. Isso é mais seguro do que permitir que um modelo publique a priorização automaticamente.

No entanto, “humano no circuito” é uma descrição de design, não uma medição de qualidade. Sua eficácia depende do que a pessoa vê, verifica e pode interromper.

Um revisor que analisa o texto pode identificar uma redação estranha, um produto conhecido atribuído à família errada ou um padrão de lançamento implausível. A experiência de Goettl aparentemente detectou essas anomalias visíveis durante o treinamento.

A falha mais difícil é a exclusão silenciosa. Se um analisador ou modelo nunca cria uma linha para uma vulnerabilidade, um revisor que examina apenas a planilha final não recebe nenhum alerta óbvio.

Um sistema mais robusto precisa de controles de reconciliação fora do modelo de linguagem. Verificações determinísticas podem comparar identificadores de origem, sinalizar registros não correspondidos, detectar CVEs duplicados e contar os itens esperados por fornecedor.

O modelo pode então lidar com tarefas que se beneficiam de interpretação. Ele pode resumir avisos, normalizar descrições inconsistentes ou propor categorias de risco para aprovação de especialistas.

Essa divisão atribui responsabilidades diferentes às máquinas. O código protege a completude e a repetibilidade, enquanto o modelo auxilia com linguagem ambígua e contexto de priorização.

Ela também cria sinais de falha mais claros. Uma incompatibilidade na reconciliação pode interromper a publicação mesmo quando a narrativa gerada parece bem acabada.

A validação dos níveis de risco exige rigor semelhante. O sistema deve registrar por que um item recebeu sua classificação, quais fatos de origem sustentaram essa decisão e o que mudou após a revisão humana.

Sem esse registro, uma aprovação final estabelece responsabilidade, mas oferece evidência limitada sobre a qualidade. Ela não pode mostrar se o revisor examinou cada recomendação ou apenas uma amostra das linhas de maior risco.

A Ivanti afirma que seus sinais de exploração conhecida, divulgação pública e volume anormal acionam uma escalada. Esse é um conjunto de regras sensato, mas os relatos públicos não verificam de forma independente sua aplicação.

As falhas relacionadas ao Adobe e ao Office também mostram por que os testes específicos por fornecedor são importantes. Um fluxo de trabalho que funciona bem em planilhas da Microsoft pode falhar quando outro publicador usa páginas web, convenções de nomenclatura diferentes ou calendários de lançamento irregulares.

Portanto, a avaliação deve abranger cada fonte de dados e cada etapa de transformação. Uma média combinada pode esconder um conector fraco de fornecedor sob um desempenho forte com a Microsoft.

A CrowdStrike descreveu um padrão de revisão diferente na Fal.Con 2026. Sua abordagem de “humano sobre o circuito” supostamente coloca um analista para trabalhar na mesma detecção em paralelo com o agente e, em seguida, comparar os vereditos.

O trabalho paralelo pode expor divergências que a revisão sequencial não detecta. Ele também preserva mais esforço humano do que um fluxo em que uma pessoa verifica um rascunho já concluído.

A Palo Alto Networks lançou o Cortex XSIAM AgentiX em fevereiro de 2026, com agentes pré-configurados e pontos de aprovação para ações de alto impacto. Seu design de SOC agêntico também preserva o controle humano quando decisões automatizadas trazem consequências maiores.

Nenhum dos dois designs resolve automaticamente o problema de entradas ausentes. Um humano e um agente podem ambos raciocinar a partir de um feed incompleto, enquanto um ponto de aprovação pode autorizar uma ação baseada em evidências defeituosas.

Ainda assim, a comparação revela um consenso emergente. Grandes fornecedores não estão tratando a autonomia irrestrita como um padrão aceitável para operações de segurança de alto impacto.

Esse consenso importa porque a linguagem do setor frequentemente confunde assistência e autonomia. Um sistema que redige um boletim difere materialmente de outro que implanta uma correção, isola um dispositivo ou encerra um incidente.

Os compradores devem mapear cada ação de IA à sua reversibilidade e ao dano potencial. Resumos de baixo impacto podem tolerar controles mais leves do que decisões que alteram sistemas de produção.

Eles também devem exigir evidências de casos reais de falha. Um benchmark que relata apenas concordância oculta se os erros envolveram redação, escopo, gravidade ou omissões.

Os casos conhecidos de alucinação detectados pela Ivanti fornecem informações mais úteis do que uma simples alegação de precisão. Eles identificam condições concretas nas quais o sistema se tornou pouco confiável.

A questão não resolvida é se os controles de produção detectam novos modos de falha, e não apenas aqueles descobertos durante o treinamento. Sites de fornecedores mudam, taxonomias evoluem e lançamentos incomuns podem invalidar as premissas de análise de ontem.

A revisão humana continua necessária, mas deve estar inserida em um sistema de controle mensurável. Caso contrário, a expressão pode se tornar uma garantia sem demonstrar que os erros mais perigosos são detectáveis.

A Admissão da Ivanti Eleva o Padrão para Todos os Fornecedores de Segurança

Os fornecedores de segurança agora enfrentam pressão para revelar não apenas que usam IA, mas exatamente como a IA influencia as prioridades voltadas ao cliente.

A Ivanti não está sozinha na automação da análise de segurança. CrowdStrike, Palo Alto Networks e outros fornecedores estão incorporando modelos e agentes a fluxos de trabalho de detecção, investigação, triagem e resposta.

A diferença competitiva exposta aqui é a transparência. A Ivanti nomeou seu modelo, descreveu suas entradas, identificou padrões conhecidos de alucinação e explicou que a publicação exige aprovação humana.

A VentureBeat relatou que não encontrou uma divulgação pública comparável de alucinações da CrowdStrike ou da Palo Alto Networks. Essa ausência não estabelece que seus sistemas falharam ou que seus controles são mais fracos.

Ela significa que os clientes não dispõem de informações comparáveis. Um fornecedor expôs parte de seu histórico de falhas, enquanto os outros descrevem principalmente arquitetura e salvaguardas.

A divulgação pública cria um difícil problema de incentivos. Uma empresa que relata erros pode parecer menos confiável do que um concorrente que publica apenas avaliações bem-sucedidas.

A aquisição de soluções de segurança pode inverter esse incentivo ao recompensar evidências. Os compradores podem fazer as mesmas perguntas a todos os fornecedores e tratar respostas ausentes como uma lacuna de controle não resolvida.

Primeiro, os clientes devem perguntar quais artefatos são gerados por IA. A resposta deve distinguir coleta, análise, resumo, pontuação, recomendação e ação automatizada.

Segundo, devem perguntar como a completude é verificada. Uma resposta válida deve abordar linhas ausentes, registros duplicados, mudanças nas fontes e falhas de ingestão.

Terceiro, devem perguntar quem revisa o resultado e o que essa revisão abrange. Uma função de aprovação nomeada é útil, mas uma lista de verificação documentada e uma trilha de auditoria oferecem garantia mais forte.

Quarto, devem solicitar categorias de erros em vez de uma única porcentagem de precisão. Os compradores precisam saber se as falhas afetam gramática, atribuição de produto, status de exploração, gravidade ou inclusão.

Essas solicitações são proporcionais à decisão em jogo. As equipes de correção usam a priorização porque não conseguem remediar todos os problemas simultaneamente.

A atualização de setembro demonstra a dimensão do problema. A Tenable identificou 964 CVEs, a Ivanti identificou 973 e a Senserva identificou 1.169 sob uma abordagem de contagem diferente.

Um comprador não precisa necessariamente que todos os fornecedores produzam um número idêntico. Mas precisa que cada fornecedor explique seu escopo e concilie suas recomendações com esse escopo.

A mesma lógica se aplica aos níveis de risco. Os fornecedores podem razoavelmente ponderar explorabilidade, exposição e contexto de negócios de maneiras diferentes, mas esses julgamentos devem permanecer rastreáveis.

A transparência também protege os fornecedores de comparações injustas. Uma metodologia documentada pode mostrar que dois totais diferem devido a um escopo definido, não porque um sistema perdeu dados silenciosamente.

Essa questão vai além da cibersegurança. Qualquer pesquisa, relatório de conformidade, resumo financeiro ou relatório operacional gerado por IA pode conter omissões plausíveis que a revisão superficial não detectará.

A segurança torna o problema especialmente visível porque os CVEs têm identificadores e avisos autoritativos. Essa estrutura oferece aos fornecedores uma maneira prática de testar a completude.

Organizações que trabalham com evidências menos estruturadas enfrentam uma tarefa mais difícil. Ainda assim, precisam de proveniência, detecção de conflitos e tratamento explícito de material ausente.

A abordagem da Ivanti é, portanto, notável, mas não suficiente. Sua divulgação informa mais aos clientes do que o silêncio informaria, enquanto seus controles relatados ainda deixam importantes questões de verificação sem resposta.

O contexto de segurança anterior da empresa torna o escrutínio especialmente importante. Os clientes que avaliam orientações de correção julgarão não apenas a eficiência do modelo, mas também a capacidade da Ivanti de comunicar riscos com precisão.

Esse escrutínio deve permanecer baseado em evidências. A habilidade do Claude discutida aqui analisou dados públicos de correções e não teria acessado ambientes de clientes.

Não era um agente de remediação autônomo. Produzia rascunhos para um boletim recorrente, com uma pessoa responsável pela publicação.

Confundir essas categorias exageraria o evento. Minimizar a alucinação porque “um humano verificou” subestimaria o desafio de controle.

A conclusão equilibrada está entre esses extremos. A Ivanti criou um processo materialmente mais rápido, detectou falhas reais do modelo, divulgou o envolvimento da IA e manteve a revisão especializada.

Ela não demonstrou publicamente que seu processo detecta cada vulnerabilidade ausente ou valida de forma independente cada decisão de prioridade. Esse é o padrão que os clientes devem agora exigir que ela, e seus concorrentes, atendam.

Três Sinais Mostrarão se as Orientações de Correção por IA Merecem Confiança

O próximo teste é saber se os fornecedores transformarão a ampla supervisão humana em uma validação visível, repetível e completa em relação às fontes.

O primeiro sinal chegará na próxima Patch Tuesday, em 13 de outubro de 2026. Analistas devem comparar os totais publicados, as definições de escopo, os rótulos de explorações conhecidas e o tratamento de dados incomuns de fornecedores.

Se a produção da Ivanti continuar rápida enquanto contabiliza claramente as discrepâncias entre fontes, seu argumento a favor da automação supervisionada se fortalece. Uma omissão inexplicada ou um erro de mapeamento o enfraqueceria.

O segundo sinal será uma divulgação mais detalhada por parte da Ivanti ou de seus concorrentes. Uma documentação útil identificaria onde os modelos operam, quais controles determinísticos protegem a completude e quais decisões exigem aprovação humana.

Essas informações fortaleceriam o argumento de que a transparência pode se tornar um padrão competitivo. A dependência contínua de uma linguagem ampla de “humano no circuito” deixaria sem solução a lacuna central de verificação.

O terceiro sinal é a evidência proveniente de avaliações em produção. Os fornecedores devem relatar categorias de erro, cobertura de fontes, substituições feitas por revisores e falsos negativos de alto impacto, sem expor detalhes exploráveis dos clientes.

Essas evidências mostrariam se os sistemas melhoram após encontrar novos formatos e casos extremos. A concordância agregada, por si só, não responderia a essa pergunta.

O relatório da CrowdStrike sobre exploração rápida explica por que esse trabalho não pode voltar inteiramente ao processamento manual. Suas conclusões sobre exploração mostram que os defensores frequentemente operam dentro de uma janela de resposta cada vez menor.

O resultado correto, portanto, não é menos automação. É uma automação cujas evidências possam ser inspecionadas antes que suas recomendações orientem pessoas ou máquinas.

Para líderes de segurança, a resposta prática é inventariar todas as fontes externas de orientação que usam IA. Pergunte se o modelo conta, interpreta, classifica ou age, pois cada função cria uma trajetória de falha diferente.

Depois, teste a alegação de revisão do fornecedor com uma pergunta difícil: Como o processo detectaria uma vulnerabilidade que nunca apareceu no rascunho gerado?

Se a resposta depender de uma pessoa perceber algo que está ausente, o controle estará incompleto. Se incluir reconciliação de fontes, tratamento de exceções e decisões humanas registradas, o fluxo de trabalho será mais confiável.

A orientação de segurança de IA da Ivanti agora oferece um estudo de caso público para essa conversa. Sua skill Claude economizou um tempo substancial dos analistas, inventou detalhes durante o desenvolvimento e obrigou a empresa a projetar o processo considerando essas falhas.

A divulgação não deve gerar confiança automática, mas merece atenção. Ela oferece aos clientes fragilidades concretas para examinar e estabelece para os concorrentes uma referência de transparência que podem superar.

Antes de confiar no próximo briefing de segurança assistido por IA, peça o papel do modelo, a verificação de completude das fontes e a tarefa real do revisor. Essas respostas revelarão mais do que qualquer pontuação de precisão destacada em uma manchete.