Quando um agente de IA deve exigir aprovação humana?

Não em cada passo. Se uma pessoa precisar aprovar cada leitura e cada chamada a uma ferramenta de baixo risco, ela rapidamente começará a clicar de forma mecânica. A aprovação é útil onde um erro do agente pode desencadear uma consequência real: financeira, externa, administrativa, jurídica, relacionada à segurança ou difícil de reverter.

Há outro ponto importante: o nível de controlo não deve depender de quão confiante o modelo parece. Um modelo confiante pode ainda estar errado. Escolhemos o controlo com base na consequência da ação.

Um modelo de decisão: cinco perguntas antes de conceder autonomia

Para cada ação do agente, verificamos cinco características.

1. A operação altera o estado?

Uma leitura costuma ser de risco menor que uma escrita. Nem sempre — uma leitura pode expor dados sensíveis — mas separar leitura de escrita é um ponto de partida útil.

2. A consequência sai do sistema interno?

Enviar um e‑mail, publicar um post, ativar um anúncio, emitir um documento ou responder a um cliente é visível externamente. Um erro torna‑se imediatamente um problema de relacionamento, custo ou reputação.

3. A operação cria custo ou compromisso?

Um agente pode executar corretamente uma chamada de API e ainda assim tomar a decisão de negócio errada. Orçamento, compras, pagamentos, subscrições ou reservas de recursos exigem uma fronteira separada.

4. A mudança pode ser revertida facilmente?

Alterar um rótulo e eliminar uma conta não pertencem à mesma classe. Considere o custo de recuperação, o tempo de recuperação, a perda de dados e o impacto sobre outros utilizadores.

5. A operação altera segurança ou permissões?

Conceder acesso de administrador, rodar um segredo, tornar um recurso público ou mudar a política de MFA merece controlo mesmo que a ação seja tecnicamente reversível.

Uma matriz prática de autonomia

Nível	Características da ação	Exemplos	Decisão padrão
A — autónomo	apenas leitura, baixo impacto, escopo restrito	estado do serviço, relatório de custos, lista de tarefas	o agente pode executar
B — autónomo com auditoria	escrita reversível em área limitada	adicionar uma etiqueta, guardar um rascunho, criar uma tarefa	o agente pode executar com permissão explícita e registo
C — aprovação antes do efeito	consequência externa, efeito financeiro ou alteração material	enviar uma mensagem, publicar, ativar uma campanha	humano aprova a operação específica
D — controlo forte	destrutivo, sensível à segurança, difícil de reverter	eliminar dados, mudar acesso de administrador, revogar uma chave	escopo separado + aprovação + pré‑visualização; frequentemente verificação adicional

Este é um modelo operacional, não um padrão legal. Cada sistema deve adaptar os níveis aos seus dados, regulamentos, consequências e mecanismos de recuperação.

A aprovação deve estar vinculada a uma consequência específica

Um diálogo de aprovação pobre parece‑se com isto:

O agente quer executar uma ação. Continuar? Sim / Não.

A pessoa não sabe o que está a autorizar.

Uma pré‑visualização melhor parece mais com isto:

Operação: ATIVAR CAMPANHA
Conta: Brillnet Ads / [identificador legível]
Campanha: Search — Pulsar GRC
Orçamento diário médio: PLN 80
Alvo: Polónia
Alteração: PAUSADA → ATIVADA
Estado reversível: a campanha pode ser pausada novamente; o gasto acumulado não é revertido
Consequência: após aprovação a campanha pode começar a gerar gasto
Fonte da decisão: tarefa #...

Só então o botão “Aprovar” tem significado útil. No Google Ads um orçamento diário médio não é um teto rígido de um dia: para a maioria das campanhas, o limite de faturação diário é o dobro desse valor. A pré‑visualização deve explicar essa consequência em vez de prometer um teto de PLN 80.

A aprovação não deve tornar‑se um passe geral para alterações futuras

Suponha que alguém aprove:

enviar esta mensagem a 12 destinatários

Se o agente mudar o conteúdo ou a lista de destinatários para 1 200 pessoas após a aprovação, a aprovação original já não deve mais ser válida.

Uma regra prática é:

A aprovação está vinculada a uma operação normalizada específica. Uma mudança material nos seus parâmetros invalida a aprovação e exige uma nova.

Uma implementação pode associar o ID da aprovação a um hash dos parâmetros da operação, a uma versão do recurso ou a outra representação estável do que foi realmente aprovado.

O modelo não deve decidir sozinho se a aprovação pode ser ignorada

Um modelo pode ser solicitado a estimar risco. Isso pode ser útil como um sinal, mas não deve ser o único controlo.

Se a política for:

quando o modelo considerar uma operação arriscada, ele pede a um humano

então o modelo também controla o mecanismo destinado a conter o impacto dos próprios erros.

Um desenho mais robusto é:

1. O modelo seleciona a ferramenta e os parâmetros.
2. O portal classifica a operação usando política explícita.
3. O motor de políticas determina se a aprovação é necessária.
4. Uma pessoa aprova quando exigido.
5. Só então a execução ocorre.

