Revisões de segurança de IA explicadas

Por Brian Tr · Atualizado em 6 de outubro de 2026

Uma revisão de segurança de IA é a verificação formal que um comprador corporativo faz no produto de IA de um fornecedor antes de permitir que ele tenha acesso aos dados da empresa. Ela começa como uma revisão normal de fornecedor de software: questionários, certificações, perguntas sobre arquitetura, termos contratuais. Depois acrescenta uma segunda camada de perguntas sobre riscos que só existem porque o produto contém um modelo, como prompt injection, vazamento de informações sensíveis e software que executa ações em nome do usuário.

Para uma startup de IA, essa revisão costuma ser o ponto em que um deal que parecia certo desacelera por semanas. Ela também é previsível. Os frameworks que os revisores usam são públicos, as perguntas se repetem de comprador para comprador, e a maior parte do trabalho é ter as evidências prontas antes que alguém peça. Esta página explica o que é a revisão, como ela difere de uma revisão padrão de SaaS, os frameworks por trás dela, as etapas por que passa e o que preparar.

O que é uma revisão de segurança de IA

Uma revisão de segurança é um processo de due diligence do lado do comprador. A equipe de segurança, risco ou TI do comprador decide se o produto de um fornecedor pode ser usado com os dados do comprador, e em quais condições. O resultado geralmente é uma aprovação, uma aprovação condicional com correções obrigatórias ou uma rejeição.

Duas coisas a diferenciam de uma conversa de vendas comum. O público é um responsável por riscos, não a pessoa que quer o produto. E as evidências precisam estar por escrito, porque o revisor terá de defender a decisão para outra pessoa depois.

Nas vendas de IA, a revisão raramente acontece sozinha. Ela corre em paralelo à revisão jurídica dos termos de dados e, cada vez mais, a uma análise separada de governança de IA. Veja o comitê de compra de IA para saber quem está do outro lado da mesa e por que a segurança costuma ter poder de veto.

Como ela difere de uma revisão padrão de SaaS

Uma revisão de segurança padrão de SaaS pergunta se o fornecedor protege os dados e opera com disciplina. Uma revisão de IA pergunta tudo isso e depois pergunta se a camada de modelo introduz novas formas de perder dados, de ser manipulado ou de causar danos. A base permanece; a camada de IA é um acréscimo.

A linha do comportamento é a que os fundadores subestimam. O software convencional é determinístico, então o revisor consegue raciocinar a partir do design. O resultado de um modelo não é fixo, então o revisor pede evidências de testes. Isso se conecta ao trabalho de avaliação descrito em por que demos importam mais para produtos de IA.

A base: questionários e certificações

Antes de qualquer pergunta específica de IA, a maioria das revisões verifica o mesmo básico.

Questionários de segurança. Os compradores costumam enviar um questionário padronizado ou um próprio. Dois formatos padronizados muito usados são o questionário SIG (Standardized Information Gathering) da Shared Assessments e o CAIQ da Cloud Security Alliance. A página do Cloud Controls Matrix da CSA descreve o CCM como um meta-framework de controles de segurança específicos para nuvem, mapeado para os principais padrões, e distribui o CAIQ junto com ele, incluindo uma versão STAR Level 1 para envio ao CSA STAR Registry. Responder ao mesmo questionário repetidamente é desperdício, então uma startup com um CAIQ ou SIG completo e atualizado consegue reaproveitar a maior parte.

SOC 2. Um relatório SOC 2 é um exame independente dos controles de uma organização prestadora de serviços. A página do conjunto SOC do AICPA lista as cinco áreas a que esses serviços se referem: segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Um relatório que cobre um período declarado é o artefato isolado mais pedido pelos revisores corporativos.

ISO/IEC 27001. O padrão internacional de gestão de segurança da informação é o outro pedido comum, especialmente de compradores fora dos EUA.

Um SOC 2 ou ISO 27001 não responde a perguntas sobre IA. Ele mostra ao revisor que sua organização opera processos controlados, que é o ingresso de entrada. Se você ainda não tem um, diga isso, informe seu cronograma e esteja pronto para responder diretamente às perguntas de fundo. Startups em estágio inicial muitas vezes passam em revisões com respostas escritas claras e um roadmap definido, mas isso reduz a quantidade de compradores dispostos a correr o risco.

Os riscos específicos de IA que os revisores procuram

