Objetivo da Aula
Ao concluir esta aula, você será capaz de:
Identificar quando automação de decisões cria riscos para pessoas reais
Aplicar LGPD Art. 20 em sistemas que tomam decisões automatizadas
Projetar Human-in-the-Loop (HITL) que funciona em produção (não apenas no papel)
Reconhecer as formas de HITL que são teatro de governança
Dimensionar o custo de revisão humana vs o risco de erro automatizado
Por que isso importa
Decisão de Arquitetura: HITL Efetivo e Pipeline PII
HITL efetivo tem critérios mensuráveis: (1) Tempo real de revisão: se o revisor tem 2 segundos por caso, ele está assinando sem revisar — defina tempo mínimo por decisão; (2) Evidência apresentada: o revisor deve ver o input, a saída, e a justificativa do modelo — não só um botão aprovar/rejeitar; (3) Taxa de discordância monitorada: 0% de rejeição ao longo do tempo indica que o HITL virou teatro — alerte se cair abaixo de um mínimo esperado; (4) Capacidade dimensionada: X% dos casos revisados × tempo por caso × volume diário = número de revisores necessários. Para PII antes de enviar ao LLM: avalie o detector por precision (falso positivo = dado inutilizável) e recall (falso negativo = PII vaza). Pseudoanonimização (substituir por token reversível) é diferente de anonimização (irreversível) — LGPD trata as duas de forma distinta.
HITL falso é pior que ausência de HITL — cria a falsa sensação de supervisão sem fornecer proteção real. Um revisor humano que verifica 500 decisões por hora não está realmente revisando: está apenas assinando. Projetar HITL efetivo é uma habilidade rara e valiosa.
Conceitos Fundamentais
Quando Automação Cria Risco Real
Alto risco (sempre precisa de HITL):
- Decisões irreversíveis: demissão automatizada, bloqueio de conta
- Decisões que afetam direitos: negação de benefícios, crédito
- Decisões sobre saúde: triagem médica, dosagem de medicamento
- Decisões sobre liberdade: análise de liberdade condicional
Médio risco (HITL em casos limítrofes):
- Priorização de atendimento (ex: chamados de suporte)
- Recomendação de conteúdo com alto engajamento
- Aprovação de transações financeiras acima de threshold
Baixo risco (automação total OK):
- Classificação de spam
- Sugestão de completamento de texto
- Recomendação de produto com valor < R$50LGPD Art. 20 na Prática
# Interface obrigatória para sistemas de alto risco:
def registrar_decisao_automatizada(
usuario_id: str,
decisao: str,
fatores: list[str],
modelo_versao: str,
) -> str:
"""Retorna ID para contestação futura."""
decisao_id = gerar_uuid()
audit_log({
"decisao_id": decisao_id,
"usuario_hash": hash_anonimo(usuario_id), # não armazenar ID puro
"decisao": decisao,
"fatores_principais": fatores[:3], # limitado
"modelo": modelo_versao,
"timestamp": iso_now(),
"canal_contestacao": "https://empresa.com.br/revisao",
})
return decisao_id
# Endpoint de contestação (obrigatório por LGPD):
# POST /revisao/{decisao_id}
# → coloca na fila de revisão humanaHITL Efetivo vs Teatro
TEATRO DE HITL (evitar):
- Revisor tem 2 segundos por caso: não consegue ler, quanto mais revisar
- Interface mostra apenas a decisão do modelo, não os dados brutos
- Revisor nunca discorda do modelo (100% de concordância = não está revisando)
- Sem incentivo para discordância: "por que me complicar?"
HITL EFETIVO:
- Revisor tem tempo para revisar dados originais, não apenas a decisão
- Interface mostra evidência contraditória ou ambígua em destaque
- Existe processo de feedback para casos discordados
- Taxa de discordância é monitorada (>0% é sinal de saúde do processo)
- Amostragem aleatória além dos casos limítrofesAprofundamento Técnico
Dimensionando HITL
def calcular_capacidade_hitl(
decisoes_por_dia: int,
pct_para_revisao: float, # ex: 0.05 = 5% dos casos
tempo_revisao_minutos: float,
horas_revisores: float, # horas disponíveis por dia
) -> dict:
casos_revisao = decisoes_por_dia * pct_para_revisao
minutos_necessarios = casos_revisao * tempo_revisao_minutos
revisores_necessarios = minutos_necessarios / (horas_revisores * 60)
return {
"casos_para_revisao": int(casos_revisao),
"revisores_necessarios": round(revisores_necessarios, 1),
"viavel": revisores_necessarios < 5, # threshold de viabilidade
}
# Exemplo:
resultado = calcular_capacidade_hitl(
decisoes_por_dia=10000,
pct_para_revisao=0.05, # 5% = casos limítrofes
tempo_revisao_minutos=5,
horas_revisores=8,
)
# → casos: 500/dia, revisores: 10.4
# Se 10 revisores não são viáveis: reduzir pct_para_revisao ou automatizar mais (aceitando mais risco)Seleção de Casos para Revisão
def selecionar_casos_revisao(decisoes: list[dict], n: int = 100) -> list[dict]:
# Estratégia: casos limítrofes + amostra aleatória
# 1. Casos limítrofes (score próximo do threshold)
THRESHOLD = 0.6
MARGEM = 0.1
limítrofes = [d for d in decisoes if abs(d["score"] - THRESHOLD) < MARGEM]
# 2. Amostra aleatória (captura erros sistêmicos invisíveis nos limítrofes)
import random
amostra_aleatoria = random.sample(decisoes, min(n // 3, len(decisoes)))
# 3. Combinar e deduplicar
revisao = list({d["id"]: d for d in limítrofes[:n * 2 // 3] + amostra_aleatoria}.values())
return revisao[:n]Exemplos Anotados
Exemplo 1: Sistema de Triagem de Candidatos
Sistema: ML ranqueia candidatos para triagem inicial
Sem HITL (ruim):
→ 500 candidatos ranqueados, RH seleciona top-50 automaticamente
→ Candidatos rejeitados nunca recebem feedback
→ Modelo tem viés histórico de contratação → perpetua discriminação
Com HITL Efetivo:
→ Top-50 automático + 10 casos aleatórios + 5 casos próximos do corte
→ Recrutador vê CV completo (não apenas score)
→ Discordâncias do recrutador alimentam retrained dataset
→ Taxa de discordância monitorada: se cair abaixo de 5% → investigarPadrões e Armadilhas
Padrões
Padrão 1: HITL em casos limítrofes + amostragem aleatória Revisão apenas nos casos limítrofes perde erros sistemáticos em casos de alta confiança.
Padrão 2: Monitorar taxa de discordância
taxa_discordancia = discordancias / total_revisados
if taxa_discordancia < 0.02:
alert("HITL potencialmente inefetivo — taxa de discordância muito baixa")Armadilhas
⚠️ Armadilha 1: HITL sem treinamento do revisor
Revisor vê dados técnicos sem contexto → aprova tudo para "não atrasar"
Solução: interface que destaca sinais de alerta e explica o risco de cada caso⚠️ Armadilha 2: Implementar revisão mas sem canal de contestação
LGPD exige que o usuário possa SOLICITAR revisão
HITL interno ≠ canal de contestação para o usuário afetadoSe não for realizar o laboratório, pule para o próximo capítulo.
Ponte para o Lab
Esta unidade é conceitual. Exercícios em exercicios.md: 1. Para um sistema descrito, dimensione o HITL (quantos revisores, qual capacidade) 2. Projete a interface de um revisor: o que deve aparecer para facilitar discordância? 3. Identifique se o HITL proposto é efetivo ou teatro
Agora você está pronto para o lab.