Por que análise de risco é o coração da validação moderna de sistemas computadorizados
A análise de risco formal é o instrumento que separa a validação moderna — proporcional, baseada em ciência e em pensamento crítico — da validação antiga, baseada em listas de verificação massivas e documentação inútil. Tanto o GAMP 5 em sua segunda edição de 2022 quanto a RDC 658/2022, a IN 134/2022 e o Guia 33/2020 da ANVISA colocam a análise de risco no centro do programa de validação, alinhados ao framework conceitual do ICH Q9 (Quality Risk Management).
Na prática, isso significa que cada decisão sobre escopo de testes, profundidade de qualificação, frequência de revisão e estratégia de revalidação deve ser fundamentada em uma análise estruturada que considere severidade do impacto, probabilidade de ocorrência da falha e detectabilidade. Validar sem análise de risco real é desperdiçar recursos; analisar risco sem reflexo na validação é encher relatório.
Este artigo aprofunda como construir e operacionalizar uma análise de risco aplicável a sistemas computadorizados em indústrias farmacêuticas, dispositivos médicos e operadores logísticos regulados.
ICH Q9 e o ciclo de gestão de risco da qualidade
O ICH Q9 — Quality Risk Management — é o documento internacional que define o framework conceitual para gestão de risco em ambientes regulados. Publicado originalmente em 2005 e revisado em 2023 (ICH Q9 (R1)), ele estrutura o processo em fases:
- Identificação do risco: o que pode dar errado?
- Análise do risco: qual a probabilidade e qual o impacto?
- Avaliação do risco: o nível de risco é aceitável? Comparado a critérios pré-estabelecidos.
- Controle do risco: mitigação por design, controle ou aceitação justificada.
- Comunicação e revisão: documentação formal e revisão periódica conforme mudanças.
Essa estrutura é universal: aplica-se a riscos de processo, de produto, de fornecedor e — no nosso caso — a riscos de sistemas computadorizados.
FMEA: a metodologia mais aplicada em CSV
Entre as várias técnicas de análise de risco (FMEA, FTA, HACCP, HAZOP, Bow-Tie), a Failure Mode and Effects Analysis (FMEA) é, sem dúvida, a mais aplicada em validação de sistemas computadorizados no Brasil. O FAR (Formulário de Análise de Risco) utilizado em protocolos QIOD é tipicamente uma adaptação de FMEA com pontuações de severidade, probabilidade e detectabilidade.
A pontuação típica usa escalas de 1 a 5 ou 1 a 10 para cada dimensão:
- Severidade (S): gravidade do impacto se a falha ocorrer. Escala que vai de “impacto cosmético” até “risco direto ao paciente”.
- Probabilidade (P): chance de ocorrência da falha. Escala que vai de “extremamente improvável” até “ocorrência frequente”.
- Detectabilidade (D): capacidade de detectar a falha antes que ela cause impacto. Escala invertida: 1 = facilmente detectável, 10 = praticamente indetectável.
O Risk Priority Number (RPN) é o produto S × P × D. Itens com RPN acima de um limite definido (geralmente 60-100 em escala 1-10, ou 30-50 em escala 1-5) demandam controles formais, mitigações ou rejeição da configuração proposta.
Como aplicar FMEA em sistemas computadorizados
A FMEA em CSV tem particularidades importantes:
Granularidade da análise
Não se analisa “o sistema” como um todo — analisa-se cada funcionalidade GxP. Para um ERP, por exemplo, isso pode significar 50, 100, 200 linhas de FAR, cobrindo desde “cadastro de material” até “emissão de certificado de análise”.
Vínculo com URS
Cada item da FAR deve estar vinculado a um requisito da URS. Esse vínculo é a coluna vertebral da matriz de rastreabilidade, garantindo que os riscos identificados realmente reflitam os requisitos do negócio.
Tipos de falha em sistemas computadorizados
As falhas típicas em sistemas computadorizados podem ser classificadas em algumas categorias:
- Falha de cálculo (resultado incorreto);
- Falha de configuração (parâmetro ou regra mal definida);
- Falha de acesso (usuário sem permissão executa ação, ou usuário autorizado é bloqueado);
- Falha de integridade (dados perdidos, corrompidos, alterados);
- Falha de integração (dados não transferidos corretamente entre sistemas);
- Falha de disponibilidade (sistema indisponível em momento crítico);
- Falha de auditabilidade (ação não registrada na trilha de auditoria).
Mitigações e controles
Para cada risco com RPN acima do limite, define-se ação:
- Mitigação por design: alteração de configuração ou customização para eliminar a falha;
- Controle preventivo: bloqueio técnico (validação de entrada, perfil restrito, alarme);
- Controle detectivo: relatório, alerta, revisão periódica que identifica falha após o fato;
- Procedural: SOP que orienta operação correta;
- Aceitação justificada: risco residual aceitável, com justificativa documentada.
Vinculando análise de risco a testes de qualificação
A FAR não pode ser documento isolado. Ela deve orientar diretamente os testes de OQ/PQ. Para cada risco identificado, deve haver caso de teste que verifique:
- O cenário positivo (a função funciona corretamente);
- O cenário negativo (a função bloqueia tentativas inválidas);
- O cenário de limite (operações no limite dos critérios de aceitação);
- O cenário de erro (comportamento do sistema diante de entrada inesperada).
A matriz de rastreabilidade liga URS → FAR → casos de teste → resultados de execução, formando o tecido lógico da validação.
Os erros mais comuns em análises de risco
Em diagnósticos que conduzimos:
- FAR como documento decorativo: preenchida apenas para cumprir requisito, sem refletir na estratégia de testes;
- Granularidade inadequada: análise feita em nível de “módulo” inteiro, sem detalhamento funcional, perdendo riscos específicos;
- Pontuação subjetiva sem critérios: cada participante atribui pontuação diferente sem padronização, gerando resultados inconsistentes;
- Mitigações genéricas: “fazer SOP” como mitigação universal, sem definir conteúdo específico;
- Falta de revisão: FAR criada na implantação, nunca revisada após mudanças significativas;
- Sem participação do usuário final: análise feita apenas por TI ou consultor, sem entender o uso real da função;
- Falta de aprovação formal: documento concluído sem assinatura formal de Qualidade, TI, validação e usuário.
Análise de risco e o ciclo de vida do sistema
A análise de risco não é exercício único na implantação. Ela é revisada e atualizada em momentos definidos:
- Antes de mudanças significativas: nova versão do sistema, novo módulo, mudança de fornecedor, alteração de processo de negócio;
- Após incidentes ou desvios: a investigação de causa raiz frequentemente identifica novos riscos não previstos;
- Em revisões periódicas: tipicamente anual para sistemas críticos, com checagem de aderência da análise à realidade operacional;
- Antes da aposentadoria do sistema: análise de riscos do processo de descomissionamento, especialmente quanto à retenção de dados regulatórios.
Análise de risco em sistemas em nuvem
Sistemas hospedados em nuvem (SaaS, IaaS, PaaS) introduzem categorias adicionais de risco que precisam ser endereçadas na FAR:
- Risco de disponibilidade do provedor (downtime do AWS, Azure, GCP);
- Risco de localização de dados (servidores fora do Brasil, implicações de LGPD e regulação setorial);
- Risco de descontinuação do serviço (provedor encerra a oferta);
- Risco de segurança em interface compartilhada;
- Risco de migração futura (lock-in tecnológico);
- Risco de auditabilidade limitada (acesso restrito a logs internos do provedor).
O GAMP 5 (2ª edição) introduziu o conceito de responsabilidade compartilhada, em que cliente e provedor de nuvem dividem responsabilidades claramente. A FAR deve refletir essa divisão, com riscos atribuídos à parte responsável.
Análise de risco e CSA (Computer Software Assurance)
A iniciativa Computer Software Assurance da FDA (com guidance publicada em setembro de 2022) reforça a abordagem baseada em risco e pensamento crítico. O CSA não substitui o GAMP 5 — ele orienta como executar validação de forma proporcional e eficiente. Empresas brasileiras que aplicam GAMP 5 corretamente já estão alinhadas com a filosofia CSA.
A diferença prática é que CSA enfatiza:
- Esforço onde o risco está, não em todos os pontos uniformemente;
- Uso intensivo de testes automatizados, exploratórios e baseados em comportamento;
- Aproveitamento da documentação do fornecedor (vendor assurance);
- Menos documentação burocrática, mais evidência funcional.
Ferramentas e templates para análise de risco
Empresas maduras usam ferramentas e templates padronizados:
- Templates de FAR aprovados como SOP, com instruções claras de preenchimento;
- Escalas de pontuação calibradas e documentadas, com exemplos para cada nível;
- Planilhas validadas ou ferramentas dedicadas (Excel macroprogramado, MS Access, ou ferramentas comerciais como ValGenesis, Kneat, IQVIA RIM);
- Workflow de aprovação eletrônica integrado ao sistema de gestão documental;
- Revisão por pares como parte do fluxo, garantindo qualidade da análise.
Documentação esperada em inspeções
Em inspeções da ANVISA, auditores tipicamente pedem:
- SOP de gestão de risco da qualidade aplicável a sistemas computadorizados;
- Análise de risco do sistema sob inspeção (FAR completa);
- Matriz de rastreabilidade ligando análise de risco a testes executados;
- Evidências de revisão periódica da análise de risco;
- Histórico de atualizações da FAR após mudanças e desvios;
- Aprovações formais por Qualidade, TI e usuário.
Conclusão
Análise de risco é o instrumento que transforma validação de sistemas computadorizados de exercício burocrático em garantia real de qualidade e conformidade. Bem aplicada, ela direciona recursos para onde realmente importam, justifica decisões em inspeções e mantém o sistema sob controle ao longo do tempo. Mal aplicada — ou inexistente — fragiliza todo o programa de validação.
A One Consultoria Regulatória apoia indústrias farmacêuticas e operadores logísticos regulados na estruturação de análises de risco robustas, alinhadas a GAMP 5, ICH Q9, RDC 658/2022 e Guia 33 da ANVISA. Fale com nossa equipe para diagnóstico do seu programa de gestão de risco em CSV.