FDA · Form 483

Os 12 erros mais comuns em Form 483

Em sistemas computadorizados GxP — e como blindar cada um antes do auditor pisar na fábrica.

Por Immunoterapêutica202610 min de leitura

O Form 483 é a lista de observações que o inspetor da FDA registra ao encontrar não-conformidade durante uma inspeção. A ANVISA emite observações equivalentes em estrutura. Quando você analisa centenas de 483 dos últimos 5 anos relacionados a sistemas computadorizados, padrões aparecem. Os mesmos 10–12 erros se repetem em farmacêuticas grandes e pequenas, multinacional e nacional.

Este artigo lista os 12 mais frequentes. Em cada um: o que o auditor literalmente vê, qual cláusula do 21 CFR Part 11 (ou RDC 658/2022) está sendo violada, e como um sistema desenhado pra GxP torna a falha estruturalmente impossível.

1. Assinatura eletrônica que é só nome digitado

O auditor vê: um campo de texto com o nome do signatário, sem reautenticação, sem timestamp confiável, sem significado declarado. Viola §11.50 e §11.200.

Como blindar: assinatura exige reauth, captura significado obrigatório de enum, e grava hash do conteúdo no momento.

2. Audit trail editável ou desativável

O auditor vê: log armazenado em tabela que o admin pode dar UPDATE/DELETE. Ou pior: opção na configuração que permite "limpar logs antigos". Viola §11.10(e).

Como blindar: tabela WORM (write-once via triggers), hash-chain SHA-256 que detecta qualquer alteração, e zero opção de UI pra desligar.

3. Sem controle de versão — ninguém sabe o SOP vigente

O auditor vê: duas versões da mesma SOP circulando em pastas diferentes, ou planilha cuja revisão foi sobrescrita perdendo o histórico.

Como blindar: versão única vigente no sistema, versões anteriores marcadas como obsoletas e bloqueadas, com histórico imutável do que mudou e por quê.

4. Treinamento na versão errada do procedimento

O auditor vê: operador treinado na revisão 2, mas a SOP vigente é revisão 3. O sistema não dispara re-treinamento quando a SOP muda.

Como blindar: matriz por cargo, "lido e compreendido" vinculado à versão específica, e disparo automático de re-treino quando o documento sobe de versão.

5. Usuário compartilhado

O auditor vê: login "qualidade01" sendo usado por 4 analistas. Impossível atribuir uma ação específica a uma pessoa específica. Viola §11.100 e ALCOA+ Atribuível.

Como blindar: credencial única por pessoa (CPF como identificador único é boa prática brasileira), MFA opcional, e RBAC granular por função.

6. CAPA sem evidência datada de fechamento eficaz

O auditor vê: CAPA marcada como "fechada" mas sem registro de verificação de eficácia, sem data, sem responsável. A ação corretiva está documentada, mas ninguém validou se ela funcionou.

Como blindar: ciclo CAPA exige etapa de verificação de eficácia com data, responsável, evidência anexada e assinatura, antes de aceitar status "closed".

7. Dado original sobrescrito

O auditor vê: valor de um lote alterado sem preservar o original. A planilha foi editada, salva, e o valor anterior se foi. Viola "O" do ALCOA+.

Como blindar: sistema preserva o valor original e registra a alteração com motivo. UI mostra "valor atual + histórico de alterações" lado a lado.

8. Backup nunca testado com restauração real

O auditor vê: backup rodando há anos, sem nenhum registro de que alguma vez foi restaurado pra verificar que funciona. Viola §11.10(c) e Annex 11 cl. 7.1.

Como blindar: teste de restauração agendado e documentado em ciclo definido (geralmente trimestral), com evidência arquivada.

9. Sistema "comprado, não validado"

O auditor vê: software em uso GxP sem URS, sem análise de risco, sem IQ/OQ/PQ, sem VSR. A empresa "confia" no fornecedor mas não tem pacote próprio. Viola §11.10(a).

Como blindar: validação executada no ambiente do cliente, com pacote documentado e mantido sob controle de mudança.

10. Acesso de quem já saiu da empresa ainda ativo

O auditor vê: ex-funcionário com login ativo meses ou anos após o desligamento. Permitiria acesso indevido — viola §11.10(d) e RDC 658 Art. 9 §3.

Como blindar: integração com RH dispara desativação imediata. Revisão trimestral documentada de acessos.

11. Registro feito "depois, de memória"

O auditor vê: operador anotando dados num caderno e digitando no sistema no fim do turno. Viola "C" do ALCOA+ (Contemporâneo).

Como blindar: registro no momento do evento. Sistema carimba timestamp do servidor. Onde precisar de entrada offline (campo, produção), uso de tablets com sincronização e ressalva.

12. Relatório de audit trail que não sai na hora

O auditor vê: pede o histórico de um registro específico e a equipe leva horas (ou dias) pra montar. Indica que a trilha não é acessível por desenho. Viola §11.10(e).

Como blindar: relatório por registro disponível em segundos via UI, exportável em formato simples (CSV/JSON) pro auditor levar e validar.

A verdade dura

9 dos 12 são estruturalmente impossíveis num sistema desenhado pra Part 11 + RDC 658 desde a primeira linha. Os outros 3 (8, 10 e 11) são processo: dependem de você executar. Se você está num sistema onde mais de 3 desses 12 ainda dependem da disciplina do seu time, está jogando com sorte na próxima inspeção.

Quer ver os 9 blindados pelo NOAH?

Em 30 minutos pelo WhatsApp, mostramos exatamente como cada um dos 9 estruturais é impossível no NOAH OS — e como te orientamos nos outros 3 que dependem de processo.

Agendar demo