Sorveglianza umana e validazione dei modelli AI: un problema di metodo, prima che di norma

Quando un sistema di intelligenza artificiale pre-classifica un case report di sicurezza, o accelera la stesura di un dossier regolatorio, c’è una domanda che precede qualsiasi discussione su scadenze normative. Chi, concretamente, è in grado di verificare che quell’output sia corretto e con quali strumenti lo dimostra? È una domanda metodologica, non legale. Una domanda che si pone oggi, indipendentemente da quando un determinato sistema rientrerà formalmente nella classificazione “alto rischio” del Regolamento (UE) 2024/1689.

Per chi lavora in biostatistica e metodologia della ricerca clinica, questa domanda non è nuova. Un sistema di intelligenza artificiale che classifica, predice o stratifica non è, dal punto di vista del rigore metodologico richiesto, diverso da un nuovo strumento diagnostico o da una scala di valutazione multi-item. È un sistema che va validato prima di essere usato, va monitorato dopo ed ogni decisione clinica o regolatoria che si basa sul suo output deve poter essere ricostruita, giustificata e difesa. Quello che l’AI Act introduce — in particolare con l’articolo 14, dedicato alla sorveglianza umana — non è un principio nuovo: è la formalizzazione normativa di ciò che la buona pratica metodologica richiedeva già.

AI Act e contesto

L’AI Act non cambia il valore scientifico di questa documentazione. Quella validità era già presente prima della norma e non dipende dall’esistenza di un obbligo legale. Quello che cambia è il contesto in cui questa documentazione viene richiesta e valutata. Un’autorità di vigilanza può esigerla e la sua assenza ha ora conseguenze formali oltre che metodologiche. Ma c’è un secondo livello, che la norma non dice e che chi lavora in metodologia vede subito.

Produrre quella documentazione richiede competenze che non si improvvisano. Sapere che un modello va validato non equivale a sapere scegliere le metriche giuste per il contesto specifico, gestire lo squilibrio tra classi nei dati di training, valutare la calibrazione oltre l’accuratezza, o costruire un piano di monitoraggio che sia statisticamente sensibile alla deriva e non solo formalmente presente. Sono competenze che si costruiscono su anni di lavoro con dati clinici e strumenti di misura complessi. La biostatistica e la metodologia non si improvvisano.

Prima di approfondire l’argomento voglio fare una precisazione importante. Questo articolo tratta i sistemi AI nel senso proprio del termine, ossia modelli che producono un output discreto su cui una persona qualificata esercita una decisione. Non si applica agli agenti AI che operano in modo autonomo attraverso sequenze di azioni interdipendenti e interazioni con ambienti esterni. Per questi ultimi, i framework di validazione e sorveglianza classici sembrano al momento insufficienti e richiedono un approccio metodologico distinto, tema che affronto in un articolo separato.

Articolo 14 AI Act: perché interessa il metodologista

L’articolo 14 specifica che i sistemi di AI ad alto rischio devono essere progettati e sviluppati in modo tale da poter essere effettivamente supervisionati da persone fisiche durante il loro utilizzo. La sorveglianza deve mettere chi la esercita nelle condizioni di comprendere le capacità e i limiti del sistema, riconoscere la cosiddetta “distorsione dell’automazione” — la tendenza a fare affidamento acritico sull’output algoritmico — e poter decidere di ignorare, correggere o bloccare l’output in qualsiasi momento.

Dal punto di vista metodologico, questo prescrive implicitamente tre cose che chi ha esperienza in validazione di strumenti di misura riconoscerà immediatamente. Prima: la sorveglianza umana è possibile solo se il sistema è stato validato in modo sufficientemente granulare da consentire a chi lo usa di sapere dove sbaglia, non solo quanto spesso sbaglia in media. Seconda: il protocollo di supervisione deve essere pre-specificato, non lasciato alla discrezionalità del momento, altrimenti non è sorveglianza, è interpretazione a posteriori. Terza: la tracciabilità delle decisioni non è un adempimento burocratico. È lo strumento che permette di verificare nel tempo se il pattern delle correzioni umane segnala un problema sistematico nel modello.

