Human-in-the-loop é uma máquina de estados, não um botão

O agente redigiu um reembolso de $4.200. Apareceu um modal: Aprovar ou Rejeitar. O operador estava em reunião. Vinte minutos depois, o cliente já tinha ligado para o suporte duas vezes. A solicitação de aprovação ficou em uma fila sem timeout, sem escalação, sem auditoria de quem foi notificado e sem um default seguro quando ninguém respondeu. Human-in-the-loop foi implementado como um botão. Produção precisava de uma máquina de estados.

Human-in-the-loop (HITL) existe porque algumas ações de agentes carregam risco que excede os limiares de execução autônoma — transações financeiras, mudanças de dados irreversíveis, comunicações com clientes, operações privilegiadas. O padrão é sólido. A implementação geralmente não é: uma interrupção de UI sem estados definidos, transições, timeouts ou modos de falha. Isso não é governança. É uma pausa que às vezes nunca termina.

Um botão modela um momento; uma máquina de estados modela um processo

Abordagem	O que cobre	O que omite
Botão Aprovar/Rejeitar	Ponto de decisão único	Timeout, escalação, aprovação parcial, rollback
Notificação por email	Alertar um humano	Resposta estruturada, auditoria, idempotência
Mensagem no Slack	Visibilidade rápida	Persistência de estado, revisores concorrentes
Máquina de estados	Ciclo de vida completo	Exige design prévio

Uma máquina de estados HITL trata cada ação com compuerta como uma instância de workflow com estados e transições explícitos:

pending_review
    ├─(approve)→ approved → executing → completed
    ├─(reject)→ rejected → cancelled
    ├─(timeout)→ escalated → pending_review (new assignee)
    ├─(timeout, no escalation target)→ auto_rejected | auto_approved (policy)
    └─(execute fails)→ failed → rollback_pending → rolled_back | manual_intervention

Cada transição registra: ator (humano ou sistema), timestamp, razão, estado anterior, hash do payload. Auditoria não é uma feature separada — é a tabela de transições.

Uma fila de aprovação sem expiração é um ataque de negação de serviço que o produto construiu contra si mesmo.

Estados que todo workflow HITL precisa

pending_review. Ação proposta, execução bloqueada. Inclui: payload proposto, score de risco, contexto do solicitante, pool de revisores atribuído, expires_at, nível de escalação.

approved / rejected. Decisões humanas terminais. Rejeição deve capturar código de razão — não apenas texto livre — para melhoria de modelo e política.

escalated. Timeout ou sobrecarga provocaram reatribuição. Registra quem foi ignorado e por quê. Rotas de escalação devem ser finitas — escalação infinita é outra forma de ficar preso.

executing. Aprovação humana; efeitos colaterais em andamento. Evita execução dupla se o revisor clicar duas vezes ou retentativas de rede dispararem aprovações duplicadas.

completed / failed / rolled_back. Verdade pós-execução. Execução falha com efeitos colaterais parciais precisa de estado de rollback — não "tentar de novo" sem reconciliação.

auto_resolved. Default orientado por política quando humanos não respondem. Deve ser explícito e raro: auto-rejeitar ações de alto risco, auto-aprovar baixo risco dentro de limites. Auto-approve silencioso em ações de alto risco é como incidentes viram manchetes.

Timeouts e escalação não são polimento opcional

Sem expires_at, revisões pendentes se acumulam. Workflows de agentes bloqueiam. Clientes esperam. Operadores voltam a um backlog de decisões obsoletas com contexto desatualizado.

Projetar timeouts por nível de risco:

Nível de risco	Ação de exemplo	Timeout de revisão	Escalação	Default ao esgotar
Baixo	Rascunho de email, nota interna	4 horas	Canal do time	Auto-aprovar ou auto-cancelar
Médio	Reembolso abaixo do limiar	30 minutos	Rotação on-call	Auto-rejeitar
Alto	Exclusão em massa, transferência bancária	15 minutos	Aprovador nomeado + backup	Auto-rejeitar, alerta
Crítico	Mudança de config em produção	5 minutos	Pager	Auto-rejeitar, bloquear ação

Escalação deve mudar responsável e notificar — não apenas reenviar a mesma notificação para alguém que já está ignorando. Após N níveis de escalação, atingir um estado terminal definido. "Ainda pendente" não é um estado terminal.