O modelo pode fornecer a explicação. A classificação final provém da política do sistema.

Exemplo da nossa própria automação: preparar uma campanha não é o mesmo que iniciar gasto

No nosso MCP interno Brillnet Ads, separamos a capacidade de preparar ou modificar uma campanha da capacidade de ativar o gasto.

Uma campanha recém‑criada tem, por defeito, o estado PAUSED quando nenhum outro estado é explicitamente fornecido. Guardar a configuração não equivale a consentir iniciar gasto. Ativar o efeito operacional requer permissão de operação explícita e confirmação no pedido. Um campo de confirmação por si só não prova que uma pessoa revisou a ação. Essa evidência requer o mecanismo de aprovação independente descrito acima.

Esta pequena separação tem um resultado útil:

• o agente pode concluir a maior parte do trabalho de preparação;
• uma pessoa não tem de inserir manualmente cada campo;
• o orçamento não começa apenas porque o modelo decidiu que a configuração estava pronta.

O mesmo padrão aplica‑se a outros fluxos de trabalho:

Preparação	Efeito que requer decisão separada
rascunho de e‑mail	enviar
proposta de papel de utilizador	conceder acesso
plano de migração	executar migração
lista de ficheiros a remover	eliminar
proposta de alteração de preço	publicar o novo preço
pagamento preparado	autorizar pagamento

Quando a aprovação pode ser desnecessária

Nem toda automação precisa ser semiautomática.

A aprovação humana costuma acrescentar pouco valor quando todas estas condições são verdadeiras:

• a operação é apenas de leitura ou de baixo impacto;
• o agente opera dentro de um escopo estreito e pré‑aprovado;
• a saída não é publicada automaticamente;
• um erro é fácil de detectar e reparar;
• não há gasto ou compromisso externo;
• permissões e definições de segurança permanecem inalteradas;
• a ação deixa evidência de auditoria suficiente para reconstruir o resultado.

Exemplo: um agente recupera o estado de campanhas todos os dias e prepara um relatório interno. Exigir aprovação humana a cada leitura não aumenta a segurança na proporção do custo operacional.

Quando recomendamos aprovação como mínimo

Nos nossos projetos, não concederia execução autónoma sem análise separada para operações que:

• enviam comunicações a clientes ou ao público;
• iniciam ou aumentam gasto;
• eliminam ou sobrescrevem dados sem caminho de recuperação simples;
• concedem, expandem ou revogam permissões;
• modificam segredos, configurações de segurança ou MFA;
• aceitam termos legais em nome de uma organização;
• atuam sobre um recurso identificado de forma ambígua;
• desencadeiam outro sistema que pode, por sua vez, executar ações de alto impacto.

Isso não significa que a aprovação humana seja sempre o único controlo. Para ações críticas, deve ser uma das várias camadas.

Atenção à fadiga de aprovação

Se um sistema pede aprovação 80 vezes por dia, os utilizadores deixam de ler os prompts. A aprovação transforma‑se num CAPTCHA para o colaborador.

Isso normalmente indica um dos três problemas de design:

1. a classificação de risco é demasiado ampla;
2. o fluxo de trabalho não agrupa mudanças logicamente relacionadas;
3. o agente tem autonomia segura insuficiente em risco baixo, de modo que tudo é escalado.

A solução não é ocultar avisos. É projetar fronteiras melhores.

O que um mecanismo de aprovação útil deve fazer

Mostrar a diferença, não o objeto completo

Para configurações, mostre antes → depois e apenas os campos que mudam. Não force o revisor a comparar duas telas manualmente.

Declarar a consequência

“Guardar alteração” é mais fraco que “Ativar campanha — pode começar a gerar gasto com um orçamento diário médio de PLN 80”.

Ter um escopo e uma validade

Uma aprovação antiga não deve continuar a autorizar uma operação depois que o contexto mudou.

Recusar uma operação materialmente alterada

Se os parâmetros mudarem após a aprovação, a aprovação deve expirar.

Deixar um registo independente

O registo de auditoria deve indicar quem aprovou o quê, quando e sob qual identificador de operação. Não deve depender apenas de uma mensagem do modelo a dizer “o utilizador concordou”.

Leia: trilhas de auditoria de agentes de IA

Lista de verificação para uma única ação de agente

Antes de conceder autonomia, responda:

• A ação é apenas de leitura?
• Altera o estado do negócio?
• Cria custo ou compromisso?
• O resultado é visível externamente?
• Envolve dados pessoais ou confidenciais?
• Altera papéis, permissões ou configuração de segurança?
• É fácil de reverter?
• O recurso alvo é inequívoco?
• Pode uma tentativa executar a ação duas vezes?
• O sistema pode mostrar uma pré‑visualização concreta antes da execução?
• A aprovação será vinculada aos parâmetros exatos?
• O estado resultante pode ser verificado após a execução?

Se uma ação combina várias características de alto risco, um único “OK” pode ser controle demasiado fraco.

Exemplo trabalhado: uma empresa de serviços envia um relatório ao cliente

