Avaliando a segurança da IA empresarial: perguntas que todo comprador deve saber responder

A segurança de IA empresarial está evoluindo rapidamente, e a maioria das organizações ainda enfrenta dificuldades para avaliar com rigor as alegações dos fornecedores. Este artigo de pesquisa da NSS Labs, desenvolvido em colaboração com a F5, a AWS e a Microsoft, oferece aos líderes de segurança e compradores empresariais as perguntas específicas que devem fazer aos fornecedores, os sinais de alerta aos quais devem estar atentos e os critérios de avaliação necessários para tomar decisões de segurança de IA confiantes e justificáveis.

Resumo executivo

A segurança de IA empresarial enfrenta um problema por parte dos compradores. As organizações sabem que a segurança de IA é importante, mas a maioria não dispõe de uma estrutura confiável para avaliar as alegações dos fornecedores, distinguir controles relevantes de controles superficiais ou exigir que os fornecedores apresentem evidências concretas.

Este artigo — o segundo de uma série de duas partes da NSS Labs, desenvolvido em colaboração com a F5, a AWS e a Microsoft — deixa de apenas definir o problema e passa a capacitar os compradores a agir sobre ele. Enquanto a Parte 1 demonstrou por que proteger apenas o modelo de IA é insuficiente, a Parte 2 transforma essa base em critérios práticos de avaliação em sete áreas críticas de capacidade.

O argumento central: as decisões de compra de soluções de segurança para IA são decisões de governança, não apenas decisões técnicas. Os compradores devem exigir evidências mensuráveis, não diagramas de arquitetura. Isso significa estabelecer parâmetros quantitativos para a eficácia da detecção, o desempenho operacional, os requisitos de auditoria e o alinhamento com frameworks — tudo validado em condições reais, não em cenários de teste isolados.

As sete áreas de capacidade examinadas pelo documento são: ameaças de entrada e controle de instruções; riscos relacionados à saída e à exfiltração de dados; resiliência do sistema em condições de degradação; governança de políticas e filtros; IA agêntica e autoridade delegada; observabilidade e análise forense; e integração e interoperabilidade. Cada seção relaciona o risco central a perguntas específicas que os compradores devem fazer aos fornecedores, às características de soluções eficazes e a sinais de alerta concretos aos quais devem estar atentos.

O documento termina com duas recomendações enfáticas: exija uma validação independente antes de comprar e trate essa validação como uma prática contínua, e não como uma verificação pontual. Fornecedores que resistem a testes relevantes demonstram imaturidade, não solidez.

Em suma, há três frases da conclusão que merecem ser levadas a sério: a aquisição de soluções de segurança de IA é uma decisão de governança com consequências de longo prazo. As empresas que fazem as perguntas difíceis desde o início estão mais bem preparadas para gerenciar riscos e evitar falhas que poderiam ser prevenidas. E a segurança de IA não terá sucesso por meio de novidades ou abstrações — apenas com responsabilização, transparência e avaliação rigorosa.

Sumário

Introdução: Da conscientização à avaliação

Estabelecimento de critérios quantitativos de avaliação

Áreas de recursos essenciais e perguntas que os compradores devem fazer

• Detecção de ameaças de entrada, controle de instruções e evasão
• Gerenciamento de riscos de saída e exfiltração de dados
• Gerenciamento de resiliência, robustez, falhas e degradação
• Eficácia de políticas/filtros e alinhamento à governança
• IA agêntica, segurança na invocação de ferramentas e autoridade delegada
• Observabilidade, auditoria e análise forense
• Integração e interoperabilidade

O que os compradores devem exigir antes de comprar

Preparação para validação independente

Conclusão: Das alegações à responsabilização

BAIXE A PARTE 1: Segurança de IA além do modelo: com o que as empresas precisam se preocupar — e por quê

Introdução: da conscientização à avaliação

À medida que a IA amplia sua presença nos sistemas empresariais de diversas formas, ela cria novas superfícies de ataque, obrigando as empresas a considerar os riscos de segurança relacionados à IA. Conselhos de administração, órgãos reguladores e equipes executivas estão começando a reconhecer que os sistemas de IA introduzem novas categorias de exposição operacional, jurídica e reputacional, além de ampliarem a superfície de ataque. Como resultado, os produtos de segurança de IA destinados a reduzir esses riscos tornaram-se uma prioridade para as equipes de segurança empresarial.

No entanto, essa conscientização não garante que as empresas estejam preparadas e, embora elas reconheçam cada vez mais a importância da segurança de IA, muitas têm dificuldade para avaliar de forma eficaz as alegações dos fornecedores que atuam nesse mercado emergente. A terminologia é inconsistente, as demonstrações costumam ter escopo limitado e as garantias frequentemente se baseiam na arquitetura, e não em evidências do mundo real. Assim, os compradores precisam tomar decisões sem uma forma clara de distinguir controles relevantes de controles superficiais ou de determinar a real eficácia da cobertura.

Em nosso white paper anterior, intitulado AI Security Beyond the Model, a NSS Labs explicou por que proteger apenas o modelo de IA é insuficiente e por que a segurança da IA empresarial deve ser tratada como um desafio de governança e de todo o sistema. Os verdadeiros desafios de segurança surgem nos sistemas que cercam o modelo — onde os dados são recuperados, as ferramentas são acionadas e as decisões automatizadas são executadas.

