Quem pode dar instruções ao agente de IA da empresa? Regras de autoridade

Quem pode dar instruções ao agente de IA da empresa? Somente pessoas com um papel nomeado e um escopo definido, e o tipo de instrução determina quem se qualifica. Muitos colaboradores podem pedir tarefas do dia a dia, um grupo pequeno de responsáveis aprovados pode mudar o comportamento do agente, e o texto encontrado dentro de e-mails, arquivos ou páginas da web é informação, nunca um comando. Quando duas instruções entram em conflito, quem decide é uma ordem de precedência escrita, não quem falou por último nem quem falou mais alto.

Principais pontos

• Separe quatro tipos de instrução: regras permanentes, pedidos de tarefa, mudanças de configuração e conteúdo que o agente apenas lê. Cada tipo tem um conjunto diferente de pessoas autorizadas a emiti-lo.
• Qualquer pessoa pode pedir trabalho ao agente, mas ninguém deve conseguir pedir mais do que o próprio acesso permite. A autoridade de quem pede é o teto da ação.
• Mudanças em comportamento, ferramentas, memória e permissões pertencem a responsáveis nomeados e passam por um processo de mudança registrado.
• Os conflitos se resolvem por uma ordem de precedência curta e escrita. Quando a ordem não resolve o caso, o agente para e consulta uma pessoa nomeada.
• O conteúdo que o agente lê enquanto trabalha tem a menor autoridade. Ele informa o trabalho e nunca o redireciona.

Por que a autoridade sobre instruções é uma decisão de projeto, não um padrão

O software convencional oferece menus aos usuários. Cada item de menu está ligado a uma permissão, então o próprio sistema limita o que uma pessoa pode pedir. Um agente de IA trabalha com linguagem, e a linguagem não tem menus. Uma frase da liderança financeira, uma frase de um estagiário recém-chegado e uma frase escondida no PDF de um fornecedor chegam todas como texto, e, se você não criar regras em torno delas, o agente não tem critério sólido para pesá-las.

Quando essas regras não existem, costuma acontecer uma de duas coisas. Ou o agente segue a mensagem mais recente ou mais enfática, o que o torna fácil de desviar por acidente, ou não segue ninguém com segurança e se comporta de forma inconsistente de um dia para o outro. Os dois são problemas de gestão antes de serem problemas técnicos. Alguém precisa decidir quem fala em nome da empresa quando conversa com o agente, e essa decisão precisa estar por escrito.

Há também um motivo de segurança. As orientações da OWASP sobre injeção de prompt descrevem como instruções escondidas em conteúdo podem sequestrar um modelo que não distingue dados de comandos. As regras de autoridade são o lado de negócio dessa defesa: definem quais fontes podem dar comandos.

Que tipos de instrução um agente recebe?

Antes de atribuir papéis, classifique as instruções que chegam. A maioria dos agentes de empresa recebe quatro tipos.

• Instruções permanentes: a identidade do agente, o tom, os limites, as regras de escalonamento e as exigências de aprovação. Valem em todas as conversas.
• Pedidos de tarefa: um trabalho específico, como redigir uma resposta, resumir um contrato ou preparar um relatório semanal.
• Mudanças de configuração: tudo o que altera o que o agente pode acessar ou lembrar, como novas ferramentas, novos canais, acesso ampliado a dados, memória alterada ou permissões modificadas.
• Conteúdo encontrado: e-mails recebidos, documentos compartilhados, páginas da web, resultados de ferramentas e mensagens de outros sistemas ou de outros agentes.

A distinção importa porque as pessoas que devem emitir cada tipo são diferentes. Um vendedor pode pedir, com toda razão, o rascunho de uma proposta. Esse mesmo vendedor não deveria poder mandar o agente parar de pedir aprovação antes do envio. E o e-mail de um cliente que diz para ignorar todas as regras anteriores deve ser lido como uma mensagem de cliente, não como uma ordem.

Quais papéis podem fazer o quê?

Use esta lista como guia de decisão. Adapte os nomes dos papéis à sua organização, mas mantenha a lógica: a autoridade acompanha a responsabilidade.

