Riscos da superinteligência para empresas: modelo de registro

A forma mais útil de lidar com os riscos da superinteligência para empresas é manter um registro de riscos: uma lista curta de riscos específicos de uma IA mais capaz, cada um com um responsável nomeado, um controle que já existe e um gatilho de revisão que indica quando olhar de novo. O registro não depende de prever quando a IA avançada vai chegar. Ele acompanha o que os seus próprios agentes conseguem acessar, decidir e alterar à medida que os modelos por trás deles melhoram.

Principais pontos

• Cada entrada do registro tem quatro partes obrigatórias: o risco, um responsável nomeado, um controle em funcionamento e um gatilho de revisão.
• Acompanhe riscos sobre os quais você pode agir (acesso, dados, dependência, supervisão, desvio de comportamento) em vez de debater prazos.
• Os gatilhos de revisão devem ser eventos, como uma troca de modelo ou uma nova ferramenta, com um intervalo de calendário apenas como reserva.
• Comece com seis a oito entradas. Um registro curto que é revisado vale mais do que um longo que fica arquivado.
• Todo controle precisa de uma evidência que alguém possa inspecionar, como um log, o resultado de uma avaliação ou uma lista de permissões.

Por que manter um registro para riscos que ainda não chegaram por completo?

Modelos mais capazes mudam o perfil de risco de uma empresa mesmo quando nada muda dentro dela. Um agente que antes redigia e-mails pode, depois de uma atualização do modelo, planejar tarefas em várias etapas, chamar ferramentas e agir em diversos sistemas. Se as permissões, a memória e as aprovações dele foram desenhadas para a versão anterior, a distância entre o que ele consegue fazer e o que você pretendia que fizesse cresce em silêncio. O registro torna essa distância visível e coloca o nome de uma pessoa ao lado dela.

O registro também é diferente de um documento de estratégia. O documento de estratégia discute o que pode acontecer. O registro responde a uma pergunta mais estreita: se esta coisa específica der errado, quem percebe, quem age e o que já está implantado? Esse enquadramento acompanha a forma como o NIST AI Risk Management Framework organiza o trabalho: governar, mapear, medir e gerenciar o risco. O registro é uma versão pequena e prática desse ciclo, dimensionada para uma empresa que não tem um departamento de riscos dedicado.

Se você ainda não tem nenhuma política de IA, uma base leve de governança de agentes de IA é um bom complemento. O registro passa então a ser a parte viva dessa política, o lugar onde ela encontra os agentes reais.

Quais campos cada entrada do registro precisa ter?

Mantenha o modelo pequeno o bastante para que as pessoas o preencham. Seis campos bastam:

• Risco: uma frase que descreve o que pode dar errado, em termos de negócio e não técnicos.
• Responsável: uma pessoa, indicada pelo cargo, que pode alterar o controle e responde se ele falhar. Não um comitê.
• Controle: a medida específica em vigor hoje, como um escopo de permissão, uma etapa de aprovação, uma avaliação ou um backup testado.
• Evidência: onde alguém pode verificar que o controle funciona, como um log, um relatório ou o resultado de um teste.
• Gatilho de revisão: o evento que obriga a uma nova análise, mais um intervalo de calendário como reserva.
• Status: implantado, parcial ou ausente.

Duas regras mantêm o modelo honesto. Primeiro, o responsável precisa ter autoridade sobre o controle. Quem só pode escalar o problema é um mensageiro, não um responsável. Segundo, se você não consegue apontar um controle que exista hoje, registre o status como ausente. Isso é informação útil, não uma falha do exercício. Um registro cheio de entradas em verde logo na primeira rodada costuma indicar que os controles foram descritos, e não verificados.

Quais riscos entram na primeira versão?

As sete entradas abaixo estão escritas como linhas que você pode copiar e adaptar. Apague as que não se aplicam e acrescente duas específicas do seu negócio.