Os revisores não inventam categorias de risco de IA do zero. A maioria se apoia no OWASP Top 10 for LLM Applications, publicado pelo OWASP GenAI Security Project. A edição de 2025 lista dez riscos:

1. Injeção de prompt (Prompt Injection)
2. Divulgação de informações sensíveis (Sensitive Information Disclosure)
3. Cadeia de suprimentos (Supply Chain)
4. Envenenamento de dados e de modelo (Data and Model Poisoning)
5. Tratamento inadequado de resultados (Improper Output Handling)
6. Autonomia excessiva (Excessive Agency)
7. Vazamento do prompt de sistema (System Prompt Leakage)
8. Fragilidades de vetores e embeddings (Vector and Embedding Weaknesses)
9. Desinformação (Misinformation)
10. Consumo ilimitado (Unbounded Consumption)

Cinco deles aparecem em quase todas as revisões.

Prompt injection. Texto que manipula o modelo para que ele ignore suas instruções. Pode chegar diretamente de um usuário ou indiretamente por meio de conteúdo que o modelo lê, como um documento, uma página web ou um e-mail. A pergunta do revisor é o que um atacante conseguiria fazer o seu produto executar ou revelar, e que limites existem se o modelo for enganado.

Divulgação de informações sensíveis. O produto pode expor os dados de um cliente a outro, ou revelar dados confidenciais em resultados ou logs? É aqui que o isolamento entre clientes, os controles de acesso na recuperação de dados e as práticas de registro são examinados.

Cadeia de suprimentos. Seu produto provavelmente depende de um modelo de terceiros, componentes open source, conjuntos de dados e possivelmente plugins. Os revisores querem saber quais são, quem os atualiza e o que acontece quando um provedor muda os termos ou sofre um incidente.

Tratamento inadequado de resultados. O resultado do modelo é uma entrada não confiável para o restante do seu sistema. Se ele é passado para um banco de dados, um navegador ou um shell sem validação, torna-se um caminho de injeção. Um modelo que escreve um comando que alguém depois executa é o caso clássico.

Autonomia excessiva. A OWASP a define como a vulnerabilidade que permite que ações danosas aconteçam em resposta a resultados do modelo inesperados, ambíguos ou manipulados. Ela lista três causas: funcionalidade excessiva, permissões excessivas e autonomia excessiva. Para produtos de agentes, essa costuma ser a pergunta central, já que o produto age, e não apenas responde. Para a visão específica de agentes, veja segurança de agentes de IA.

Os frameworks que os revisores citam

Quatro nomes aparecem em questionários e documentos de políticas. Saber o que cada um é, e o que não é, evita que você prometa demais.

NIST AI RMF. O NIST afirma que o AI RMF 1.0, lançado em 26 de janeiro de 2023, destina-se a uso voluntário para melhorar a forma como as organizações incorporam confiabilidade ao design, desenvolvimento, uso e avaliação de IA. O NIST lançou o Generative AI Profile (NIST-AI-600-1) em 26 de julho de 2024. Segundo o próprio perfil, um perfil é uma implementação das funções do framework para um contexto específico, e este define riscos novos ou agravados pela IA generativa e depois sugere ações para governá-los, mapeá-los, medi-los e gerenciá-los. Não existe "certificado pelo NIST". Diga "alinhado a" apenas se você realmente mapeou suas práticas.

ISO/IEC 42001. O padrão especifica requisitos para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de IA, e se aplica a qualquer organização que desenvolva, forneça ou use produtos ou serviços baseados em IA. Foi publicado em 18 de dezembro de 2023. Por ser um padrão de sistema de gestão, a certificação significa que um auditor avaliou seus processos. Não é uma garantia de que um determinado resultado do modelo seja seguro, e não é exigido na maioria das revisões hoje. Para uma startup, é um diferencial quando ela vende para compradores que o pedem.

MITRE ATLAS. Inspirado na matriz ATT&CK da MITRE, o ATLAS organiza como adversários atacam sistemas com IA. Equipes de segurança o usam para montar modelos de ameaça e cenários de red team. Raramente pedem a uma startup que seja "compatível com o ATLAS", mas citá-lo no seu modelo de ameaças mostra que o trabalho foi feito.

As etapas de uma revisão

O processo de cada comprador é diferente, mas a maioria segue o mesmo arco.

