Audit trail conforme Part 11 §11.10(e): o que NÃO pode

Os 5 pecados que invalidam sua trilha perante o auditor FDA — e como o sistema certo torna cada um estruturalmente impossível.

Toda farmacêutica que opera sob 21 CFR Part 11 tem alguma forma de "audit trail". O problema é que o §11.10(e) é específico sobre o que essa trilha precisa fazer — e a maioria das implementações falha em pelo menos um dos critérios. Esse artigo destrincha o parágrafo, mostra os 5 erros mais comuns, e explica como cada um vira observação em inspeção FDA.

O texto literal do §11.10(e) exige que sistemas usados pra criar, modificar, manter ou transmitir registros eletrônicos garantam "o uso de trilhas de auditoria seguras, geradas pelo computador, com timestamp, pra registrar independentemente a data e hora de entradas e ações do operador que criem, modifiquem ou apaguem registros eletrônicos". Cada palavra importa.

Os 5 pecados que invalidam audit trail

1. Trilha desabilitável

Se existe opção na configuração que permite desligar o audit trail (mesmo só pro admin, mesmo "temporariamente pra debug"), ela viola o espírito do §11.10(e). A trilha precisa ser secure — não negociável. Sistema bem desenhado nem expõe essa opção.

2. Trilha editável após o registro

Se o admin do banco consegue dar UPDATE numa linha do audit trail sem que o próprio sistema detecte e marque, a trilha não é segura. O parágrafo exige que a trilha registre independentemente — o que implica que a alteração da trilha seria, ela mesma, registrável e detectável. Hash-chain SHA-256 resolve isso: alterar um registro quebra a cadeia, e a quebra é detectável por qualquer auditor que recalcule.

3. Timestamp do cliente, não do servidor

"Computer-generated timestamp" pra FDA significa timestamp do servidor, idealmente em UTC. Se a hora vem do navegador do usuário (que pode ser alterada), ou do horário local sem fuso, a trilha não atende ao critério de independência. O carimbo de tempo precisa vir de fonte confiável — relógio do servidor sincronizado com NTP.

4. Cobertura parcial

O §11.10(e) menciona "criar, modificar ou apagar" registros. Se sua trilha cobre só criação, mas modificações e tentativas de exclusão não aparecem, está incompleta. Pra cobrir bem: toda transação do banco que afeta um registro GxP gera entrada na trilha — não importa se foi via UI, API ou job em background.

5. Inacessível na inspeção

A trilha existir não basta. Quando o auditor pede o histórico de um registro específico, precisa sair em segundos, de forma legível. Se sua equipe leva horas pra extrair, indica que a trilha está enterrada num log que ninguém revisa. Anti-padrão clássico.

O que o §11.10(e) exige (em uma frase)

Trilha de auditoria que é (a) segura contra alteração e desativação, (b) gerada pelo computador com timestamp confiável, (c) registrando independentemente toda criação, modificação e exclusão de registro GxP, (d) recuperável e legível durante todo o período de retenção, (e) revisável em formato que permita inspeção.

Como o NOAH OS atende

• Trilha sem botão de desligar — não há opção, em UI ou config, pra desabilitar.
• Hash-chain SHA-256 — toda alteração quebra a cadeia, e a quebra é detectável por verificação independente fora do sistema.
• Timestamp do servidor em UTC — relógio sincronizado com NTP, marcado em cada evento.
• Cobertura total — triggers de banco garantem que toda alteração em tabela GxP gera entrada, mesmo via SQL direto.
• Relatório por registro em segundos — UI mostra histórico completo, e exporta CSV/JSON pro auditor levar.