Este artigo parte dessa base, avançando da compreensão do problema para a avaliação de possíveis soluções e ajudando os compradores corporativos a formular perguntas mais pertinentes ao selecionar fornecedores de segurança de IA. Em consonância com o AI Security Beyond the Model, este artigo se concentra principalmente nas proteções em tempo de execução (os controles externos ao modelo que aplicam políticas, protegem dados e geram evidências de auditoria), reconhecendo, ao mesmo tempo, que a segurança do modelo/IA Responsável reduz o risco intrínseco do modelo, mas não é capaz de gerenciar sozinha o risco das interações corporativas. À medida que os sistemas de IA são incorporados aos fluxos de trabalho corporativos, as decisões de segurança se cruzam cada vez mais com a governança, a gestão de riscos e a responsabilidade regulatória. As organizações devem ser capazes de explicar não apenas como os sistemas de IA funcionam, mas também como os riscos são controlados, monitorados e auditados.

As seções a seguir buscam reformular as principais áreas de capacidade de segurança de IA como critérios de avaliação. Em vez de prescrever tecnologias ou arquiteturas específicas, elas se concentram no que os compradores devem ser capazes de compreender, testar e defender ao selecionar controles de segurança de IA para ambientes de produção.

Estabelecimento de critérios quantitativos de avaliação

Avaliar a segurança da IA exige ir além de alegações qualitativas e adotar uma validação mensurável. Os compradores devem estabelecer expectativas mínimas que permitam uma comparação objetiva entre fornecedores.

Eficácia da detecção: Os fornecedores devem demonstrar sua capacidade de detecção com base em estruturas e metodologias de teste padronizadas, desenvolvidas por organizações independentes de testes reconhecidas. As organizações devem exigir taxas de precisão mensuráveis para padrões de ataque conhecidos, e os fornecedores devem divulgar a metodologia de teste, os limites de cobertura e as compensações relacionadas a falsos positivos. A prevenção da exposição de dados confidenciais deve distinguir entre tipos de dados estruturados e informações confidenciais contextuais, mantendo uma precisão de detecção consistente entre diferentes modelos de base e níveis de complexidade dos prompts.

Desempenho operacional: Os compradores devem estabelecer limites de latência que equilibrem segurança e usabilidade. Os sistemas devem demonstrar desempenho sob cargas em escala de produção, e não apenas em condições de teste isoladas. As taxas de falsos positivos também são importantes — o excesso de falsos positivos gera fadiga de alertas e impulsiona a adoção de IA paralela. Os fornecedores devem ser capazes de fornecer métricas de produção referentes a períodos significativos.

Requisitos de auditoria: A conformidade regulatória depende de registros abrangentes, com detalhes suficientes para reconstruir incidentes meses depois. Os eventos devem ser exportados para o SIEM em formatos padrão e com latência mínima. Os requisitos de retenção variam conforme o setor e o caso de uso.

Alinhamento com frameworks: Os fornecedores devem mapear os controles de acordo com frameworks consolidados de organizações independentes de testes reconhecidas. Os compradores devem exigir que os fornecedores demonstrem essas capacidades usando conjuntos de testes padronizados e amostras de tráfego de produção. A validação independente por terceiros fornece evidências confiáveis da eficácia dos controles.

Áreas de recursos essenciais e perguntas que os compradores devem fazer

No nível mais básico, as proteções de segurança dos modelos podem bloquear prompts maliciosos, filtrar conteúdo não permitido e aplicar regras simples de uso. Esses recursos são necessários, mas muitas falhas de IA empresarial de alto impacto não decorrem da falta de regras, e sim da falta de contexto, resiliência e visibilidade.

Por exemplo, um sistema de IA pode estar em conformidade com todas as políticas de conteúdo definidas e, ainda assim, divulgar informações confidenciais por meio de agregação, inferência ou combinação inadequada de contextos. Da mesma forma, um sistema pode aplicar corretamente as regras em condições normais, mas falhar de maneira imprevisível sob alta carga, durante interrupções parciais ou em caso de falhas em dependências.

Detecção de ameaças de entrada, controle de instruções e evasão

A maioria dos controles de segurança de IA afirma “filtrar prompts” ou “bloquear entradas maliciosas”, mas essa abordagem muitas vezes simplifica demais o problema. Na maioria dos sistemas de IA, o risco não decorre apenas do que os usuários inserem diretamente em um sistema, mas também de instruções incorporadas ao conteúdo consumido posteriormente por esses sistemas. Esse conteúdo pode incluir documentos, páginas da web, chamados, e-mails ou bases de conhecimento e precisa ser confiável o suficiente para ser tratado como contexto legítimo.

Autores

Bob Walder - Analista Sênior, NSS Labs
lan Foo - Diretor de Tecnologia e Vice-Presidente Executivo de Produtos, NSS Lab

Colaboradores

Esta pesquisa foi desenvolvida em colaboração com líderes dos setores de segurança, computação em nuvem e IA de toda a indústria.

Cameron Delano - Arquiteto Sênior de Soluções, F5
Jeanette Hurr - Arquiteta Global de Soluções, F5
Riggs Goodman III - Arquiteto Principal de Soluções, Segurança e Privacidade de IA, AWS
Raj Bagwe - Arquiteto Sênior de Soluções, AWS
Zachary Riffle - Arquiteto de Segurança, Microsoft