• Risco: o agente ganha capacidade ou acesso a ferramentas além do que suas permissões previam. Responsável: líder de operações. Controle: permissões de menor privilégio e limites de aprovação por escrito. Gatilho de revisão: qualquer troca de modelo, nova integração ou novo tipo de ação.
• Risco: a equipe deixa de conferir as respostas, e os erros do agente passam para as decisões. Responsável: o gestor da área que usa o agente. Controle: revisão humana por amostragem e um aprovador nomeado para ações de consequência. Gatilho de revisão: as amostras deixam de ser revisadas ou as aprovações se tornam automáticas na prática.
• Risco: know-how confidencial ou dados pessoais vazam por memória, prompts ou canais conectados. Responsável: líder de segurança ou jurídico. Controle: memória com escopo definido, logs de acesso e regras de tratamento de dados para cada canal. Gatilho de revisão: nova fonte de dados, novo canal ou acesso de um novo prestador.
• Risco: instruções escondidas em e-mails, documentos ou páginas da web conduzem o agente a usar mal suas ferramentas. Responsável: líder de segurança. Controle: tratar conteúdo externo como não confiável e aplicar a autorização no lado da ferramenta, não só no prompt. Gatilho de revisão: o agente é conectado a qualquer nova fonte de conteúdo externo.
• Risco: o comportamento muda depois de uma atualização de modelo ou de prompt e ninguém percebe. Responsável: o operador do agente. Controle: avaliações recorrentes com amostras de tarefas reais, mais monitoramento dos logs. Gatilho de revisão: qualquer atualização do fornecedor ou resultado de avaliação abaixo do limite combinado.
• Risco: a dependência de um único fornecedor dificulta levar a memória e a configuração do agente para outro lugar. Responsável: líder de tecnologia ou de compras. Controle: memória e configuração exportáveis, com backup e restauração já testados. Gatilho de revisão: renovação de contrato, aviso de descontinuação ou mudança relevante nas condições do fornecedor.
• Risco: novas regras sobre IA ou dados pessoais passam a valer para um caso de uso que você já opera. Responsável: líder jurídico. Controle: inventário dos casos de uso e dos tipos de dados dos agentes, conferido com as regras que se aplicam a você. Gatilho de revisão: entrada em um novo mercado, tratamento de uma nova categoria de dados pessoais ou publicação de orientação por um órgão regulador.

A quarta entrada segue um padrão documentado no OWASP Top 10 for LLM Applications, uma boa referência para o responsável por segurança. A terceira e a sexta se ligam a temas maiores: como proteger o know-how da empresa à medida que os agentes ficam mais capazes e como migrar agentes de IA para outro fornecedor aprofundam o que cada controle deve conter.

Como escrever gatilhos de revisão que realmente disparam?

Revisões só por calendário falham porque o mundo muda entre uma data e outra. Um modelo pode ser atualizado numa terça, uma nova ferramenta conectada numa quarta, e a próxima revisão agendada pode estar a semanas de distância. Os gatilhos funcionam melhor quando estão ligados a eventos que alguém já enxerga. Use esta lista ao escrevê-los:

• Ligue os gatilhos a eventos de mudança: nova versão de modelo, nova ferramenta, nova fonte de dados, novo grupo de usuários ou aviso do fornecedor.
• Ligue os gatilhos a sinais: queda nos resultados de avaliação, aumento no número de respostas corrigidas ou acessos incomuns nos logs.
• Diga quem é avisado. O gatilho vai para o responsável pelo nome, não para uma caixa de entrada compartilhada.
• Acrescente um intervalo de reserva para que entradas sem movimento também sejam vistas. Para as entradas ligadas a permissões, um ritmo trimestral funciona bem, e a revisão trimestral de IA na empresa descreve as etapas e as evidências.
• Registre o resultado todas as vezes: sem alteração, controle ajustado ou risco escalado.

Gatilhos baseados em sinais precisam de algo para medir. Isso significa logs e rastros que mostrem o que o agente fez, que é o território da observabilidade; o guia introdutório de observabilidade do OpenTelemetry explica os conceitos com clareza. Significa também avaliações que reflitam o trabalho real. O artigo da Anthropic sobre como desmistificar as avaliações (evals) de agentes de IA é uma leitura prática para quem vai montar as suas. Sem isso, um gatilho como resultado de avaliação abaixo do limite não tem em que se apoiar para disparar.

