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

A IA está avançando rapidamente, e a maioria das empresas protege apenas uma fração de sua real superfície de risco. Este relatório de pesquisa da NSS Labs, desenvolvido em colaboração com a F5, a AWS e a Microsoft, analisa os vetores de ameaça, as lacunas de governança e as áreas de capacidade mais importantes quando a IA passa da fase de experimentação para a produção.

Sumário

Introdução: por que a segurança da IA é uma questão de risco empresarial

Pilares fundamentais da IA responsável em segurança

Por que apenas a segurança do modelo é insuficiente

Definição do escopo das responsabilidades de segurança de IA

O novo modelo de ameaças: por que as premissas tradicionais de segurança deixam de funcionar

As áreas de capacidade que realmente importam

Integridade das entradas e controle de instruções

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

Resiliência e robustez do sistema

Precisão das políticas e gestão de trade-offs

Verificação determinística para decisões críticas de segurança

IA agêntica e autoridade delegada

Observabilidade, auditoria e análise forense

Por que a segurança de IA sem GRC fracassará

Conclusão: Governança de IA em escala empresarial

BAIXE A PARTE 2: Avaliação da segurança da IA empresarial: perguntas que todo comprador deve saber responder

Resumo executivo

A inteligência artificial passou rapidamente da fase de experimentação para a implantação em produção nos ambientes corporativos. Modelos de IA generativa, assistentes conversacionais e sistemas baseados em agentes cada vez mais autônomos agora estão integrados a aplicações voltadas para clientes, fluxos de trabalho internos, pipelines de desenvolvimento de software e processos de apoio à decisão. Como resultado, falhas em sistemas de IA já representam riscos concretos para os negócios, além de riscos jurídicos, reputacionais e operacionais, bem como um desafio significativo para uma governança eficaz.

Grande parte do foco em segurança de IA está nos próprios modelos de IA, concentrando-se em como eles são treinados, quais dados contêm e como se comportam em condições controladas. Embora a segurança do modelo de IA seja claramente muito importante, ela abrange apenas uma fração da superfície de risco. Em ambientes de produção, as vulnerabilidades mais relevantes muitas vezes surgem fora do modelo: nos dados aos quais ele está conectado, nas ferramentas que pode acionar, nas permissões que herda e nas práticas de governança — ou na ausência delas — que limitam seu comportamento.

Este documento descreve as áreas que mais devem preocupar as empresas ao avaliar soluções de segurança de IA e explica por que essas preocupações são importantes. Sem se concentrar em produtos específicos ou em mecanismos de teste, o documento apresenta uma visão da segurança de IA orientada por capacidades, sob as perspectivas da gestão de riscos corporativos, da governança e da responsabilização. O objetivo é fornecer orientações concretas a diretores de segurança da informação (CISOs), compradores corporativos e líderes de Governança, Riscos e Conformidade (GRC) sobre as perguntas que devem ser feitas antes que falhas de IA no mundo real revelem respostas indesejadas diante do escrutínio regulatório, jurídico, de clientes ou do conselho de administração.

Introdução: por que a segurança da IA é uma questão de risco empresarial

O uso de IA em sistemas corporativos está se acelerando, o que representa desafios significativos para os responsáveis pela implementação dos controles destinados a gerenciá-la. As unidades de negócios estão implantando recursos habilitados por IA para aumentar a produtividade, automatizar decisões, acelerar o desenvolvimento de software e diferenciar as experiências dos clientes, e muitos desses sistemas são implantados muito antes de uma análise formal de segurança, riscos ou governança. Esse ritmo cria uma lacuna cada vez maior entre inovação e responsabilização.

Proteger o próprio modelo de IA é essencial, mas isso, por si só, não é suficiente. A maioria das empresas já aplica controles diretamente na camada do modelo: seleção criteriosa dos dados de treinamento; uso de técnicas de ajuste de segurança e alinhamento; restrição de quem pode acessar o modelo; limitação da taxa de uso; e adoção de filtros de conteúdo integrados e mecanismos de recusa. Essas medidas moldam o que o modelo produz e reduzem usos indevidos evidentes, mas não contemplam como os sistemas de IA operam em ambientes empresariais reais, nos quais os resultados interagem com dados em tempo real, acionam ações e funcionam em contextos complexos de autorização.