Os compradores devem perguntar como um sistema distingue, durante a execução, as instruções do sistema, a intenção do desenvolvedor, o conteúdo recuperado e as entradas do usuário. Em arquiteturas que usam geração aumentada por recuperação (RAG), essa distinção é fundamental. Se o conteúdo recuperado puder substituir implicitamente as políticas do sistema, o sistema ficará vulnerável à injeção indireta de prompts, mesmo que nenhuma consulta explicitamente maliciosa seja enviada.

As empresas devem esperar respostas claras para perguntas como:

• Com que eficácia o sistema consegue detectar, avaliar e bloquear solicitações e instruções proibidas pela política?
• Até que ponto o sistema consegue detectar e impedir tentativas de substituir o comportamento esperado do sistema por meio de prompts de entrada?
• Até que ponto o sistema lida bem com prompts ambíguos ou limítrofes, nos quais a intenção não está clara, sem deixar de minimizar interferências no uso legítimo?
• Com que eficácia o sistema consegue impedir que instruções incorporadas ao conteúdo enviado influenciem o modelo de maneiras não intencionais?
• Com que eficácia o sistema consegue lidar com tentativas de burlar os controles por meio de formatação incomum, codificação ou transformações do prompt?
• Até que ponto o sistema consegue equilibrar a segurança com casos de uso legítimos baseados em funções (por exemplo, simulações de treinamento, red teaming e trabalho criativo) sem criar formas fáceis de contornar os controles?
• Com que eficácia o sistema impede que usuários (ou conteúdo externo) influenciem ou substituam instruções do sistema/agente, regras de roteamento, restrições de uso de ferramentas ou outros controles de "prioridade mais alta"?
• O sistema é capaz de detectar, identificar e regular de forma eficaz o uso do modelo para evitar uso abusivo ou excessivo (além do permitido pela política) e custos indevidos?
• O sistema consegue mostrar, nos logs, qual fonte de instrução prevaleceu quando ocorreram conflitos (sistema vs. desenvolvedor vs. recuperação vs. usuário)?

Na prática, as falhas nessa área muitas vezes ocorrem sem nenhum prompt obviamente mal-intencionado e surgem, em vez disso, da forma como conteúdo não confiável é introduzido no contexto da IA. Um invasor pode inserir instruções ocultas em um documento (por exemplo, um documento de políticas, uma página de wiki interna ou um artigo de suporte ao cliente) que posteriormente é processado pelo sistema de IA por meio de um pipeline complexo de recuperação de múltiplas fontes. Quando o modelo recupera esse conteúdo, ele pode tratar essas instruções incorporadas como orientações confiáveis, em vez de considerá-las entradas não confiáveis. Em ambientes corporativos nos quais o conteúdo interno pode ser amplamente editado, essa forma de injeção indireta de prompt pode ser particularmente difícil de detectar.

Por exemplo, não é necessário — nem, do ponto de vista de um agente mal-intencionado, necessariamente desejável — que a alteração de uma única fonte de informação acione um alerta e impeça que danos graves sejam causados de imediato. Em vez disso, pequenas alterações em várias fontes de dados podem ser uma estratégia melhor, resultando, ao longo do tempo, em mudanças sutis, porém persistentes, no comportamento do sistema, como flexibilizar as restrições de resposta, expor fluxos de trabalho internos ou priorizar o contexto controlado pelo invasor em detrimento das políticas do sistema. O resultado final pode ser uma extração de dados confidenciais em maior escala.

Portanto, os compradores devem avaliar se os controles de segurança de IA tratam todo o conteúdo recuperado como potencialmente hostil e se os limites das instruções são aplicados de forma consistente, independentemente da origem dessas instruções.

Soluções eficazes distinguem com alta precisão as entradas dos usuários do conteúdo recuperado. Quando tentativas de sobrepor instruções aparecem nos prompts dos usuários, os sistemas as bloqueiam; quando frases semelhantes aparecem em artigos legítimos de suporte, os sistemas as tratam adequadamente. A detecção se baseia na intenção semântica, e não em palavras-chave, identificando ataques ofuscados por meio da manipulação de codificação ou de cenários de interpretação de papéis. Os fornecedores precisam demonstrar a detecção usando a arquitetura RAG real da organização, com recuperação de múltiplas fontes. Os sistemas devem fornecer métricas de produção referentes a períodos significativos, incluindo taxas de detecção, taxas de falsos positivos e latência.

Os sinais de alerta incluem: dependência de filtragem genérica de prompts; garantias vagas de que "o modelo cuida disso"; incapacidade de demonstrar a aplicação dos limites das instruções em condições adversariais; falta de métricas de produção referentes a períodos significativos; incapacidade de demonstrar a detecção usando a arquitetura RAG interna; e detecção baseada apenas em palavras-chave, sem análise da intenção semântica.

A integridade das entradas não se resume a bloquear linguagem maliciosa; trata-se de preservar a autoridade das políticas em ambientes dinâmicos e não confiáveis.

Gerenciamento de riscos de saída e exfiltração de dados