Un caso di lavoro: la pre-classificazione degli ICSR (Individual Case Safety Reports)

Per rendere il ragionamento concreto, consideriamo uno schema ricorrente in farmacovigilanza. Un sistema AI applicato alla fase di triage e valutazione degli ICSR (Individual Case Safety Reports), ovvero le segnalazioni individuali di sospette reazioni avverse. Il sistema assegna un livello di priorità agli ICSR in arrivo e segnala potenziali segnali di sicurezza da verificare. La decisione finale — se il caso costituisce un segnale, se va escalato, se va comunicato alle autorità competenti — resta umana. Il sistema AI accelera il processo di triage, non lo sostituisce.

Dal punto di vista della validazione statistica, costruire la documentazione di sorveglianza per questo tipo di sistema richiede quattro componenti distinte.

Misurazione delle performance

Sensibilità e specificità rispetto a un riferimento esperto, con attenzione particolare al tasso di falsi negativi. Nella fase di triage e valutazione degli ICSR, il tasso di falsi negativi è la metrica critica. Un ICSR classificato erroneamente come non prioritario può portare a ritardare o perdere del tutto l’identificazione di un segnale di sicurezza, con conseguenze potenzialmente gravi per la salute pubblica.

A queste si aggiunge la calibrazione. Non è sufficiente che il sistema classifichi correttamente, serve verificare che la confidenza dichiarata dall’algoritmo corrisponda alla sua reale accuratezza empirica. Questo tipo di analisi, nella sua struttura logica, è identico a uno studio di reliability inter-rater in cui si misura l’accordo tra il sistema e un gold standard umano esperto. Tutto ciò usando le stesse metriche e le stesse cautele metodologiche che si applicano quando si confrontano due revisori umani. È un terreno consolidato, applicato a un nuovo oggetto.

Pre-specificazione del protocollo di sorveglianza

Prima che il sistema entri in uso, il protocollo di supervisione deve essere scritto. Deve esplicitare in quali condizioni l’output viene accettato senza verifica aggiuntiva, in quali richiede revisione obbligatoria, chi ha l’autorità di correggere o bloccare e attraverso quale procedura. Il principio è lo stesso di un piano di analisi statistica pre-specificato. Le regole si stabiliscono prima di osservare i risultati per evitare che le decisioni vengano prese o giustificate a posteriori. Un protocollo di sorveglianza scritto dopo che il sistema è già operativo vale metodologicamente quanto un SAP scritto dopo aver visto i dati.

Monitoraggio longitudinale delle performance

Un modello validato al baseline non è garantito stabile nel tempo. I dati in ingresso cambiano — nuovi pattern di reazioni avverse, nuovi prodotti, variazioni nel mix di popolazione — e le performance possono degradare in modo silenzioso, senza che nessun alert esplicito lo segnali. Il piano di monitoraggio deve specificare con quale frequenza si ri-misurano le performance, con quale soglia si attiva una revisione del modello e chi è responsabile di questa valutazione periodica. È la stessa logica di un piano di follow-up in uno studio osservazionale. Il disegno deve prevedere i timepoint di controllo prima che i dati arrivino, non reagire alla deriva quando è già evidente.

Tracciabilità sistematica delle decisioni

Tracciare sistematicamente significa che qualsiasi sistema ha necessità di essere accompagnato da un log che permetta di ricostruire, per ogni caso, cosa ha proposto il sistema e cosa ha deciso la persona responsabile. Questo non è solo un requisito di trasparenza: è lo strumento diagnostico del modello nel tempo. Se la persona responsabile corregge sistematicamente le classificazioni del sistema in una certa categoria, quella frequenza di correzione è un segnale che indica che il modello ha un bias specifico che va corretto, non che il processo di sorveglianza funziona bene.