Como é um gatilho na prática? Um cenário ilustrativo

Este é um cenário ilustrativo, não o relato de um caso real. Uma distribuidora usa um agente que redige respostas a e-mails de fornecedores e atualiza anotações em pedidos abertos. O provedor anuncia uma nova versão do modelo, com uso de ferramentas mais forte. Esse anúncio é um gatilho de revisão para duas entradas do registro: capacidade além das permissões previstas e desvio de comportamento após uma atualização.

O operador do agente roda o conjunto salvo de e-mails antigos de fornecedores na nova versão e compara os resultados com os da atual. A qualidade dos textos é parecida. Porém, a nova versão tem mais disposição para propor alterações nos registros de pedidos, uma ação que está fora da lista aprovada. O responsável decide manter a versão atual por enquanto, cria uma etapa de aprovação para qualquer atualização de registro e repete a comparação antes de trocar.

Em seguida, o responsável atualiza o registro: controle ajustado, evidência anexada (os resultados da comparação e a nova regra de aprovação) e próxima revisão definida. Nada dramático aconteceu, e esse é o ponto. O registro transformou um anúncio de fornecedor em uma pequena decisão documentada, tomada por uma pessoa nomeada, antes que qualquer coisa chegasse à produção.

Como manter o registro vivo, e onde entra a operação gerenciada?

A maioria dos registros morre depois da primeira reunião porque ninguém é dono da rotina. Um plano simples ajuda a mantê-lo em andamento:

• Monte a primeira versão a partir das sete entradas acima. Remova o que não se aplica e acrescente duas suas.
• Confirme que cada responsável aceita o papel. Quem descobre a entrada depois não vai agir sobre ela.
• Para cada entrada, localize o controle existente e a sua evidência. Marque como ausente o que você não encontrar.
• Coloque cada gatilho onde as mudanças já são aprovadas ou anunciadas, para que ele dispare sem esforço extra.
• Faça uma revisão mensal curta dos itens abertos e ausentes e uma revisão mais completa a cada trimestre.
• Mantenha um executivo responsável pelo registro como um todo, em geral quem patrocina o trabalho com IA.

Em um projeto da Be Human, o registro está ligado ao trabalho de operação gerenciada. O primeiro projeto define uma função útil, a memória e as ferramentas de que ela precisa, seus limites de aprovação e um critério de sucesso observável, o que dá à maioria das entradas um responsável e um controle desde o início. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões e resposta a incidentes, de modo que a evidência por trás de cada controle seja produzida como parte da rotina, e as melhorias sigam um processo controlado de mudança em vez de ajustes improvisados.

Para encontrar a primeira tarefa que vale entregar a um agente, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Precisamos de um registro de riscos se usamos apenas ferramentas de IA simples? Vale ter uma versão curta. Mesmo ferramentas simples tocam em dados da empresa e influenciam decisões, então cada uma merece um responsável e uma regra para saber quando revisitá-la. Com poucas ferramentas, três ou quatro entradas podem bastar.

Quem deve ser o responsável pelo registro como um todo? Um executivo deve responder por ele, de preferência o patrocinador do trabalho com IA, enquanto as entradas individuais pertencem a quem controla os sistemas envolvidos. O executivo não resolve todos os riscos. A função dele é garantir que cada entrada tenha um responsável, um controle em funcionamento e uma revisão recente.

Com que frequência o registro deve ser revisado? Revise as entradas quando o gatilho disparar e use um intervalo de reserva para as demais. Uma conferência mensal dos itens abertos e uma revisão trimestral mais completa funcionam para a maioria das empresas de médio porte. Se os seus agentes mudam com frequência, encurte o intervalo das entradas sobre permissões e desvio de comportamento.

Como isso difere de um registro de riscos de TI comum? Usa a mesma disciplina, mas cobre riscos específicos de agentes: eles agem, guardam memória, leem conteúdo externo e seu comportamento pode mudar quando o modelo é atualizado. Por isso, os gatilhos de revisão se ligam a mudanças de modelo e de ferramenta, além de datas no calendário. Se você já tem um registro de TI, acrescente essas entradas a ele em vez de criar um documento paralelo.

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