Controle de Mudanças em Sistemas Validados: Como Manter a Conformidade

Por que controle de mudanças é o teste real de maturidade de um programa de validação

Validar um sistema é desafiador, mas é projeto com data de início e fim. Manter o sistema validado ao longo do tempo, em meio a atualizações, customizações, mudanças regulatórias, novos requisitos de negócio e correções de bugs, é outra história. É justamente nesse momento — no controle de mudanças — que se separam programas de validação maduros dos meramente formais. Empresas com gestão de mudanças robusta atravessam inspeções da ANVISA, FDA e MHRA sem trauma. Empresas que tratam mudanças informalmente acumulam riscos silenciosos que explodem em auditorias.

O controle de mudanças em sistemas computadorizados é exigência explícita da RDC 658/2022, da IN 134/2022, do Guia 33/2020 da ANVISA e do GAMP 5 em sua segunda edição. A lógica é simples: qualquer alteração em um sistema validado pode comprometer seu estado validado. Portanto, mudanças precisam ser avaliadas, autorizadas, executadas com controle e revalidadas na proporção do impacto.

Este artigo aprofunda como estruturar um processo de change management eficiente, proporcional ao risco e alinhado às exigências regulatórias brasileiras.

O que conta como mudança em sistema computadorizado

Mudanças em sistemas computadorizados aparecem em formas variadas, e nem sempre é óbvio que se trata de mudança que demanda controle formal:

• Atualizações de versão: upgrade do ERP, patch de segurança, nova versão do banco de dados, novo service pack do sistema operacional;
• Mudanças de configuração: alteração de parâmetro, nova regra de negócio, mudança em workflow, criação de novo perfil de usuário;
• Customizações: novo programa ABAP, nova função PL/SQL, modificação em macro Excel validada, integração nova via API;
• Mudanças de infraestrutura: novo servidor, migração para nuvem, alteração de banco de dados, mudança de rede;
• Mudanças organizacionais: novos usuários, mudança de perfis, transferências internas, desligamentos;
• Mudanças regulatórias: novos requisitos da ANVISA, mudança em norma técnica, atualização de SOP;
• Mudanças de processo: novo produto, nova linha de fabricação, nova rota de distribuição que exige reconfigurar o sistema.

Todas essas categorias podem afetar o estado validado e precisam passar pelo processo formal de gestão de mudanças.

O fluxo completo de gestão de mudanças

Um processo maduro de change management para sistemas computadorizados segue passos bem definidos:

1. Requisição formal

Toda mudança começa com requisição formal, geralmente em sistema de gestão de mudanças (Change Management System) integrado ao QMS. A requisição deve conter: descrição da mudança proposta, justificativa de negócio, áreas/sistemas impactados, urgência percebida e solicitante.

2. Avaliação preliminar

Análise rápida para classificar a mudança quanto à criticidade preliminar (baixa, média, alta) e quanto à categoria (técnica, regulatória, organizacional). Mudanças críticas são encaminhadas para avaliação completa imediatamente.

3. Avaliação de impacto regulatório

Avaliação formal pela área de Qualidade, considerando: impacto sobre estado validado do sistema, impacto sobre dados regulatórios, impacto sobre integridade de dados (ALCOA+), impacto sobre conformidade com RDC 658, IN 134, Guia 33, 21 CFR Part 11 e demais regulamentos aplicáveis.

4. Definição do escopo de revalidação

Com base no impacto, define-se o escopo dos testes de revalidação:

• Mudança sem impacto GxP: documentação simplificada, sem revalidação;
• Mudança com impacto local: testes funcionais específicos da área alterada;
• Mudança com impacto sistêmico: testes funcionais ampliados, testes de regressão, possível PQ;
• Mudança estrutural: revalidação parcial ou completa, com atualização de URS, FAR, IQ/OQ/PQ e matriz de rastreabilidade.

5. Plano de execução

Documento que define: o que será feito, por quem, em que ambiente (desenvolvimento, homologação, produção), com que critérios de aceitação, com que cronograma e com que plano de contingência caso a mudança precise ser revertida.

6. Aprovação formal pré-execução

A mudança não vai a produção sem aprovação formal de: solicitante, TI, Qualidade, validação e usuário final. Aprovações eletrônicas com assinatura digital ou aprovação no QMS são o padrão moderno.

7. Execução

Implementação da mudança conforme o plano, com registros completos de cada etapa: o que foi feito, quando, por quem, com que resultados de testes. A execução em produção deve ocorrer em janela de mudança planejada.

8. Testes de validação pós-mudança

Execução dos testes definidos no escopo de revalidação. Resultados documentados, com tratamento formal de desvios encontrados.

9. Liberação final

Aprovação formal de Qualidade autorizando o uso do sistema em produção após a mudança, com atualização da documentação de validação (URS, FAR, especificações, manuais).

10. Fechamento e arquivamento

Encerramento formal da mudança, atualização do inventário de sistemas, comunicação às áreas afetadas, treinamento se aplicável.

Categorização de mudanças por risco

Empresas maduras categorizam mudanças por nível de risco/impacto para definir profundidade do processo:

• Mudança Tipo 1 (Like-for-like): substituição de componente por outro idêntico, sem impacto funcional. Documentação mínima, sem revalidação.
• Mudança Tipo 2 (Menor): ajuste de parâmetro não crítico, novo perfil de usuário, correção de bug sem impacto regulatório. Testes específicos da função.
• Mudança Tipo 3 (Maior): nova funcionalidade, mudança de regra de negócio com impacto GxP, customização significativa. Revalidação parcial com testes funcionais e regressão.
• Mudança Tipo 4 (Crítica): upgrade de versão, mudança de infraestrutura, migração de plataforma. Revalidação extensa, possivelmente completa.

A categorização não pode ser feita pelo solicitante isoladamente — Qualidade e validação devem confirmar a classificação para evitar subestimação de impacto.

Gestão de emergências e mudanças de urgência

Existem cenários em que uma mudança precisa ser implementada com urgência: vulnerabilidade crítica de segurança, falha em produção que para a operação, exigência regulatória imediata. Para esses casos, o procedimento prevê fluxo emergencial:

• Avaliação rápida de impacto por equipe reduzida;
• Aprovação preliminar por gerente sênior ou comitê de emergência;
• Execução com documentação simplificada;
• Revisão pós-fato (within 5 a 10 dias úteis) para regularizar documentação completa;
• Análise de causa raiz para entender por que houve necessidade emergencial.

Importante: mudanças de urgência devem ser exceção, não regra. Quando uma empresa começa a abrir muitas mudanças emergenciais, é sinal de que o processo regular está falhando.

Integração com gestão de configuração e desenvolvimento

O controle de mudanças se integra com outros processos:

• Gestão de configuração: registro do estado técnico do sistema (versões de software, parâmetros, customizações), atualizado a cada mudança;
• Versionamento de código: para Categoria 5, controle de versões via Git, SVN ou ferramenta equivalente, com rastreabilidade entre commits e mudanças;
• Ambientes segregados: desenvolvimento, homologação, produção, com promoção controlada entre ambientes;
• Pipelines de CI/CD: cada vez mais comuns mesmo em ambientes regulados, com automação dos testes de regressão.

Mudanças em sistemas em nuvem

Sistemas SaaS introduzem complexidade adicional. O provedor de nuvem pode aplicar atualizações sem aviso, ou com aviso curto. Para isso:

• O contrato com o provedor deve cobrir comunicação de mudanças com antecedência adequada;
• O cliente deve manter SOP específica para tratamento de mudanças do provedor;
• Testes de regressão automatizados são fortemente recomendados para detectar impactos rapidamente;
• Mudanças do provedor devem ser registradas no Change Management System como qualquer outra mudança.

Métricas e KPIs do processo de mudanças

Programas maduros monitoram métricas para sustentar melhoria contínua:

• Número de mudanças abertas, em execução, fechadas, por mês;
• Tempo médio entre abertura e fechamento, por tipo de mudança;
• Percentual de mudanças emergenciais;
• Mudanças com desvios identificados em testes;
• Mudanças que tiveram efeitos colaterais não previstos;
• Tempo entre identificação de necessidade e implantação.

Os erros mais comuns em controle de mudanças

Em auditorias e diagnósticos, vemos com frequência:

• Mudanças aplicadas em produção sem passar pelo Change Management System;
• Categoria de mudança subestimada para evitar revalidação completa;
• Aprovações eletrônicas sendo executadas por pessoa diferente do aprovador formal;
• Testes pós-mudança documentados sem evidência objetiva (prints, exports, logs);
• Documentação de validação não atualizada após mudanças (URS, FAR, matriz de rastreabilidade);
• Plano de contingência mencionado mas nunca testado;
• Mudanças emergenciais nunca regularizadas após o fato;
• Falta de comunicação às áreas afetadas, gerando problemas operacionais inesperados.

Documentação esperada em inspeções

Em inspeções da ANVISA, auditores tipicamente solicitam:

• SOP de Change Management para sistemas computadorizados;
• Lista de mudanças do último ano com classificação por tipo;
• Documentação detalhada de mudanças críticas selecionadas, incluindo avaliação de impacto, plano de execução, evidências de testes e aprovações;
• Evidências de atualização da documentação de validação após mudanças;
• Histórico de mudanças do sistema sob inspeção;
• Política de mudanças emergenciais e registros de uso recente.

Plano para implantar ou maturar o processo

Empresas que querem estruturar ou maturar o controle de mudanças devem seguir:

1. Definir SOP corporativa de Change Management aplicável a sistemas computadorizados;
2. Implementar ou configurar sistema de gestão de mudanças (idealmente no QMS já existente);
3. Definir matriz de aprovação por tipo de mudança;
4. Definir templates padronizados (formulário de avaliação, plano de execução, relatório pós-implementação);
5. Treinar todos os envolvidos (TI, Qualidade, validação, usuários-chave);
6. Estabelecer KPIs e ciclo de revisão mensal/trimestral;
7. Realizar simulação de inspeção a cada 6-12 meses para identificar lacunas.

Conclusão

Controle de mudanças é o instrumento que mantém o investimento em validação ao longo do tempo. Sem ele, programas de validação envelhecem rapidamente e perdem aderência à realidade operacional. Com ele, o sistema computadorizado permanece sob controle e adequado ao uso ao longo de toda sua vida útil.

A One Consultoria Regulatória apoia empresas na estruturação de processos de gestão de mudanças alinhados ao GAMP 5, à RDC 658/2022 e à IN 134/2022. Fale com nossa equipe para diagnóstico do seu programa de change management.