Modelo de registro de riscos de IA: uma versão simples para começar

Um registro de riscos de IA é um documento curto e compartilhado, com uma linha por agente de IA, que anota o que pode dar errado, quem é responsável por esse risco, qual controle o limita e quando ele será revisado de novo. Este modelo de registro de riscos de IA começa com essas quatro colunas numa única página, e você só acrescenta detalhe quando uma decisão real pedir. Abaixo estão os campos, um jeito de preenchê-los e um ritmo de revisão que uma equipe pequena consegue manter.

Principais pontos

• Mantenha uma linha por agente, porque o risco depende do que o agente pode ler, escrever, enviar e decidir.
• Quatro campos fazem a maior parte do trabalho: risco, responsável, controle e data de revisão. O resto é opcional.
• Escreva cada risco como uma frase concreta e indique uma pessoa como responsável, não uma equipe.
• Um controle só vale se você consegue apontar uma evidência de que ele funciona, como um log, um teste ou uma revisão por amostragem.
• Um registro só serve se for reaberto. Coloque uma data em cada linha e combine quais eventos provocam uma revisão antecipada.

O que é um registro de riscos de IA e por que mantê-lo pequeno?

Um registro de riscos de IA é uma lista viva das formas como seus agentes de IA podem causar dano ou decepcionar, junto com as decisões que você tomou para limitar isso. É a mesma ideia de um registro de riscos em finanças ou operações, aplicada a um software que lê informações, redige mensagens e, às vezes, executa ações.

Frameworks como o NIST AI Risk Management Framework descrevem o trabalho com risco em funções amplas: estruturar a governança, entender o contexto, medir e gerenciar. Essa estrutura é sólida, mas uma empresa com poucos agentes não precisa de um programa para começar. Precisa de uma página que as pessoas realmente abram.

Registros grandes falham de um jeito previsível. São montados uma vez, preenchidos com riscos genéricos copiados de uma lista pronta e nunca mais lidos. Um registro pequeno, com linhas específicas, tende a sobreviver porque cada linha descreve algo que o responsável reconhece no trabalho do dia a dia.

Por que uma linha por agente? Dois agentes podem rodar sobre o mesmo modelo e ainda assim carregar riscos muito diferentes. Um resume reuniões internas. O outro envia e-mails a clientes sobre as faturas deles. O modelo é o mesmo, mas o que cada um alcança e faz não é, e é isso que o registro deve descrever.

O que entra em cada linha do modelo?

Copie estes campos para uma planilha ou um documento compartilhado. Os quatro primeiros são o núcleo. Os três últimos valem a pena depois que as primeiras linhas já parecerem naturais.

• Risco: uma frase no formato “Se isto acontecer, este dano atinge esta pessoa ou este sistema.” Seja específico sobre o que o agente toca.
• Responsável: uma pessoa com nome e sobrenome, capaz de decidir se aceita, reduz ou interrompe o risco. Nome de equipe não é responsável.
• Controle: a medida concreta que limita o risco, como uma permissão mais restrita, uma etapa de aprovação, uma restrição de dados ou uma checagem de monitoramento.
• Data de revisão: uma data de calendário, não “trimestral”. Quem olhar a linha deve ver quando a próxima revisão vence.
• Agente e função: o nome do agente e uma frase sobre o trabalho dele, para que a linha faça sentido para quem chegou agora.
• Evidência: onde um revisor consegue verificar que o controle funciona, por exemplo uma lista de acessos, um trecho de log, um resultado de teste ou um conjunto de respostas amostradas.
• Status: aberto, aceito, reduzido ou encerrado, nas palavras do responsável.

Dois hábitos mantêm o modelo honesto. Primeiro, escreva o risco como algo que pode ser observado, não como uma sensação. “O agente pode ser inseguro” não dá para revisar. “O agente pode citar a um cliente uma política de reembolso desatualizada” dá. Segundo, faça do controle algo que uma pessoa possa ligar ou desligar. “Tomar cuidado” é uma esperança, não um controle.

Como preencher o registro, passo a passo?

Você consegue completar uma primeira versão em uma sessão de trabalho, com as pessoas que de fato usam os agentes. Siga esta sequência.

