CSV: Periodic Review e Change Control come finding ricorrenti

Un sistema non e considerato validato in un audit per il fatto che al go-live e presente un report di validazione firmato. E considerato validato fintanto che lo stato documentato corrisponde allo stato reale. Questa distinzione e il nucleo della maggior parte dei finding di Annex 11: la qualifica iniziale e corretta, ma tra il go-live e la successiva ispezione intercorrono due anni di operativita in cui nessuno ha mantenuto lo stato di validazione.

L'equivoco: "validato" e una data, non uno stato

La Computer System Validation (CSV) viene gestita in molte organizzazioni come un progetto. Esiste un piano di validazione, un'analisi del rischio, i cicli di qualifica IQ, OQ e PQ e infine un report con rilascio. Con cio l'introduzione e completata, il team di progetto si scioglie e il sistema passa all'operativita.

Il EU-GMP-Leitfaden Annex 11 (Computerised Systems) tratta però lo stato validato come un ciclo di vita, non come una data precisa. Due sezioni lo rendono esplicito:

• Sezione 11 (Periodic evaluation) richiede che i sistemi computerizzati vengano valutati periodicamente per confermare che si trovino ancora in stato validato e soddisfino Annex 11.
• Sezione 10 (Change and Configuration Management) richiede che ogni modifica a un sistema validato sia gestita attraverso una procedura definita con valutazione dell'impatto.

Chi intende la CSV come un'unica chiusura di progetto soddisfa entrambe le esigenze il giorno del rilascio e le perde progressivamente in seguito. Esattamente questa perdita diventa visibile nell'audit.

Periodic Review: la lacuna più frequente dopo la qualifica iniziale

La valutazione periodica e la routine che documenta lo stato validato durante il ciclo di vita di un sistema. Verifica cosa e cambiato dall'ultima valutazione: modifiche, deviazioni, CAPA aperte, valutazioni dell'audit trail, incidenti, modifiche agli utenti e alle autorizzazioni. La frequenza non e fissata, ma va stabilita in modo risk-based, spesso annuale o biennale, graduata in base alla criticita GxP.

Nella pratica questa review dopo la qualifica iniziale spesso non viene eseguita. Pattern tipici:

• Non esiste una procedura con trigger e responsabilita, cosicche nessuno avvia la review nei tempi.
• La review viene eseguita, ma come pura conferma formale senza un effettivo confronto target/effettivo della storia del sistema.
• La valutazione copre solo una parte dei sistemi GxP-rilevanti, perché il catalogo di sistema e incompleto.

Il risultato e un sistema nominalmente validato, il cui stato di validazione non e però più dimostrabile. All'ispezione il revisore trova la discrepanza tra documentazione e realta nello stesso momento dell'azienda - con la differenza che la registra come finding.

Change Control: la storia lacunosa come major finding

Ancora più immediatamente critica e la storia del Change Control. La Sezione 10 richiede che le modifiche ai sistemi validati avvengano in modo controllato, inclusa una valutazione dell'entita della riqualifica necessaria. L'errore più frequente non e l'elusione consapevole di questo processo, ma la classificazione delle routine tecniche come non rilevanti ai fini regolamentari.

Una patch software, un aggiornamento del sistema operativo, una modifica della configurazione o un aggiornamento da parte del produttore vengono trattati come operazioni IT amministrative e introdotti al di fuori del Change Control. Manca il Impact Assessment che risponde alla domanda: questa modifica tocca funzioni GxP-rilevanti, e quale parte del sistema deve essere riqualificata? Nel corso dei mesi si crea così una storia in cui lo stato documentato e quello reale del sistema divergono.

Nel contesto ispettivo questa lacuna e difficile da colmare, perché non può essere generata retroattivamente: una storia di Change Control non tenuta durante l'operativita non può essere documentata a posteriori. Appartiene quindi regolarmente ai major finding dei sistemi validati. Dove in aggiunta l'Audit Trail secondo la Sezione 9 non e attivato o non viene mai valutato, il rilievo sul Change Control si combina con un rilievo sull'integrita dei dati.

Risk-based anziche a pioggia: GAMP 5

Maggiore impegno nella validazione non significa automaticamente maggiore conformita. GAMP 5 (ISPE, A Risk-Based Approach to Compliant GxP Computerized Systems, 2a edizione 2022) gradua lo sforzo in base alla categoria di sistema: dal software standard ai prodotti configurati come LIMS o ERP fino allo sviluppo personalizzato. Una categorizzazione errata ha costi in entrambe le direzioni.

• Eccessiva validazione vincola risorse su sistemi standard non critici che mancano altrove.
• Validazione insufficiente fa entrare in operativita un sistema GxP-critico con una copertura di test inadeguata - un rischio regolamentare.

Questa logica vale non solo all'introduzione, ma determina anche l'intensita di Periodic Review e riqualifica per ogni sistema. Una solida classificazione del rischio e quindi il presupposto affinche l'operativita CSV continuativa rimanga proporzionata.

Annex 22: i sistemi AI richiedono un quadro esteso

Per i sistemi basati su AI e ML nei processi GxP - ad esempio nel controllo della qualità, nei sistemi di laboratorio o nel controllo della produzione - il classico quadro CSV non sara prevedibilmente sufficiente. Il EU GMP Annex 22 (bozza, consultazione 2025) affronta un livello aggiuntivo rispetto ad Annex 11, tra cui il monitoraggio continuo dei modelli e un Change Control specifico per l'AI per gli aggiornamenti del modello.

Importante per l'inquadramento: il documento e ancora non definitivo. Chi utilizza AI nei processi GxP dovrebbe tuttavia allineare tempestivamente il quadro CSV esistente a questi requisiti, anziche adeguarsi dopo l'entrata in vigore. Un sistema AI modifica il suo comportamento in modo diverso dal software deterministico: un modello valido all'introduzione può deviare dal suo stato qualificato a causa di dati di input modificati. Con cio la valutazione continua, che Annex 11 richiede in ogni caso, diventa per i sistemi AI il compito centrale effettivo e non un adempimento burocratico a una data fissa.

Lo stato validato viene mantenuto durante l'operativita oppure non lo e affatto. Concretamente questo significa tre routine che devono entrare in funzione dopo la qualifica iniziale:

• Procedura di Periodic Review con trigger definito, responsabilita e criteri che impongono un confronto target/effettivo della storia del sistema - non solo una conferma.
• Change Control con logica di Impact Assessment che registra ogni modifica incluse patch e aggiornamenti e determina in modo motivato l'entita della riqualifica.
• Audit Trail Review come routine fissa, cosicche la valutazione non avvenga solo in occasione dell'ispezione.

Entourage accompagna questi passi insieme alla QA: dall'analisi delle lacune del catalogo di sistema e dalla categorizzazione GAMP 5, attraverso la documentazione di qualifica per i sistemi critici, fino all'operativita CSV continuativa con Periodic Review e Change Control. Per l'AI nei processi GxP estendiamo il quadro Annex 11 esistente con i requisiti che la bozza di Annex 22 prospetta, progettato per il documento finale.