Política de Aprovação para Agentes de IA: Template Prático

Política de Aprovação para Agentes de IA: Template Prático

Uma política de aprovação para agentes de IA define quais ações são negadas, quais podem rodar de forma autônoma e quais devem parar para uma pessoa responsável revisar o efeito exato antes da execução. Uma política útil também define quem pode aprovar, qual evidência essa pessoa recebe, quando a decisão expira, o que acontece na rejeição ou ausência de resposta e qual registro prova que a regra foi aplicada.

“Exigir aprovação humana em ações de risco” é um princípio, não uma política operacional. Ele deixa runtime, revisor e time de incidente adivinharem o significado de “risco”, “aprovação” e “humano” no momento da ação.

Este template transforma o princípio em contrato aplicável. Ele não é certificação de segurança nem substitui revisão jurídica, de privacidade ou específica do setor.

O contrato de aprovação em uma tabela

Aprovação é apenas um controle. O agente ainda precisa de credenciais delimitadas, restrição de ferramentas, validação, logs, falha segura e responsável operacional.

1. Inventarie ações, não apenas ferramentas

O nome de uma ferramenta é amplo demais para uma política. Uma ferramenta de CRM pode consultar o nome de uma empresa, mudar uma etapa da oportunidade, exportar todos os contatos ou apagar um registro. Esses efeitos precisam de regras diferentes.

Inventarie cada ação com:

• agente e fluxo;
• ferramenta e operação;
• recurso e classe de dado;
• leitura, rascunho, escrita, envio, exclusão ou mudança de permissão;
• efeito interno ou externo;
• efeito reversível ou difícil de reverter;
• valor, volume e frequência máximos;
• impacto no cliente, financeiro, jurídico, de segurança ou de produção;
• credencial usada na execução;
• ações posteriores disparadas pela mudança;
• responsável e responsável de fallback.

Comece por negar quando uma ação não tem responsável nem necessidade de negócio definida. Um modelo não deve criar a própria autoridade porque encontrou uma ferramenta tecnicamente disponível.

O AI RMF do NIST pede papéis claros, responsabilidades, processos de supervisão humana e escopo de aplicação documentado. O inventário de ações torna essas decisões concretas.

2. Atribua um nível de decisão

A matriz abaixo é um ponto de partida de implementação. Adapte ao negócio e às obrigações aplicáveis.

A política também pode negar uma classe inteira mesmo com aprovação. Algumas ações devem ficar fora do caminho do agente porque nenhuma revisão prática torna a exposição aceitável.

Não envie toda ação para uma pessoa. O Agentic AI Lens atual da AWS alerta que revisão indiscriminada cria fadiga e aprovação automática por hábito. A atenção humana deve ficar nas decisões onde julgamento pode mudar o resultado.

3. Classifique o risco fora do agente

Use propriedades determinísticas que a aplicação consegue verificar:

• tipo da ação e alvo;
• permissão exigida;
• reversibilidade;
• sensibilidade do dado;
• visibilidade externa;
• valor financeiro;
• número de registros ou pessoas afetadas;
• impacto em produção ou cliente;
• novidade em relação ao fluxo aprovado;
• origem e nível de confiança da entrada;
• anomalia, taxa ou padrão de repetição recente.

O agente pode sugerir uma classificação, mas não deve ser o único componente a decidir se a própria ação exige aprovação. Um motor de política, wrapper de ferramenta ou regra de workflow deve aplicar o nível antes do efeito.

A AWS alerta explicitamente contra depender de um classificador de risco exposto ao mesmo conteúdo não confiável do pedido. A OWASP também recomenda privilégio mínimo e confirmação humana para ações irreversíveis ou de alto impacto, principalmente quando uma entrada não confiável pode influenciar o agente.

4. Mostre a ação exata, não uma história

O aprovador precisa de um artefato revisável. O pedido de aprovação deve incluir:

ID do pedido:
Versão da política:
Agente e fluxo:
Usuário ou sistema solicitante:
Ferramenta e operação:
Identidade da credencial:
Recurso alvo:
Estado atual:
Argumentos exatos ou diff proposto:
Efeito externo esperado:
Efeitos posteriores:
Evidências e links das fontes:
Regra de política aplicada:
Nível de risco e motivo:
Reversibilidade:
Rollback ou compensação:
Chave de idempotência:
Prazo da decisão:
Papel do aprovador:

