Modelo de carta de governança de IA: donos, aprovações e revisões

Uma carta de governança de IA é um documento curto que define quem é o dono de cada agente de IA, quais ações o agente pode executar sozinho, quais exigem a aprovação de uma pessoa nomeada e quando esse arranjo será revisto. Para a maioria das empresas, uma versão de uma página é suficiente, e ela deve ser atualizada sempre que o agente ganhar uma nova capacidade, uma nova ferramenta ou acesso a novos dados. O modelo abaixo lista os blocos que precisam ser preenchidos e a decisão que cada um obriga a tomar.

Principais pontos

• Nomeie um dono responsável por cada agente e, separadamente, um operador que o mantém funcionando.
• Escreva os níveis de aprovação como ações específicas, e não como rótulos genéricos como "sensível" ou "importante".
• Vincule as datas de revisão a dois gatilhos: o calendário e qualquer mudança no que o agente consegue fazer.
• Guarde a carta junto às configurações de permissão do agente para que os dois nunca fiquem em desacordo.
• Releia a carta quando um modelo, uma ferramenta ou uma fonte de dados mudar, e não apenas depois que algo der errado.

Por que uma carta de uma página funciona melhor que um manual de políticas

A maioria das políticas de IA é escrita uma vez, aprovada em uma reunião e depois esquecida pelas pessoas que de fato operam o agente. A carta foi feita para ser lida por quem precisa decidir rápido. Um teste prático: alguém de fora do projeto deveria conseguir lê-la em poucos minutos e responder a três perguntas. Para que serve este agente? Quem é responsável por ele? O que ele não pode fazer sem pedir autorização antes?

Uma página também obriga a fazer escolhas. Se uma regra não cabe na carta, ou ela é detalhada demais para um documento assim e pertence a um procedimento operacional, ou ainda não foi decidida. Os dois casos merecem atenção antes de o agente entrar em produção. Para o contexto mais amplo de onde a carta se encaixa nas decisões de IA da empresa, o guia de governança de agentes apresenta um ponto de partida leve.

Os seis blocos do modelo

Copie estes títulos para um único documento e preencha cada um com uma resposta curta e específica. Prefira deixar a linha em branco a escrever uma frase genérica.

• Finalidade: o papel de negócio que o agente desempenha, o resultado que ele deve melhorar e o trabalho que ele não faz.
• Donos: o dono de negócio que aceita os resultados, o operador que mantém o agente e o revisor que não pertence a nenhuma das duas equipes.
• Capacidades e limites: as ferramentas, fontes de dados e canais que o agente usa hoje e os que ele não consegue acessar.
• Níveis de aprovação: o que o agente pode fazer sozinho, o que precisa de um aprovador nomeado e o que nunca deve fazer.
• Ritmo de revisão: as revisões agendadas e os eventos que disparam uma revisão antecipada.
• Evidências e condições de parada: o que é registrado, onde o registro fica e em quais condições o agente é pausado.

Os dois últimos blocos são os que mais costumam faltar. Sem eles, a carta declara uma intenção, mas ninguém tem como verificar se o agente a seguiu.

Atribua donos que de fato possam decidir

Três papéis fazem trabalhos diferentes, e a carta deve nomear uma pessoa para cada um. O dono de negócio decide para que o agente serve, aceita seus resultados e resolve as disputas sobre o escopo. O operador mantém integrações, credenciais e monitoramento funcionando, mas não deve conseguir ampliar as permissões do agente sozinho. O revisor verifica permissões e incidentes e tem autoridade para recomendar uma pausa. Quando uma só pessoa acumula os três papéis, a carta ainda pode funcionar em uma equipe pequena, mas o revisor deve ser alguém que não construiu o agente, porque é essa pessoa que faz a checagem sobre quem construiu. O artigo complementar sobre direitos de decisão e datas de revisão aprofunda a questão de quem decide o quê.

Defina níveis de aprovação como ações, não categorias

Palavras como "sensível" ou "alto risco" não dizem ao agente nem ao operador o que fazer. Escreva cada nível como um tipo concreto de ação. Um conjunto que funciona na prática fica assim:

• Ler e resumir: o agente pode buscar e descrever informações de fontes aprovadas.
• Rascunhar: o agente pode preparar uma saída que uma pessoa revisa antes de qualquer coisa sair da equipe.
• Agir com aprovação: o agente só executa a ação depois que uma pessoa nomeada aprova aquele pedido específico.
• Agir dentro de limites: o agente executa a ação sozinho, dentro de um limite declarado, e informa o que fez depois.
• Nunca: a ação está fora das permissões do agente, qualquer que seja o pedido.

Cenário ilustrativo: um agente de atendimento rascunha respostas para perguntas sobre reembolso no nível de rascunho. Ele pode emitir um reembolso apenas dentro de um valor fixo e somente depois que um líder de equipe aprova aquele chamado específico, então essa ação fica no nível de agir com aprovação. Alterações no texto da política de reembolso ficam em nunca, porque o agente não é o autor da política.