Il punto metodologico che l’AI Act non dice esplicitamente

C’è una dimensione del problema che il testo normativo lascia implicita e che vale la pena rendere esplicita. La sorveglianza umana è efficace solo se chi la esercita è in grado di riconoscere quando il sistema sta sbagliando. Questo richiede non solo che il protocollo esista, ma che la persona designata abbia una comprensione sufficientemente profonda delle condizioni in cui il modello è stato validato. Deve insomma essere chiaro su quale popolazione, con quale distribuzione degli esiti, con quali limiti di generalizzabilità il modello è valido.

In pratica: un sistema validato su una popolazione di ICSR europei potrebbe comportarsi diversamente su segnalazioni provenienti da altri contesti regolatori. Un sistema calibrato su un certo mix di prodotti potrebbe perdere accuratezza quando il portafoglio cambia. La persona responsabile della sorveglianza non può riconoscere questi problemi se non ha accesso alla documentazione di validazione originale e non è stata formata su cosa cercare. Questo è esattamente il motivo per cui la documentazione di validazione non è un documento da produrre una volta e archiviare. Esso è il riferimento operativo della sorveglianza e deve essere leggibile e utile per chi lo usa, non solo completo per chi lo deposita.

Il problema della validazione indipendente

Quando si studia metodologia della ricerca, uno degli aspetti importanti è la valutazione esterna dei sistemi. Questa procedura serve per evitare bias legati a possibile “interferenze” anche involontarie, da parte di chi ha sviluppato e addestrato il modello. Questo è un aspetto che nella procedura di validazione dei modelli AI sembra essere sottovalutato da parte delle organizzazioni che introducono questi sistemi. La validazione condotta da chi ha sviluppato o adottato il modello non è, per definizione, indipendente. E l’assenza di indipendenza è un limite metodologico strutturale, non una questione di buona fede.

In ricerca clinica questo principio è consolidato. Uno studio di validazione di uno strumento diagnostico condotto esclusivamente dal gruppo che lo ha sviluppato è considerato a rischio di bias, indipendentemente dalla qualità tecnica del lavoro. La stessa logica si applica a un modello di intelligenza artificiale. Chi ha costruito il sistema — o chi ha deciso di adottarlo — ha un interesse, anche solo cognitivo, nel trovare che le performance siano adeguate. Questo non implica disonestà. Esso implica che il disegno della validazione, la scelta delle metriche, la selezione del dataset di test e la definizione del gold standard possono essere inconsapevolmente orientati verso una conferma piuttosto che verso una verifica critica.

Una validazione indipendente — condotta da chi non ha partecipato né allo sviluppo né all’adozione del sistema, con accesso ai dati originali e libertà di scegliere le metriche appropriate al contesto — è la risposta metodologicamente corretta a questo problema. Non è un lusso aggiuntivo. È la condizione che rende la documentazione di validazione effettivamente difendibile, davanti a un revisore, a un’autorità di vigilanza, o semplicemente davanti a un collega che chiede su quali basi il sistema è stato giudicato affidabile.

La domanda da farsi ora

La domanda che vale la pena farsi non è se il proprio sistema rientri formalmente nella classificazione alto rischio dell’AI Act. È una domanda più vicina alla pratica quotidiana: se qualcuno — un revisore, un’autorità, un cliente — chiedesse di vedere la documentazione di validazione del sistema in uso, quella documentazione reggerebbe a un esame metodologico indipendente? Passerebbe insomma una sorta di peer-review?

Costruire una risposta affermativa a questa domanda richiede esperienza specifica nella scelta delle metriche, nella gestione dei bias del dataset, nella pre-specificazione del protocollo prima di osservare i risultati, nel disegno del monitoraggio longitudinale. Sono competenze che si sviluppano nel tempo, lavorando su dati clinici complessi e strumenti di misura che devono essere difendibili. Chi le costruisce solo quando la situazione lo richiede — scopre quasi sempre, in quel momento, che non bastava il tempo che aveva.