🤔 Por que e quando colocar humano no processo
Human-in-the-loop não é uma admissão de que o agente não funciona — é design inteligente. Sistemas agentic bem projetados usam HITL estrategicamente: nos pontos onde o custo de um erro é maior do que o custo de um humano revisar.
🎯 Quando HITL é obrigatório
Delete de dados, transferência financeira, envio de email em massa, rescisão de contrato. Se não pode desfazer, humano aprova.
O agente retorna confidence score abaixo do threshold definido para aquele tipo de decisão. Incerteza é motivo de escalada.
Defina limites claros: agente pode aprovar pagamentos até R$500, acima disso requer aprovação humana.
Qualquer ação que envolva dados RESTRICTED (saúde, financeiro, legal) precisa de revisão humana antes de execução.
HITL como estratégia de longo prazo
Cada decisão que humano aprova é um dado de treinamento. Com o tempo:
- ✓Taxa de aprovação sem revisão sobe (agente melhora)
- ✓Threshold de confiança pode subir gradualmente
- ✓Limites financeiros de autonomia podem expandir
- ✓HITL overhead diminui conforme agente amadurece
Quando NÃO usar HITL
- ✗Ações reversíveis de baixo impacto (análise, rascunho)
- ✗Processos de alta frequência onde latência importa
- ✗Tarefas onde agente tem histórico de 99%+ de acurácia
- ✗Notificações informativas (sem ação consequente)
💡 HITL como diferencial de confiança
Paradoxalmente, agentes com HITL bem projetado têm mais adoção interna do que agentes totalmente autônomos. Stakeholders confiam mais quando sabem que existe revisão humana nos pontos críticos. Use HITL não só como defesa técnica, mas como argumento comercial para adoção.
🚦 Tipos de checkpoint: approval, review e notification
Usar o mesmo tipo de checkpoint para todas as situações é ineficiente. Calibrar o tipo correto de checkpoint para cada ponto do fluxo define se o HITL adiciona valor ou apenas burocracia.
Approval Gate — bloqueante
O agente para completamente e aguarda aprovação humana. Sem aprovação, não executa a ação seguinte. Timeout sem resposta: escalada automática.
Usar quando: ação irreversível, impacto financeiro alto, acesso a dados restritos, decisão legal ou regulatória
Review Gate — com opção de revisão
Humano pode aprovar (agente continua), solicitar revisão (agente refaz com novo contexto) ou rejeitar (agente aborta). Permite iteração sem bloquear totalmente.
Usar quando: qualidade importa mas processo pode iterar, output tem ambiguidade que humano pode clarear
Notification Only — informativo
Agente executa e informa o humano do que foi feito. Sem bloqueio. Humano pode reverter se necessário, mas fluxo não para.
Usar quando: ação reversível de baixo impacto, informação que stakeholder precisa ter mas não precisa aprovar
🗺️ Mapeando checkpoints no fluxo do agente
Para cada etapa do agente, defina explicitamente: qual tipo de checkpoint? Qual o trigger? Quem recebe? Qual o timeout? Qual a escalada?
checkpoint_config = {
"send_proposal_email": {
"type": "approval_gate",
"approver": "sales_manager",
"timeout_hours": 4,
"escalation": "vp_sales",
"context_required": ["proposal_pdf", "client_history", "deal_value"]
},
"generate_draft": {
"type": "review_gate",
"reviewer": "account_executive",
"timeout_hours": 24,
"escalation": "auto_approve"
},
"log_crm_activity": {
"type": "notification_only",
"notify": "account_executive",
"channel": "slack"
}
}
🖥️ UX de aprovação: contexto claro, não dump de JSON
Se o processo de aprovação é difícil ou confuso, humanos aprovam sem ler — eliminando completamente o valor do HITL. A UX de aprovação define se o checkpoint é uma defesa real ou apenas teatro de segurança.
📋 Anatomia de uma boa notificação de aprovação
Agente SDR · Lead: TechCorp LTDA
O que o agente quer fazer:
Enviar proposta comercial personalizada para João Silva (CTO) da TechCorp LTDA com valor de R$85.000/ano.
Qualificação
Score: 87/100
Tamanho
240 funcionários
Interação
3 emails, 1 call
UX de aprovação efetivo
- ✓Resumo executivo em 3-5 linhas do que o agente quer fazer
- ✓Dados relevantes pré-calculados (não raw data)
- ✓Timer visível com deadline para aprovação
- ✓One-click approve para mobile (a maioria aprova no celular)
- ✓Campo para comentário opcional ao aprovar/rejeitar
UX que causa aprovação sem leitura
- ✗Dump de JSON do estado interno do agente
- ✗Notificações muito frequentes (fadiga de aprovação)
- ✗Processo de aprovação com muitos cliques
- ✗Contexto insuficiente para tomar decisão informada
- ✗Sem indicação de urgência ou consequência de não responder
💡 Regra dos 30 segundos
O humano deve ser capaz de entender o que o agente quer fazer e tomar uma decisão informada em menos de 30 segundos. Se seu processo de aprovação demora mais, a UX está errada. Teste com cronômetro: simule aprovação e meça o tempo até decisão informada.
⏸️ Aprovação assíncrona: pause, notify, resume
Aprovação síncrona (agente fica em loop esperando) desperdiça recursos e cria timeouts. O padrão correto é pause-notify-resume: agente persiste estado, envia notificação e retoma do ponto exato quando aprovado.
🔄 Fluxo de aprovação assíncrona
Persistir estado completo
Agente serializa estado atual (contexto, tools já executadas, próxima ação pendente) e persiste em banco de dados. Pode ser reiniciado sem perder progresso.
Enviar notificação com token de aprovação
Envia Slack/email com link de aprovação único (JWT token assinado). O link contém o approval_request_id que identifica qual decisão está sendo tomada.
Humano aprova via link
Humano clica no link, vê contexto formatado, toma decisão (approve/reject/request_revision). Ação registrada com identidade, timestamp e reasoning.
Webhook retoma o agente
Sistema envia webhook para o agente com a decisão. Agente carrega estado persistido, aplica a decisão e continua execução do ponto exato onde parou.
Timeout: escalada automática
Se não há resposta em N horas: renotifica, escalada para supervisor. Se ainda sem resposta: auto-aprovação (para ações de baixo risco) ou auto-rejeição com alerta.
🏗️ Implementação: schema de estado persistido
{
"execution_id": "exec_7f3a2b",
"agent_id": "financial-agent-prod",
"checkpoint_at": "send_payment",
"state_snapshot": {
"conversation_history": [...],
"tools_executed": ["fetch_invoice", "validate_supplier"],
"next_action": {
"tool": "create_payment",
"params": {"amount": 3500.00, "recipient": "vendor-456"}
}
},
"approval_request": {
"id": "apr_8g4b3c",
"created_at": "2026-03-03T14:00:00Z",
"expires_at": "2026-03-03T18:00:00Z",
"approver": "finance_manager_id",
"token": "eyJhbGc..."
}
}
📋 Audit de decisões humanas: quem aprovou o quê
Registrar decisões humanas no contexto de HITL não é apenas compliance — é o dataset que treinará o sistema a precisar cada vez menos de aprovação. Cada aprovação é um exemplo de "o que o agente propôs estava correto". Cada rejeição é um exemplo de "aqui o agente errou".
📊 Schema do audit trail de decisões humanas
Campos obrigatórios:
- •approval_id: ID único da decisão
- •approver_id: quem aprovou (verificado por SSO)
- •decision: approve/reject/request_revision
- •timestamp: com timezone UTC
- •context_snapshot: o que o agente propôs
Campos para melhoria contínua:
- •reasoning: por que aprovou/rejeitou
- •time_to_decide: quanto tempo levou
- •modifications: o que foi alterado (se revision)
- •confidence_reported: o humano estava seguro?
- •outcome: resultado posterior da decisão
📊 Usando o audit para melhorar o agente
- •Alta taxa de rejeição em determinado tipo de ação = agente está errando sistematicamente neste caso
- •Tempo de aprovação alto = contexto insuficiente ou UX ruim para este tipo de decisão
- •Reasoning de rejeição recorrente = padrão que pode virar nova regra para o agente
- •Taxa de aprovação subindo = agente pode ter autonomia expandida nessa categoria
⚠️ Audit trail imutável é requisito de compliance
Para conformidade com SOX, BACEN e regulamentos similares, o audit trail deve ser imutável — não pode ser modificado ou deletado retroativamente. Use append-only storage: AWS CloudTrail, Kafka com retenção configurada, ou banco de dados com triggers que bloqueiam UPDATE/DELETE.
📊 Métricas de HITL: medir para melhorar
Métricas de HITL são o sinal de maturidade do sistema agentic. Taxa de aprovação crescendo significa agente aprendendo. Tempo de aprovação alto significa UX ruim. Escalada frequente significa threshold de confiança muito baixo.
Approval Rate
Checkpoints aprovados sem pedido de revisão
Meta: crescer mensalmente. Indica que agente está acertando mais.
Time-to-Approve
Tempo médio de aprovação humana
Meta: abaixo do SLA definido. Alto indica UX ruim ou contexto insuficiente.
Escalation Rate
Checkpoints escalados por timeout
Meta: abaixo de 5%. Alto indica problemas no processo de notificação.
📈 KPIs de maturidade do HITL
💡 HITL como trajetória para autonomia
O objetivo de longo prazo não é ter mais HITL — é ter HITL apenas onde realmente importa. Meça a aprovação rate por categoria de ação. Quando uma categoria atinge 95%+ de aprovação por 3 meses consecutivos, considere remover o checkpoint e mover para notification-only. HITL bem gerenciado se torna cada vez menos necessário.
✅ Resumo do Módulo 6.4
Próximo Módulo:
6.5 — Produto SaaS Agentic: arquitetura multi-tenant, billing por uso, rate limiting, painel admin e pricing strategy.