📚 Por que governança vira kernel
Na computação tradicional, governança de TI era uma camada adicionada depois: relatórios mensais, auditorias anuais, controles "bolt-on". Na era agêntica, isso não funciona mais. Quando um agente executa centenas de ações por dia, logs e audit trails precisam ser gerados dentro do agente — automaticamente, em tempo real, sem intervenção humana. Governança bolt-on quebra quando a escala aumenta; built-in escala junto com o sistema.
🏗️ Built-in vs bolt-on
- Bolt-on (ruim): governança adicionada depois. Dependente de humano lembrar. Quebra em automação. Inconsistente.
- Built-in (correto): hooks que geram log automaticamente. Observabilidade como default. Zero overhead humano.
- Resultado: sistema que governança governa a si mesmo — não precisa de lembretes para registrar.
📊 Custo real
Governança bolt-on custa mais: horas de trabalho manual para compilar relatórios + inconsistências + gaps de cobertura + falha de audit em momentos críticos. Governança built-in tem custo único de setup e depois roda sozinha.
📝 Audit trail por sessão
Cada sessão de agente é um evento rastreável. O audit trail é o registro completo do que aconteceu: quais prompts foram dados, quais tools foram chamadas, quais arquivos foram editados, qual foi o custo em tokens, e quais decisões foram tomadas. Sem esse registro, você não tem como responder "o que o agente fez na terça-feira às 14h?" — e em ambientes regulados, essa pergunta não é opcional.
O que o audit trail captura
- •Timestamp + usuário — quem iniciou, quando, em qual ambiente.
- •Prompts recebidos — a instrução original do humano.
- •Tools chamadas — Read, Edit, Bash — com parâmetros exatos.
- •Arquivos modificados — diff de cada mudança.
- •Custo de tokens — input + output + cache hits.
- •Aprovações humanas — o que foi confirmado, por quem, quando.
💡 Implementação mínima
Hook de PostToolUse que appenda ao /logs/session-YYYY-MM-DD.jsonl. Um arquivo JSON por dia, uma linha por chamada de tool. Simples, pesquisável, replicável para S3/GCS para retenção longa. A skill session-handoff já gera esse tipo de registro automaticamente.
🏛️ Compliance por arquitetura
HIPAA, GDPR, SOC2, ISO 27001 — todos esses frameworks têm uma coisa em comum: exigem evidência de que controles funcionam, não apenas promessas de que funcionam. A boa notícia é que path scoping + audit trail + permissões mínimas já constroem automaticamente a base auditável que esses frameworks exigem. Compliance não precisa ser um projeto separado; é um resultado emergente de uma boa arquitetura agêntica.
Mapeamento de controles
- HIPAA Minimum Necessary → path scoping que limita acesso a PHI ao mínimo necessário por função.
- GDPR Right to Access → audit trail rastreável por titular de dados.
- SOC2 CC6.3 (Access Controls) → allowlist/denylist + jurisdição documentada por agente.
- SOC2 CC7.2 (Monitoring) → logs em tempo real + alertas de violação de escopo.
- ISO 27001 A.9 (Access Management) → least privilege + revisão periódica de permissões.
Dra. Sana — HIPAA na prática
A clínica da Dra. Sana tem compliance HIPAA emergente da arquitetura: PHI em pasta isolada (minimum necessary), audit trail de toda leitura, aprovação humana para cruzamento de domínios, logs imutáveis por 7 anos. Custo de compliance: zero trabalho adicional — é o que o sistema já faz.
🚨 Decisões de alto impacto
Em sistemas agênticos, algumas decisões são irreversíveis ou de alto custo: deletar dados, enviar comunicações em massa, executar pagamentos, modificar configurações de segurança. Essas ações precisam de um processo formal de autorização — não apenas um "confirmar" no terminal, mas um registro documentado de quem autorizou, com base em quê, e quando.
Protocolo four-eyes
- 1. Agente prepara — lista exatamente o que vai fazer, impacto estimado, reversibilidade.
- 2. Primeiro revisor — analisa a proposta, pode aprovar com condições ou rejeitar.
- 3. Segundo revisor — para ações críticas (pagamentos acima de threshold, deletes em prod).
- 4. Log assinado — ambas as aprovações registradas com timestamp e identidade.
- 5. Execução rastreada — agente executa com hook que loga o resultado real vs esperado.
⚠️ Sem paper trail — o risco legal
Sally, a advogada, sabe: em litígio, a pergunta é sempre "quem autorizou?". Se a resposta for "o agente fez sozinho", não há defesa. O four-eyes com log assinado transforma essa resposta em "João Souza autorizou em 15/05/2026 às 14:23, após revisão de Pedro Lima".
🧾 Evidências para auditoria
Um auditor não aceita "funcionou" — aceita evidência. A evidência auditável é um pacote exportável que mostra, para cada ação relevante: qual era o estado antes, qual instrução foi dada, o que foi executado, qual o estado depois, e quem aprovou. Esse pacote precisa ser íntegro (não adulterável), acessível (recuperável anos depois) e legível (humano consegue entender).
Componentes do pacote auditável
- •Input completo — prompt original, CLAUDE.md vigente, contexto da sessão.
- •Ações executadas — cada tool call com parâmetros, resultado, timestamp.
- •Estado antes/depois — git diff para código; snapshot para dados.
- •Aprovações — quem confirmou o quê, quando, com qual justificativa.
- •Hash de integridade — SHA-256 do log para detectar adulteração.
💡 Retenção e armazenamento
Logs de sessão em /logs/ local + replicação automática para S3 com Object Lock (tamper-proof). Retenção: 7 anos para dados HIPAA, 3 anos para dados GDPR por padrão. Custo de armazenamento é negligível vs custo de não ter quando precisar.
📈 Métricas de governança
Sem métricas, governança vira teatro — parece funcionar mas não tem como saber se funciona de verdade. As métricas de governança medem não só o que aconteceu, mas a saúde do próprio sistema de controle. São métricas de segundo nível: medem o processo, não só o resultado.
KPIs de governança agêntica
- % ações cobertas por audit trail — meta: 100% para ações de alto risco, 80%+ geral.
- % ações com path scope definido — meta: 100% para agentes em produção.
- Tempo médio até aprovação — mede friction; muito alto = processo emperrado.
- Taxa de rejeição de aprovações — alto = agente propondo coisas erradas; baixo = controle eficaz.
- Desvios de escopo detectados — agente tentou acessar fora do path permitido.
- Cobertura de revisão do CLAUDE.md — % de mudanças que passaram por PR review.
Leading indicators
Medem o processo antes do resultado: % sessões com log ativo, % agentes com jurisdição documentada. Permitem corrigir antes do problema.
Lagging indicators
Medem resultado: incidentes de segurança, falhas de audit, violações de compliance detectadas. Confirmam se o sistema funcionou.
📋 Resumo do Módulo
Próximo Módulo:
2.6 — Identidade > prompt: o "passwd" da era agêntica