Engenharia para Confiabilidade
Como construir sistemas confiáveis a partir de componentes não confiáveis – e por que isso não é tão novo quanto parece.
O desconforto
Todo desenvolvedor conhece este contrato:
Mesma entrada → mesma lógica → mesmo output. Sempre.
A IA quebra esse contrato. O mesmo prompt, o mesmo modelo, a mesma entrada podem produzir outputs diferentes em execuções consecutivas. Para engenheiros treinados em sistemas determinísticos, isso parece fundamentalmente quebrado.
A resistência não é puramente intelectual. É emocional. Os engenheiros constroem identidade em torno da qualidade do seu output, do controle sobre o comportamento do sistema. Quando um componente produz resultados inconsistentes, isso não desafia apenas uma premissa técnica. Desafia o senso de domínio que torna o trabalho significativo. Reconhecer isso é o primeiro passo para superá-lo.
Não está quebrado. É um tipo diferente de sistema. E requer um tipo diferente de engenharia de confiabilidade.
Você já faz isso
O desconforto é real, mas o problema não é novo. Os desenvolvedores já trabalham com componentes não confiáveis no dia a dia:
- Redes falham. Você faz retry. Adiciona timeouts. Projeta para falha parcial.
- APIs de terceiros mudam. Você versiona. Escreve testes de contrato. Adiciona fallbacks.
- Race conditions existem. Você usa locks, filas e idempotência.
- Usuários fornecem lixo como entrada. Você valida, sanitiza e rejeita.
Nenhum desses sistemas é determinístico no nível do componente. Eles são confiáveis no nível do sistema – porque você projetou confiabilidade em torno de partes não confiáveis.
A IA é o mesmo padrão. O modelo é um componente não confiável. Seu trabalho é construir um sistema confiável em torno dele.
O enquadramento
O software tradicional pergunta: Funciona?
Os sistemas de IA perguntam: Com que frequência funciona?
Este não é um padrão mais baixo. É um mais honesto. O software tradicional também falha – apenas falha de formas que aprendemos a esconder (tratamento de erros, retries, degradação graciosa). A IA torna a não confiabilidade visível em vez de enterrá-la.
Confiabilidade não é "dá sempre a mesma resposta". Confiabilidade é "o sistema funciona consistentemente dentro de limites aceitáveis". Os limites são seus para definir.
O conjunto de ferramentas
A transição de sistemas determinísticos para probabilísticos requer práticas de engenharia específicas. Nenhuma delas é exótica – são a mesma disciplina que você já aplica a sistemas distribuídos, aplicada a um novo tipo de componente.
A avaliação substitui os testes unitários
No software tradicional, os testes verificam outputs exatos. Nos sistemas de IA, você avalia distribuições.
Todo sistema de IA deve ter:
- Um conjunto de dados de avaliação que representa o comportamento esperado
- Execuções de avaliação automatizadas a cada mudança
- Verificações de regressão que detectam degradação
Isso desempenha o mesmo papel de uma suíte de testes. Sem isso, os sistemas de IA degradam silenciosamente – não porque o código mudou, mas porque o modelo mudou.
Guardrails substituem a confiança
O output de LLM quase nunca deve ser confiado diretamente. O modelo fornece raciocínio. O sistema fornece confiabilidade.
Os sistemas em produção devem incluir camadas de validação:
- Outputs estruturados ou schemas que impõem o formato
- Regras de negócio determinísticas que sobrepõem o julgamento do modelo quando apropriado
- Validação de output que detecta alucinações e violações de restrições
- Loops de retry e reparo para falhas recuperáveis
- Agente revisor – um agente avaliador separado revisa o output do agente primário (veja abaixo)
- Revisão humana graduada por risco quando o custo do erro é alto – veja portões de validação graduados por risco para a alocação HITL / HOTL / HOOTL
Os guardrails não são uma admissão de que a IA é ruim. São a engenharia que torna a IA útil.
Agente revisor é o padrão de produção
Para trabalho não trivial, emparelhe o gerador com um agente avaliador separado – contexto diferente, às vezes um modelo diferente. O padrão é hoje o padrão de produção para revisão de código (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot review) e está sendo adotado em atendimento ao cliente (revisão de tom + política), processamento de documentos e outros domínios de tarefas discretas.
Por que importa: humanos avaliando output rapidamente são avaliadores não confiáveis de output incorreto apresentado com confiança. Agentes revisores, executados em contextos diferentes, trazem à tona o que humanos cansados não notam. A pesquisa PoLL ("Panel of LLM judges") constata que júris de modelos menores frequentemente superam um único juiz grande (Verga et al., 2024) – e com custo menor.
Estrutura de custo: um agente revisor separado em cada artefato aproximadamente dobra o gasto de inferência por tarefa. No Rung 5, hoje considera-se que vale a pena – a matemática do custo por unidade entregue funciona porque a revisão humana em escala não funciona.
Etapas menores substituem prompts grandes
Prompts grandes que tentam resolver tudo são frágeis. Eles combinam muitos modos de falha em uma única chamada.
Os sistemas de IA confiáveis decompõem as tarefas:
- Classificar a entrada
- Recuperar contexto relevante
- Gerar output
- Validar estrutura e qualidade
- Reparar se necessário
Cada etapa pode ser avaliada, monitorada e melhorada independentemente. Unidades de raciocínio menores aumentam a confiabilidade pelo mesmo motivo que funções pequenas são mais confiáveis do que monolíticas.
A observabilidade substitui as premissas
Os sistemas de IA em produção devem expor:
- Logs de prompts – o que entrou
- Respostas do modelo – o que saiu
- Pontuações de avaliação – quão bom foi
- Casos de falha – o que deu errado
- Métricas de custo e latência – o que custa
Você não pode melhorar o que não consegue ver. E os sistemas de IA falham de formas invisíveis sem instrumentação – o output parece plausível, mas está errado.
O versionamento substitui a estabilidade
Os modelos de IA evoluem continuamente. Uma atualização de modelo pode mudar o comportamento de formas que nenhuma mudança de código explicaria.
As práticas de engenharia devem incluir:
- Versionamento de modelo – fixe a versão do modelo em produção. Atualize deliberadamente.
- Versionamento de prompt – trate os prompts como código. Rastreie mudanças. Revise diffs.
- Avaliação na atualização – execute sua suíte de avaliação antes e depois de cada mudança de modelo, da mesma forma que você roda testes antes de implantar uma nova dependência.
- Iteração rápida – quando algo quebra, itere rápido. A correção geralmente está no prompt, nos guardrails ou na avaliação – não no modelo.
Trate mudanças de modelo como atualizações de dependência. Você já sabe como gerenciar isso.
Modos de falha e recuperação em maturidade alta
O conjunto de ferramentas lida com modos de falha conhecidos. Em maturidade de Tier 3 / Rung 5, três preocupações adicionais se tornam dominantes: dois novos modos de falha (sycophancy, casos de borda subjetivos) e um padrão de resposta (recalibração vs depuração) que distingue a prática de maturidade alta da prática de maturidade baixa. Nenhum é detectado por testes ou monitoramento; os engenheiros precisam reconhecê-los.
Sycophancy: uma preocupação estrutural
LLMs defendem posições erradas com confiança de forma consistente. Isso é medido em múltiplos estudos (Sharma et al., 2023; Wen et al., 2024; OpenAI sobre alucinação, 2025). Wen et al. constataram que o RLHF torna os modelos melhores em convencer humanos de que estão certos sem torná-los melhores em estar certos (taxa de falso-positivo +24% em QA, +18% em programação).
A literatura discorda genuinamente sobre se a sycophancy é uma correção de treinamento tratável ou um artefato estrutural do RLHF.
A postura do framework: trate a sycophancy como uma preocupação estrutural para fins de engenharia, independentemente da trajetória de treinamento.
Construa salvaguardas de processo (sinal externo, agente revisor, recuperação de verdade-base, testes executáveis) em cada loop. Não confie na confiança do modelo como sinal de correção.
Se o treinamento a melhorar mais tarde, as salvaguardas continuam sendo infraestrutura útil. Se não melhorar, as salvaguardas são essenciais.
Casos de borda subjetivos
Em maturidade baixa, os casos de borda são técnicos: os testes não os capturam, o monitoramento os mostra como anomalias, a correção está no código. Em maturidade mais alta, o caso de borda dominante muda: torna-se subjetivo. Um usuário relata que a IA errou em algo – mas os testes passam, o monitoramento está verde, e a falha é qualitativa.
Exemplos:
- Engenharia – um PR está tecnicamente correto, mas o agente tomou um caminho de implementação errado; o usuário nota "não era isso que eu quis dizer"
- Atendimento ao cliente – um ticket resolvido por IA tem fatos corretos, mas o tom está fora para o estado emocional do cliente
- Finanças – uma transação está corretamente categorizada pela regra, mas a regra em si deturpa a intenção do negócio
- Conteúdo / marketing – o texto é gramatical e está dentro da spec, mas perde a voz da marca
A recuperação é conversa, não correção. Converse com o usuário. Entenda o que ele estava tentando alcançar. Atualize a spec ou o contexto – não o código.
Este modo de falha está bem documentado mas pouco nomeado. Fontes de praticantes o referenciam com vocabulário diferente: o problema dos 70% de Addy Osmani (os últimos 30% são trabalho humano), pesquisas de UX da NN/g, o Guidebook PAIR. O framework o nomeia explicitamente porque a resposta operacional difere estruturalmente da correção de um bug técnico.
Recalibração vs depuração
Quando a IA está errada, duas respostas são possíveis:
Corrigir o artefato (código, resposta, documento) que o agente produziu. Trata a falha como um problema de código.
Reconstruir o entendimento do agente via contexto novo, spec rearticulada, brainstorm multi-perspectiva. Trata a falha como um problema de spec ou contexto.
Essas são operacionalmente distintas.
A literatura sobre autocorreção intrínseca é unânime: um modelo que se comprometeu com uma direção errada não a perceberá com confiabilidade sozinho; reflexão na mesma janela de contexto após uma resposta errada agrava o erro em vez de corrigi-lo (Huang et al., 2023; Kamoi et al., 2024). Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) constataram que 41,8% das falhas multi-agente são problemas de especificação ou design que precisam de re-especificação, não de nova tentativa.
Heurística prática: se a mesma spec produz o mesmo output errado em duas execuções novas, depure a spec, não o artefato. A maioria das falhas não triviais em maturidade alta são problemas de recalibração disfarçados de problemas de depuração.
Veja Lab de IA § Protocolo de estado bloqueado para o padrão operacional.
A mudança de papel
Nesse modelo, os engenheiros não estão escrevendo lógica principalmente. Eles estão projetando sistemas que supervisionam inteligência. Isso é, estruturalmente, gestão: especificar intenção a um executor imperfeito, avaliar output em vez de controlar o processo, e iterar na sua própria comunicação quando o resultado não corresponde à intenção. Os gestores sempre operaram em um mundo probabilístico. Os engenheiros estão se juntando a eles.
- •Escrever lógica de negócio
- •Implementar algoritmos conhecidos
- •Debugar linha por linha
- •Otimizar caminhos de execução
- •Projetar prompts e interfaces de ferramentas
- •Construir camadas de validação e avaliação
- •Projetar loops de retry e correção
- •Monitorar desempenho em nível de sistema
Isso não é um rebaixamento. É uma mudança para um nível mais alto de abstração, a mesma mudança que aconteceu quando os engenheiros migraram de assembly para linguagens de alto nível, ou de bare metal para infraestrutura em nuvem. Cada transição pareceu perda de controle. Cada uma foi, na verdade, ganho de alavancagem.
O princípio central
Não programamos inteligência. Projetamos ambientes onde a inteligência performa de forma confiável.
A não confiabilidade não é o problema. É a natureza do componente. A engenharia é o que transforma um componente não confiável em um sistema confiável.
Isso não é novo. É o que os engenheiros sempre fizeram.
Relacionado: Maturidade do código aborda o problema inverso: não como fazer sistemas confiáveis a partir de output de IA não confiável, mas como dar aos agentes de IA uma base de código legível o suficiente para produzir trabalho confiável. A mesma incerteza, refletida.
← Voltar para o início · O Lab de IA · Padrões de Execução de IA · O Framework de Referência