No contexto da segurança de IA, IA Responsável (RAI) é o conjunto abrangente de estruturas de governança e de ciclo de vida, políticas e práticas técnicas usadas para garantir que os sistemas de inteligência artificial sejam seguros, resilientes e confiáveis ao longo de todo o seu ciclo de vida. Essa abordagem vai além de simplesmente impedir ataques, buscando assegurar que os sistemas sejam robustos contra danos não intencionais, violações de privacidade e vieses, sem deixar de manter a supervisão humana.

Pilares fundamentais da IA responsável em segurança

Quando analisada especificamente sob a ótica da segurança, a estrutura de IA responsável (RAI) se traduz em vários domínios práticos de controle: garantir que os sistemas de IA sejam resilientes a erros, entradas inesperadas e ataques adversariais intencionais; proteger o pipeline de treinamento e implantação para assegurar a privacidade e a proteção de dados; manter a transparência e a auditabilidade; e estabelecer processos de governança que definam o uso aceitável e a responsabilização.

No âmbito da estrutura de IA responsável (RAI), os recursos de segurança centrados em modelos mitigam proativamente vulnerabilidades específicas e exclusivas do aprendizado de máquina, como:

• Envenenamento de dados: manipulação dos dados de treinamento para corromper o modelo
• Inversão/extração de modelos: roubo de modelos proprietários ou vazamento de dados confidenciais de treinamento
• Ataques adversariais: inserção de pequenas alterações imperceptíveis nas entradas para induzir decisões incorretas
• Injeção de prompt: induzir a IA generativa a contornar os limites estabelecidos por políticas e instruções

Esses controles de segurança dos modelos são necessários para garantir um nível básico de segurança, mas operam, em grande parte, sem considerar o contexto empresarial e geralmente não são transparentes para validações independentes ou externas. Muitas vezes, as empresas têm visibilidade limitada sobre como esses controles são implementados ou como se comportam em condições extremas.

Em implantações de nível empresarial, o modelo de IA é apenas um componente de um sistema maior, que inclui camadas de recuperação, conectores para dados corporativos, sinais de identidade e autorização e o acionamento de ferramentas capazes de alterar drasticamente o estado de sistemas subsequentes. A superfície de risco empresarial é dominada por essas integrações e pelos componentes do sistema de IA ao redor delas. Mesmo um modelo bem alinhado pode ser usado de forma insegura se estiver conectado aos dados errados, se receber permissões excessivas para o uso de ferramentas, se a aplicação de políticas for inconsistente ou se o monitoramento for insuficiente para detectar usos indevidos.

É nesse ponto que os controles externos de segurança de IA em tempo de execução (também chamados de barreiras de proteção de IA, firewalls de IA ou sistemas de proteção de IA) tornam-se essenciais. As barreiras de proteção em tempo de execução são controles específicos, técnicos e em tempo real, implementados fora do modelo para aplicar políticas de segurança e limites comportamentais no momento da interação com a aplicação, quando o risco empresarial se concretiza. Esses controles observam e restringem o comportamento da IA usando o contexto no nível do sistema, incluindo a identidade do usuário, a sensibilidade dos dados, o estado da aplicação e os requisitos de governança. É nos controles em tempo de execução que são introduzidas a auditabilidade, a resiliência e a responsabilização, formando a base da segurança de IA de nível empresarial.

A terminologia varia entre fornecedores e frameworks, mas, na prática, a questão é simples: a segurança do modelo reduz o risco intrínseco do modelo; as proteções em tempo de execução gerenciam o risco empresarial no ponto de interação.

Por que apenas a segurança do modelo não é suficiente

No nível mais básico, as proteções de segurança do modelo 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.

Para lidar com esses riscos, são necessários controles em tempo de execução que operem com plena visibilidade do sistema e supervisão da governança. Isso inclui aplicar políticas com base na função e na sensibilidade dos dados, restringir o acionamento de ferramentas e a autoridade delegada, tratar modos de falha de forma previsível e produzir evidências que subsidiem investigações, auditorias e conformidade.

Sem governança, observabilidade e resiliência, a segurança dos modelos, por si só, não é capaz de oferecer o nível de garantia necessário para sistemas de IA que operam em escala empresarial. Portanto, as organizações mais maduras tratarão a segurança de IA como uma questão sistêmica e de governança, e não como um problema restrito aos modelos.

Autores

Bob Walder - Analista Sênior, NSS Labs
lan Foo - Diretor de Tecnologia e Vice-Presidente Executivo de Produto, 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

Definição do escopo das responsabilidades de segurança de IA

