Categorias GAMP 5: Cat 1 a Cat 5 com exemplos reais

A categoria certa define o esforço de validação. A categoria errada destrói o orçamento ou — pior — passa por uma inspeção rasa que volta como achado.

A primeira pergunta que todo plano de validação deveria responder é "qual categoria GAMP esse software se encaixa?". A resposta direciona o nível de documentação, o tipo de testes, e a granularidade dos protocolos IQ/OQ/PQ. Cliente que erra a categoria gasta o triplo ou — pior — entrega um pacote frágil que não sustenta inspeção.

Esse artigo explica as categorias 1, 3, 4 e 5 do GAMP 5 (2ª edição, 2022), com exemplos do que entra em cada uma e como ajustar a estratégia de validação a cada faixa.

Categoria 1 — Infraestrutura

O que é: sistemas operacionais, bancos de dados, runtime de containers, ferramentas de monitoramento. Software que dá suporte mas não é o sistema GxP em si.

Exemplo: Windows Server, Linux, PostgreSQL, Docker, Nginx.

Estratégia de validação: qualificação do ambiente (IQ), não validação por casos de uso. Verifica versão, configuração de hardening, backup, monitoramento. Documenta uma vez, mantém ao longo do ciclo de vida.

O erro clássico: tratar infraestrutura como Cat 4 e gastar tempo escrevendo casos de teste pro Postgres. Não faz sentido — o vendor já validou.

Categoria 3 — Software de prateleira não configurável

O que é: software comercial usado sem customização. O comportamento é definido pelo fabricante e o cliente apenas usa.

Exemplo: calculadora de planilha eletrônica simples, leitor de PDF, software de backup off-the-shelf.

Estratégia de validação: avaliação de fornecedor (vendor assessment) + testes de aceitação cobrindo os fluxos GxP-críticos. Não precisa de URS detalhada — o sistema é fixo e a abordagem é "verifico o que ele entrega".

Categoria 4 — Software configurável

O que é: software comercial que é configurado (não programado) pelo cliente. Configuração via interface administrativa ou arquivos. A funcionalidade central é do fabricante, mas o workflow ou as regras de negócio são do cliente.

Exemplo: eQMS de mercado configurado pra processos do cliente, ERP em farma, LIMS, sistemas de building management.

Estratégia de validação: esforço cheio. URS, FS/DS, análise de risco, IQ, OQ, PQ. A configuração específica do cliente vira foco do OQ — porque é onde mora a customização.

É a categoria que mais aparece em farma brasileira (incluindo eQMS). Veja o detalhamento de IQ/OQ/PQ pra entender o caminho de execução.

Categoria 5 — Software customizado

O que é: software desenvolvido sob medida pelo cliente ou por um fornecedor, com código específico daquela operação. Inclui scripts customizados, macros complexas de planilha, sistemas legados internos.

Exemplo: sistema interno de batch records, software escrito por TI da própria empresa, scripts de cálculo regulado.

Estratégia de validação: a mais rigorosa. Inclui revisão de código, testes unitários, integração contínua, change control rigoroso, ciclo de vida de desenvolvimento documentado. SDLC inteiro precisa estar sob controle GxP.

A categoria não é estática

O ponto que muita gente perde: uma configuração avançada pode elevar a categoria. Se você customiza tanto um Cat 4 que ele virou praticamente código novo — o auditor pode tratar como Cat 5.

Exemplos típicos:

• Workflow tão personalizado que perdeu o template original
• Scripts injetados que mudam a lógica do produto
• Integrações via API que executam regras de negócio próprias

Esses casos precisam de avaliação de risco específica e geralmente exigem testes adicionais.

A pegadinha do "qual categoria?" no eQMS

eQMS quase sempre é Cat 4 (configurável). Mas o auditor não aceita só "é Cat 4, foi validado". Ele quer ver:

• Quais configurações específicas foram feitas?
• Como o vendor garante que upgrades futuros não quebram a configuração?
• O cliente conseguiu reproduzir os testes do vendor no ambiente próprio?

Isso é exatamente o que o PQ executa — não basta confiar no IQ/OQ do fornecedor.

Validado de fábrica vs. validado no cliente

Software entregue "validado de fábrica" significa que IQ + OQ vêm executados pelo fornecedor. O cliente executa apenas o PQ no seu ambiente, com sua configuração específica. Isso reduz custo e tempo (de meses pra semanas) sem reduzir rigor — desde que o pacote do vendor seja auditável.

O custo total cai dramaticamente quando o cliente não precisa contratar consultoria pra refazer IQ/OQ que o fornecedor já fez.