• Passo 1, liste todos os agentes, inclusive os informais. Inclua assistentes que pessoas configuraram por conta própria, porque eles também carregam risco real. O artigo sobre como encontrar shadow AI sem punir ninguém mostra como trazê-los à tona com calma.
• Passo 2, descreva o alcance de cada agente. Anote o que ele pode ler, o que pode escrever ou enviar, quais ferramentas pode acionar e quais ações não podem ser desfeitas.
• Passo 3, rascunhe os riscos com três perguntas. Qual é a pior resposta errada plausível? Que informação poderia sair do lugar a que pertence? Qual ação seria difícil de reverter?
• Passo 4, atribua um responsável a cada risco. Se ninguém quer assumir, isso já é uma descoberta. O texto sobre quem é responsável quando o agente de IA comete um erro ajuda a resolver a questão antes que um incidente a force.
• Passo 5, escolha um controle para cada risco e prefira controles embutidos no sistema a lembretes para a equipe. Uma permissão que não existe não pode ser usada de forma indevida. Uma etapa de aprovação é mais forte quando está dentro do fluxo de trabalho, como descrito em quando seu agente de IA deve parar e perguntar.
• Passo 6, registre a evidência. Anote onde você olharia para confirmar que o controle funciona hoje.
• Passo 7, defina a data de revisão e leia a página inteira em voz alta numa reunião curta. As linhas que ninguém consegue explicar em voz alta precisam ser reescritas.

Como fica uma linha preenchida? Um cenário ilustrativo

O exemplo a seguir é ilustrativo, não um caso real. Imagine uma empresa de serviços com um agente de suporte que redige respostas a dúvidas de cobrança. Ele lê o histórico de faturas do cliente e prepara rascunhos que um membro da equipe envia.

Esta é uma linha para esse agente.

• Agente e função: Redator de respostas de cobrança. Prepara rascunhos de respostas sobre faturas para um membro da equipe revisar e enviar.
• Risco: Se o agente citar uma condição de pagamento desatualizada, o cliente recebe por escrito um compromisso errado.
• Responsável: A liderança de suporte.
• Controle: Os rascunhos nunca são enviados automaticamente. O agente lê apenas o documento de condições vigentes, e a liderança de suporte é a única que edita esse documento.
• Evidência: As configurações de envio mostram que não há envio automático. O documento de condições tem um histórico de alterações que a liderança de suporte confere.
• Data de revisão: A primeira segunda-feira do mês seguinte, ou antes, se o documento de condições mudar.

E uma segunda linha para o mesmo agente.

• Risco: Se um cliente colar dados pessoais sem relação com o assunto numa mensagem, o agente pode guardá-los em suas anotações.
• Responsável: A gerência de operações.
• Controle: A memória é limitada a uma lista curta de campos aprovados, e tudo o que estiver fora da lista é descartado.
• Evidência: Uma olhada periódica nas anotações guardadas de uma pequena amostra de clientes.
• Data de revisão: Definida na mesma reunião mensal.

Repare no que as linhas não têm: nenhuma fórmula de pontuação, nenhum código de cores, nenhuma justificativa longa. Cada linha nomeia um evento concreto, uma pessoa e uma medida que pode ser verificada. Se o responsável quiser depois classificações de probabilidade e impacto, pode adicionar colunas sem refazer nada.

Quais riscos um primeiro registro deve cobrir?

Você não precisa inventar riscos do zero. Use esta lista como ponto de partida ao redigir as linhas e mantenha só os que se aplicam ao agente que está na sua frente.

• Respostas erradas ou inventadas: o agente afirma algo falso com confiança, diante de um cliente ou numa decisão interna.
• Exposição de dados: informações chegam a uma pessoa, ferramenta ou log que não deveria tê-las. O guia sobre minimização de dados em agentes de IA é um bom complemento aqui.
• Permissões em excesso: o agente pode fazer mais do que o trabalho dele exige. A orientação de autorização da OWASP gira em torno do privilégio mínimo, e a mesma ideia vale para o acesso de agentes a ferramentas.
• Instruções ocultas em conteúdo: um documento, página web ou e-mail contém texto que tenta desviar o agente. O OWASP Top 10 para aplicações com LLM chama isso de prompt injection, e a lista inteira é uma boa fonte de ideias para o registro.
• Contexto desatualizado: o agente continua se apoiando numa política, tabela de preços ou dado de cliente que mudou. Veja engenharia de contexto para agentes de negócio.
• Mudança silenciosa: uma atualização de modelo, troca de ferramenta ou instrução editada altera o comportamento sem que ninguém tenha decidido isso.
• Responsabilidade indefinida: ninguém sabe dizer quem aprova mudanças, quem é avisado de incidentes ou quem pode desligar o agente.