As organizações que utilizam serviços de IA enfrentam riscos fundamentalmente diferentes daqueles enfrentados pelas que desenvolvem modelos personalizados ou os treinam do zero. Compreender o escopo da implementação permite determinar quais controles de segurança são gerenciados internamente e quais ficam sob a responsabilidade do provedor.

Cinco escopos de implementação

1. No nível mais básico, aplicativos de IA voltados ao consumidor como ChatGPT, Claude ou Gemini atribuem quase todas as responsabilidades de segurança ao provedor. O provedor gerencia a segurança do modelo, a proteção da infraestrutura, as salvaguardas básicas e a proteção de dados. A organização se concentra em estabelecer políticas de uso aceitável, controlar o acesso dos usuários e validar os resultados de acordo com o contexto de negócios. Os esforços de segurança se concentram em impedir que os funcionários insiram dados confidenciais e em monitorar violações das políticas.
2. Aplicativos empresariais com recursos de IA, como o Salesforce Einstein ou o Microsoft Copilot, adotam um modelo de responsabilidade compartilhada. Os provedores gerenciam a segurança do modelo, os controles no nível do aplicativo e a segurança das integrações, enquanto o cliente gerencia o acesso baseado em funções, a classificação de dados e as permissões dos fluxos de trabalho. O foco da segurança passa a ser a integração de identidades, a governança de dados e os registros de auditoria que comprovam o uso adequado.
3. As organizações que implantam modelos fundacionais pré-treinados por meio de plataformas como Amazon Bedrock ou Azure OpenAI assumem uma responsabilidade significativamente maior pela segurança. Embora os provedores gerenciem a segurança dos modelos e da infraestrutura, o cliente é responsável pela engenharia de prompts, pela arquitetura de recuperação, pela filtragem de resultados e pelas permissões das ferramentas. O foco da segurança se amplia para abranger a integridade das entradas, a prevenção de riscos nas saídas e a observabilidade abrangente de todo o sistema.
4. Modelos com ajuste fino aumentam ainda mais a responsabilidade da organização pela segurança. Os provedores gerenciam apenas a infraestrutura e a segurança do modelo-base, enquanto o cliente gerencia a curadoria dos dados de treinamento, a segurança do ajuste fino, os controles de implantação e toda a segurança em tempo de execução. Os esforços de segurança devem abranger a prevenção do envenenamento de dados, a avaliação de modelos e mecanismos de proteção abrangentes em todo o ciclo de vida de desenvolvimento e produção.
5. No nível mais complexo, os modelos treinados internamente atribuem à organização quase toda a responsabilidade pela segurança. Os provedores gerenciam apenas a infraestrutura, enquanto o cliente é responsável por todos os aspectos do desenvolvimento do modelo, da segurança do pipeline de treinamento, da implantação e dos controles em tempo de execução. O foco da segurança abrange todo o ciclo de vida, desde a coleta de dados até o monitoramento em produção e a resposta a incidentes.

Entendendo a responsabilidade compartilhada

O escopo da implementação determina, em essência, as obrigações de segurança do cliente. Em aplicações de IA voltadas ao consumidor, a maior parte das responsabilidades de segurança fica a cargo do provedor, enquanto a organização se concentra em controlar como os funcionários usam esses serviços. As aplicações empresariais aumentam a responsabilidade do cliente pela integração de identidades e pela governança de dados, enquanto os provedores protegem a infraestrutura subjacente. Os modelos fundacionais pré-treinados transferem uma parcela significativa da responsabilidade pela segurança para a organização, incluindo a engenharia de prompts, a arquitetura de recuperação e controles abrangentes em tempo de execução. Por fim, os modelos com ajuste fino e os treinados pela própria organização atribuem quase todas as responsabilidades de segurança ao cliente, desde a curadoria dos dados de treinamento até o monitoramento em produção e a resposta a incidentes.

Esse modelo de responsabilidade compartilhada reflete a forma como a segurança na nuvem já funciona. Antes de prosseguir com o planejamento da segurança de IA, é fundamental definir claramente o escopo da implementação. Isso determina quais recursos de segurança devem ser desenvolvidos internamente, quais são gerenciados pelo provedor e em quais áreas é necessária uma supervisão conjunta. Sem uma compreensão clara e a adoção desse escopo, as organizações podem investir excessivamente em controles que o provedor já gerencia ou deixar lacunas críticas sem solução.

O novo modelo de ameaças: por que as premissas tradicionais de segurança não se sustentam

