Log imutável de decisões de IA com encadeamento de hash

O artigo executivo "Trilha de auditoria para decisões tomadas com IA" trata do porquê: sem trilha auditável, a empresa não consegue explicar uma decisão automatizada quando questionada por um regulador, um cliente ou um processo judicial. Este texto trata de como construir essa trilha de forma que ela resista a alteração, mesmo por quem tem acesso administrativo ao banco de dados.

Por que um log comum não basta

Um log tradicional em banco relacional — tabela com UPDATE e DELETE permitidos — não prova nada em uma auditoria. Qualquer pessoa com acesso de administrador pode alterar um registro depois do fato e não deixar rastro da alteração. Para decisões de IA que afetam pessoas, o padrão precisa ser mais forte: um log em que qualquer alteração retroativa seja matematicamente detectável.

Estrutura append-only com encadeamento de hash

A técnica central é simples: cada entrada do log inclui o hash da entrada anterior, formando uma cadeia. Alterar qualquer entrada no meio da cadeia muda seu hash, o que quebra a referência da entrada seguinte, tornando a alteração detectável em uma verificação de integridade.

import hashlib
import json

def hash_entrada(entrada: dict, hash_anterior: str) -> str:
    payload = json.dumps(entrada, sort_keys=True) + hash_anterior
    return hashlib.sha256(payload.encode()).hexdigest()

def registrar_decisao(decisao: dict, hash_anterior: str) -> dict:
    entrada = {
        "id": decisao["id"],
        "timestamp": decisao["timestamp"],
        "caso_de_uso": decisao["caso_de_uso"],
        "titular_id": decisao["titular_id"],
        "entrada_modelo": decisao["entrada_modelo"],
        "saida_modelo": decisao["saida_modelo"],
        "versao_modelo": decisao["versao_modelo"],
        "hash_anterior": hash_anterior,
    }
    entrada["hash"] = hash_entrada(entrada, hash_anterior)
    return entrada

Cada nova decisão referencia o hash da anterior. O primeiro registro da cadeia usa um hash-gênesis fixo e conhecido. Verificar a integridade da cadeia inteira é percorrê-la recalculando os hashes e comparando com os valores armazenados — uma operação O(n) que pode rodar como job periódico.

Âncora periódica

Encadeamento de hash prova integridade interna — que a cadeia não foi alterada depois de escrita —, mas não prova, sozinho, quando a cadeia existia. Se toda a cadeia estiver sob controle exclusivo da empresa, alguém com acesso total ao banco pode, em teoria, recalcular a cadeia inteira do zero.

Âncora periódica resolve isso publicando o hash da cadeia, em intervalos regulares (diário ou semanal), em um destino fora do controle exclusivo da empresa: um serviço de timestamping (RFC 3161), um registro público, ou simplesmente um relatório assinado enviado a um terceiro (auditor externo, cartório eletrônico). A partir do momento da publicação, qualquer tentativa de reescrever a cadeia até aquele ponto entra em conflito com a âncora publicada.

Dia 1: hash da cadeia até entrada 4.200 -> publicado em serviço de timestamping
Dia 2: hash da cadeia até entrada 4.850 -> publicado
...

Correção sem quebrar a cadeia

Decisões de IA às vezes precisam de correção — um registro foi criado com dado errado, uma classificação de risco mudou depois de revisão. Em um log append-only, a correção nunca sobrescreve o registro original; ela entra como um novo registro compensatório que referencia o registro que corrige:

{
  "id": "dec-9931",
  "tipo": "correcao",
  "corrige_id": "dec-8420",
  "motivo": "reclassificacao de risco apos revisao humana",
  "valor_anterior": {"risco": "medio"},
  "valor_corrigido": {"risco": "alto"},
  "timestamp": "2026-05-18T14:02:00Z",
  "hash_anterior": "a1f3...",
  "hash": "9be0..."
}

Isso preserva o histórico completo: qualquer consulta ao registro original mostra o valor como estava no momento da decisão, e uma consulta ao estado atual segue a cadeia de correções até o valor vigente. Nada é apagado, e o motivo da correção fica registrado tanto quanto o dado corrigido.

Retenção alinhada ao documento de negócio

O log de decisões não deve ter uma política de retenção arbitrária definida pela engenharia. A retenção precisa espelhar o que o comitê de IA e o jurídico definiram como prazo de guarda para aquele tipo de decisão — muitas vezes vinculado ao prazo legal de prescrição aplicável ou ao ciclo de vida do relacionamento com o titular.

Isso implica que o schema do log precisa carregar, por entrada, o caso de uso e, por extensão, a política de retenção aplicável — não um prazo global único para todo o sistema. Um job de expurgo remove entradas expiradas preservando a integridade da cadeia (por exemplo, substituindo o conteúdo por um marcador "expurgado por retenção" que mantém o hash original, técnica de poda com prova, análoga ao que blockchains fazem para reduzir o tamanho da cadeia sem perder verificabilidade).

Consultas por decisão, período e titular

Sem índice adequado, uma cadeia de hash é ótima para prova de integridade e péssima para consulta operacional. O desenho precisa separar as duas responsabilidades: a cadeia imutável é a fonte de verdade para integridade, e um índice de consulta (por id de decisão, por titular, por intervalo de tempo, por caso de uso) é reconstruído a partir dela, podendo ser refeito do zero a qualquer momento sem risco — porque a cadeia é a autoridade, não o índice.

CREATE INDEX idx_log_titular ON indice_consulta (titular_id, timestamp);
CREATE INDEX idx_log_caso_uso ON indice_consulta (caso_de_uso, timestamp);

Exportação para auditoria e independência de fornecedor

Um requisito frequentemente esquecido: a trilha de auditoria precisa sobreviver à troca de fornecedor de infraestrutura de IA. Isso significa que o formato de exportação não pode ser proprietário de uma plataforma específica. Um formato de exportação robusto inclui, por entrada, todos os campos necessários para verificação independente da cadeia — sem depender de nenhum sistema específico para recalcular os hashes:

export.jsonl:
{"id": "...", "hash": "...", "hash_anterior": "...", "payload": {...}}
{"id": "...", "hash": "...", "hash_anterior": "...", "payload": {...}}

Um auditor externo deve conseguir baixar esse arquivo e verificar a integridade da cadeia com um script simples, sem acesso ao sistema de origem.

O que fazer na segunda-feira

• Verifique se o log atual de decisões de IA permite UPDATE ou DELETE em registros existentes; se permitir, esse é o ponto mais urgente a corrigir.
• Implemente encadeamento de hash no log de decisões de maior risco primeiro, e amplie depois para os demais.
• Defina o mecanismo e a periodicidade de âncora externa antes de declarar o log como "auditável".
• Escreva o formato de exportação e teste com um script independente do sistema de origem, verificando se a cadeia é validável fora da plataforma.

Leitura complementar

Trilha executiva:

• Trilha de auditoria para decisões tomadas com IA — a leitura de negócio deste mesmo tema.