O estado atual e o payload exato importam mais que a explicação do agente. Se o payload contém um email, mostre destinatário, assunto, corpo e anexos. Se muda um registro, mostre os campos antes e depois. Se executa um comando, mostre executável resolvido e argumentos.

Não exponha raciocínio oculto nem dados pessoais desnecessários. Entregue ao revisor os fatos necessários, com os controles de acesso adequados ao registro original.

O Agents SDK da OpenAI pausa antes de uma chamada de ferramenta que exige aprovação e apresenta nome e argumentos por uma interrupção. A implementação continua responsável pela interface, identidade do revisor, política e registro operacional.

5. Vincule a aprovação a uma proposta imutável

Uma aprovação deve autorizar um efeito específico, não uma família futura de ações.

Vincule a decisão a:

• ID do pedido;
• ação e argumentos;
• alvo e versão do estado atual;
• versão da política;
• identidade do agente e da credencial;
• identidade do aprovador;
• data e expiração;
• valor, volume ou escopo máximo;
• chave de idempotência quando a ação pode repetir.

Invalide a aprovação quando um campo material mudar. Novo destinatário, novo valor, novo anexo, novo argumento de comando, estado diferente do alvo ou outra versão de política exigem nova decisão.

Evite escolhas amplas de “sempre aprovar” para ferramentas externas ou de alto impacto. Recursos de plataforma que persistem uma decisão durante uma execução são conveniências técnicas, não motivo para transformar revisão estreita em autoridade permanente.

6. Defina quem pode aprovar

Nomeie papéis, não um “humano” indefinido.

O aprovador precisa de autoridade e contexto. Senioridade sozinha não qualifica alguém para revisar migração de banco, promessa a cliente ou ação financeira.

Nas operações de maior impacto, o negócio pode exigir revisores independentes. A AWS descreve revisões independentes como defesa contra erro e engenharia social. O limite correto é decisão do negócio, não número universal.

7. Faça expiração e rejeição falharem de forma segura

Todo pedido precisa de um caminho terminal:

• Aprovado: executar a ação vinculada antes da expiração.
• Rejeitado: registrar a decisão e parar a ação.
• Expirado: não executar, depois cancelar ou criar pedido novo.
• Cancelado: fechar porque o fluxo ou estado mudou.
• Escalado: enviar o mesmo artefato revisável para backup autorizado.

Silêncio não é aprovação. Se o revisor está indisponível, o fallback deve negar, aguardar ou transferir para um responsável definido, conforme o fluxo.

Quando houver rejeição, o agente não pode tentar o mesmo efeito com outra redação. O revisor pode informar o motivo ou uma alternativa permitida. Trabalho materialmente diferente vira novo pedido com novo ID.

O OpenClaw oferece askFallback e documenta deny como fallback seguro quando a rota de aprovação está indisponível. Suas aprovações de execução também continuam separadas de autorização por usuário e isolamento do host.

8. Execute com segurança depois da aprovação

A aprovação não garante que a execução continua segura ou adequada. Imediatamente antes da ação:

1. autentique a identidade de execução;
2. confirme que a aprovação é válida e ainda não foi usada;
3. verifique novamente política e estado atual;
4. valide argumentos e limites exatos;
5. adquira proteção de idempotência ou limite transacional;
6. execute com a credencial estreita;
7. capture o recibo do provedor ou sistema;
8. verifique o estado posterior esperado;
9. alerte o responsável se o resultado for parcial ou diferente;
10. consuma a aprovação para impedir replay.

Se a ação falhar pela metade, não reporte sucesso. Rode o caminho definido de rollback ou compensação e preserve o resultado parcial para o incidente.

9. Preserve uma cadeia de evidência

O registro deve conectar:

entrada → proposta → decisão da política → decisão humana → execução → resultado verificado

Preserve:

• referência da entrada e links das fontes confiáveis;
• versões do agente, modelo, instrução e ferramenta;
• regra aplicada e sinais de risco;
• artefato de aprovação e identidade do revisor;
• decisão de aprovar, rejeitar, expirar ou cancelar;
• payload exato executado;
• recibo externo ou diff do sistema;
• validação posterior;
• referência de rollback ou incidente;
• política de retenção e acesso.

Os logs devem registrar o que aconteceu, não apenas o que o agente disse que faria. Revise taxa de aprovação, motivos de rejeição, tempo de fila, expiração, substituições, pedidos repetidos e incidentes por classe de ação.

Template copiável de política

policy:
  id: customer-operations-agent
  version: 1
  owner: operations
  default: deny

actions:
  - id: crm.read_assigned_account
    tier: observe
    limits:
      records: 1
      assignment_required: true

  - id: crm.update_next_step
    tier: bounded_autonomous
    limits:
      fields: [next_step, follow_up_at]
      records_per_run: 1
      reversible: true
    evidence:
      - source_record
      - validation_result
      - execution_receipt

  - id: email.send_customer
    tier: single_approval
    approver_roles: [account_owner, sales_lead]
    bind_to:
      - recipient
      - subject
      - body
      - attachments
      - policy_version
    expires_in_minutes: 30
    on_reject: stop
    on_timeout: deny
    retry_requires_new_request: true

  - id: access.expand_permissions
    tier: independent_review
    approver_roles: [system_owner, security_owner]
    reviewers_required: 2
    prior_approval_inheritance: false

evidence:
  record:
    - request_id
    - agent_id
    - workflow_id
    - tool_and_arguments
    - matched_rule
    - reviewer_identity
    - decision_and_timestamp
    - execution_receipt
    - verified_outcome

Este é um formato de política, não uma configuração pronta para toda plataforma. Traduza para o motor de política, wrappers de ferramentas, sistema de identidade e armazenamento do workflow.

Teste a política antes de conceder autoridade real

No mínimo, teste:

Adicione falhas reais ao conjunto de avaliação. A qualidade da aprovação faz parte do piloto, então conecte a política ao scorecard de medição do piloto de automação com IA e ao checklist de prontidão para agentes em produção.

Perguntas frequentes

Quais ações de um agente de IA precisam de aprovação humana?

Ações costumam merecer aprovação quando criam efeito externo, mudam dado sensível, movem dinheiro, afetam produção, apagam informação, ampliam autoridade ou são difíceis de reverter. A regra exata deve refletir impacto, escopo, credenciais e decisões de risco do negócio.

Toda ação do agente deve exigir aprovação?

Não. Aprovação em tudo pode criar filas e decisões automáticas por hábito. Negue ações não suportadas, permita leitura estreita ou trabalho reversível sob limites determinísticos e reserve atenção humana para risco relevante.

Aprovação humana é igual a autorização?

Não. Autorização define o que a identidade de execução pode acessar ou alterar. Aprovação registra uma decisão sobre uma ação proposta. A credencial ainda deve ter apenas as permissões mínimas necessárias.

O que um pedido de aprovação deve mostrar?

Mostre alvo e argumentos exatos ou diff, estado atual, efeito esperado, fontes, regra aplicada, reversibilidade, recuperação, expiração e papel do revisor. Um resumo genérico em linguagem natural não basta para uma decisão de alto impacto.

O que acontece quando uma aprovação é rejeitada?

A ação para e a decisão fica registrada. O agente não deve repetir silenciosamente o mesmo efeito. Uma proposta materialmente diferente exige novo pedido e nova decisão.

Uma aprovação continua válida depois que o payload muda?

Não diante de mudança material. Vincule a decisão à proposta exata e invalide quando destinatário, valor, alvo, anexo, comando, estado atual ou versão da política mudar.

Referências primárias

• Core do AI Risk Management Framework do NIST
• Guia prático da OpenAI para construir agentes
• Guia human-in-the-loop do Agents SDK da OpenAI
• Agentic AI Lens da AWS sobre revisão humana em decisões críticas
• Cheat Sheet de segurança para agentes de IA da OWASP
• Aprovações de execução do OpenClaw

---

Uma política de aprovação é útil quando o runtime consegue aplicá-la e a operação consegue prová-la. Mapeie política, ferramentas e controle humano para um sistema de IA empresarial antes de conceder autoridade real.