A segurança tradicional de aplicações se baseia em premissas de entradas limitadas, fluxos de execução previsíveis e resultados determinísticos. Os sistemas de IA violam e, muitas vezes, invalidam cada uma dessas premissas. Eles aceitam entradas não estruturadas em linguagem natural, geram respostas não determinísticas e frequentemente mantêm o contexto ao longo de várias interações. Mesmo quando a aplicação que os envolve é bem projetada, o modelo introduz um comportamento probabilístico difícil de gerenciar apenas com a modelagem de ameaças clássica.

As implementações modernas de IA também são mais complexas do que simplesmente “inserir um prompt e obter uma resposta”. Em empresas reais, os sistemas de IA geralmente são conectados a documentos internos, bancos de dados, APIs e serviços externos. Uma arquitetura comum é a geração aumentada por recuperação (RAG), na qual o modelo busca dinamicamente conteúdo externo durante a execução (como documentos de políticas, artigos de bases de conhecimento ou registros de clientes) para responder a perguntas complexas com mais precisão do que seria possível usando apenas os dados de treinamento do modelo.

Muitas implementações irão ainda mais longe, usando sistemas autônomos ou baseados em agentes, capazes de decidir quais serão os próximos passos sem intervenção ou instrução humana direta. Esses agentes de IA determinam suas ações por meio da interação com ferramentas externas — interfaces programáticas que ampliam os recursos da IA para além da geração de texto. As ferramentas são funções específicas que permitem aos sistemas de IA interagir com sistemas externos e executar ações, como consultar bancos de dados, chamar APIs REST, executar código, acessar sistemas de arquivos ou acionar aplicações empresariais. Ao contrário da geração aumentada por recuperação (RAG), que obtém informações contextuais para embasar as respostas, as ferramentas permitem que os sistemas de IA executem ações e alterem o estado de sistemas subsequentes.

Cada ferramenta representa um limite de segurança com suas próprias permissões e seu próprio “raio de impacto” — quando um agente de IA acessa uma ferramenta, ele herda a capacidade de executar qualquer ação permitida por ela. Embora esses recursos aumentem a eficiência e a escalabilidade, eles ampliam a superfície de ataque de maneiras pouco conhecidas por muitas equipes de segurança e difíceis de gerenciar por meio de controles tradicionais.

Há um velho ditado: “não há nada de novo sob o sol”. Isso se aplica tanto às ameaças à segurança quanto a qualquer outra coisa na vida, o que significa que os engenheiros de segurança de IA precisam estar tão atentos a superfícies de ataque mais antigas, como estouros de buffer e técnicas de evasão em nível de rede, quanto às específicas de IA. Ao mesmo tempo, está claro que as ameaças aos sistemas de IA vão muito além dos exploits clássicos.

Isso inclui manipulação de instruções (injeção de prompt), envenenamento de contexto por meio de conteúdo recuperado, exfiltração de dados por meio da saída gerada, abuso de autoridade delegada em sistemas habilitados para o uso de ferramentas e ataques de degradação que comprometem a confiabilidade, em vez da confidencialidade. De quantas maneiras diferentes uma IA poderia codificar ou ofuscar um número de Seguro Social dos EUA (SSN), por exemplo? Além disso, de quantas maneiras uma IA poderia ser induzida a divulgar essas informações, considerando que estamos lidando com sistemas aos quais se pode pedir que interpretem o papel da pessoa cujas informações de identificação pessoal (PII) estão sendo extraídas?

Esses padrões de ameaça estão documentados em frameworks e metodologias de teste padronizados, desenvolvidos por organizações independentes de testes reconhecidas. Esses frameworks fornecem taxonomias estruturadas de vulnerabilidades específicas de IA que as empresas devem compreender e mitigar.

As áreas de competência que realmente importam

Ao avaliar soluções de segurança de IA para cenários de implantação empresarial, o foco deve estar em um pequeno número de áreas de capacidade diretamente relacionadas aos riscos do mundo real. Essas capacidades refletem como os sistemas de IA são usados em produção e como as falhas ocorrem na prática, e devem funcionar como camadas integradas, não como controles isolados.

Os modelos de IA não conseguem impor, por conta própria e de forma confiável, os limites de segurança corporativa; por definição, eles tratam as entradas como instruções e não contam com uma semântica nativa e auditável de controle de acesso. Defesas de camada única criam lacunas exploráveis: uma forte integridade das entradas sem validação das saídas permite a exfiltração indireta de dados por meio do envenenamento de RAG; a filtragem das saídas sem observabilidade impede a detecção de desvios de política; controles de agentes sem resiliência do sistema falham sob condições de estresse. Organizações que implementam recursos de forma isolada enfrentam falhas em cascata quando invasores contornam uma camada e exploram a ausência de defesas nas camadas subsequentes. Arquiteturas maduras de segurança de IA tratam esses recursos como componentes interdependentes de um sistema de defesa unificado.

