O cenário
Uma seguradora de saúde pede: "queremos um sistema que ajude nossos analistas a decidir sobre pedidos de reembolso complexos, cruzando o histórico do segurado, a apólice e o laudo médico — precisa ser rápido, defensável numa auditoria regulatória, e não pode aprovar nada sozinho." O time de produto quer lançar em oito semanas. O time jurídico exige trilha de auditoria completa. O time de operações já está sobrecarregado e não pode virar gargalo de revisão manual em todo pedido.
Esse pedido, como quase todo pedido real de sistema em produção, é um feixe de restrições em tensão: velocidade de lançamento contra rigor de compliance, autonomia do sistema contra necessidade de revisão humana, custo operacional contra qualidade da decisão. Não existe uma resposta que maximiza todos os quatro ao mesmo tempo — existe uma arquitetura que faz os trade-offs certos, de forma declarada e defensável.
Esta lição não introduz um domínio novo. Ela pede que você aplique, num único artefato, os frameworks de decisão dos 24 tópicos anteriores da trilha — e o formato desse artefato é um pacote de arquitetura: não um ADR isolado, mas o conjunto de decisões, evidências e planos que um arquiteto profissional apresenta para defender um sistema de ponta a ponta.
O que um pacote de arquitetura precisa ter
Um pacote de arquitetura completo, no nível que o CCAR-P exige, tem cinco partes — cada uma corresponde a um agrupamento dos sete domínios da certificação:
- Descoberta e requisitos — a restrição real por trás do pedido (não o pedido literal), os stakeholders, e os SLAs traduzidos em métricas verificáveis.
- Decisão de arquitetura — a solução desenhada, com as alternativas descartadas e a restrição que cada uma violava, cobrindo escolha de modelo, padrão de orquestração (workflow, agêntico, ou LLM aumentado) e integração.
- Plano de avaliação — como qualidade, custo, latência e segurança serão medidos antes e depois do lançamento, incluindo o que aciona um rollback.
- Controles de governança — quais obrigações regulatórias se aplicam, como cada uma vira controle técnico, e onde fica o ponto de revisão humana.
- Plano de lifecycle — como o sistema é documentado, comunicado aos stakeholders, e sustentado depois do lançamento.
O erro mais comum em um pacote de candidato é tratar essas cinco partes como seções isoladas, escritas uma depois da outra sem que uma restrinja a outra. Um pacote forte mostra as dependências entre elas: a decisão de arquitetura no item 2 existe porque uma restrição do item 1 exigiu; o ponto de revisão humana no item 4 existe porque o item 3 identificou onde o erro é mais caro.
Atravessando os sete domínios no mesmo cenário
Design de Solução e Arquitetura. O fluxo de análise de reembolso precisa de um padrão agêntico com ferramentas restritas (consultar apólice, consultar histórico, produzir uma recomendação) — não um workflow rígido demais para lidar com casos ambíguos, nem múltiplos agentes especializados para uma tarefa que uma sessão bem orquestrada resolve.
Modelos Claude, Prompt e Engenharia de Contexto. A recomendação final é saída estruturada com um contrato explícito (campos obrigatórios, o que nunca pode ser afirmado sem evidência no laudo ou na apólice), com o contexto relevante (apólice, histórico, laudo) posicionado de forma que reduza risco de lost-in-the-middle numa consulta que pode ser longa.
Integração. O sistema busca dados de três fontes diferentes (apólice, histórico, laudo) — decisão de RAG ou consulta direta depende da forma desses dados, e a integração entre sistemas internos e o serviço de recomendação precisa aplicar least privilege: o serviço nunca deveria ter mais acesso do que precisa pra decidir aquele pedido específico.
Avaliação, Testes e Otimização. O plano de avaliação mede acurácia da recomendação contra decisões históricas de analistas humanos, latência (o analista não pode esperar minutos por uma resposta), e custo por decisão — com um dataset representativo de casos, não só os mais simples.
Governança, Segurança e Gestão de Risco. Dados de saúde tornam HIPAA a obrigação central: cada consulta ao histórico do segurado precisa de trilha de auditoria, e a decisão final — que pode negar um reembolso — nunca é executada automaticamente; ela sempre chega como recomendação para um analista humano aprovar. Esse é o ponto de human-in-the-loop de maior risco do fluxo.
Comunicação com Stakeholders e Ciclo de Vida. O time jurídico, o time de produto e o time de operações recebem versões diferentes do mesmo pacote de arquitetura — a mesma decisão, traduzida para a preocupação de cada audiência, sem perder o trade-off real em nenhuma das versões.
Produtividade do Desenvolvedor e Capacitação Operacional. O time que vai operar o sistema recebe um runbook de handoff e ferramentas configuradas (incluindo Claude Code para debugging assistido de casos que o sistema classificou com baixa confiança) — o sistema não depende de quem o construiu para continuar funcionando.
O failure mode mais caro
Num cenário como esse, o failure mode mais caro não é a recomendação estar tecnicamente errada uma vez — é o sistema parecer confiável o suficiente para que a revisão humana vire aprovação automática sem leitura real, e uma negação de reembolso indevida chegar ao segurado sem ter sido de fato revisada. Formato impecável e confiança aparente do sistema, combinados com um analista sobrecarregado, produzem exatamente esse padrão.
A mitigação não está em nenhum domínio isolado — está na interseção deles: o plano de avaliação (domínio 4) precisa medir não só a acurácia do sistema, mas a taxa real de revisão humana efetiva (quanto tempo o analista gasta por caso, não só se ele clicou em aprovar); e o controle de governança (domínio 5) precisa tornar a ausência dessa revisão efetiva, por si só, motivo de escalonamento — não apenas confiar que o processo está sendo seguido.
Coloque em prática
O laboratório desta lição pede que você monte e valide a estrutura de um pacote de arquitetura completo — descoberta, decisão, avaliação, governança e lifecycle — verificando que nenhuma seção está vazia, que a decisão referencia pelo menos uma restrição do discovery, e que existe um ponto de revisão humana associado a toda ação de risco alto identificada no plano de governança.