O problema
Um time constrói um assistente que resume laudos médicos para pacientes. Funciona bem em testes. Vai para produção. Três semanas depois, o assistente resume um laudo de forma tecnicamente correta, mas omite uma informação que, para aquele paciente específico, era a mais importante do documento — e ninguém revisou antes de a resposta chegar até ele.
O problema não foi o modelo "alucinar". Foi a ausência de uma camada de controle proporcional ao risco da tarefa. Um sistema que resume documentos internos de baixo risco pode operar sem revisão humana constante. Um sistema que entrega informação médica direto ao paciente final não pode — e a diferença entre os dois não é o modelo usado, é a arquitetura de governança em volta dele.
Esta lição é sobre colocar autoridade em volta da capacidade: garantir que o poder de um sistema de agir, decidir ou responder seja proporcional ao controle que existe para pegar o que ele fizer de errado.
Guardrails são camadas, não um interruptor único
Um erro comum é tratar segurança como uma decisão binária: "o sistema tem um filtro de conteúdo, logo está seguro". Guardrails eficazes são camadas independentes, cada uma cobrindo um tipo diferente de falha:
- Validação de entrada — rejeitar ou sinalizar entradas fora do escopo esperado antes que cheguem ao modelo.
- Restrição de capacidade — limitar o que o sistema pode fazer (quais ferramentas, quais ações irreversíveis) independente do que o modelo "decidir" fazer.
- Validação de saída — checar se a resposta é factualmente sustentada, segue o formato esperado, e não viola uma política antes de sair do sistema.
- Revisão humana no ponto certo — não em todo lugar, mas onde o custo de um erro é alto o suficiente para justificar o atraso.
Cada camada cobre uma falha que as outras não cobrem. Um filtro de saída não impede uma ação irreversível que já aconteceu antes da resposta ser gerada. Uma restrição de capacidade não garante que uma resposta textual está correta. Tratar qualquer uma isoladamente como "a" solução de segurança é o erro que a prova costuma testar.
Os failure modes mais comuns não são exóticos
Sistemas baseados em LLM falham de um número relativamente pequeno de formas recorrentes: alucinação apresentada com confiança indistinguível de um fato correto, sensibilidade a como a pergunta é formulada (o mesmo pedido, reformulado, produz respostas inconsistentes), vazamento de informação de um contexto para outro quando isolamento não foi garantido, e ações automatizadas demais para tarefas que ainda exigem julgamento humano.
Reconhecer esses padrões com antecedência muda o desenho da arquitetura. Se alucinação é o risco dominante numa tarefa, a mitigação é ancorar a resposta em fonte verificável (RAG bem desenhado, não RAG genérico). Se o risco é ação irreversível, a mitigação é um ponto de confirmação humana antes da execução, não depois.
Validação humana no ponto certo, não em todo ponto
O instinto de "colocar um humano revisando tudo" parece seguro, mas não escala e, na prática, produz revisão superficial — quando tudo precisa de aprovação, a atenção real cai para tudo. A decisão de arquitetura correta é identificar o ponto do fluxo onde um erro custa mais caro (uma ação irreversível, uma informação sensível saindo do sistema, uma decisão com impacto legal) e colocar a revisão humana exatamente ali, deixando o resto do fluxo operar com velocidade.
Um distrator típico de cenário: uma alternativa que propõe "revisão humana em cada etapa, para garantir segurança máxima". Parece a opção mais cautelosa. Na prática, é operacionalmente inviável e desloca a atenção humana do ponto que realmente importa para uma rotina de aprovações que perde eficácia pelo volume.
Coloque em prática
O laboratório desta lição pede que você construa um classificador de nível de risco que, dado o tipo de ação de um sistema (reversível vs. irreversível, dado interno vs. dado sensível ao usuário final), determina que camadas de guardrail e em qual ponto a revisão humana deveria entrar — a mesma lógica que evita o cenário do laudo médico revisado tarde demais.