Avaliação de segurança de fornecedor de IA: passo a passo

Uma avaliação de segurança de fornecedor de IA verifica quatro pontos antes de um agente se conectar aos seus sistemas: que acesso ele terá, como seus dados serão tratados, o que ficará registrado e o que o fornecedor faz quando algo dá errado. Faça isso como um exercício escrito e curto, em que cada resposta venha acompanhada de evidência, e deixe o resultado definir as primeiras permissões do agente. Um fornecedor que não consegue responder com clareza já está lhe dando uma informação útil.

Principais pontos

• Avalie a função, não apenas a empresa. O mesmo fornecedor pode ter risco baixo para uma pesquisa somente de leitura e risco alto para um agente que envia e-mails.
• Peça primeiro o acesso na menor forma possível e pergunte quem pode alterá-lo, em quanto tempo ele pode ser revogado e como você saberia que foi usado.
• Acompanhe seus dados em cada etapa: entrada, memória, registros, backups, chamadas ao modelo e exclusão. Cada etapa precisa de um responsável nomeado e de uma regra.
• Os registros devem permitir reconstituir o que o agente fez e por quê, sem expor mais conteúdo sensível do que o necessário.
• Um processo de incidentes é um documento somado a um hábito ensaiado. Peça para ver os dois antes de assinar.

Por que um agente de IA exige uma avaliação de segurança diferente de um software comum?

Uma avaliação tradicional de software pergunta se o produto é seguro para usar. A avaliação de um agente precisa fazer uma segunda pergunta: é seguro deixar esse sistema agir em nosso nome? Um agente lê documentos, guarda contexto, aciona ferramentas e, às vezes, escreve em sistemas de registro. Por isso a avaliação cobre comportamento, e não apenas infraestrutura.

Três características tornam os agentes diferentes. Primeiro, eles recebem instruções por texto, e o texto pode vir de qualquer lugar: um e-mail, um documento compartilhado, uma página da web. Por isso o OWASP Top 10 para aplicações com LLMs inclui prompt injection e excesso de autonomia entre os principais riscos. Segundo, eles têm memória, então um erro ou um vazamento pode persistir além de uma única sessão. Terceiro, eles usam credenciais, e qualquer fraqueza na forma como elas são guardadas e delimitadas vira uma fraqueza nos seus próprios sistemas.

Isso não exige um programa pesado de conformidade. Exige um conjunto enxuto de perguntas, feitas em ordem sensata, com respostas que você consiga verificar. Se a sua empresa ainda está montando políticas mais amplas, o início leve de governança de IA é um bom complemento desta avaliação.

Qual é o passo a passo da avaliação?

Faça o trabalho nesta ordem. Cada etapa gera algo que você pode arquivar, e cada uma pode encerrar a avaliação mais cedo se a resposta for inaceitável.

• Etapa 1: descreva a função em um parágrafo. Nomeie a tarefa, os sistemas que o agente tocaria, os dados que leria e as ações que poderia executar. Todo o resto será julgado contra esse parágrafo.
• Etapa 2: liste o acesso de que a função realmente precisa. Separe leitura, rascunho e envio, e marque quais ações exigiriam aprovação humana.
• Etapa 3: envie ao fornecedor um questionário escrito sobre acesso, tratamento de dados, registros e incidentes. Prefira respostas escritas a uma conversa comercial, porque respostas escritas podem ser comparadas e citadas depois.
• Etapa 4: peça evidências por trás das respostas. Podem ser descrições de arquitetura, exemplos de registros, um diagrama do fluxo de dados, um rascunho do procedimento de incidentes e a lista de subprocessadores.
• Etapa 5: teste você mesmo uma das afirmações. Peça uma demonstração de revogação de credencial, de exportação de registros ou de exclusão de um item de memória, e acompanhe a execução.
• Etapa 6: registre a decisão, as condições e a data da próxima revisão. Aprove um primeiro escopo estreito, não a visão inteira.

As perguntas para fornecedor de agentes de IA antes de assinar cobrem o lado comercial da mesma conversa. Este roteiro fica na segurança.

Como avaliar o acesso que o agente terá?

O acesso é a origem da maior parte dos danos evitáveis, então dedique aqui mais tempo. O Authorization Cheat Sheet do OWASP recomenda negar por padrão e conceder apenas o que a tarefa exige. Aplique isso ao agente de forma literal: comece sem nenhum acesso e adicione uma permissão por vez, cada uma com um motivo.

Faça estas perguntas ao fornecedor sobre acesso:

• Como o agente se autentica nos nossos sistemas? Procure autorização delegada, com tokens limitados e revogáveis, em vez de senhas compartilhadas ou do login pessoal de uma pessoa.
• Podemos conceder leitura sem escrita, e rascunho sem envio? Se essas permissões não puderem ser separadas, o modelo de permissões é grosseiro demais.
• Quem, dentro do fornecedor, pode ver ou usar nossas credenciais, e como esse acesso é registrado?
• Em quanto tempo conseguimos cortar o acesso do agente, e revogar uma credencial interrompe todos os caminhos até aquele sistema?
• O que acontece quando uma conexão expira ou uma permissão é removida? Um bom agente para e avisa, em vez de procurar outro caminho.

A diferença entre ler, preparar e enviar merece ênfase. Uma ferramenta que só lê ainda pode vazar informação se for enganada, mas não altera seus registros. Uma ferramenta que prepara rascunhos mantém uma pessoa no circuito. Uma ferramenta que envia compromete a empresa. O artigo sobre menor privilégio para agentes de IA aprofunda como escalonar essas permissões.

Pergunte também sobre o lado humano. Quem, dentro da sua empresa, é dono de cada conexão? Quem aprova uma nova permissão? Se a resposta for ninguém em particular, resolva isso antes de as respostas do fornecedor importarem.

Um cenário ilustrativo

Este é um exemplo ilustrativo, não um caso real. Uma empresa de serviços quer um agente que prepare e-mails de acompanhamento depois de reuniões com clientes. A avaliação mostra que a configuração padrão do fornecedor pede acesso total à caixa de e-mail, inclusive para envio. A empresa, então, concede leitura a uma única caixa compartilhada e acesso somente de rascunho para as mensagens de saída. Uma pessoa revisa e envia cada rascunho. Depois de algumas semanas analisando os registros, a empresa decide se alguma categoria de mensagem é segura o bastante para envio automático. O agente é útil desde o primeiro dia, e o pior resultado de um erro é um rascunho ruim que uma pessoa se recusa a enviar.

Como avaliar o tratamento de dados?

Acompanhe os dados etapa por etapa. Muitas avaliações param na pergunta se o fornecedor treina modelos com os seus dados. Isso importa, mas é apenas uma etapa. Peça um fluxo de dados em linguagem simples, que cubra todos os lugares onde sua informação pode ficar guardada ou passar.

Percorra estas etapas e obtenha uma resposta escrita para cada uma:

• Entrada: que conteúdo o agente recebe, e podemos limitá-lo por fonte, pasta ou campo?
• Chamadas ao modelo: quais provedores de modelo recebem nosso conteúdo, sob quais termos e com qual retenção?
• Memória: o que o agente guarda entre sessões, onde isso fica, e podemos inspecionar, corrigir e excluir?
• Registros e rastros: contêm o conteúdo completo ou apenas referências, e quem pode lê-los?
• Backups e subprocessadores: para onde vão as cópias, e quem mais tem contato com elas?
• Saída do contrato: quando o contrato termina, o que é devolvido, o que é excluído e como a exclusão é confirmada?

A memória merece atenção especial porque se comporta de forma diferente de um histórico de conversa. Uma informação que o agente lembra pode reaparecer em uma tarefa posterior, para outra pessoa. Pergunte se a memória pode ser delimitada por equipe ou função, e decida com critério o que pode entrar nela.

A propriedade também entra nesta seção. Seus prompts, instruções, memória e resultados devem continuar sendo seus, em um formato que você consiga exportar. O guia sobre quem é dono dos prompts e dados na IA da empresa lista as cláusulas que vale conferir.

Se a sua empresa trata dados pessoais de pessoas no Brasil ou na Europa, confirme também qual parte é controladora e qual é operadora, e onde o tratamento acontece. Pergunte ao fornecedor como ele apoia as suas obrigações (no Brasil, as da LGPD) e leve os detalhes ao seu assessor jurídico. Esta avaliação não substitui orientação jurídica.

Como devem ser os registros e a resposta a incidentes?

Registros e incidentes caminham juntos, porque você não consegue responder àquilo que não consegue ver. O texto introdutório de observabilidade do OpenTelemetry descreve bem a ideia: um sistema é observável quando você consegue entender seu comportamento interno a partir dos sinais que ele emite. No caso de um agente, esses sinais devem responder a uma pergunta simples: o que ele fez, com qual autoridade e com base em quais entradas?

Peça para ver um exemplo real de registro, com o conteúdo sensível mascarado, e confira se ele mostra:

• A tarefa ou solicitação que iniciou o trabalho e quem ou o que a acionou.
• As fontes que o agente leu e as ferramentas que chamou, com entradas e saídas ou referências a elas.
• Qualquer aprovação solicitada, quem a deu e quando.
• Erros, novas tentativas e paradas, incluindo conexões expiradas.
• A versão das instruções e da configuração em vigor naquele momento.