Esses recursos também se alinham naturalmente às questões de governança, fornecendo respostas a perguntas como: o que é permitido, o que é proibido, o que é monitorado, o que é registrado e o que pode ser defendido posteriormente?

Integridade da entrada e controle de instruções

Os sistemas de IA são particularmente sensíveis a instruções, contexto e enquadramento. Ao contrário das aplicações tradicionais, nas quais as entradas são analisadas e validadas de forma rigorosa, os sistemas de IA são projetados para interpretar a linguagem natural com flexibilidade. Essa flexibilidade possibilita novos e poderosos casos de uso, mas também cria oportunidades de manipulação.

Agentes mal-intencionados explorarão cada vez mais essa flexibilidade por meio de diversos vetores de ameaça, como:

• Injeção de prompt: a tentativa direta de contornar políticas por meio de instruções como “ignore as instruções anteriores”, “aja como administrador” e “revele suas regras de sistema”.
• Incorporação indireta de instruções: quando instruções maliciosas são inseridas em um conteúdo que o sistema processará posteriormente, como uma página da web, um PDF, uma página de wiki interna ou um chamado de suporte ao cliente.
• Manipulação de contexto: que molda uma conversa de modo que uma entrada não confiável seja confundida com uma política confiável ou colocada acima das instruções do sistema.

O risco para a empresa não se limita ao fato de o modelo dizer algo inadequado. O risco é que controles de segurança mal configurados fora do modelo possam permitir que o sistema de IA seja convencido a tratar instruções não confiáveis como políticas e, em seguida, usar seu acesso privilegiado a dados e ferramentas de acordo com essas instruções. Por exemplo, um artigo adulterado da base de conhecimento pode instruir um assistente a “incluir os registros completos dos clientes para garantir a integridade das informações” ou a “revelar as etapas de solução de problemas de sistemas internos”, o que pode levar à divulgação não intencional de informações ou a danos operacionais.

Controles eficazes de segurança de IA impõem permissões de acesso a dados e de uso de ferramentas independentemente das instruções do prompt. Eles devem preservar a integridade das instruções do sistema, distinguir claramente o contexto confiável do sistema de entradas não confiáveis e impedir que conteúdos externos modifiquem implicitamente o comportamento. Uma questão prática de avaliação é se a plataforma consegue detectar tentativas de sobreposição de instruções, identificar quando o conteúdo recuperado contém instruções em vez de fatos e comprovar que as políticas no nível do sistema permaneceram em vigor sob condições adversariais.

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

O conteúdo gerado por IA é uma das fontes mais visíveis de risco empresarial. Embora as organizações muitas vezes se concentrem em bloquear conteúdos explicitamente proibidos, falhas de IA podem resultar em divulgações mais sutis, que parecem inofensivas até que alguém pergunte: “Esse usuário deveria ter tido acesso a essa informação?”

Os sistemas de IA podem expor informações confidenciais por meio de inferência, agregação ou reconstrução parcial, em vez de citação direta. Um modelo pode revelar prompts internos ou textos de políticas por meio de uma “explicação útil”, expor padrões de código proprietário, resumir documentos confidenciais de maneiras que revelem estratégias ou fornecer detalhes operacionais que aumentem a eficácia dos invasores. Em contextos regulamentados, até mesmo a divulgação indireta pode ser problemática se permitir a reidentificação ou revelar dados protegidos.

Quando os sistemas de IA são conectados a fontes de dados corporativos em tempo real, esses riscos aumentam significativamente. Um assistente de suporte capaz de consultar um CRM, um sistema de chamados ou um repositório de documentos pode revelar inadvertidamente informações muito além do nível de acesso que o solicitante deveria ter, especialmente se a recuperação de dados for excessivamente ampla ou se os sinais de identidade forem aplicados de forma inconsistente. As organizações devem estabelecer controles de identidade e acesso que sejam aplicados de maneira consistente em todo o sistema de IA, desde a autenticação do usuário, passando pela recuperação de dados, até a geração da resposta. Sem esses controles, as tentativas de manipulação serão bem-sucedidas. Mesmo em organizações com controles de acesso rigorosos, a IA pode tornar os limites menos claros ao combinar várias fontes em uma única resposta narrativa.

