SOC 2 e ISO 27001 para fornecedores de IA: o que exigir

Um relatório SOC 2 ou um certificado ISO 27001 mostra que o fornecedor de IA mantém um programa de segurança documentado, examinado por uma parte independente. Não mostra como a IA se comporta, o que acontece com os seus dados dentro de um fluxo de modelo, nem se é seguro conectar um agente às suas ferramentas. Ao avaliar SOC 2 e ISO 27001 para fornecedores de IA, trate a certificação como a porta de entrada e faça em seguida as perguntas específicas de IA.

Principais pontos

• SOC 2 e ISO 27001 descrevem como o fornecedor protege a própria organização e os próprios sistemas, dentro de um escopo que ele mesmo define.
• Leia o escopo, o tipo de relatório, as exceções e a lista de prestadores de serviço subcontratados antes de qualquer outra parte.
• Nenhuma das duas estruturas testa o comportamento do modelo, a resistência a injeção de prompt, a qualidade das respostas ou o que um agente pode fazer nos seus sistemas.
• Pergunte por escrito sobre treinamento com os seus dados, suboperadores, permissões, registros e condições de saída, mesmo quando o certificado estiver limpo.
• A certificação reduz um tipo de risco. Definir a configuração e os limites de aprovação continua sendo responsabilidade da sua empresa.

O que o SOC 2 realmente cobre em um fornecedor de IA?

O SOC 2 é um relatório de atestação escrito por um auditor independente. O auditor examina os controles do fornecedor com base em critérios publicados e emite uma opinião. Os critérios são agrupados em categorias: segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. A segurança sempre entra. As demais são escolhidas pelo fornecedor, então um relatório pode não dizer nada sobre confidencialidade ou privacidade.

Existem dois tipos de relatório. O Tipo I descreve se os controles foram bem desenhados em uma data específica. O Tipo II testa se esses controles realmente funcionaram ao longo de um período declarado. Para o comprador, o Tipo II pesa mais, porque mostra que os controles foram usados dia após dia, e não apenas bem descritos em uma data.

O detalhe mais importante é o escopo. O fornecedor escreve uma descrição do sistema que informa quais produtos, infraestrutura e equipes estão dentro da auditoria. Um fornecedor pode ter um relatório válido que cobre o portal de cobrança e a plataforma principal, enquanto o produto de agentes, mais novo, fica de fora. O relatório é verdadeiro, mas não trata do que você está comprando.

O que a ISO 27001 cobre e como ela se diferencia?

A ISO 27001 certifica um sistema de gestão de segurança da informação. Isso significa que o fornecedor tem um processo gerenciado para identificar riscos, escolher controles, revisá-los e melhorá-los. Um organismo de certificação audita o sistema, emite o certificado e volta periodicamente para auditorias de acompanhamento.

Dois documentos importam. A declaração de escopo diz quais partes da organização e quais locais estão cobertos. A Declaração de Aplicabilidade lista quais controles o fornecedor escolheu e quais excluiu, com a justificativa. Ler as exclusões muitas vezes revela mais do que ler as inclusões.

A diferença prática em relação ao SOC 2: a ISO 27001 certifica que existe um sistema de gestão e que ele funciona, enquanto o SOC 2 entrega um relatório detalhado sobre controles específicos e os testes do auditor. Muitos compradores conseguem pedir o relatório SOC 2 completo mediante um acordo de confidencialidade. Com a ISO 27001, em geral você vê o certificado e o escopo, e pede a Declaração de Aplicabilidade à parte. Nenhum dos dois é melhor em todos os casos. Alguns fornecedores têm ambos, o que é um sinal razoável de uma área de segurança madura, mas continua sendo uma afirmação sobre a organização, não sobre a IA.

O que essas certificações não cobrem em um produto de IA?

As estruturas foram escritas para organizações prestadoras de serviço em geral. Elas não testam o que torna um agente de IA diferente de um software comum. Vale nomear com clareza algumas lacunas:

• Comportamento do modelo: se as respostas são corretas, consistentes ou adequadas ao seu processo.
• Injeção de prompt: se um texto hostil em um e-mail ou documento consegue levar o agente a executar uma ação que você não pretendia. O OWASP Top 10 for LLM Applications descreve essa classe de risco e outras específicas de sistemas com modelos de linguagem.
• Uso de dados para treinamento: se o seu conteúdo melhora os modelos do fornecedor ou do provedor do modelo. Uma auditoria limpa pode conviver com uma política permissiva nesse ponto.
• Permissões do agente: o que ele pode ler, escrever, enviar ou gastar depois de conectado às suas ferramentas. O desenho de autorização é uma disciplina à parte, bem tratada no OWASP Authorization Cheat Sheet.
• Provedores a jusante: o provedor do modelo e outros serviços por trás do fornecedor podem ter garantias próprias, e diferentes.
• A sua configuração: uma plataforma segura ainda pode ser configurada com acesso amplo e sem aprovações.

Para pensar o risco específico de IA além dos controles de segurança, o NIST AI Risk Management Framework é uma boa referência. Ele organiza o risco em governança, mapeamento, medição e gestão, o que combina com as perguntas que o certificado deixa em aberto.

Como ler na prática um relatório SOC 2 ou um certificado ISO?

A maioria dos compradores recebe o documento, vê a palavra certificado e arquiva. Uma rotina curta de leitura transforma o documento em evidência. Use esta lista, na ordem:

• Escopo: o sistema descrito inclui exatamente o produto, a região e o ambiente que você vai usar?
• Tipo e período do relatório: é Tipo I ou Tipo II, e o período termina em data recente o bastante para ser relevante?
• Opinião do auditor: é sem ressalvas ou aponta ressalva em algum controle?
• Exceções: os testes encontraram desvios, e a gestão respondeu com uma correção crível?
• Organizações subcontratadas: quais provedores de nuvem, de modelo ou de dados ficam fora da auditoria, ou seja, têm controles que este relatório não testa?
• Controles complementares da entidade usuária: o que o relatório espera que você faça do seu lado, como gerenciar o acesso dos seus próprios usuários?
• Critérios selecionados: confidencialidade e privacidade estão incluídas ou só segurança?
• Pontos da ISO: quem emitiu o certificado, ele está vigente e o que a Declaração de Aplicabilidade exclui?

A exclusão de subcontratados e os controles da entidade usuária são os dois itens mais esquecidos. O primeiro mostra onde a garantia termina. O segundo mostra qual parte do trabalho sempre foi sua.

Que perguntas de acompanhamento o comprador de IA ainda deve fazer?

Depois de ler o certificado, passe às perguntas que ele não responde. Faça-as por escrito e guarde as respostas junto ao contrato. Elas se dividem em cinco grupos.

Tratamento de dados. O fornecedor ou algum provedor de modelo retém prompts, arquivos ou respostas, e por quanto tempo? Algo disso é usado para treinamento ou avaliação? Onde é armazenado e processado? O artigo sobre quem é dono dos prompts e dos dados na IA da empresa ajuda a definir o texto que você deve pedir.

Suboperadores. Quais provedores tocam os seus dados, em que papel, e como você será avisado quando a lista mudar? É possível se opor a uma mudança?

Permissões do agente. Qual é o acesso padrão do agente, como ele é restringido e quem aprova uma ampliação? Ações como enviar mensagens ou alterar registros exigem aprovação humana?

Registros e evidências. Você consegue ver quem ou o que fez o quê, com quais entradas, e consegue exportar esses registros? A retenção e o acesso aos registros devem estar declarados, não presumidos. Equipes de setores regulados costumam precisar de uma trilha de auditoria completa do agente, e vale definir isso desde o início.

Incidentes e saída. Em quanto tempo o fornecedor avisará sobre um incidente que afete os seus dados? O que você recebe no encerramento, em que formato, e como os dados são excluídos depois?

Um cenário ilustrativo: relatório limpo com o escopo errado

Este é um cenário ilustrativo, não um caso real. Uma distribuidora planeja dar ao agente de IA de um fornecedor acesso à caixa de entrada compartilhada e aos registros de pedidos. O fornecedor envia um relatório SOC 2 Tipo II, e o responsável de operações do comprador lê a seção de escopo antes de encaminhá-lo à diretoria.