1. Abertura. A equipe de compras ou de segurança do comprador abre uma solicitação de fornecedor, classifica os dados envolvidos e decide o nível de profundidade. Um produto que toca dados pessoais de clientes ou se conecta a sistemas centrais passa por uma revisão mais profunda do que um que trabalha com conteúdo público.
2. Troca de documentos. Você envia o que tem: visão geral de segurança, relatório SOC 2 ou ISO, questionário preenchido, termos de tratamento de dados, lista de suboperadores, diagrama de arquitetura.
3. Questionário e esclarecimentos. O revisor analisa as respostas e envia perguntas complementares. As perguntas específicas de IA geralmente chegam aqui: treinamento com dados do cliente, provedores de modelo, guardrails, registros.
4. Aprofundamento técnico. Para implantações de maior risco, uma reunião com os engenheiros de segurança do comprador. Eles podem pedir para ver a arquitetura, o isolamento entre clientes, como prompts e ferramentas são tratados e os resultados de testes.
5. Testes, quando exigidos. Alguns compradores realizam ou solicitam testes de intrusão, ou pedem evidências de testes adversariais da camada de modelo.
6. Decisão de risco e correção. O revisor aprova, aprova com condições ou recusa. As condições muitas vezes viram compromissos contratuais ou um plano de correção com datas.
7. Contratação e nova revisão. As conclusões alimentam o contrato. Muitos compradores refazem a revisão periodicamente ou quando algo relevante muda, como um novo provedor de modelo ou uma nova funcionalidade autônoma.

O custo em tempo é real, e é por isso que o pacote de evidências importa. A forma como o resultado se conecta aos termos do deal é tratada em de pilotos de IA a contratos.

Que evidências uma startup de IA deve ter prontas

Os revisores avançam mais rápido quando as respostas já estão escritas. A abordagem prática é um pacote de confiança permanente, mantido atualizado, que você pode enviar sob demanda.

Escreva respostas que resistam ao escrutínio. Uma afirmação como "estamos protegidos contra prompt injection" convida a uma pergunta complementar que você não consegue responder, porque nenhum fornecedor pode prometer isso. Uma afirmação como "conteúdo não confiável é tratado como dado, chamadas de ferramentas são limitadas a estes escopos e ações de alto impacto exigem aprovação" dá ao revisor algo específico para verificar. A mesma disciplina de sustentar cada afirmação com evidências aparece em vender IA para compradores céticos.

Erros comuns

• Exagerar a conformidade. Dizer "compatível com o NIST" ou "certificado ISO 42001" quando nada disso é verdade é a forma mais rápida de perder credibilidade e criar exposição jurídica.
• Não conhecer a própria cadeia de suprimentos. Se você não sabe dizer quais provedores de modelo veem dados de clientes, a revisão trava.
• Ignorar as permissões dos agentes. Dar credenciais amplas a um agente por conveniência é exatamente o que a autonomia excessiva descreve.
• Esconder limitações. Os revisores respeitam muito mais "esta é uma limitação conhecida e este é o controle" do que o silêncio. Para os aspectos de conformidade de agentes, veja conformidade de agentes de IA.

Fatos principais

• Base mais camada de IA: uma revisão de segurança de IA executa as verificações padrão de fornecedores (questionário, SOC 2 ou ISO 27001, termos de dados) e depois acrescenta riscos específicos de modelo.
• Lista da OWASP: a edição de 2025 do OWASP Top 10 for LLM Applications aponta dez riscos, de Prompt Injection a Unbounded Consumption.
• A autonomia excessiva tem três causas: a OWASP lista funcionalidade excessiva, permissões excessivas e autonomia excessiva.
• O NIST AI RMF é voluntário: o NIST lançou o AI RMF 1.0 em 26 de janeiro de 2023 e o Generative AI Profile em 26 de julho de 2024. Nenhum dos dois é uma certificação.
• A ISO/IEC 42001 é certificável: publicada em 18 de dezembro de 2023, ela especifica requisitos para um sistema de gestão de IA.
• O SOC 2 abrange cinco áreas: segundo o AICPA, segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade.
• Existem questionários reutilizáveis: a CSA distribui o CAIQ com o seu Cloud Controls Matrix, incluindo uma versão STAR Level 1.

Leitura relacionada

• Perguntas sobre privacidade de dados que os compradores de IA fazem
• Confiança e avaliação como ativo de vendas
• O que é uma política de IA responsável?
• Vender IA para compradores céticos
• O comitê de compra de IA
• De pilotos de IA a contratos
• Por que demos importam mais para produtos de IA
• Segurança de agentes de IA
• Conformidade de agentes de IA