CSV vs CSA: per vent'anni la Computer System Validation è stata sinonimo di protocolli chilometrici, screenshot e firme su ogni pagina. Con la guidance finale FDA Computer Software Assurance for Production and Quality Management System Software, pubblicata il 24 settembre 2025 e aggiornata il 3 febbraio 2026, la Computer Software Assurance (CSA) diventa il riferimento ufficiale: meno documentazione difensiva, più pensiero critico e testing proporzionato al rischio. In questo articolo vediamo cosa cambia davvero rispetto alla CSV tradizionale, come applicare il nuovo approccio e cosa significa per chi lavora in ambito GxP.
CSV vs CSA: perché la FDA ha cambiato approccio
La CSV "classica" nasce dalla guidance FDA General Principles of Software Validation (GPSV) del 2002. Un documento pensato per un'epoca in cui il software era in gran parte custom e installato on-premise. Nel tempo, però, l'applicazione della GPSV è degenerata in un eccesso di burocrazia: script di test firmati riga per riga, centinaia di screenshot, evidenze cartacee duplicate. Il risultato, osservato dalla stessa FDA, è paradossale: le aziende investono più energie nel produrre documentazione che nell'assicurare la qualità reale del software.
La CSA ribalta la prospettiva. L'obiettivo non è dimostrare di aver testato tutto allo stesso modo, ma concentrare lo sforzo di assurance dove il rischio per la qualità del prodotto e la sicurezza del paziente è più alto, applicando il principio del least burdensome approach. La guidance finale sostituisce formalmente la Sezione 6 della GPSV 2002 (quella dedicata al software di produzione e del sistema qualità), mentre il resto della GPSV rimane in vigore.
Dalla bozza 2022 alla guidance finale: le tappe
Il percorso della CSA è stato lungo e vale la pena ricostruirlo, perché molte aziende sono rimaste ferme alla bozza:
- Settembre 2022: FDA pubblica la draft guidance Computer Software Assurance for Production and Quality System Software.
- 24 settembre 2025: CDRH e CBER pubblicano la guidance finale, che recepisce i commenti ricevuti sulla bozza.
- 3 febbraio 2026: FDA emette una versione aggiornata con il titolo Computer Software Assurance for Production and Quality Management System Software, allineato alla terminologia della QMSR (21 CFR Part 820 armonizzato con ISO 13485, applicabile dal 2 febbraio 2026).
Rispetto alla bozza, la versione finale aggiunge una sezione terminologica su IaaS, PaaS e SaaS, chiarisce che il framework può applicarsi anche agli strumenti di intelligenza artificiale usati in produzione o nel sistema qualità, amplia le indicazioni su quanto ci si può appoggiare alla documentazione del fornitore e insiste sulla preferenza per evidenze digitali rispetto alla carta.
Come funziona la CSA: intended use, rischio, assurance
Il metodo CSA si articola in quattro passi logici, da ripetere per ogni software (o singola feature) in ambito:
- Identificare l'intended use: il software (o la funzione) è usato direttamente in produzione o nel sistema qualità, oppure lo supporta soltanto?
- Analisi del rischio di processo: una failure del software può generare un problema di qualità che compromette prevedibilmente la sicurezza? Se sì, il rischio di processo è "high"; altrimenti "not high". La FDA usa questa classificazione binaria, ma ammette scale più granulari (moderato, basso).
- Selezionare le attività di assurance commisurate al rischio: testing scripted rigoroso per le funzioni ad alto rischio, metodi unscripted per il resto.
- Registrare le evidenze: intended use, determinazione del rischio, cosa è stato testato, da chi e con quale esito.
I cambi di paradigma regolatorio come questo si capiscono meglio un pezzo alla settimana: iscriviti a The Pragmatic GMP, la newsletter settimanale gratuita di GuideGxP, per ricevere analisi pratiche e audit-ready su CSA, Annex 11 e data integrity.
CSV vs CSA: il confronto punto per punto
| Aspetto | CSV tradizionale (GPSV 2002) | CSA (guidance finale 2025) |
|---|---|---|
| Punto di partenza | Documentare la convalida di tutto il sistema | Intended use e rischio per paziente/qualità |
| Testing | Prevalentemente scripted, uniforme | Scripted solo dove il rischio è alto; unscripted altrove |
| Evidenze | Screenshot, stampe, firme manuali | Record digitali: log di sistema, audit trail, risultati nel tool |
| Fornitori | Audit on-site e riconvalida interna | Leverage risk-based della documentazione del vendor (ISO, SOC, SBOM) |
| Cloud e AI | Non contemplati | IaaS/PaaS/SaaS e tool AI esplicitamente in ambito |
| Effort documentale | Alto, indipendente dal rischio | Proporzionato al rischio (least burdensome) |
Testing scripted e unscripted: come scegliere
La novità più concreta per chi convalida è la legittimazione del testing non scriptato. Per le funzioni a rischio "not high" la guidance indica esplicitamente metodi come ad-hoc testing, error-guessing ed exploratory testing: il tester esercita il sistema con scenari realistici e registra in modo sintetico cosa ha fatto e cosa ha osservato, senza script passo-passo pre-approvati. Per le funzioni a rischio "high" resta raccomandato un testing più rigoroso e tracciabile, tipicamente scripted. Nessun metodo è però imposto per legge: la scelta va motivata con pensiero critico e documentata nella risk analysis.
Evidenze e documentazione: cosa si aspetta la FDA
CSA non significa "niente documenti". Significa documenti giusti. Il fascicolo minimo che un ispettore si aspetta di trovare comprende: l'inventario dei software mappato sugli intended use, la classificazione del rischio di processo per ciascuno, la descrizione delle attività di assurance svolte, chi le ha eseguite e i risultati. La guidance scoraggia esplicitamente screenshot e duplicazioni cartacee quando il sistema genera già log e audit trail utilizzabili come evidenza. Attenzione a un punto spesso frainteso: se i record sono elettronici, il 21 CFR Part 11 continua ad applicarsi, e la FDA non esercita discrezionalità sulla convalida del software di produzione e qualità.
E per il pharma? GAMP 5 e Annex 11
Formalmente la CSA è una guidance per i dispositivi medici (software di produzione e del quality management system sotto 21 CFR Part 820). Ma i suoi principi sono già pratica corrente anche nel farmaceutico: GAMP 5 Second Edition (ISPE, 2022) incorpora critical thinking, testing agile e leverage del fornitore in piena coerenza con la CSA, e la revisione in corso dell'Annex 11 EU GMP spinge nella stessa direzione risk-based. Chi opera in ambito GxP può quindi adottare l'impostazione CSA nella propria metodologia di convalida, mantenendo come riferimenti vincolanti Annex 11 e Part 11 per i record elettronici.
Raccomandazione GuideGxP
Non riscrivere tutte le SOP in una notte. Il passaggio da CSV a CSA si fa per gradi e con evidenze solide: aggiorna prima la procedura di risk assessment dei sistemi computerizzati introducendo la classificazione per intended use e rischio di processo; definisci nella SOP quando è ammesso il testing unscripted e come documentarlo; rivedi la qualifica dei fornitori per sfruttare in modo difendibile certificazioni e pacchetti di test del vendor; e assicurati che audit trail e log siano effettivamente recuperabili, perché nella CSA sono loro la tua evidenza primaria. In audit, la domanda non sarà "quanti script hai eseguito?" ma "come hai deciso dove concentrare il testing?".
Per impostare governance, audit trail review e controlli di data integrity difendibili in ispezione, dai un'occhiata alla nostra Data Integrity in ambito GMP – Guida Operativa a governance, audit trail review e laboratori QC: il complemento ideale per portare la CSA dentro il tuo PQS.
