ALCOA+ e hash-chain: a evidência que o inspetor consegue verificar

Por que "ter audit trail" não é o mesmo que integridade de dados de verdade.

Quase toda farmacêutica brasileira que faz alguma coisa de digital diz "tem audit trail". O problema é que essa frase, sozinha, não significa quase nada. Um arquivo de texto com timestamps "tem audit trail". Uma planilha com macro "tem audit trail". Um sistema enterprise que registra eventos num log que o próprio admin pode editar "tem audit trail". E todos os três falham na pergunta que importa: o auditor consegue verificar que esses registros não foram alterados depois?

Esse artigo é sobre a diferença entre ter audit trail e ter audit trail que sobrevive à inspeção. A ponte entre os dois se chama hash-chain — e ele existe há mais de 30 anos no mundo de criptografia. Vale entender, porque é exatamente isso que separa um sistema GxP sério de um teatro de compliance.

ALCOA+ não é um framework, é a pergunta de cada inspetor

ALCOA+ (Atribuível, Legível, Contemporâneo, Original, Acurado, mais Completo, Consistente, Duradouro, Disponível) é o critério que FDA, ANVISA e EMA usam pra julgar se um dado merece confiança. Não é uma certificação que você obtém — é uma pergunta que o inspetor faz, registro por registro, durante a inspeção. E quando o sistema não consegue responder a um desses 9 critérios para um achado específico, o achado vira observação.

O ponto cego de quase toda implementação que vejo é o "O" de Original e o "A" de Acurado. Esses dois exigem que o dado original seja preservado, que toda alteração seja registrada com motivo, e — o mais difícil — que o auditor consiga verificar que o registro que ele está vendo agora é o mesmo que foi feito naquele momento, ou que toda mudança está documentada. Se o sistema permite que o admin (ou um atacante) altere a trilha sem deixar rastro, ALCOA+ falha. Ponto.

O que é um hash-chain — e por que ele resolve isso

Um hash criptográfico é uma função matemática que pega qualquer dado e produz uma string de tamanho fixo (no caso do SHA-256, sempre 256 bits, ou 64 caracteres hexadecimais). Pequenas mudanças no input geram outputs completamente diferentes. E mais importante: dado o hash, é praticamente impossível recuperar o input original — ou achar dois inputs que geram o mesmo hash.

Um hash-chain aplica isso em sequência. Cada registro de audit trail carrega, junto com seus dados, o hash do registro anterior. O resultado é uma cadeia matemática onde cada elo "trava" o anterior:

Se alguém alterar qualquer registro no meio da cadeia, todos os hashes posteriores deixam de fechar. A quebra é detectável por qualquer pessoa que recalcule a cadeia — incluindo o auditor.

É exatamente assim que blockchain funciona, mas a aplicação aqui é muito mais simples: não há mineração, não há consenso distribuído. Só uma sequência cronológica de hashes encadeados, gravada no banco junto com cada evento.

Por que o auditor consegue verificar — sem confiar no fornecedor

A grande virada do hash-chain pra inspeção é que ele é verificável fora do sistema. O inspetor não precisa acreditar no fornecedor. Ele pode:

1. Exportar o audit trail completo em formato simples (CSV ou JSON).
2. Pegar o primeiro registro, calcular o SHA-256 dos seus dados, comparar com o hash gravado.
3. Repetir pra cada registro subsequente, concatenando o hash anterior conforme a regra documentada.
4. Se a cadeia fecha do começo ao fim, o conjunto é íntegro. Se quebra em algum ponto, há alteração não declarada.

Essa verificação pode ser feita com um script de 20 linhas em Python — não depende do NOAH OS estar rodando, nem do fornecedor cooperar. É o equivalente criptográfico de uma assinatura à mão em papel que não pode ser falsificada sem que isso seja óbvio.

O que muda na prática pro time de qualidade

Pra um QA experiente, o impacto é prático e imediato:

• Em inspeção: quando o inspetor pede o histórico de qualquer registro, ele vem com os hashes encadeados. Se ele quiser, valida na hora.
• Em CAPA: o ciclo achado → ação → eficácia tem cada passo gravado num elo da cadeia. Ninguém edita "depois" sem deixar rastro.
• Em assinatura: cada assinatura eletrônica inclui o hash do conteúdo assinado. Se o conteúdo muda, a assinatura para de fechar — o que é exatamente o que a 21 CFR Part 11 §11.50(a) exige.
• Em backup e restore: quando você restaura um backup, a cadeia continua íntegra porque os hashes vieram junto. Você prova continuidade.

Os 4 erros que invalidam o seu hash-chain

Mesmo quem implementa um hash-chain pode comprometê-lo. Vou listar os 4 que mais aparecem:

1. Calcular o hash só sobre parte do registro

Se o hash cobre só "quem fez" e "quando", mas não o conteúdo da ação, o atacante muda o conteúdo e a cadeia continua válida. O hash precisa cobrir todo o registro, incluindo metadados.

2. Não vincular cada hash ao anterior

Sem o link, cada registro fica auditável individualmente mas a sequência não. Alguém pode deletar um registro inteiro do meio sem detecção. Cada hash precisa incluir o hash anterior como input.

3. Permitir reescrita do banco sem propagar o recálculo

Se o admin do banco consegue fazer um UPDATE direto e o sistema não recalcula, a cadeia fica desatualizada mas "fechada" do ponto onde foi mexido. Triggers de banco ou uma camada de aplicação com WORM (write-once, read-many) blindam isso.

4. Não publicar a chain-tip externamente

O melhor controle é publicar o hash do último registro (chain-tip) em algum lugar imutável — um log público, um e-mail diário pra equipe, ou idealmente um carimbo de tempo confiável. Aí, mesmo um admin que reescreve tudo não consegue esconder que reescreveu, porque o chain-tip de ontem está num lugar que ele não controla.

Como o NOAH OS implementa

O NOAH OS faz isso por desenho. Cada evento (criação, edição, aprovação, assinatura, exclusão lógica) gera um registro de audit trail que inclui o hash SHA-256 do conteúdo do evento + o hash do registro anterior. A cadeia é gravada com triggers de banco que tornam impossível atualizar uma linha sem que o sistema recalcule — o admin do banco não consegue burlar sem deixar rastro óbvio. A chain-tip atual pode ser exportada a qualquer momento, e existe uma ferramenta CLI que recalcula a cadeia inteira sobre o export, devolvendo "íntegra" ou apontando o registro exato onde quebrou.

O resultado: quando o inspetor pede a evidência, ele recebe um arquivo que ele mesmo pode validar — sem precisar acreditar em ninguém. Esse é o critério mínimo de ALCOA+ aplicado a sério.