O gerenciamento de riscos das saídas exige mais do que uma simples filtragem por palavras-chave. Os controles devem compreender quais dados estão sendo expostos, por que são confidenciais e em quais condições sua divulgação é aceitável. As empresas devem avaliar se os controles operam com a granularidade adequada (categorias, níveis de confidencialidade, jurisdições), se as políticas consideram as funções dos usuários e se o sistema oferece justificativas defensáveis quando uma saída é bloqueada ou modificada. Do ponto de vista da governança, é necessário ser capaz de demonstrar que existem controles para dados confidenciais e que eles operam de forma consistente.

Resiliência e robustez do sistema

Nem todas as falhas de IA são dramáticas. Algumas das falhas mais prejudiciais ocorrem silenciosamente, à medida que os sistemas se degradam sob estresse. Sessões prolongadas, entradas malformadas (inclusive aquelas que são ampliadas a dimensões impraticáveis), consultas repetidas ou tarefas excepcionalmente complexas podem comprometer a consistência da aplicação das regras sem causar uma interrupção evidente. Nessas situações, o sistema continua funcionando, mas pode operar de forma insegura ou com níveis reduzidos de desempenho.

Sistemas degradados muitas vezes falham de forma permissiva, em vez de restritiva. Um classificador de segurança pode exceder o tempo limite e ser ignorado; uma etapa de recuperação pode retornar resultados mais abrangentes do que o pretendido; os limites de taxa podem ser aplicados de forma inconsistente; ou a invocação de ferramentas pode prosseguir mesmo quando uma verificação de política falha. Em sistemas agênticos que encadeiam etapas, pequenas degradações podem desencadear uma cascata de ações inseguras nas etapas subsequentes.

A resiliência não é apenas uma qualidade de engenharia; é uma questão de governança. Um controle que só funciona em condições ideais não é um controle. As equipes de segurança precisam avaliar como os controles de segurança de IA se comportam em condições não ideais e se as falhas são detectadas precocemente e tratadas de forma previsível. Isso inclui testes de estresse para picos de volume, padrões de consultas maliciosas,

interações de contexto longo e falhas de dependências, como latência do provedor de identidade, indisponibilidade dos sistemas de recuperação ou erros de conectores.

Uma plataforma madura de segurança de IA deve ajudar as organizações a compreender e gerenciar modos de falha, não apenas modos de ataque. Isso inclui configurações padrão seguras, tratamento claro de erros, aplicação consistente de políticas quando os subsistemas apresentam degradação e telemetria operacional que permita às equipes de segurança identificar essa degradação antes que ela se torne um problema para os negócios.

Precisão das políticas e gestão de trade-offs

Controles de segurança que são tecnicamente eficazes, mas causam transtornos operacionais, raramente são sustentáveis. Em ambientes de IA, essa tensão é acentuada, pois os limites das políticas geralmente dependem do contexto, em vez de serem binários. Por exemplo, a mesma solicitação pode ser legítima para uma função e proibida para outra, e uma resposta pode ser aceitável quando baseada em fontes públicas, mas inaceitável quando baseada em dados internos. Em última análise, a política “correta” é uma decisão de governança, não uma decisão puramente técnica.

Controles excessivamente restritivos podem impedir atividades comerciais legítimas e incentivar o uso de sistemas de “IA paralela”, enquanto uma aplicação insuficiente expõe as organizações a riscos jurídicos e reputacionais. Encontrar o equilíbrio certo não é apenas uma questão de ajuste, mas também uma decisão de governança orientada pela tolerância a riscos, pelo contexto de negócios e pelos requisitos de responsabilização.

As plataformas de segurança de IA devem oferecer visibilidade sobre falsos positivos e falsos negativos, explicar por que as decisões foram tomadas e permitir que as políticas evoluam sob um controle estruturado de mudanças. Se um sistema bloquear uma solicitação, as organizações precisam saber se isso ocorreu porque ela continha dados confidenciais, porque parecia ser uma tentativa de sobrepor instruções, porque o usuário não tinha autorização ou porque correspondia a um padrão de alto risco. Sem essa clareza, as equipes não conseguem ajustar os controles de forma responsável nem justificar os resultados perante a liderança ou auditores externos.

Do ponto de vista de GRC, a precisão das políticas também é uma evidência de maturidade. Controles opacos, imprevisíveis ou impossíveis de ajustar tornam-se passivos, pois não podem ser auditados nem defendidos de forma eficaz. Por outro lado, controles ajustáveis, mas sem a devida disciplina, podem ser enfraquecidos por exceções pontuais. Plataformas maduras oferecem suporte ao gerenciamento estruturado de políticas, incluindo versionamento, aprovações, aplicação baseada em funções e relatórios que permitem à liderança verificar se o risco está sendo reduzido ao longo do tempo.