Para cada item, pergunte se ele é real para esse agente. Um agente de redação com acesso somente de leitura tem pouca exposição a alguns deles, e escrever “não se aplica, porque ele não consegue enviar nem editar” é uma entrada perfeitamente boa. Mostra que a pergunta foi feita.

Com que frequência revisar e o que deve antecipar a revisão?

A data de revisão é o campo mais negligenciado e o mais valioso. Sem ela, o registro vira um documento de boas intenções. Escolha a data pelo tamanho do dano que o risco pode causar e pela velocidade com que o entorno do agente muda. Um agente que pode contatar clientes ou mexer em registros financeiros merece uma data mais próxima do que um que resume anotações internas.

Combine também os eventos que provocam uma revisão antecipada, independentemente do calendário.

• Uma nova ferramenta, fonte de dados ou canal é conectado ao agente.
• O modelo, as instruções ou a base de conhecimento do agente são alterados.
• Ocorre um erro, uma reclamação ou um quase incidente envolvendo o agente.
• O responsável deixa a empresa ou muda de função.
• Muda uma política, um contrato ou uma norma de que o trabalho do agente depende.

Em cada revisão, o responsável responde a três perguntas simples. O risco ainda está descrito corretamente? O controle continua em vigor, e a evidência mostra isso? Aconteceu algo que muda o status? Depois, define a próxima data. Se uma revisão não produz mudanças sucessivamente, aumente o intervalo daquela linha. Se produz surpresas, reduza o intervalo e investigue o motivo.

Uma sessão de revisão curta também funciona como ponto de avaliação. Quando um controle depende da qualidade das respostas, amostre respostas reais e compare com o que o responsável aceitaria. Guias de avaliação, como o guia de evals da OpenAI e os textos da Anthropic sobre avaliação de agentes, explicam como tornar essa amostragem repetível à medida que o número de agentes cresce.

Como a abordagem gerenciada da Be Human trata o registro?

Um primeiro projeto da Be Human define uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável. Essas quatro decisões correspondem diretamente às linhas do registro: as ferramentas e a memória descrevem o alcance, os limites de aprovação são controles e o critério de sucesso dá ao responsável algo para verificar. Durante a operação gerenciada, o monitoramento, as avaliações recorrentes e as revisões de permissões geram achados, e esses achados atualizam as linhas e as datas de revisão correspondentes. A empresa mantém os nomes dos responsáveis e as decisões de aprovação, porque essas são escolhas de negócio. O atendimento é remoto, em inglês e português.

Perguntas frequentes

Quantos riscos cada agente deve ter no registro? Comece pelos poucos que você consegue descrever de cabeça, geralmente de dois a quatro por agente. Se você não consegue indicar um controle ou um responsável para um risco, ele ainda não está pronto para virar uma linha. Acrescente mais apenas quando um evento real ou uma revisão mostrar uma lacuna.

Quem deve cuidar do registro em si? Escolha uma pessoa para manter o documento e conduzir a reunião de revisão, muitas vezes alguém de operações ou compliance. Essa pessoa não é dona de todos os riscos. Cada risco mantém o seu responsável, que está mais perto do trabalho e pode decidir o que fazer.

Precisamos de um registro se só usamos um assistente de chat? Sim, mas bem pequeno. Até uma única linha ajuda, se disser quais informações a equipe pode colar no chat, quem confere as respostas antes de saírem da empresa e quando essa prática será revisada. Uma política de uso aceitável de IA para funcionários pode então reunir as regras detalhadas.

Como o registro de riscos se relaciona com a regulação? O registro não é um documento de conformidade legal, mas reúne fatos organizados para levar a um advogado ou consultor. Quais regras se aplicam depende de onde você atua e do que o agente faz com dados pessoais ou com decisões sobre pessoas. Peça a um profissional qualificado que confirme isso e mantenha o registro como o documento de trabalho dos seus controles.

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