O conteúdo gerado por IA claramente representa um risco significativo, uma vez que um agente não humano pode ter extraído dados de diversos sistemas para formular sua resposta, e essa resposta pode revelar a usuários externos mais informações do que se pretendia originalmente. Muitas falhas de alto impacto não envolvem conteúdo explicitamente proibido, mas sim a divulgação sutil de informações que não deveriam ter sido reveladas a determinado usuário, em determinado contexto e em determinado momento.

Um invasor ou usuário não autorizado pode fazer uma série de perguntas que, à primeira vista, parecem inofensivas e que, individualmente, retornam dados permitidos, mas que, em conjunto, possibilitam inferir ou reconstruir informações confidenciais. Por exemplo, um assistente de IA conectado a sistemas internos de chamados e documentação pode resumir problemas operacionais, funções de pessoal ou configurações de sistemas de maneiras que revelem indiretamente a arquitetura interna ou dados regulamentados. Essas falhas raramente são detectadas por filtros de palavras-chave. Em vez disso, o risco surge da agregação e do contexto. Os compradores devem avaliar se os controles de saída consideram a exposição cumulativa e se os sistemas conseguem explicar por que uma resposta foi restringida — um requisito essencial para a governança e a auditabilidade.

Os compradores devem esperar respostas claras para perguntas como:

• Como os controles de segurança de IA avaliam quais informações estão de fato sendo expostas em determinado contexto, em vez de simplesmente identificar quais palavras-chave ou frases aparecem na saída?
• O sistema consegue distinguir entre informações públicas, informações internas e dados regulamentados?
• Com que eficácia o sistema impede que o modelo revele dados confidenciais nas respostas, mesmo quando a solicitação do usuário parece legítima ou ambígua?
• Quais tipos de dados confidenciais são abrangidos pela proteção (por exemplo, dados pessoais, dados financeiros e informações corporativas confidenciais) e como ela pode ser adaptada à organização?
• Os controles levam em consideração a função do usuário, a jurisdição ou a origem dos dados?
• O sistema consegue explicar por que uma saída foi bloqueada ou modificada?
• O sistema consegue aplicar controles tanto às solicitações quanto às respostas, incluindo bloqueio, ocultação de informações e transformação segura, com evidências para auditoria?
• Quais ações o sistema pode realizar para impedir que o modelo gere dados confidenciais (bloquear, ocultar, transformar, alertar ou exigir uma etapa adicional de revisão/aprovação)?
• Até que ponto o sistema consegue impedir truques de prompt e estratégias de evasão que tentam induzir o modelo a divulgar dados indiretamente (por exemplo, solicitando "exemplos", "modelos", "dados de teste" ou "resumos" que contenham informações reais)?
• O sistema consegue prevenir e detectar vazamentos de dados entre sessões ou locatários, garantindo que as informações da sessão, do contexto ou das fontes de dados consultadas de um usuário não apareçam nas respostas de outro usuário?
• Com que eficácia o sistema impede que o modelo revele prompts do sistema, instruções internas, políticas ocultas ou detalhes da configuração operacional?
• Com que eficácia o sistema impede a exposição de credenciais ou segredos (por exemplo, chaves de API ou tokens) que possam existir nos dados de treinamento, no contexto do sistema, em logs, conectores ou conteúdo recuperado?
• Com que eficácia o sistema impede que o modelo produza respostas prejudiciais, depreciativas ou fortemente tendenciosas, especialmente em casos extremos em que um usuário tenta provocar o modelo?
• Até que ponto o sistema consegue impedir que o modelo gere longos trechos protegidos por direitos autorais de forma literal ou reproduza conteúdo protegido de outras maneiras?
• Se o modelo estiver conectado a conteúdo corporativo interno (por exemplo, documentos, wiki ou sistemas de chamados), o sistema consegue impedir que ele reproduza materiais internos restritos além daqueles que o usuário está autorizado a visualizar?
• Com que eficácia o sistema consegue impedir que o modelo oriente um usuário passo a passo em fluxos de trabalho prejudiciais ou produza artefatos operacionais (por exemplo, scripts, comandos ou código) que possam criar vulnerabilidades de segurança ou comportamentos inseguros no sistema?

Quando os sistemas de IA são conectados a fontes de dados corporativos em tempo real, esses riscos aumentam significativamente, e podem ocorrer falhas relacionadas à saída quando os sistemas de IA combinam informações de várias fontes em uma única resposta.

A avaliação dos controles de saída exige compreender como soluções maduras lidam com a exposição contextual de dados. Sistemas sensíveis ao contexto entendem o significado semântico, não apenas palavras-chave. Isso significa que informações de identificação pessoal (PII) estruturadas devem ser bloqueadas, enquanto informações públicas são permitidas de acordo com o contexto. A aplicação de controles baseados em funções garante que usuários diferentes vejam resultados distintos para consultas idênticas, conforme seus níveis de autorização. Os sistemas devem detectar a exposição cumulativa entre sessões, quando perguntas individualmente inofensivas revelam, em conjunto, informações confidenciais. As decisões de bloqueio precisam incluir referências específicas a políticas, tipos de dados e requisitos de autorização. A integração com as políticas existentes de classificação de dados elimina configurações duplicadas.

