21 CFR Part 11 na prática: assinatura com significado do ato

O que o inspetor verifica numa assinatura eletrônica, e por que "nome digitado num campo" não conta.

Quase toda farmacêutica que adota um sistema digital pra controlar processos GxP descobre, um pouco tarde demais, que existe uma diferença gigante entre "assinatura eletrônica que funciona" e "assinatura eletrônica conforme 21 CFR Part 11". A diferença não é técnica nem cara de implementar. É de desenho. E quem ignora descobre o problema na primeira inspeção da FDA — geralmente sob a forma de uma observação no Form 483 que cita literalmente o §11.50.

Esse artigo desmonta o que o Part 11 exige em assinatura, parte por parte, e mostra o que precisa estar no sistema pra atender. Não é texto pra advogado regulatório — é texto pra QA, RA e arquiteto de software que precisa fazer a decisão certa antes de assinar contrato.

O que o Part 11 chama de assinatura eletrônica

O 21 CFR Part 11 define assinatura eletrônica como "qualquer combinação de símbolos eletrônicos executada, adotada ou autorizada por um indivíduo como o equivalente legal de uma assinatura manuscrita". Note que a definição é deliberadamente ampla — ela não diz que precisa ser biometria ou certificado digital. Pode ser um par usuário+senha, desde que cumpra as garantias específicas dos parágrafos seguintes.

O ponto crucial vem em §11.200, que exige que cada assinatura eletrônica seja única para um indivíduo, não pode ser reutilizada por outra pessoa, e exige o uso de pelo menos dois componentes (ex.: identificador + senha) na primeira assinatura de uma sessão. As assinaturas subsequentes dentro da mesma sessão podem usar só um componente (a senha), desde que a sessão tenha sido controlada.

O parágrafo que mais reprova: §11.50

Se eu pudesse escolher um único parágrafo do Part 11 pra estudar em detalhe, seria o §11.50. Ele exige que toda assinatura eletrônica de um registro inclua três informações impressas e ligadas ao registro:

1. O nome impresso do signatário.
2. A data e hora em que a assinatura foi executada.
3. O significado associado à assinatura — por exemplo: revisão, aprovação, responsabilidade, autoria.

O item 3 é o que falha em 90% das implementações. Quando o sistema só registra "Fulano assinou", sem dizer se foi revisão, aprovação, execução, ou recebimento, ele não cumpre o §11.50. E quando o auditor pega o relatório do documento aprovado e vê só "assinado por Fulano em 12/03/2026 às 14:32", a observação é direta: "The significance of the signature was not displayed".

Assinatura sem significado declarado é, do ponto de vista do Part 11, equivalente a assinar um cheque em branco. Funciona até alguém perguntar o que aquela assinatura significa.

O que é "significado do ato" na prática

O significado precisa ser explícito e tem que estar amarrado à transição que está sendo executada. Numa SOP que segue o ciclo Rascunho → Revisão → Aprovação → Vigente, cada transição exige uma assinatura com um significado diferente:

• Revisor: "Revisei o conteúdo e concordo que está pronto para aprovação."
• Aprovador: "Aprovo este documento para uso em produção GxP."
• Executor: "Executei este procedimento conforme descrito e os resultados estão registrados."

O sistema precisa armazenar esse significado, exibi-lo em qualquer relatório que liste a assinatura, e — fundamental — vincular a assinatura ao conteúdo específico que foi assinado. Se o conteúdo mudar depois, a assinatura tem que perder validade. É exatamente isso que §11.70 exige: o link entre assinatura e registro tem que ser robusto contra alterações posteriores.

Como o NOAH OS implementa

O NOAH foi desenhado contra esses parágrafos desde a primeira linha de código. Cada assinatura eletrônica no sistema:

• Exige reautenticação — não basta estar logado, o usuário digita a senha novamente. Isso atende §11.200(a)(2).
• Captura significado obrigatório de um conjunto enumerado (REVIEWED, APPROVED, EXECUTED, REJECTED, ACKNOWLEDGED), nunca texto livre. Atende §11.50(a)(3).
• Calcula o hash SHA-256 do conteúdo no momento da assinatura e grava junto. Se o conteúdo mudar 1 byte depois, a assinatura para de fechar. Atende §11.70.
• Aplica two-person rule: o mesmo usuário não pode revisar e aprovar o próprio documento. Atende boas práticas de segregação de função (FDA Guidance 2003).
• Registra identidade, timestamp do servidor (UTC), significado, hash do conteúdo e hash do registro anterior no audit trail hash-chain. Atende §11.50 + §11.10(e).

5 perguntas pra fazer ao seu sistema atual

Antes de aceitar que sua implementação "atende Part 11", pergunte:

1. Se eu gerar um relatório do documento aprovado, ele mostra explicitamente se aquela assinatura foi revisão ou aprovação?
2. Se eu alterar uma vírgula no conteúdo do documento depois de assinado, a assinatura é invalidada automaticamente?
3. O usuário consegue assinar sem digitar a senha de novo (só clicando "Aprovar")? Se sim, viola §11.200.
4. O mesmo usuário pode revisar e aprovar o mesmo documento? Se sim, viola two-person rule.
5. Quando exporto o relatório de auditoria, dá pra reconstruir matematicamente cada assinatura sem confiar no sistema?

Se a resposta de qualquer uma é "não" ou "não sei", você tem um problema que vai aparecer na próxima inspeção.