A descrição do sistema cobre o painel web e o armazenamento de dados do fornecedor. O ambiente de execução do agente, a parte que lê e-mails e chama ferramentas, aparece como um serviço separado, lançado depois do início do período auditado. O relatório também exclui o provedor do modelo como organização subcontratada. Surgem duas perguntas: o ambiente de execução do agente entrará na próxima auditoria, e que garantia o provedor do modelo possui?

O fornecedor responde às duas com transparência. O ambiente de execução entrará em um período posterior, e os termos do provedor do modelo dizem que o conteúdo do cliente não é usado para treinamento. O comprador não desiste. Segue com um piloto mais restrito: acesso somente leitura à caixa de entrada, nenhum envio sem aprovação e uma cláusula que exige aviso se os suboperadores mudarem. O certificado não estava errado. Ele apenas descrevia menos do que o comprador supôs no início.

Um plano de revisão em cinco etapas antes de assinar

A revisão não precisa ser longa. Precisa ser ordenada, com responsáveis. Este plano serve para uma empresa de médio porte em que Jurídico, TI e Operações dividem o trabalho.

• Etapa 1: Solicite o relatório SOC 2 ou o certificado ISO, a declaração de escopo e, no caso da ISO, a Declaração de Aplicabilidade, com acordo de confidencialidade se necessário.
• Etapa 2: Aplique a lista de leitura acima e anote cada diferença entre o escopo e o produto que você pretende usar.
• Etapa 3: Envie por escrito os cinco grupos de perguntas e peça respostas que possam ser anexadas ao contrato.
• Etapa 4: Teste o que for possível. Peça uma demonstração de registros, configurações de permissão e exclusão de dados em vez de aceitar uma descrição. O guia sobre como avaliar uma demonstração de agente de IA mostra como.
• Etapa 5: Defina o limite inicial: quais dados, quais ferramentas, quais ações exigem aprovação. Revise-o após o primeiro período de uso real.

Quem verifica o quê também importa. O Jurídico olha os termos de dados e a responsabilidade, a TI olha acesso e integração, o Financeiro olha as condições comerciais. O texto sobre o processo de compras de agentes de IA detalha esses papéis.

Como a Be Human trata a garantia em um projeto gerenciado

A Be Human não considera o certificado do fornecedor o fim da revisão. Em um projeto gerenciado, ajudamos o cliente a documentar quais provedores fazem parte da pilha, quais dados cada um recebe e quais garantias cada um publicou. Definimos com o cliente o papel do agente, o acesso às ferramentas e os limites de aprovação, mantemos os registros disponíveis para revisão e agendamos revisões de permissões para que o acesso não se desvie com o tempo. O cliente mantém o controle dos limites. O modelo de responsabilidade compartilhada define até onde vão os deveres do provedor e onde começam os da empresa.

Perguntas frequentes

SOC 2 ou ISO 27001 é melhor para um fornecedor de IA? Nenhum dos dois é melhor em todos os casos. O SOC 2 entrega um relatório detalhado com controles testados, mais fácil de inspecionar, enquanto a ISO 27001 mostra um sistema de segurança gerenciado e é amplamente reconhecida em várias regiões. Importa mais que o escopo inclua exatamente o produto que você vai usar.

Um relatório SOC 2 significa que meus dados não serão usados para treinar modelos? Não. O relatório examina segurança e controles relacionados, não as condições comerciais sobre treinamento. Peça a política de treinamento e retenção do fornecedor e de qualquer provedor de modelo por trás dele, e inclua a resposta no contrato.

E se um fornecedor de IA promissor ainda não tem certificação? Muitos fornecedores jovens ainda estão a caminho de uma. Pergunte se há auditoria planejada e para qual escopo, e compense com acesso mais restrito, um piloto limitado, cláusulas contratuais mais fortes e testes diretos de registros e exclusão. Não leia a ausência como prova de más práticas, nem a presença como prova de boas práticas.

Com que frequência devo revisar a garantia de um fornecedor? Revise quando o relatório ou o certificado for renovado, quando o fornecedor lançar um novo produto ou suboperador e quando o seu próprio uso crescer. Para configurações estáveis, uma verificação anual curta com a lista original costuma bastar, com uma revisão extra sempre que o agente ganhar novas permissões.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.