Os sinais de alerta incluem: filtragem baseada apenas em palavras-chave; decisões de aplicação de políticas pouco transparentes; incapacidade do sistema de demonstrar a aplicação de controles baseados em função — por exemplo, quando a mesma consulta retorna o mesmo resultado independentemente do nível de autorização do usuário; incapacidade do fornecedor de explicar, em linguagem clara, por que determinado resultado foi bloqueado; e ausência de trilhas de auditoria. As empresas devem buscar evidências de que os controles de saída operam com base no contexto, na intenção e na responsabilização.

Tratamento de resiliência, robustez, falhas e degradação

As empresas estão acostumadas a avaliar os controles de segurança com base em sua eficácia em condições normais de rede, mas a segurança de IA exige uma mentalidade diferente. Algumas das falhas mais significativas ocorrem não quando os sistemas são atacados diretamente, mas quando são submetidos a estresse devido ao volume, à complexidade, a falhas de dependências ou a padrões inesperados de interação.

As principais perguntas a serem feitas seriam:

• Até que ponto o sistema mantém a disponibilidade e a capacidade de resposta durante interações com o usuário excepcionalmente longas ou complexas (por exemplo, sessões de "maratona")?
• Os controles são aplicados de forma consistente durante sessões de longa duração ou fluxos de trabalho de agentes com várias etapas?
• Como o sistema evita o esgotamento de recursos ou a degradação do serviço ao receber rajadas de entradas repetitivas, malformadas ou sem sentido?
• O que acontece quando os controles de segurança da IA se deterioram?
• As verificações de políticas expiram? Em caso afirmativo, a aplicação das políticas falha de forma permissiva ou restritiva?
• Como o sistema equilibra a segurança e a disponibilidade durante falhas de dependências, e esse comportamento pode ser configurado e auditado?

Os sistemas de IA do mundo real operam sob condições variáveis, como picos de uso, indisponibilidade de serviços upstream, provedores de identidade lentos ou serviços de recuperação degradados. Nesses cenários, os componentes de aplicação de políticas podem falhar parcialmente, em vez de por completo. Por exemplo, um serviço de avaliação de políticas pode exceder o tempo limite, ou uma etapa de classificação pode ser ignorada para preservar a capacidade de resposta. Se essas falhas não forem tratadas com cuidado, os sistemas poderão adotar por padrão um comportamento permissivo sem alertar os operadores e, em fluxos de trabalho agênticos, isso poderá permitir que ações prossigam sem as verificações adequadas. Esses não são casos extremos hipotéticos, mas modos de falha comuns em sistemas distribuídos. Portanto, os compradores devem exigir demonstrações de como os controles de segurança de IA se comportam quando as dependências se degradam e verificar se os modos de falha são previsíveis, visíveis e alinhados à tolerância a riscos da empresa.

Um sistema resiliente não deve simplesmente bloquear tudo quando algo dá errado, nem permitir silenciosamente comportamentos inseguros. Em vez disso, deve reduzir seu desempenho de forma previsível, comunicar os erros com clareza e continuar oferecendo proteção adequada à medida que as condições se deterioram.

Sistemas bem projetados devem documentar modos de falha explícitos para cada dependência. Quando os serviços excederem o tempo limite, os sistemas devem falhar de maneira adequada, registrar os eventos, alertar as equipes de segurança e exibir mensagens claras aos usuários. Em testes de estresse, a precisão da detecção deve permanecer alta, a latência deve se manter dentro de limites aceitáveis e as solicitações não devem conseguir contornar as verificações de segurança. A degradação deve ocorrer de forma previsível e acompanhada de alertas, não silenciosamente, e os disjuntores devem encerrar prontamente processos fora de controle. Os fornecedores devem ser capazes de descrever as metas de disponibilidade dos mecanismos de aplicação e o comportamento em caso de falha e, quando essa aplicação for essencial para a missão, os compradores poderão exigir compromissos contratuais.

Os sinais de alerta incluem: incapacidade de descrever os modos de falha; ausência de testes de estresse ou alegações de que "o sistema nunca falhou na prática"; degradação silenciosa sem alertas; ausência de disjuntores para interromper processos descontrolados; incapacidade de demonstrar que a precisão da detecção permanece alta durante testes de estresse; e sistemas que permitem que solicitações contornem as verificações de segurança durante a degradação.

Eficácia de políticas/filtros e alinhamento à governança

Controles de segurança de IA tecnicamente sofisticados, mas desalinhados do ponto de vista operacional, raramente resistem ao contato com a linha de frente — as áreas de negócio. Em ambientes corporativos, as decisões sobre políticas geralmente não são binárias nem imutáveis e, em última análise, são decisões de governança.

Os compradores devem perguntar:

• Como as políticas são definidas, aprovadas, versionadas e auditadas?
• As políticas podem ter seu escopo definido por função, sensibilidade dos dados, localização geográfica ou contexto de negócios?
• O sistema consegue explicar por que uma decisão foi tomada?
• Até que ponto o sistema permite implementar políticas que reflitam a postura de conformidade específica da organização (normas do setor, políticas internas e restrições de uso aceitável) e como essas políticas são mantidas ao longo do tempo?
• Com que eficácia o sistema ajuda a evitar respostas que possam gerar riscos jurídicos ou de conformidade (por exemplo, recomendações ou orientações que violem regras ou normas aplicáveis)?