O padrão de runbooks para agentes IA em produção cobre resposta operacional quando agentes falham — HITL é a camada de prevenção para ações que não deveriam falhar de forma autônoma em primeiro lugar.

Idempotência e concorrência evitam execução dupla

Dois operadores abrem a mesma aprovação. Ambos clicam em Aprovar. Sem idempotência, o reembolso roda duas vezes.

Requisitos:

• Token de aprovação ligado a um único ID de instância de workflow.
• A transição de pending_review para approved é atômica — o primeiro vence, o segundo recebe "já resolvido."
• Passo de execução idempotente contra sistemas externos — API de pagamento com chave de idempotência, upsert em banco com chave de deduplicação.
• Bloqueio otimista no campo de versão de estado.

Revisão concorrente sem bloqueio é condição de corrida disfarçada de colaboração.

Rollback e calibração de confiança pertencem ao mesmo design

Aprovação humana não garante execução correta. Ações aprovadas podem falhar no meio do caminho. Falhas parciais precisam de transições de rollback e notificação humana — não loops de retentativa silenciosos.

Calibração de confiança em UI de IA aborda quanta autonomia usuários concedem a agentes na interface. Máquinas de estados HITL implementam essa calibração no workflow de backend: quais ações exigem estados humanos, quais seguem de forma autônoma e o que acontece nos limites. Ajustes de confiança no frontend e máquinas de estados no backend devem coincidir — uma UI que mostra "auto" enquanto o backend enfileira cada ação cria confusão em ambas as direções.

Como equipes devem implementar human-in-the-loop?

Essas escolhas de design separam governança em produção de interrupções de demo.

Human-in-the-loop é o mesmo que workflows de aprovação?

Workflows de aprovação são uma instância de HITL. HITL também inclui: edição humana antes de enviar, seleção humana entre propostas do agente, override humano da classificação do agente. Cada variante precisa de estados — nem toda variante exige binário Aprovar/Rejeitar.

O que deve acontecer quando ninguém responde?

Nunca deixar ações em pending_review indefinidamente. Política explícita: auto-rejeitar por padrão para ações irreversíveis ou de alto valor; auto-aprovar apenas para ações de baixo risco abaixo de limiares definidos com auditoria completa. Documentar a política onde operadores possam vê-la antes de perder um timeout.

Como HITL interage com orçamentos de contexto do agente?

Revisões pendentes retêm estado do agente — resultados de ferramentas, ações propostas, contexto de conversa. Períodos pendentes longos incham orçamentos de janela de contexto quando o agente retoma. Preferir resumir estado pendente ao retomar em vez de reproduzir o transcript completo pré-aprovação.

Um argumento comum vai na direção oposta

A visão oposta sustenta que HITL anula o propósito dos agentes — que sistemas autônomos deveriam ser confiados ou não implantados, e que compuertas de aprovação criam gargalos piores que o risco que previnem.

Gargalos vêm de botões sem máquinas de estados, não de HITL em si. HITL bem desenhado auto-resolve caminhos de baixo risco instantaneamente, roteia risco médio para revisão assíncrona e bloqueia apenas ações genuinamente de alto risco. Isso é mais rápido que recuperar de erros autônomos em produção.

Autonomia plena sem HITL é válida para domínios somente leitura ou facilmente reversíveis. A máquina de estados ainda existe — só não tem transições pending_review.

Key takeaways

• Human-in-the-loop é uma máquina de estados: pending, approved, rejected, escalated, executing, completed, failed, rolled back.
• Botões Aprovar/Rejeitar sem timeouts criam bloqueios indefinidos e decisões obsoletas.
• Rotas de escalação devem ser finitas com defaults terminais explícitos.
• Transições idempotentes evitam execução dupla por aprovadores concorrentes.
• Auditar cada transição de estado — ator, timestamp, razão, hash do payload.
• Alinhar estados HITL de backend com ajustes de calibração de confiança no frontend.

Conclusion

Teatro de segurança coloca um humano na captura de tela. HITL em produção coloca humanos em um workflow com finais definidos — o que acontece quando aprovam, rejeitam, ignoram ou se desconectam. A máquina de estados é a diferença entre governança e um modal que nunca fecha.

A auditoria para produtos de agentes existentes: listar cada ação que espera input humano. Para cada uma, documentar estado atual, timeout, escalação e default quando ninguém responde. Células vazias são o roadmap de implementação.