Registre o nível de cada ação no mesmo lugar onde as permissões são configuradas. Uma carta que diz uma coisa enquanto o sistema permite outra é uma das falhas mais comuns que uma revisão encontra. As orientações de autorização da OWASP destacam o princípio geral de que o acesso deve ser verificado a cada ação, e não apenas no início de uma sessão.

Defina datas de revisão e gatilhos que acompanhem a capacidade

Só o calendário não basta para agentes cuja capacidade muda. Use dois tipos de revisão. O primeiro é agendado: uma revisão operacional mensal de registros, erros e incidentes, e uma revisão trimestral de permissões, na qual o revisor confirma que cada ferramenta e fonte de dados ainda é necessária. O segundo é disparado por eventos e deve iniciar uma revisão, em vez de esperar pelo próximo horário do calendário:

• Uma nova versão de modelo é adotada, ou o fornecedor muda o comportamento do modelo.
• Uma nova ferramenta, conector ou fonte de dados é adicionada ao agente.
• O agente recebe um novo canal, como e-mail, portal de clientes ou aplicativo de mensagens.
• Ocorre um incidente, incluindo uma saída errada que foi percebida por uma pessoa.
• Um contrato, uma regulamentação ou uma política interna muda uma regra que o agente precisa seguir.

O crescimento de capacidade deve chegar como uma solicitação de mudança, e não como uma ampliação silenciosa de acesso. A solicitação declara o que o agente passará a fazer e não fazia antes, quem aprovou e qual evidência mostrará que aquilo funciona. Os passos estão descritos em como solicitar e aprovar mudanças em um agente de IA gerenciado. O NIST AI Risk Management Framework trata a governança como uma função contínua ao longo da vida de um sistema, e essa é a leitura correta para um ritmo de revisão.

Escreva as condições de parada em termos simples. Por exemplo, o agente é pausado quando repete o mesmo erro, quando tenta uma ação marcada como nunca ou quando o revisor pede a pausa. O registro é o que torna essas condições verificáveis. Anotar o pedido, as ferramentas acionadas, o aprovador e o resultado é a prática básica que guias de observabilidade, como a introdução da OpenTelemetry aos conceitos de observabilidade, descrevem para sistemas de software em geral.

Como a Be Human conduz a carta em um projeto gerenciado

A Be Human projeta, implementa e opera infraestrutura de IA personalizada para empresas, por isso a carta não é um documento arquivado depois do lançamento. Em um primeiro projeto, o papel útil do agente, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável são definidos em conjunto, e a carta é escrita a partir dessas decisões. Na operação gerenciada, os mesmos donos e datas de revisão orientam o monitoramento, as avaliações recorrentes, a revisão de permissões e a resposta a incidentes, e qualquer mudança de capacidade passa pelo caminho de aprovação que a carta descreve. O objetivo é que o documento e o sistema em funcionamento continuem sendo a mesma coisa.

Escolhendo o primeiro agente a ser governado

Comece com um agente, um papel e um dono nomeado, em vez de uma política para a empresa inteira que cubra ferramentas que ninguém implantou ainda. Escolha o papel cujos níveis de aprovação sejam mais fáceis de escrever, porque isso torna a primeira revisão rápida e dá à equipe um exemplo prático. Estenda o modelo para um segundo agente somente depois que o primeiro passar por um ciclo completo de revisão. Se você não tem certeza de qual tarefa deve ser a primeira a ter uma carta, faça o diagnóstico gratuito de IA da Be Human para identificar a primeira tarefa que vale a pena entregar a um agente.

Perguntas frequentes

Quão longa deve ser uma carta de governança de IA? Uma página é um bom alvo. Uma carta que precisa de uma segunda página costuma conter procedimentos que pertencem a um documento operacional. O teste é se um novo revisor consegue lê-la uma vez e saber quem decide, o que o agente pode fazer e quando ele será verificado de novo.

Quem deve assinar a carta? O dono de negócio deve assinar, porque aceita os resultados do agente, e o revisor deve assinar para confirmar que os limites podem ser verificados. Os papéis nomeados importam mais do que as assinaturas, então, quando as pessoas mudarem, a carta deve ser atualizada com os novos nomes e a data da mudança. Vale acrescentar a aprovação da liderança quando o agente atua com clientes ou com pagamentos.

Qual é a diferença entre uma carta e uma política de IA? A política declara princípios gerais que valem para a empresa inteira, enquanto a carta descreve um agente específico, seus donos, suas permissões e suas datas de revisão. Muitas empresas precisam dos dois: a política define as regras e cada carta aplica essas regras a um agente em particular. Uma carta pode funcionar sozinha para um único agente, mas fica difícil de conciliar quando vários agentes compartilham as mesmas ferramentas ou os mesmos dados.

O que deve acontecer quando um agente ganha uma nova capacidade? A mudança deve passar por uma solicitação de mudança por escrito antes de ser habilitada, e não depois. A solicitação deve dizer qual nova ação passa a ser possível, quem aprovou, qual nível de aprovação se aplica e qual evidência vai mostrar que a mudança está funcionando. Depois da mudança, o revisor deve atualizar a carta e as configurações de permissão ao mesmo tempo, para que o documento nunca descreva um sistema que já não existe.

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