As falhas de políticas muitas vezes não decorrem de más intenções, mas do desalinhamento entre a aplicação técnica e a realidade dos negócios. Por exemplo, um sistema de IA pode bloquear corretamente o acesso a determinadas categorias de dados, mas fazê-lo de uma forma que impeça fluxos de trabalho legítimos, levando os usuários a contornar totalmente os controles por meio de ferramentas não autorizadas. Por outro lado, políticas definidas de forma excessivamente vaga podem permitir que informações confidenciais sejam expostas em contextos que violem obrigações regulatórias ou contratuais. Com o tempo, ajustes pontuais para responder a reclamações podem comprometer a integridade das políticas e a responsabilização. Portanto, os compradores devem avaliar se as plataformas de segurança de IA oferecem suporte a uma governança estruturada de políticas, incluindo aprovações documentadas, histórico de versões e a capacidade de analisar os resultados da aplicação das políticas. Sem essa disciplina, a precisão das políticas torna-se subjetiva e difícil de justificar após um incidente de segurança.

A aplicação excessivamente rigorosa das regras pode causar transtornos e até levar usuários frustrados a implementar sistemas de IA "paralelos" não autorizados, enquanto uma aplicação insuficiente pode resultar em riscos regulatórios e reputacionais. Ambas as situações refletem falhas de governança, e não do modelo.

Uma gestão eficaz de políticas deve tratá-las como código, com controle de versão, fluxos de trabalho de aprovação e trilhas de auditoria. As alterações nas políticas devem exigir aprovações documentadas das partes interessadas das áreas de segurança, jurídica e de negócios antes da implantação em produção. Toda decisão de aplicação deve ser rastreável até a cláusula, a versão e a seção específicas da política, bem como até a lógica de autorização correspondente. Sempre que possível, o aprimoramento das políticas deve ser orientado por dados provenientes de painéis do sistema, que forneçam informações como tendências de falsos positivos, bloqueios de alto impacto e, quando viável, recomendações de ajuste.

Os sinais de alerta incluem: tomada de decisões opaca; ajustes ad hoc ou alegações de que as políticas são "autoaprendizes" sem que haja responsabilização; ausência de controle de versão e de fluxos de aprovação para alterações nas políticas; decisões de aplicação que não podem ser vinculadas a cláusulas específicas das políticas; e conflitos entre políticas sem regras de resolução documentadas.

IA agêntica, segurança na invocação de ferramentas e autoridade delegada

À medida que os sistemas de IA deixam de apenas prestar assistência passiva e passam a agir em nome de usuários e de outros sistemas, surge uma nova categoria de risco, conhecida como autoridade delegada. Sistemas de IA agêntica podem acionar outras ferramentas, modificar registros e iniciar fluxos de trabalho complexos em velocidade computacional.

Os compradores que avaliam a segurança da IA agêntica devem analisar várias áreas-chave de controle:

• Quais ações o sistema pode realizar de forma autônoma?
• Como as permissões são limitadas?
• Até que ponto o sistema garante que um agente faça apenas o que lhe é permitido ao receber autoridade delegada para agir em nome de um usuário?
• A autonomia pode ser escalonada de acordo com o risco ou o contexto, já que, sem limites claros, pequenos erros podem se propagar rapidamente entre os sistemas?
• Até que ponto os controles do sistema impedem que um prompt leve o sistema a executar ações fora dos limites previstos (mesmo que o usuário "peça com jeitinho") quando ele pode interagir com ferramentas e agentes externos ou utilizá-los?
• O sistema previne ou contém de forma eficaz loops recursivos ou comportamentos "descontrolados", nos quais um agente continua agindo sem atingir o objetivo?
• Qual é a eficácia do sistema na prevenção do uso não autorizado de ferramentas, da escalada de APIs/ações, de autonomia excessiva/loops e do encadeamento inseguro entre ferramentas?
• Em arquiteturas multiagente, com que eficácia o sistema impede que dados confidenciais recuperados ou gerados por um agente sejam propagados desnecessariamente para agentes subsequentes ou ferramentas que executam tarefas relacionadas?
• Em arquiteturas multiagente, é fundamental que a autoridade seja propagada corretamente entre os limites do sistema. Com que eficácia o sistema preserva o contexto de identidade ao longo das cadeias de agentes, garantindo que agentes e ferramentas subsequentes operem estritamente dentro das permissões do usuário original, em vez de usar privilégios elevados do sistema?

Falhas na delegação de autoridade costumam ocorrer quando sistemas de IA recebem amplo acesso a ferramentas para viabilizar a automação sem as devidas restrições. Por exemplo, um agente de IA encarregado de resolver problemas de suporte pode consultar bancos de dados, atualizar registros e notificar usuários. Uma instrução mal interpretada ou um contexto inesperado pode resultar na alteração incorreta de dados ou em uma comunicação prematura com os clientes. Como essas ações ocorrem na velocidade das máquinas, os erros podem se propagar antes que a supervisão humana consiga intervir. Em fluxos de trabalho complexos, ações individuais de baixo risco podem se combinar e gerar consequências de alto impacto. Os compradores devem avaliar se os controles de segurança de IA aplicam o princípio do menor privilégio, exigem confirmação para ações sensíveis e oferecem mecanismos para limitar ou revogar a autonomia de forma dinâmica. Tratar o comportamento autônomo dos agentes como uma questão de governança é essencial para evitar uma escalada silenciosa.