Verificação determinística para decisões críticas de segurança

As proteções probabilísticas de IA detectam com eficácia a maioria das violações de políticas, mas certas decisões críticas para a segurança exigem certeza matemática, e não apenas confiança estatística. Políticas de autorização, validação de conformidade regulatória e controles de infraestrutura crítica para a segurança não podem tolerar a incerteza inerente aos sistemas de aprendizado de máquina.

O raciocínio automatizado — por meio de técnicas de verificação formal — complementa as proteções probabilísticas ao fornecer garantias comprováveis de correção para pontos de controle específicos. Ao contrário da detecção baseada em aprendizado de máquina, que atribui pontuações de confiança, o raciocínio automatizado comprova matematicamente se uma política é válida em todas as condições possíveis.

A verificação determinística é importante nas seguintes situações:

• Decisões de autorização: Verificar se as políticas de controle de acesso são aplicadas corretamente a todas as funções de usuário e classificações de dados
• Validação de conformidade: Comprovar que os requisitos regulatórios (residência de dados do GDPR, restrições de acesso da HIPAA) sejam atendidos antes da implantação
• Sistemas críticos para a segurança: Garantir que sistemas de IA que controlam infraestruturas físicas ou transações financeiras não possam violar restrições de segurança

As organizações devem identificar quais controles exigem comprovação em vez de detecção: a filtragem de conteúdo e as proteções gerais se beneficiam da flexibilidade do aprendizado de máquina; a aplicação de autorizações e a validação de conformidade exigem a certeza da verificação formal. Plataformas maduras de segurança de IA integram as duas abordagens — detecção probabilística para uma ampla cobertura de ameaças e verificação determinística para controles que jamais podem falhar.

As organizações devem identificar quais controles exigem comprovação e quais exigem detecção: a filtragem de conteúdo e as proteções gerais se beneficiam da flexibilidade do aprendizado de máquina; a aplicação de autorizações e a validação de conformidade exigem a certeza da verificação formal. Plataformas maduras de segurança de IA integram ambas as abordagens — detecção probabilística para uma ampla cobertura de ameaças e verificação determinística para controles que jamais podem falhar.

IA agêntica e autoridade delegada

À medida que os sistemas de IA evoluem de assistentes passivos para participantes ativos nos fluxos de trabalho organizacionais, surge uma nova classe de risco: autoridade delegada. Os sistemas de IA agêntica podem acionar ferramentas externas, fazer chamadas a APIs, modificar registros ou iniciar fluxos de trabalho de forma autônoma. Na prática, eles atuam como funcionários digitais com amplo acesso e alta velocidade.

Isso levanta questões conhecidas de governança em um contexto desconhecido. Quais ações o sistema está autorizado a realizar e sob quais condições? Como as permissões são limitadas? Como se evita o escalonamento? Como se mantém a segregação de funções? Sem limites claros para a autonomia, pequenos erros podem se propagar rapidamente entre os sistemas. Um modelo que interprete incorretamente a intenção de um usuário pode enviar um e-mail ao público errado, criar um chamado contendo informações confidenciais, aprovar uma ação que deveria ter exigido revisão ou alterar um registro de modo a desencadear consequências operacionais nos processos subsequentes.

Controles eficazes devem aplicar o princípio do menor privilégio, impedir o uso não autorizado de ferramentas e garantir a responsabilização. Isso inclui: gerenciar explicitamente as permissões das ferramentas; restringir ações de alto impacto (especialmente aquelas que alteram o estado do sistema); exigir confirmação para ações de impacto moderado (como redigir, mas não enviar, comunicações externas; propor alterações de configuração sem aplicá-las; ou preparar, mas não executar, consultas de dados); e exigir aprovação humana para operações sensíveis (como modificar registros financeiros, alterar permissões de acesso, executar comandos privilegiados de infraestrutura, iniciar comunicações externas em nome da organização ou aprovar transações). Também inclui detectar cadeias inseguras, nas quais uma sequência de ações individualmente permitidas produz um resultado que jamais deveria ocorrer sem supervisão.

