Documentação pública
O PATRON grava cada interação com o modelo em um hash-chain SHA-256 e monta uma árvore de Merkle sobre essa cadeia. O escritório consegue provar que o histórico de trabalho com IA não foi alterado depois, sem acesso aos nossos servidores e sem expor o conteúdo dos autos.
SHA-256 · árvore de Merkle conforme RFC 6962 · verificação offline · AGPL-3.0
Vale para o PATRON 1.3.0. Publicado em 23 de agosto de 2026, atualizado em 24 de agosto de 2026.
Trilha de auditoria em um sistema de IA é o registro de eventos que permite reconstruir quem perguntou, quando, qual modelo respondeu, em quais fontes a resposta se apoiou e quem a aprovou. Histórico de chat não é isso. Histórico de chat pode ser editado e apagado sem deixar marca, e a trilha existe justamente para pegar esse tipo de alteração.
A diferença aparece sob pressão. Quando o compliance ou o juízo pergunta como aquela resposta surgiu, o escritório com histórico de chat tem uma captura de tela. O escritório com trilha de auditoria tem prova que se verifica mecanicamente e cuja correção não depende da boa vontade do fornecedor.
O registro cobre o trabalho com o modelo, o acesso administrativo ao próprio registro e as operações sobre dados pessoais. A lista de tipos de evento é fechada e sustentada por uma restrição CHECK no banco, então um tipo novo não aparece sem uma migração visível no histórico do código.
RegistradoPergunta do usuário e resposta do assistente, escolha da rota do modelo, execução do pipeline de defesa contra injeção de prompt, aprovação humana de uma alteração, controle de fonte na revisão tabular, limite de custo.
Meta-auditoriaAbertura do visualizador de auditoria, exportação do pacote de evidências, cálculo forçado da raiz de Merkle, consulta a métricas. A intenção de levar a prova para fora fica gravada antes de a prova sair do sistema.
RegistradoPedidos de exclusão e de exportação sob GDPR e LGPD, consentimento para processamento em nuvem em um Caso específico, ativação e desativação de conector de fonte do direito, edição de documento.
Restrição de projeto: o payload do evento guarda números, identificadores e valores de enumeração. Conteúdo de documento e dado pessoal não ficam ali. É essa condição que permite o pacote de evidências sair do escritório sem que os autos do cliente saiam junto.
O registro só aceita acréscimo. Cada linha guarda o hash da linha anterior em prev_hash e o seu próprio hash, calculado a partir de prev_hash concatenado com a forma canônica em JSON dos demais campos do evento: carimbo de tempo, tipo de evento e os identificadores de pessoa, Caso, documento e payload.
A primeira linha do sistema carrega um prev_hash de sessenta e quatro zeros. A serialização é determinística e independe da ordem das chaves no JSON, então os mesmos dados sempre produzem o mesmo hash, inclusive depois de o banco mudar de máquina.
Apague ou altere uma linha no meio e os elos se rompem. Não dá para trocar um evento sem recalcular todos os seguintes, e isso deixa marca nas raízes de Merkle já seladas.
Escolhemos hash-chain em vez de registro assinado com chave privada porque assinatura exige gestão e rotação de chave do lado do escritório. O preço dessa decisão está descrito abaixo, na seção de limites.
A cadeia sozinha detecta alteração. Conferi-la, porém, exige percorrer o registro inteiro. A árvore de Merkle resolve isso: prova que um evento pertence a um bloco selado sem revelar os outros eventos daquele bloco.
EntradaAs folhas são os hashes de evento que já estão na cadeia. Não recalculamos nada, então a camada de Merkle nunca modifica o registro e é somente leitura em relação a ele.
RegraUm nó interno é o SHA-256 da concatenação dos hashes dos filhos esquerdo e direito. Com número ímpar de nós em um nível, o último é duplicado, seguindo a convenção da RFC 6962 usada no Certificate Transparency.
SaídaGuardamos a raiz junto com o intervalo do bloco, a contagem de eventos, o horário e quem calculou. O cálculo roda por comando do administrador ou por gatilho automático quando uma contagem de eventos ou um intervalo de tempo é ultrapassado.
O algoritmo é determinístico: o mesmo bloco de eventos sempre produz a mesma raiz. O padrão da camada vem de microsoft/agent-governance-toolkit (licença MIT), o algoritmo em si da RFC 6962.
Cada caminho entrega um alcance de prova diferente a um custo diferente. Qual deles usar depende de o auditor estar examinando um evento isolado, o histórico inteiro ou uma prova levada para fora do escritório.
Rode npm run audit:verify do lado do escritório. Ele percorre o registro e recalcula cada elo. Linha apagada do meio, reordenada ou alterada depois é apontada. O custo cresce de forma linear com o número de eventos; isso decorre do próprio algoritmo, e é tudo que dá para afirmar sem medição.
A prova de Merkle devolve os hashes irmãos do evento até a raiz do bloco, em formato que segue a RFC 6962. O auditor recalcula por conta própria e compara com a raiz gravada. O resto do bloco continua coberto. Sob sigilo profissional, às vezes essa é a única condição em que a auditoria acontece.
O pacote de evidências é um arquivo autossuficiente. O verificador roda com python verify.py. Usa apenas a biblioteca padrão do Python 3.8, não faz chamada de rede e não precisa de acesso ao banco do escritório.
O verificador do pacote trabalha em três estágios: somas de verificação de cada parte contra o manifesto, depois a continuidade dos elos no extrato do registro, por fim um hash sobre o todo. Devolve código de saída 0 para pacote íntegro, 1 para adulterado e 2 em erro de leitura, então você o encaixa em um script em vez de rodar na mão.
O artigo 12 do Regulamento (UE) 2024/1689 exige que sistemas de alto risco registrem eventos automaticamente ao longo do ciclo de vida. Abaixo, o requisito confrontado com o que o registro de fato grava.
| Requisito do art. 12 | O que o PATRON grava |
|---|---|
| Registro de eventos durante a operação | Cada pergunta e resposta como evento separado com carimbo de tempo, acrescentado e nunca editado |
| Identificação de quem exerce a supervisão | Identificador de pessoa em cada evento e um tipo de evento próprio para a aprovação humana de uma alteração |
| Dados de entrada que levaram ao resultado | Escolha da rota do modelo, as fontes citadas pela resposta e o veredito do controle de fonte em três classes |
| Versão do sistema e configuração | Versões da aplicação e dos conectores no pacote de evidências, junto da impressão digital dos prompts usados |
| Poder demonstrar conformidade à autoridade | Exportação de pacote verificável fora do sistema; a própria exportação vai para o registro |
Leitura da MateMatic sobre o AI Act e a proteção de dados, não posição da OAB nem de conselho profissional. Para avaliação formal de conformidade, use o texto consolidado no EUR-Lex, CELEX 32024R1689. Se uma implantação concreta conta como alto risco depende do uso que o escritório faz dela, não da ferramenta sozinha.
Um hash-chain detecta alteração de uma linha. Isso não é o mesmo que provar quem produziu a linha. Sem assinatura criptográfica, o escritório pode negar que determinado pacote veio dele, e o hash sozinho não encerra a discussão.
Assinatura Ed25519 com carimbo de tempo conforme a RFC 3161 está reservada aqui como decisão de arquitetura separada e não está implementada. Dizemos isso de forma direta, porque em um litígio a distância entre detectar alteração e irretratabilidade costuma ser o ponto.
Também não impomos política de retenção. O registro cresce enquanto o escritório o mantiver, e por quanto tempo guardar segue sendo decisão dele, a ser conciliada com a proteção de dados e com o sigilo profissional.
Cada um desses limites é conferível no código: não há assinatura no módulo que monta o pacote, nem regra de expurgo no esquema do banco.
Qual a diferença entre trilha de auditoria e histórico de chat?
O histórico de chat pode ser alterado e ninguém percebe. A trilha de auditoria amarra os registros com hashes, então apagar ou trocar uma entrada rompe a continuidade e aparece. O chat responde à pergunta "o quê". A trilha responde à pergunta "foi mesmo assim".
Como conferir a trilha de auditoria no sistema de IA de um escritório?
Peça ao fornecedor o algoritmo, um verificador que rode sem falar com o servidor dele e um pacote de evidências de exemplo. Se a verificação exige login no sistema do fornecedor, aquilo não é auditoria, é visita guiada: você confere a afirmação dele com a ferramenta dele. A resposta "temos log de auditoria completo" não significa nada até você ver com o que se confere.
O auditor precisa de acesso aos autos do cliente?
Não. Nada do que o auditor recebe contém o texto de um documento, e o servidor mascara os dados pessoais antes de o pacote sair do sistema. A prova de Merkle confirma um evento isolado sem descobrir o resto do bloco.
Por que a RFC 6962 especificamente?
É a especificação do Certificate Transparency, provada na auditoria pública de certificados na internet. A construção da árvore e o formato da prova estão escritos, então o auditor pode montar o próprio verificador em vez de confiar no nosso. Pegamos um padrão existente em vez de inventar um. Saiu mais barato e mais seguro de auditar.
Quem pode exportar o pacote de evidências?
Depende de qual pacote. Um administrador de uma lista de endereços mantida pelo escritório exporta o arquivo de um único evento do registro. Quem escreveu a peça baixa o pacote de prova dela, porque a fronteira é o caso, não o papel. O registro grava a intenção de levar a prova para fora nos dois casos, antes de a prova existir.
Código aberto facilita adulterar o registro?
A segurança aqui não se apoia em manter o algoritmo secreto, e sim nas propriedades da função de hash. Código aberto permite ao escritório e ao auditor dele confirmar que gravamos o que dizemos gravar. Um produto fechado pediria que aceitassem isso na palavra.
O PATRON roda no equipamento do escritório. O registro, o verificador e o código estão lá desde a primeira execução.