Un operatore descrive una deviazione. Il sistema di intelligenza artificiale cerca casi simili nell’archivio, ne riassume le cause e propone alcuni documenti da consultare. Il revisore apre il primo risultato: il caso riguarda la stessa apparecchiatura, ma una configurazione di linea che non è più in uso. Un precedente più pertinente, registrato con una terminologia diversa, non compare.
È un esempio ipotetico, ma chiarisce il problema: che cosa deve dimostrare la validazione se il sistema interviene nella ricerca delle informazioni su cui si baserà una decisione di qualità? Il fatto che la decisione resti al revisore è rilevante. Per capire se il sistema è adatto all’uso previsto, occorre però valutare anche ciò che il revisore potrebbe non vedere.
L’uso previsto delimita la prova
«Supporto alla gestione delle deviazioni» è una descrizione troppo ampia per costruire un protocollo di prova. Recuperare precedenti, redigere una sintesi, suggerire una causa e assegnare una priorità sono attività diverse. Un sistema può svolgerne bene una e risultare inadeguato per un’altra. Ognuna espone inoltre il processo a errori diversi: un precedente omesso può restringere l’indagine; una causa proposta con troppa sicurezza può orientarla nella direzione sbagliata.
Nel caso ipotizzato, il primo passo è definire un perimetro verificabile: il sistema cerca precedenti in un archivio autorizzato, restituisce i riferimenti ai record originali e distingue i risultati pertinenti da quelli solo parzialmente affini. Il revisore può aprire le fonti e, se necessario, ampliare la ricerca con gli strumenti già disponibili. Restano da definire i siti e le linee coperti, le lingue e le tipologie di record incluse, oltre al comportamento atteso se l’archivio è incompleto o non offre riscontri sufficienti.
Queste scelte hanno una conseguenza pratica. Se durante l’uso emerge che i revisori copiano abitualmente la sintesi generata nelle indagini, quella sintesi sta assumendo un ruolo ulteriore rispetto alla ricerca dei precedenti. È un segnale per riesaminare l’uso effettivo e capire se le evidenze raccolte coprano anche quel passaggio.
Una buona prova mette in difficoltà il sistema
Un insieme di esempi facili può mostrare che la funzione è disponibile, ma dice poco su come si comporterà nei casi che richiedono più attenzione. Per una prova utile, il team Qualità può selezionare deviazioni storiche e stabilire in anticipo quali precedenti considererebbe pertinenti, quali fonti dovrebbero essere escluse e per quale ragione. Le valutazioni degli esperti possono divergere: documentare il motivo del disaccordo è più informativo che costruire una risposta attesa artificialmente univoca.
Nel set di prova inserirei casi con descrizioni simili ma cause diverse, cambi di terminologia tra reparti, record riferiti a configurazioni non più in uso e ricerche senza un precedente pertinente. Verificherei anche che i riferimenti restituiti siano consultabili, che la sintesi sia fedele al record citato e che il sistema rispetti i permessi di accesso. Se genera una sintesi, proverei a ripetere alcune richieste per capire quanto varia la risposta e se quella variabilità incide sulle informazioni essenziali.
Il criterio di accettazione dovrebbe riflettere le conseguenze dell’errore. Un buon risultato medio può nascondere omissioni concentrate proprio nelle deviazioni più critiche. Prima della prova, quindi, conviene concordare quali omissioni renderebbero l’uso inaccettabile e in quali casi il sistema debba mostrare che non ha trovato evidenze sufficienti. Lo stesso criterio aiuta a decidere se restringere il perimetro iniziale, per esempio a una sola linea o a una famiglia di deviazioni ben documentata.
La supervisione va provata nel flusso di lavoro
Scrivere in procedura che una persona verifica il risultato è il punto di partenza. La prova utile è osservare che cosa quella persona riesce a verificare nelle condizioni reali: se può aprire rapidamente il record, riconoscerne stato e versione, capire quali parti della sintesi derivano dalla fonte e recuperare documenti che il sistema ha omesso.
Un test con i revisori può confrontare la ricerca con e senza assistente sullo stesso insieme di casi. Oltre al tempo impiegato, interessa osservare se cambia l’insieme dei precedenti consultati, se gli utenti riconoscono una fonte poco pertinente e se riescono a motivare il percorso seguito. Un risparmio di tempo è utile se il processo conserva la capacità di trovare e vagliare le informazioni che contano.
La supervisione dipende anche dall’interfaccia. Se la sintesi appare in primo piano e i riferimenti sono difficili da aprire, verificare costa più fatica che accettare. Rendere visibili le fonti e consentire al revisore di correggere o scartare il suggerimento sono scelte di progettazione che possono essere verificate durante le prove.
Il controllo delle modifiche riguarda anche le fonti
Una volta introdotto il sistema, il suo comportamento può cambiare perché viene aggiornata la versione del modello, perché si modifica la logica di ricerca o perché viene riorganizzato l’archivio. Anche senza toccare il modello, un cambiamento nei criteri di indicizzazione o nei metadati può far sparire dai risultati un’intera classe di record.
Il controllo delle modifiche dovrebbe permettere di ricostruire quale configurazione ha prodotto un risultato e di individuare quali prove ripetere. Se cambia la ricerca, per esempio, ha senso riprovare i casi in cui la terminologia differisce tra reparti. Se cambia la generazione della sintesi, occorre verificare di nuovo la fedeltà ai record citati e il comportamento in assenza di riscontri. Se cambia il perimetro delle fonti, tornano in primo piano copertura, versioni e permessi. Per un servizio esterno, la possibilità di conoscere e valutare gli aggiornamenti è quindi una domanda da porre al fornitore prima dell’adozione.
Il quadro GMP e il lavoro sull’Annex 22
Il riferimento europeo per i sistemi computerizzati in ambito GMP è l’Annex 11 di EudraLex Volume 4 [1]. Va tenuto distinto dal lavoro sull’Annex 22, dedicato all’AI. Il rapporto EMA pubblicato il 2 ottobre 2026 raccoglie il contributo degli esperti su possibili misure di controllo per modelli adattivi, probabilistici e generativi. È un documento che informa la revisione della bozza: da solo non costituisce una modifica delle GMP applicabili né un via libera all’uso di questi modelli nelle applicazioni critiche [2].
Per un’azienda che sta valutando un’applicazione, il lavoro può partire da un compito circoscritto: scrivere l’uso previsto in termini verificabili, scegliere gli errori che contano, raccogliere evidenze con gli utenti e stabilire come rivalutarle nel tempo. Nel caso delle deviazioni, la prova decisiva è se il revisore riesca a individuare e verificare i precedenti rilevanti anche quando il primo risultato lo porta nella direzione sbagliata.
Fonti e riferimenti
- Commissione europea. EudraLex Volume 4 – Good Manufacturing Practice guidelines, Annex 11 – Computerised Systems.
- EMA. Workshop on expert contributions to artificial intelligence guidance development – Annex 22. La pagina raccoglie il rapporto pubblicato il 2 ottobre 2026.
Vuoi trovare più facilmente MakingPharmaIndustry su Google?
Aggiungici alle tue fonti preferite