Em sistemas bem projetados, esses riscos são mitigados por meio de controles arquiteturais. Sistemas devidamente restritos aplicam o princípio do menor privilégio a cada ferramenta, com limites de permissão documentados. A autonomia gradual deve exigir confirmação para ações de impacto moderado e aprovação humana para ações de alto impacto, enquanto a preservação do contexto de identidade garante que os agentes herdem as permissões do usuário, e não as permissões no nível do sistema. Quando os usuários solicitarem operações sensíveis, os agentes devem recuperar apenas informações autorizadas e bloquear o acesso não autorizado. Mecanismos de interrupção precisam encerrar prontamente loops descontrolados, e todas as ações dos agentes devem ser registradas integralmente, incluindo o raciocínio, as verificações de autorização e os resultados.

Esses controles refletem uma distinção importante entre restrições arquiteturais, nas quais o sistema impede tecnicamente que um agente acione determinadas ferramentas ou ações, e restrições comportamentais, nas quais o agente poderia executar a ação, mas é instruído a não fazê-lo. Sempre que possível, os limites críticos para a segurança devem se basear em controles arquiteturais, e não apenas em instruções comportamentais.

Os sinais de alerta incluem: Entre os sinais de uma governança agêntica fraca estão o acesso irrestrito a ferramentas ou a dependência exclusiva do alinhamento do modelo para evitar o uso indevido; a ausência de limites de permissão documentados para cada ferramenta; a falha em preservar o contexto de identidade para garantir que os agentes herdem as permissões dos usuários; a incapacidade de detectar sequências de ações inseguras por meio da análise de cadeias; e o registro incompleto das ações dos agentes, sem verificações de raciocínio e autorização.

Observabilidade, auditoria e análise forense

Quando algo dá errado em um sistema de IA, é importante ser capaz de demonstrar como e por que isso aconteceu e, talvez, até mesmo reproduzir o ocorrido.

Os compradores devem perguntar se as interações com a IA podem ser reconstruídas de ponta a ponta, incluindo entradas, contexto, políticas, saídas, ações, ferramentas acionadas e dados acessados. Sistemas eficazes também devem oferecer suporte a monitoramento e alertas contínuos, permitindo que as equipes de segurança detectem comportamentos anormais, cadeias de ações inseguras ou interações inesperadas entre agentes antes que os incidentes se agravem. Sem visibilidade suficiente sobre o comportamento do sistema, a resposta a incidentes torna-se especulativa e os esforços de governança perdem credibilidade.

Quando ocorrem incidentes relacionados à IA, pode-se exigir que as organizações apresentem evidências, e não apenas explicações. Sem registros detalhados das entradas, do contexto recuperado, das políticas aplicadas, das saídas e das ações, as equipes de resposta a incidentes são obrigadas a reconstituir os eventos com base em suposições, e não em fatos — algo particularmente problemático em sistemas de IA, nos quais o comportamento pode não ser reproduzível devido ao não determinismo. Por exemplo, um órgão regulador ou auditor interno pode questionar por que determinadas informações foram divulgadas ou por que uma ação automatizada foi executada. No entanto, sem observabilidade de ponta a ponta, as organizações não conseguem demonstrar a intenção, a proporcionalidade ou a eficácia dos controles. Portanto, os compradores devem avaliar se as plataformas de segurança de IA oferecem o nível de visibilidade necessário para dar suporte à resposta a incidentes, à elaboração de relatórios de conformidade e ao aprendizado pós-incidente.

O registro abrangente de logs deve permitir a reconstrução completa das solicitações, incluindo o prompt original, o contexto recuperado com as respectivas fontes, o contexto de identidade e autorização, as políticas avaliadas e suas versões, a saída do modelo, as modificações realizadas, a resposta final ao usuário e as ações subsequentes. Os eventos de segurança de IA devem poder ser integrados a sistemas SIEM com latência mínima, permitindo a correlação com o tráfego de rede e os eventos de autenticação. Violações críticas devem gerar alertas rapidamente, com contexto suficiente para uma resposta imediata, incluindo painéis unificados para acompanhar métricas de segurança, desempenho e qualidade, com análise de tendências.

Do ponto de vista de GRC, sistemas que não podem ser observados não podem ser governados.

Integração e interoperabilidade

Controles de segurança de IA que operam de forma isolada criam lacunas de visibilidade e impedem uma resposta coordenada. Arquiteturas de defesa em profundidade exigem controles que compartilhem dados de telemetria e coordenem a aplicação de políticas entre as diferentes camadas de segurança.

Gerenciamento de identidades e acessos: Os limites de autorização devem abranger desde a autenticação do usuário, passando pela recuperação de dados, até a saída final. As organizações devem avaliar como os sistemas se integram aos provedores de identidade e se as alterações de função são propagadas adequadamente. Os sistemas devem manter o contexto de autorização quando agentes de IA atuarem em nome dos usuários, com cadeias de permissões rastreáveis; e as políticas de acesso devem ser herdadas dos modelos de RBAC existentes, sem duplicação de configurações. Na camada de recuperação, os sistemas devem aplicar o princípio do menor privilégio, filtrando os documentos com base no nível de autorização do usuário solicitante.

