O problema
Um time termina de construir um assistente que resume prontuários médicos para uma equipe de triagem. A arquitetura está tecnicamente correta: RAG bem desenhado, avaliação automatizada, observabilidade em produção. Alguém pergunta na revisão final: "isso está em conformidade com HIPAA?" Silêncio. Ninguém tinha essa resposta pronta, porque compliance nunca entrou como restrição de design — só ia ser verificado depois, como uma auditoria separada do trabalho de arquitetura.
Esse é o padrão que esta lição existe para quebrar. Governança regulatória não é um checklist que se aplica sobre uma arquitetura pronta. É uma restrição que, como latência ou custo, molda decisões de design desde a primeira linha — que dado pode sair do ambiente controlado, quem precisa aprovar antes de uma ação irreversível, o que precisa ficar auditável depois.
De obrigação regulatória a controle técnico
GDPR, HIPAA e FedRAMP (os três mais citados no domínio de Governança do CCAR-P) não são textos jurídicos que um arquiteto lê e memoriza — são fontes de restrições técnicas concretas, e o trabalho do arquiteto é fazer essa tradução:
- GDPR exige que dados pessoais tenham uma base legal de tratamento e um caminho de exclusão. Isso vira um requisito técnico: cada registro que entra no sistema precisa carregar proveniência (de onde veio, sob qual base legal), e o sistema precisa suportar exclusão real, não só ocultação.
- HIPAA exige controle de acesso e trilha de auditoria para informação de saúde. Isso vira: quem (ou qual agente) acessou qual registro, quando, e com que justificativa — registrado de forma que sobreviva a uma investigação, não como log efêmero.
- FedRAMP exige que o processamento de dados governamentais aconteça dentro de fronteiras de infraestrutura autorizadas. Isso vira uma restrição de arquitetura de implantação, não uma política escrita — a chamada ao modelo, o armazenamento de contexto, tudo precisa respeitar essa fronteira fisicamente, não só por acordo.
O erro comum é tratar essas obrigações como uma camada de "compliance" adicionada depois, geralmente na forma de um documento de políticas que ninguém consulta durante o design. A resposta certa em cenário quase sempre é: identifique a obrigação relevante ao domínio do sistema (saúde, dados pessoais, setor público) e traduza cada uma em um controle técnico verificável antes de desenhar o fluxo de dados.
Human-in-the-loop no ponto certo, não em todos os pontos
A segunda metade desta lição é sobre onde colocar revisão humana. O instinto de segurança é "revisar tudo" — mas revisão humana em todo ponto do fluxo não escala, cansa o revisor, e o cansaço produz aprovação automática sem leitura real, que é pior do que nenhuma revisão.
O framework de decisão parte de uma pergunta: qual é o ponto do fluxo onde um erro é mais caro e mais difícil de reverter? Human-in-the-loop pertence ali, não em todo lugar:
- Uma sugestão de resumo que um humano vai ler antes de agir não precisa de aprovação prévia — o próprio ato de usar o resumo já é a revisão.
- Uma ação que modifica um registro de prontuário, envia uma notificação a um paciente, ou libera um pagamento precisa de aprovação explícita antes de executar, porque o custo de reverter é alto ou o dano já aconteceu no momento da execução.
Um distrator comum em cenário: colocar revisão humana logo na primeira etapa do pipeline (por exemplo, aprovar cada consulta antes de o modelo processá-la) em vez de na etapa que produz a ação irreversível. Isso parece cauteloso, mas move o gargalo pro lugar errado — revisa o que é barato de errar e deixa passar sem revisão o que é caro.
Governança não é uma decisão única
A última peça é reconhecer que uma decisão de governança tomada no design inicial pode deixar de ser suficiente conforme o sistema evolui em produção. Um novo tipo de dado passa a fluir pelo sistema, um novo mercado com regulação diferente é atendido, ou um incidente revela uma lacuna de controle que ninguém tinha antecipado. Nesses momentos, a decisão de governança precisa ser revisitada — não é algo que se resolve uma vez na arquitetura e nunca mais se olha.
Um sinal prático de que isso está bem desenhado: existe um dono claro da política de governança do sistema, e existe um gatilho definido (mudança de tipo de dado, expansão de mercado, incidente) que aciona uma nova revisão — não depende de alguém lembrar de revisitar por conta própria.
Coloque em prática
O laboratório desta lição pede que você mapeie um conjunto de obrigações regulatórias para controles técnicos concretos e valide se um ponto de human-in-the-loop está posicionado na etapa de maior risco do fluxo, não na mais conveniente.