Um agente de IA que atua em contas ligadas pode alterar dados ou desencadear processos empresariais. Antes de escolher um fornecedor, o responsável pelo negócio e quem analisa a segurança podem comparar os controlos de um fluxo de trabalho proposto com os requisitos escritos da organização. O resultado é um registo datado de provas. Uma pergunta sem resposta permanece em aberto; uma alegação do produto não demonstra, por si só, que uma ação será impedida. O método baseia-se no NIST AI Risk Management Framework Playbook e no AI Agent Security Cheat Sheet da OWASP; nenhum deles avaliou o fornecedor candidato.
A grande mudança
- O que mudou: A aquisição de um agente pode incluir ações delegadas em sistemas empresariais. O comprador precisa de saber quem pode fazer o agente agir, sobre o quê e mediante aprovação de quem.
- Por que importa: O comprador pode associar cada ação proposta a um controlo identificado e às respetivas provas. Isto oferece ao responsável pelo negócio e a quem analisa a segurança uma base concreta para limitar o acesso ou suspender a aquisição.
- O que observar: A decisão depende de provas para a versão exata do produto e o fluxo de trabalho. Um controlo mostrado na documentação pode ainda exigir uma demonstração supervisionada antes de ser aceite para a utilização pretendida.
Reúna quatro elementos
Use o perfil de risco escrito já existente e aprovado pela organização. Deve identificar o responsável pelo negócio, o resultado pretendido, os dados e destinos permitidos, as ações autorizadas, a autoridade de aprovação, as consequências inaceitáveis e as condições de paragem. Se não existir, peça às pessoas responsáveis que o definam antes de avaliar o fornecedor. Este guia não pode definir a tolerância ao risco da organização por elas.
A orientação MANAGE 3.1 do NIST pede que se aplique a tolerância ao risco da organização aos sistemas de IA de terceiros e que os seus controlos sejam documentados. O Playbook oferece sugestões voluntárias, não uma lista universal de aquisições. As perguntas sobre controlos de ação abaixo também se baseiam na orientação de segurança da OWASP para agentes. Estes referenciais apontam perguntas úteis; as provas do próprio fornecedor devem responder-lhes.
Identifique um fornecedor candidato, o produto e a versão de implementação exatos em análise. Obtenha a documentação atual e as provas que o fornecedor está autorizado a partilhar. Dê acesso ao registo comparativo a quem analisa a segurança e ao responsável pelas aquisições. Mantenha ficheiros sensíveis de arquitetura ou provas num local privado aprovado; a folha de trabalho pode conter ligações, sem copiar segredos.
1. Transforme o fluxo em requisitos
Liste cada ação proposta do agente, o sistema de destino e os dados que precisa de ler ou alterar. Separe a leitura da escrita e das ações visíveis externamente ou irreversíveis. Para cada uma, copie o requisito relevante do perfil de risco escrito: identidade permitida, âmbito da ferramenta e do destino, aprovação, registo, tratamento de dados, interrupção e recuperação. Registe o responsável e a data do perfil.
Crie uma linha por requisito. Assim, o desconhecido fica visível em vez de ficar escondido numa classificação geral do fornecedor. A exigência de o agente nunca aceder a determinada conta precisa de uma linha tanto como uma ação permitida.
2. Identifique quem age e o que pode ser executado
Pergunte que pessoa, conta de serviço ou identidade de agente inicia cada ação, onde ficam as credenciais e se um agente pode passar um pedido a outro. Identifique o componente que verifica a permissão na execução. Compare as permissões reais das ferramentas do fornecedor com as ferramentas, operações, contas e destinos permitidos pelo perfil. Solicite provas de configuração ou arquitetura aplicáveis a esta versão; uma frase na instrução é uma prova fraca de um limite imposto pelo sistema.
Para ações que exigem aprovação, pergunte o que a pessoa que analisa vê antes da execução e como a aprovação fica associada ao interveniente, à chamada exata da ferramenta, ao destino e aos parâmetros. Saiba o que acontece se a aprovação expirar, for negada, for usada duas vezes ou se a ação pedida mudar. Registe como revogar o acesso e quem pode parar uma execução ativa. Um ecrã de aprovação e uma verificação na execução respondem a perguntas diferentes; peça provas de ambas quando o perfil exigir ambas.
3. Acompanhe os dados e o registo da ação
Desenhe o percurso proposto da entrada até ao modelo, ferramentas, destinatários externos, cópias armazenadas e registos. Pergunte que dados recebe cada componente, quem pode recuperá-los e como funcionam a conservação e a eliminação. Inclua subcontratantes ou transferências entre sistemas relevantes para o perfil. Marque uma pergunta sem resposta sobre destino ou conservação como desconhecida; não deduza proteção de privacidade de uma declaração ampla de política.
Solicite um registo de execução para a versão relevante. Quem analisa consegue ligar um interveniente e uma versão de política à chamada proposta da ferramenta, à aprovação ou recusa, ao destino exato e ao resultado? Verifique se o registo mostra apenas uma decisão, uma execução real ou ambas. Uma captura de ecrã, uma exportação de configuração e um percurso completo de eventos demonstram coisas diferentes. Anote partes ocultadas que impeçam a comparação, mantendo credenciais e dados pessoais fora da folha de trabalho.
4. Solicite provas de falhas
Peça provas associadas à versão para uma ação permitida e os percursos de falha exigidos pelo perfil: aprovação negada ou expirada, ferramenta ou destino fora do âmbito, execução interrompida e, quando relevante, falha no registo ou na verificação de políticas. Registe o que foi testado, quando, sob que políticas e definições de ferramentas, o resultado esperado e o observado. Um plano de teste é um pedido de provas, não um resultado observado.
A pessoa responsável pela análise de segurança decide se é necessária uma demonstração supervisionada e autoriza o seu âmbito. Use entradas e contas permitidas fora de produção. Não ligue sistemas em operação apenas para preencher uma folha de aquisições. Se o fornecedor não puder apresentar provas, registe a lacuna e o próximo pedido, sem imaginar o resultado de um teste.
5. Registre a decisão e o trabalho pendente
Em cada linha, marque cumpre apenas quando as provas apresentadas responderem ao requisito escrito para esta versão e fluxo. Marque lacuna quando houver conflito, ou desconhecido quando faltarem provas ou forem demasiado fracas. Anote registos contraditórios e quem deve resolvê-los. O responsável pelo negócio e a pessoa responsável pela segurança registam então a decisão real: pedir mais provas, solicitar aprovação para um piloto restrito, adiar ou rejeitar. Uma entrada que cumpre é um juízo sobre as provas, não uma garantia de segurança nem um substituto do processo de aquisição da organização.
Mantenha o registo datado e reavalie as linhas afetadas quando mudarem o fluxo, a versão do produto, a política, as contas ligadas ou os destinos dos dados. Um piloto posterior precisa de autorização, limites e análise próprios.
Requisito do perfil escrito | Provas do fornecedor, versão e data | Tipo de prova e o que demonstra | Cumpre, lacuna ou desconhecido | Responsável pela análise e próxima ação |
|---|---|---|---|---|
[Um requisito de ação ou controlo] | [Ligação privada ou referência documental; versão; data] | [Alegação, configuração, registo de evento ou demonstração observada; limitação] | [Escolha uma opção e explique] | [Nome, pedido de provas ou decisão] |
Cabeçalho do registo: fluxo e responsável; versão do perfil de risco e data de aprovação; produto candidato e versão de implementação; data da análise; responsável pela análise de segurança; responsável pelas aquisições; localização das provas de acesso restrito. Registro da decisão: decisão, linhas por resolver, limites aceites ou controlos compensatórios, responsável pela aprovação e motivo da próxima análise. Deixe estes campos em branco até que as pessoas responsáveis os analisem realmente.
As orientações públicas usadas para formular estas perguntas estão disponíveis gratuitamente. Preparar a comparação exige tempo da equipa e dos responsáveis pela análise. Provas do fornecedor, acesso confidencial e demonstrações autorizadas podem acrescentar custos ou limitar o que pode ser verificado; obtenha os termos reais junto do candidato. Este exercício documental não testa um fornecedor nem estabelece conformidade jurídica ou um limiar universal de aquisição.
Fontes e leituras adicionais
- NIST AI RMF Playbook, Manage apoia a aplicação da tolerância ao risco da própria organização aos recursos de IA de terceiros, a documentação dos controlos e a sua avaliação. A página informa que AI RMF 1.0 está a ser atualizado e o Playbook será atualizado depois; não informa a data de revisão da página. Não avalia este fornecedor.
- Introdução do NIST AI RMF Playbook descreve as sugestões como voluntárias e informa que o Playbook não é uma lista para seguir integralmente. A folha de trabalho é uma síntese da BIG CHANGE para a tarefa indicada ao leitor.
- OWASP AI Agent Security Cheat Sheet trata de ferramentas com âmbito limitado, autorização na execução, aprovações associadas a ações, registos, proteção de dados e provas de validação associadas à versão. A página atual não informa versão nem data de publicação. São categorias de provas, não demonstração de que um fornecedor as implementa.