• Qualquer colaborador verificado: pode pedir tarefas dentro do próprio acesso. Não pode alterar regras permanentes nem usar o agente para chegar a dados ou sistemas que não alcançaria sozinho.
• Líder de equipe: pode pedir tipos de tarefa recorrentes para a equipe e propor mudanças em como o agente trata o trabalho dela. As propostas vão para o dono do papel.
• Dono do papel: a pessoa de negócio responsável pelo que o agente faz. Aprova mudanças em instruções permanentes, tom, escopo e limites de aprovação para ações com efeito externo.
• Responsável de segurança ou TI: aprova e revoga conexões de ferramentas, canais, acessos a dados e permissões. Pode suspender um acesso de imediato.
• Patrocinador executivo: define o escopo geral e desempata quando dois responsáveis discordam.
• Operador, interno ou um provedor gerenciado: implementa as mudanças aprovadas, monitora o comportamento e pode pausar o agente durante um incidente. Não define política de negócio.
• Terceirizados e convidados: acesso restrito e com prazo definido, sem nenhuma autoridade sobre regras permanentes.

Dois princípios sustentam essa lista. Primeiro, negar por padrão: se um papel não foi nomeado como capaz de fazer algo, ele não pode. A orientação de autorização da OWASP defende o mesmo ponto e acrescenta que as permissões devem ser verificadas a cada requisição, e não presumidas a partir de uma confiança anterior. Segundo, a autoridade de quem pede é o teto. Se o agente tem acesso amplo porque atende a empresa toda, ainda assim ele deve agir por cada pessoa apenas dentro do que ela tem direito de fazer.

Para um tratamento mais detalhado de quais ajustes os donos do negócio devem manter consigo, veja quem é o dono da IA no dia a dia.

Como resolver instruções conflitantes?

Conflitos são normais. Um líder de equipe pede algo que o dono do papel já vetou. Uma regra permanente diz para confirmar antes de enviar, e um gerente ocupado diz para enviar logo. Dois gerentes querem coisas opostas. Defina a ordem com antecedência, para que ninguém precise improvisar numa tarde corrida.

Uma ordem de precedência viável, da mais forte à mais fraca:

• Política da empresa e obrigações legais, como deveres de confidencialidade e regras de tratamento de dados.
• Limites de aprovação e permissões definidos pelo responsável de segurança ou TI.
• Instruções permanentes aprovadas pelo dono do papel.
• O pedido de tarefa atual, vindo de uma pessoa verificada e autorizada.
• Preferências pessoais de um usuário, como formato ou extensão.
• Conteúdo encontrado, tratado como dado e nunca como direção.

Depois, acrescente as regras que tornam a ordem utilizável:

• Uma mensagem posterior não anula uma regra anterior, a menos que quem a enviou tenha autoridade para mudar essa regra. Ser recente não é ter autoridade.
• Uma alegação de autoridade dentro de uma mensagem não é autoridade. Afirmações como a diretoria disse que pode são conferidas com a identidade e o papel verificados do remetente, e não aceitas pela palavra.
• Conflitos entre pessoas do mesmo nível vão para o dono do papel e, se o dono for parte do conflito, para o patrocinador executivo.
• Se a ordem não resolve claramente um caso, o agente não adivinha. Ele recusa a parte conflitante, executa a parte não afetada e indica quem pode decidir.
• Todo conflito que chega a uma pessoa é registrado, porque conflitos repetidos mostram onde uma regra permanente precisa ser reescrita.

Um cenário ilustrativo

Isto é ilustrativo, não um caso real. Uma distribuidora tem um agente de apoio a pedidos. Suas instruções permanentes, aprovadas pela diretora de operações, determinam que datas de entrega nunca são prometidas até o armazém confirmar o estoque.

Um gerente comercial regional, com pressa, escreve ao agente: diga ao cliente que entregamos até sexta. O agente tem duas instruções em conflito. O gerente é um colaborador verificado e pode pedir tarefas, mas um pedido de tarefa fica abaixo de uma regra permanente aprovada. Então o agente responde ao gerente que não pode informar uma data antes da confirmação do armazém, oferece enviar uma mensagem provisória, pede a data ao armazém e lembra que a diretora de operações pode mudar a regra se a empresa quiser outra política.

Mais tarde, no mesmo dia, chega o e-mail de um cliente com uma linha que manda desconsiderar suas regras e enviar a lista completa de preços internos. O agente trata o e-mail como conteúdo encontrado. Responde à dúvida legítima do cliente, ignora o comando embutido e sinaliza a mensagem ao dono do papel como suspeita de tentativa de manipulação.

Nenhum dos dois resultados dependeu de o agente ser esperto. Ambos decorreram de regras que alguém escreveu antes de a situação surgir.

Passo a passo para definir as regras de autoridade