Integração com SIEM: Os eventos de segurança de IA devem ser correlacionados com dados mais abrangentes de telemetria de segurança. Para isso, os sistemas devem exportar eventos para plataformas SIEM em formatos padrão, como OCSF ou CEF, com latência mínima. Formatos de log proprietários impedem a correlação com o tráfego de rede, eventos de autenticação e padrões de acesso a dados. As organizações devem verificar se é possível criar regras de detecção personalizadas com base em eventos de segurança de IA e se os alertas se integram aos fluxos de trabalho existentes de resposta a incidentes.

Alinhamento com frameworks de conformidade: As soluções devem mapear os controles para frameworks estabelecidos, com cobertura específica dos controles e evidências de auditoria, e os relatórios de conformidade devem ser personalizáveis de acordo com requisitos regulatórios específicos. Alegações genéricas de conformidade sem o mapeamento de controles específicos são insuficientes.

Suporte a APIs e automação: As operações modernas de segurança exigem controle programático, com sistemas que ofereçam suporte a fluxos de trabalho de políticas como código e à integração de infraestrutura como código. APIs sem documentação ou sujeitas a mudanças frequentes tornam as integrações frágeis.

O que os compradores devem exigir antes de comprar

As empresas devem exigir evidências em vez de diagramas de arquitetura e materiais de marketing sofisticados, repetibilidade em vez de demonstrações impecáveis e validação independente em vez de alegações sem comprovação.

Os compradores devem esperar que os fornecedores expliquem as limitações, ofereçam suporte a testes realistas e forneçam evidências que resistam a uma análise rigorosa.

Não se deve confiar em controles de segurança que não possam ser testados ou explicados para proteger sistemas de IA essenciais aos negócios.

Preparação para a validação independente

Avaliar a segurança da IA é difícil, mas essa dificuldade não justifica a falta de validação. Testes independentes continuam sendo uma das poucas maneiras de as empresas terem confiança de que os controles e recursos funcionam conforme alegado.

Os compradores devem esperar abordagens de validação que reflitam condições do mundo real, incluindo entradas adversariais, cenários de degradação e requisitos de governança. Fornecedores que não estejam dispostos a participar de validações significativas demonstram imaturidade, não solidez.

A validação também não deve ser tratada como uma atividade pontual. Controles de segurança de IA que apresentam bom desempenho na avaliação inicial podem perder eficácia à medida que as ameaças evoluem, os recursos dos modelos avançam e surgem novas técnicas de ataque. O cenário de ameaças muda rapidamente, e os incidentes de segurança de IA podem envolver métodos de ataque nunca vistos antes. Portanto, as organizações devem estabelecer requisitos de validação contínua, além dos testes iniciais.

Integração de inteligência de ameaças: As organizações devem avaliar a frequência com que os fornecedores atualizam suas soluções para incorporar vulnerabilidades recém-divulgadas por provedores de inteligência de ameaças e organizações de pesquisa em segurança. Os fornecedores devem demonstrar a capacidade de detectar ataques publicados recentemente, e não apenas aqueles presentes em dados históricos de treinamento. A ingestão automatizada de inteligência de ameaças permite uma resposta mais rápida do que os processos de análise manual.

Compatibilidade com a evolução dos modelos: Os recursos dos modelos fundacionais evoluem rapidamente, exigindo que os controles de segurança se adaptem. As organizações devem solicitar dados sobre a eficácia da detecção específica para cada modelo em diferentes modelos fundacionais e ter cautela com alegações genéricas sem evidências quantitativas, que podem ocultar pontos cegos. Os fornecedores devem apresentar cronogramas claros para a certificação de novas versões dos modelos e medidas de mitigação provisórias durante eventuais lacunas no processo de certificação.

Validação conduzida pelo comprador: As organizações devem testar continuamente os controles, em vez de depender exclusivamente da validação do fornecedor. Os compradores devem negociar direitos contratuais para realizar exercícios periódicos de red team, testes automatizados contínuos de evasão e testes A/B de alterações de políticas em produção. Fornecedores que restringem os testes dos clientes ou não disponibilizam telemetria granular demonstram imaturidade.

As organizações devem tratar a validação como uma parceria contínua, e não como uma avaliação pontual, para manter sua eficácia à medida que o cenário de ameaças evolui. Sem essa prática, até mesmo controles bem projetados podem acabar se mostrando insuficientes diante de novas técnicas de ataque.

Conclusão: das alegações à responsabilização

A aquisição de soluções de segurança para IA não é apenas uma decisão técnica; é uma decisão de governança com consequências de longo prazo.

As empresas que fazem as perguntas difíceis desde o início estão mais bem preparadas para gerenciar riscos, justificar decisões e evitar falhas que poderiam ser prevenidas.

A segurança da IA não será bem-sucedida por meio de novidades ou abstrações, mas sim por meio de responsabilização, transparência e avaliação rigorosa.

© 2026 NSS Labs®. Todos os direitos reservados. Nenhuma parte desta publicação pode ser reproduzida, copiada/digitalizada, armazenada em um sistema de recuperação, enviada por e-mail ou, de qualquer outra forma, divulgada ou transmitida sem o consentimento expresso por escrito da NSS Labs ("nós").