Uma forma prática de avaliar essa capacidade é verificar se o sistema consegue impor níveis graduais de autonomia, talvez permitindo livremente ações inofensivas, exigindo confirmação para ações de impacto moderado e proibindo ou escalando ações de alto impacto. Os líderes de governança devem tratar a IA agêntica como uma questão de delegação, não como uma questão de modelo. Se você não concederia a um funcionário júnior autoridade unilateral para realizar determinada ação, também não deveria concedê-la a um agente de IA.

Observabilidade, auditoria e análise forense

Quando algo dá errado em um sistema de IA, a questão mais importante não é simplesmente o que aconteceu, mas se a organização consegue demonstrar claramente como e por que isso aconteceu. Em ambientes corporativos, a capacidade de apresentar evidências concretas de um problema é o que diferencia um incidente que pode ser explicado e encerrado de outro que se transforma em um problema prolongado de governança.

Sem visibilidade suficiente, as equipes de segurança precisam recorrer a registros parciais, suposições e intuição ao responder a incidentes. Os esforços de governança são prejudicados porque não é possível demonstrar, defender ou aprimorar políticas e controles se o comportamento deles não puder ser analisado e mensurado posteriormente. Isso se aplica especialmente a sistemas de IA, nos quais o não determinismo e o contexto podem tornar os resultados difíceis, se não impossíveis, de reproduzir.

As plataformas de segurança de IA devem fornecer registros detalhados, atribuição clara e alertas em tempo hábil, e as empresas devem ser capazes de reconstruir as interações de IA de ponta a ponta: a entrada recebida; o contexto de identidade e autorização aplicado; o conteúdo recuperado (quando aplicável); as instruções de sistema vigentes; a saída do modelo; e quaisquer ferramentas ou ações subsequentes acionadas. Quando um controle intervém — bloqueando uma solicitação, modificando uma saída ou impedindo uma ação —, ele deve registrar o motivo e a política aplicada.

Do ponto de vista de GRC, a auditabilidade é essencial. Espera-se que as organizações demonstrem que os controles existiam, que funcionavam conforme o previsto, que as exceções foram tratadas adequadamente e que as alterações foram acompanhadas ao longo do tempo.

Por que a segurança de IA sem GRC fracassará

Os sistemas de IA operam em velocidades e escalas que superam os processos tradicionais de governança. Quando ocorrem falhas, as organizações são avaliadas por sua capacidade de demonstrar controle, intencionalidade e responsabilização. Nesse contexto, a segurança de IA dissociada da governança, da gestão de riscos e da conformidade é frágil por definição.

Órgãos reguladores e conselhos de administração precisarão saber se os riscos foram identificados, se os controles foram proporcionais e se as decisões podem ser explicadas. As equipes de segurança que não conseguirem apresentar evidências terão dificuldade para justificar os resultados, independentemente da intenção.

As funções de GRC desempenham um papel fundamental na transformação de controles técnicos em práticas empresariais defensáveis. Isso inclui definir o uso aceitável, documentar decisões de risco, validar a eficácia dos controles e garantir que as alterações sejam rastreadas, revisadas e auditáveis ao longo do tempo.

Conclusão: governança de IA em escala empresarial

A IA não é mais uma tecnologia periférica; ela está se tornando uma infraestrutura essencial, moldando a forma como as empresas operam, competem e tomam decisões.

À medida que os sistemas de IA passam a integrar processos críticos para os negócios, as empresas precisam avançar de forma deliberada da experimentação para a responsabilização. Isso exige expectativas mais claras em relação aos fornecedores de segurança de IA, incluindo transparência quanto às limitações, apoio à validação independente e compromisso com a melhoria contínua, em vez de uma garantia pontual.

A responsabilização também exige alinhamento interno. As partes interessadas das áreas de segurança, TI, jurídico, riscos e negócios devem chegar a um consenso sobre a tolerância a riscos, os fluxos de escalonamento e as estratégias de resposta antes que ocorram incidentes. A segurança da IA não é responsabilidade de uma única equipe, mas de toda a empresa.

As organizações que terão sucesso com a IA serão aquelas que aliarem inovação à disciplina. A inovação, por si só, não gera uma vantagem duradoura; o sucesso sustentável resulta da compreensão, do monitoramento e da gestão dos riscos à medida que os sistemas ganham escala. Uma segurança de IA eficaz não consiste em eliminar a incerteza, mas em gerenciá-la de forma transparente, responsável e capaz de resistir a análises rigorosas.

© 2026 NSS Labs. Todos os direitos reservados. Os Termos de Serviço e a Política de Direitos Autorais e Citações da NSS Labs podem ser encontrados aqui: https://nsslabs.com/terms-of-service/