Depois pergunte quem pode ler os registros, por quanto tempo são mantidos e se você pode exportá-los. Registros que capturam tudo podem se tornar um risco de dados por si sós, então a melhor resposta é uma escolha deliberada sobre o que armazenar. O artigo sobre o que registrar na observabilidade de agentes de IA trata dessa troca.

Sobre incidentes, peça o rascunho do procedimento e faça estas perguntas:

• O que conta como incidente e quem o declara?
• Como e em quanto tempo seremos avisados, e por qual canal?
• O agente pode ser pausado imediatamente, por nós e também pelo fornecedor?
• Como as ações afetadas são identificadas e, quando possível, revertidas?
• O que a revisão pós-incidente produz, e nós a recebemos?
• Quando o procedimento foi ensaiado pela última vez?

A última pergunta separa um documento de um hábito. Um fornecedor que já praticou a pausa de um agente e o rastreamento de suas ações responde de forma concreta. Um que não praticou responde em termos genéricos.

O NIST AI Risk Management Framework é uma boa referência para estruturar esse raciocínio: ele organiza o trabalho com risco de IA em governar, mapear, medir e gerenciar. Você não precisa adotá-lo formalmente, mas o vocabulário ajuda na hora de registrar quem é responsável por quê.

Como interpretar as respostas e decidir?

Trate a avaliação como um guia de decisão, não como uma nota. Para cada área, separe as respostas do fornecedor em três grupos.

• Aceitar: a resposta é específica, escrita, apoiada por evidência, e você viu o funcionamento. Avance para um primeiro escopo estreito.
• Aceitar com condições: a resposta é razoável, mas incompleta. Defina uma condição com prazo, como acesso somente de rascunho até que a exportação de registros seja demonstrada.
• Parar: a resposta é vaga, foge para linguagem de marketing ou revela a ausência de um controle, como a falta de uma forma rápida de revogar o acesso. Não conecte sistemas até resolver.

Alguns padrões costumam justificar a parada. O fornecedor pede mais acesso do que a função exige e não sabe explicar por quê. As credenciais são compartilhadas entre clientes. Você não consegue excluir a memória nem exportar os registros. Ninguém sabe descrever o que acontece quando o agente erra. Cada um desses pontos é mais fácil de corrigir antes do contrato do que depois.

Depois da aprovação, mantenha a avaliação viva. Refaça-a quando a função mudar, quando uma nova ferramenta for conectada ou quando o fornecedor trocar de subprocessadores ou de modelos. Um início em fases ajuda: o plano de implantação de agentes de IA em fases permite que o agente trabalhe ao lado das pessoas, sem autoridade, enquanto você compara os registros com o que esperava.

A Be Human trata essas questões como parte de como projeta e opera agentes, e não como um detalhe posterior. Um primeiro projeto define uma função, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável, de modo que a lista de acessos e o fluxo de dados existam por escrito desde o início. A operação gerenciada inclui monitoramento, revisão de permissões, manutenção de integrações e resposta a incidentes, com a identidade, a memória e as permissões do agente sob o seu controle. Você pode pedir essa documentação e solicitar uma demonstração de revogação de conexão antes de qualquer entrada em produção.

Perguntas frequentes

Quanto tempo deve levar uma avaliação de segurança de fornecedor de IA? Depende da função, não do tamanho da empresa. Uma função estreita, somente de leitura, pode ser avaliada em poucas sessões focadas, enquanto um agente que escreve em sistemas centrais merece mais tempo e uma aprovação em etapas. Agende a avaliação antes do piloto, não durante ele.

Precisamos de um especialista em segurança para conduzir essa avaliação? Não necessariamente. Um dono de negócio ou líder de operações pode conduzir o processo se alguém da área técnica ajudar a verificar as evidências, como os escopos de acesso e os exemplos de registros. Se o agente tocar dados regulados ou muito sensíveis, envolva cedo seu assessor de segurança ou jurídico.

E se o fornecedor se recusar a compartilhar o procedimento de incidentes? Trate isso como um sinal importante. Alguns detalhes podem ser confidenciais, mas o fornecedor deve conseguir compartilhar um resumo sob acordo, cobrindo notificação, pausa e revisão. Se ele não consegue descrever o processo de forma alguma, a escolha mais segura é esperar.

A avaliação muda se usarmos um agente desenvolvido sob medida, em vez de um fornecedor? As mesmas quatro áreas se aplicam, mas as respostas passam a ser suas. Você ainda precisa documentar acesso, fluxo de dados, registros e etapas de incidente, e decidir quem mantém tudo isso. O guia de decisão para construir ou comprar agentes de IA ajuda a medir quanto desse trabalho você quer assumir.

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