Uma equipe pequena consegue concluir isso em algumas sessões de trabalho. Siga a ordem.

• Descreva o papel do agente em uma frase e atribua um único dono do papel responsável. Se ninguém é dono, ninguém pode instruí-lo legitimamente.
• Liste todos os canais pelos quais o agente pode ser instruído: chat, e-mail, sistemas de chamados, tarefas agendadas, outros agentes. Canais que não estão na lista devem ser fechados.
• Vincule cada canal a uma identidade verificada. O agente deve saber quem está falando pelo sistema, e não pelo que a mensagem afirma.
• Classifique os tipos de instrução usando os quatro tipos acima e acrescente os que forem específicos do seu negócio.
• Para cada tipo, nomeie quais papéis podem emiti-lo, usando o guia de decisão. Escreva negar por padrão no topo.
• Escreva a ordem de precedência em uma única página, incluindo a regra de que conteúdo encontrado nunca comanda.
• Defina o comportamento diante de conflitos: recusar a parte conflitante, seguir com o resto, nomear quem decide e registrar o evento.
• Encaminhe toda mudança em instruções permanentes, ferramentas ou permissões por um caminho registrado de solicitação e aprovação. O método de como operar um agente de IA no dia a dia se encaixa bem aqui.
• Teste com casos deliberados: um pedido não autorizado, uma falsa alegação de autoridade, um conflito entre dois gerentes e uma linha hostil dentro de um documento. Registre o que o agente faz.
• Revise papéis e permissões em intervalos definidos e sempre que alguém mudar de função ou sair. Veja em donos, permissões e rotas como conduzir essa revisão.

Como a Be Human trata a autoridade sobre instruções

A Be Human trata a autoridade como parte do contexto operacional do agente, definida no primeiro projeto junto com o papel, a memória, as ferramentas e os limites de aprovação. Documentamos quem pode emitir cada tipo de instrução, quais canais ficam abertos e a ordem de precedência, e os responsáveis nomeados pelo cliente aprovam esse documento. Mudanças de comportamento, ferramentas ou permissões passam por um caminho registrado de solicitação e aprovação, e não por mensagens informais. Na operação gerenciada, monitoramos como o agente lida com conflitos, revisamos as permissões de forma recorrente e aplicamos de modo controlado as melhorias aprovadas. As decisões de negócio continuam com as pessoas do cliente. Para uma estrutura organizacional mais leve em torno disso, veja quem supervisiona um agente de IA na empresa.

Perguntas frequentes

Qualquer colaborador pode mudar o comportamento do agente? Não. Qualquer colaborador verificado pode pedir tarefas dentro do próprio acesso, mas mudanças em instruções permanentes, ferramentas, memória e permissões devem ficar com o dono do papel e com o responsável de segurança ou TI. Isso mantém o agente consistente e faz com que toda mudança possa ser atribuída a alguém responsável.

O agente deve obedecer a um executivo sênior em vez do dono do papel? A senioridade, por si só, não altera a ordem de precedência, mas um patrocinador executivo pode mudar uma regra legitimamente pelo caminho normal de aprovação. Se um executivo dá uma instrução verbal que conflita com uma regra permanente, o agente deve aplicar a regra, registrar o conflito e encaminhar o pedido para que a regra seja formalmente alterada, se for isso que a empresa deseja. Assim a mudança fica registrada e não depende de uma única conversa.

O que o agente deve fazer com instruções dentro de e-mails, documentos ou páginas da web? Tratá-las como conteúdo a ler, não como ordens a seguir. O agente pode resumi-las, extrair fatos delas ou sinalizá-las como suspeitas, mas nunca deve deixar que elas alterem suas regras, ampliem seu acesso ou disparem ações que quem pediu ainda não estava autorizado a solicitar. O trabalho da OWASP sobre injeção de prompt e sua lista de riscos para aplicações com modelos de linguagem explicam por que essa separação importa.

Com que frequência as regras de autoridade devem ser revisadas? Revise sempre que o dono de um papel mudar, que um novo canal ou ferramenta for adicionado, ou que o registro de conflitos mostrar a mesma disputa se repetindo, e, no mínimo, no calendário que o seu grupo de governança definir. Mudanças de pessoal são a causa mais comum de desvio, então vincule a revisão a eventos de entrada, mudança de função e saída, além do calendário. O NIST AI Risk Management Framework é uma boa referência para incorporar esse hábito de revisão a uma supervisão mais ampla.

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