Considere um fluxo de trabalho proposto em vez de uma implementação já reportada. Um agente recupera registos aprovados, compara prazos e prepara um relatório. O proprietário da conta continua responsável pelo conteúdo. O responsável pelo processo define os dados permitidos e quem pode autorizar a entrega.

A preparação do rascunho pode correr dentro do limite pré‑aprovado. Antes de enviar, mostre ao cliente, o endereço exato do destinatário, assunto, mensagem e anexos, juntamente com a versão dos dados de origem. O revisor deve poder inspecionar o documento diretamente. Confiar apenas no resumo do modelo enfraquece a revisão.

A aprovação cobre esse pacote específico. Acrescentar um destinatário, substituir um anexo ou mudar uma recomendação material invalida a aprovação. Uma regra previamente definida pode permitir uma correção ortográfica, mas não deve tornar permissão para mudar o sentido. O responsável pelo processo define as mudanças materiais; o componente de execução impõe o limite.

O que o registo de aprovação deve conter

Associe a aprovação à pessoa, função, inquilino, ferramenta, recurso alvo, versão dos dados, parâmetros, validade e identificador da tarefa. Distinga proposto, pendente, aprovado, em execução e resultados incertos. O operador deve saber se um clique prepara uma ação ou a desencadeia.

Um hash de parâmetros ajuda a detectar substituição. Não prova que a pessoa leu a pré‑visualização. Uma interface clara e um revisor autorizado continuam a ser essenciais. Uma pessoa sem permissão para conceder acesso de administrador não deve adquirir essa permissão através de um diálogo de aprovação de agente.

Para lotes, mostre a contagem de objetos, exceções materiais e efeito total. Uma aprovação pode cobrir um lote precisamente definido. Não pode cobrir objetos arbitrários selecionados após a aprovação. Isto reduz diálogos repetidos sem perder controlo de escopo.

Tratar execução incerta antes de tentar novamente

Um fornecedor pode executar um pedido mesmo quando a resposta nunca chega ao agente. Falta de confirmação não é prova de falha. Repetir pode enviar um segundo e‑mail, criar um documento duplicado ou incorrer em custo adicional. Primeiro verifique o identificador do pedido e o estado do fornecedor.

Quando chaves de idempotência são suportadas, associe‑as à operação e reutilize‑as para o mesmo pedido. Caso contrário, implemente deteção de duplicados ou peça ao operador que decida após verificar o estado. Registe um resultado incerto com honestidade. Clicar duas vezes não resolve um resultado desconhecido.

Silêncio não é aprovação

Designe um suplente e um canal de notificação para cada processo. A expiração sem resposta bloqueia a operação controlada. O agente pode continuar a preparar outro trabalho autorizado e de baixo risco; não deve inferir consentimento a partir do silêncio ou de um prazo de negócio.

Defina a interrupção de emergência separadamente. A permissão para parar um fluxo de trabalho incorreto pode ser mais restrita que a permissão para iniciá‑lo. Preserve o estado de execução e a lista de ações concluídas. Restaurar a configuração não pode recuperar uma mensagem ao cliente que já foi lida.

Verificar se a revisão altera decisões

Registe correções, recusas, tempo de espera e tentativas de executar parâmetros materialmente alterados. Compare tipos de operação separadamente. Aprovação lenta de comunicações ao cliente não deve impedir a preparação autónoma de tarefas internas.

Se cada proposta for aprovada imediatamente durante semanas, reveja uma amostra com o responsável pelo processo. A política pode ser demasiado ampla, ou as pré‑visualizações podem omitir informação útil. Um alto número de aprovações não é evidência de segurança.

Amanhã, escolha uma ação externa. Construa a sua pré‑visualização, identifique um revisor autorizado, defina validade e verifique que mudar o destinatário invalida a aprovação. Confirme que a recusa não produz efeito externo.

Recomendações e limites de fonte

A OWASP cobre controlos de ações de alto impacto e integridade de aprovação. Guias de autorização de transações abordam a verificação no lado do servidor de dados de transação significativos. O NIST AI RMF fornece orientação voluntária de gestão de risco. A nossa matriz A–D é uma recomendação de engenharia, não uma obrigação legal de aprovar cada ação de IA. A documentação interna do MCP Ads, datada de 28 de julho de 2026, descreve o design de controlo citado; não prova independentemente a operação em produção para um cliente.

Limite

Este modelo de classificação é a nossa prática de engenharia, não aconselhamento jurídico ou padrão formal de avaliação de risco. Processos regulados, médicos, financeiros ou críticos para a segurança podem exigir controlos mais fortes.

Veja também MCP e agentes de IA: projetando ferramentas mais seguras e Privilégio mínimo para agentes de IA.

Fontes

• OWASP AI Agent Security Cheat Sheet. Acedido: 2026-10-02.
• OWASP Transaction Authorization Cheat Sheet. Acedido: 2026-10-02.
• NIST AI Risk Management Framework. Acedido: 2026-10-02.
• Google Ads Help — About spending limits. Acedido: 2026-10-02.