A automação fica arriscada quando consegue produzir efeitos irreversíveis mais rápido do que uma pessoa consegue entendê-los. Um botão de aprovar não basta: o fluxo precisa mostrar uma proposta clara, encaminhá-la à pessoa certa, manter estado pendente durável, expirar, evitar replay e registrar o que ocorreu depois da decisão.
Persista ID único da proposta, identidade do agente, recurso-alvo, operação, nível de risco, evidências, versão da política, criação e prazo. A decisão deve referenciar essa proposta imutável. Se as entradas mudarem, invalide a aprovação e peça nova análise em vez de reutilizar consentimento para uma ação diferente.
| Classe da ação | Política possível | Exemplo de controle |
|---|---|---|
| Reversível e baixo impacto | Automática dentro de limites estreitos | Atualizar rascunho interno ou repetir sincronização de leitura |
| Efeito relevante ao cliente | Um revisor autorizado | Enviar aviso ou alterar configuração de conta |
| Alto impacto ou financeiro | Revisão forte, talvez duas pessoas | Estorno elevado, dados de pagamento ou bloqueio em lote |
| Proibida ou insegura | Negação obrigatória, sem override | Contornar identidade ou extrair dados restritos |
O risco depende de escopo, reversibilidade, valor, pessoas afetadas e qualidade da evidência, não simplesmente de a solicitação ter sido produzida por IA. Aprovação humana não substitui autorização, validação de entrada nem privilégio mínimo. O serviço executor precisa verificar novamente permissão e política após a aprovação.
Mostre mudança exata, objetos afetados, consequência esperada, evidência de origem, incerteza, justificativa de política e uma prévia segura. Diferencie explicação gerada pelo modelo de fatos verificados pelo sistema. Não pré-selecione aprovação nem esconda rejeição. Se faltarem dados ou confiança, ofereça adiar ou solicitar mais informações.
Autentique o revisor de forma independente, autorize aquela ação e tenant e vincule o token a uma única proposta. Use validade curta e consumo único; proteja links de callback contra encaminhamento e exposição em logs. Aplique separação de funções para que quem propôs não aprove ações de alto risco. Registre decisor, horário, versão apresentada e alteração efetivamente executada.
Trabalho pendente exige workflow durável, não processo esperando em memória. Ao expirar, escolha estado seguro como rejeitado ou pendente de atenção. Endpoint idempotente impede que callback duplicado execute duas vezes. Use transição compare-and-swap para impedir dois revisores de consumir a mesma proposta. Se a execução falhar após aprovação, mantenha a decisão e mostre falha: aprovar não significa concluir.
Acompanhe tempo de decisão, aprovações e rejeições por risco, expirações, overrides, falhas posteriores e carga de revisão. Aprovação sempre rápida e sem rejeições pode indicar validação automática informal. Audite amostras e teste que propostas não aprovadas, vencidas ou de outro tenant não possam executar.
Veja também identidade e autorização de agentes e limites de memória de agentes.
Uma etapa confiável é uma transição durável, proporcional ao risco e auditável. Mostre exatamente o que ocorrerá, revalide autoridade durante a execução, expire consentimento antigo e torne decisões duplicadas inofensivas. Julgamento humano só ajuda quando há controle e evidência suficiente.