AI e data validation: guardare prima di toccare

C’è un momento, in ogni studio, in cui il dataset arriva. È il momento in cui dovrebbe iniziare il processo fondamentale di data validation — quella revisione sistematica dei dati raccolti che garantisce la qualità di tutto quello che viene dopo. Eppure, quasi sempre, il processo è un altro.

Il dataset viene esportato dal sistema di raccolta dati e accompagnato da una mail dal testo semplice quanto efficace: “Ecco i dati, possiamo procedere”. Da lì parte verso chi più se la cava con i numeri. A volte lo manda il coordinatore dello studio. Altre volte lo prepara direttamente il medico investigatore. In alcuni casi arriva da una CRO, già “pulito”. Quasi sempre, chi lo prepara non è un biostatistico.

E quasi sempre, ormai, la prima cosa che succede è che qualcuno che ha poca pratica di biostatistica, lo carica su un’AI e chiede di analizzarlo. L’output che viene fuori è una perfetta analisi statistica corredata di medie, deviazioni standard, test statistici e sempre impeccabilmente al suo posto ilp-value. Dunque il lavoro è tutto qui: raccogliere dati, metterli su un Excel, poi darli in pasto all’AI e, dunque, magia: i risultati sono pronti. Siamo proprio sicuri?

Dati in, risultati out: è davvero statistica?

Se la risposta è sì, allora no, non siamo affatto sicuri. L’AI ha fatto la sua parte: ha ricevuto dei dati e ne ha restituiti altri. Ma questo non è fare un’analisi statistica. Esattamente come inserire i dati clinici di un paziente in un computer e ricevere una diagnosi non è fare il medico: è un processo che assomiglia a una diagnosi, ma manca di tutto ciò che la rende tale. Allo stesso modo, caricare un dataset e ricevere tabelle e p-value è meccanizzare una serie di operazioni senza aver prima capito cosa si sta analizzando e perché. Senza supervisione, senza regole, senza pensiero. Senza nessuna di quelle domande fondamentali che ogni biostatistico si pone prima quando riceve un file da analizzare: “Come è fatto questo dataset? Cosa contiene? Cosa dovrebbe contenere?”

Analizzare prima di validare il dataset — ed è proprio a questo che portano quelle domande — è come abitare una casa costruita senza che nessuno abbia mai controllato le fondamenta. Somiglia a quella casa pericolante che la piccola Chiyo descrive nelleMemorie di una geishadi Arthur Golden: una casa che sta apparentemente in piedi, ma è battuta da ogni vento e pronta a cedere al primo carico che non aveva previsto. I dati sembrano stare in piedi. Finché qualcuno non ci appoggia sopra una disamina seria.

Data validation: molto più che controllare i numeri

Quello che ho descritto potrà sembrare un’iperbole, un’esagerazione per creare rumore. Purtroppo, mi spiace smentire, nell’epoca dell’AI è una pratica fin troppo diffusa. E voglio essere chiara: non è una storia di negligenza. È la storia di un pezzo mancante, troppo spesso assente nell’attuale ricerca scientifica, raramente insegnato, quasi mai discusso apertamente. Abbiamo una serie di clinici eccellenti, ma questa eccellenza non significa in automatico una trasmissione per osmosi del sapere alla ricerca metodologica e alla biostatistica. Queste sono competenze diverse che si possono sì apprendere, ma non si possono delegare senza controllo e senza conoscenza all’AI.

Il passaggio che manca si chiama data validation. Un processo che non vuol dire controllare che i numeri ci siano o che sembrino plausibili a prima vista. Vuol dire misurare quei numeri rispetto a tutto ciò che esiste fuori dal dataset: il protocollo, il piano di analisi statistica, il data dictionary, le decisioni prese durante la raccolta. Vuol dire sapere cosa dovrebbe esserci e confrontarlo con quello che effettivamente c’è — non per confermare, ma per trovare quello che non torna.

Il ruolo di protocollo, SAP e data dictionary

Sorrido sempre quando sento di elaborazioni statistiche senza neanche una bozza dipiano statisticoalle spalle o senza una definizione seppur minima di data dictionary. Questi non sono documenti burocratici: sono le linee guida di come funziona lo studio e di come dovrebbero essere i dati prima di passare alla fase successiva di analisi. Sono documenti in cui si decide, prima ancora di raccogliere un dato, quali variabili si misureranno, come, con quali regole e con quali aspettative. Senza di essi, la data validation non ha un riferimento rispetto a cui confrontare i dati — e l’analisi che ne segue è un navigare alla cieca sperando di avvistare terra.

La data validation è un atto di contestualizzazione, che richiede memoria e competenze specifiche. La memoria di chi ha letto il protocollo, di chi conosce le finestre temporali previste per ogni visita, di chi sa che il valore 99 in quella colonna non è un outlier ma un codice convenzionale per il dato mancante: informazioni che stanno nel SAP e nel data dictionary, non nel dataset. Insomma la memoria e la competenza di chi ha messo al centro del proprio lavoro non il risultato, ma il metodo. Di chi crede che l’evidenza emerga dal dato e non il contrario.

Fatta la legge, trovato l’inganno?

A questo punto sembrerebbe che la soluzione sia facile: diamo all’AI l’informazione che manca — il protocollo, il SAP e il data dictionary. Se dispone di queste informazioni saprà dove andare. Ragionamento perfettamente logico. Ma inutile, lo anticipo già. Purtroppo caricare questi ulteriori documenti — a patto sempre che qualcuno li abbia predisposti, il che non è sempre un dato certo — non risolve il problema. L’AI leggerà quei documenti, ne comprenderà il contenuto, darà indicazioni su come muoversi. Ma non ragionerà su di essi nello stesso modo in cui lo fa un esperto.

L’AI è predisposta per fornire risposte, non per fare le domande. Ad esempio, non si chiederà perché il biostatistico che ha impostato il SAP ha scelto di trattare una certa variabile come continua invece che per intervalli — e dunque non si interrogherà sulla necessità di controllare la presenza di outlier. Non sa che 99 in uno score non significa un valore anomalo, ma un dato mancante, e non si chiederà perché quel dato mancante ricorre su molti soggetti. Insomma non coglierà la tensione tra una scelta metodologica e i dati che ha davanti. Non percepirà che quella distribuzione anomala potrebbe essere il segnale di un problema di raccolta, non di una caratteristica reale della popolazione.

L’AI non ha questo approccio e, almeno per il momento, sembra non possa averlo. Ha tantissime capacità: ragiona, collega, produce — ma non può sapere il ragionamento non scritto che sta dietro a una scelta rispetto a un’altra: il ragionamento di chi ha progettato lo studio, di chi conosce il contesto clinico, di chi sa perché si è andati in una certa direzione e non in un’altra. Quel “perché” è tacito, incorporato nell’esperienza di chi lo ha fatto. E nessun file caricato su una piattaforma AI può trasferirlo.

Dove l’AI nella data validation fa davvero la differenza

Dunque qual è la strada? Abbandonare l’AI perché imprecisa? Tornare al controllo manuale, ignorando gli strumenti che la tecnologia mette a disposizione? No — saremmo noi fuori logica. Siamo partiti da un approccio che delega tutto all’AI e non possiamo certo finire con il rifiutare ex abrupto l’intero sistema che sta modificando il nostro modo di lavorare. La scienza può avanzare lenta, ma non procede mai a ritroso.

La data validation ha due anime. Una richiede giudizio: quella contestualizzazione che solo chi conosce lo studio può fare. L’altra richiede esecuzione — e su quella l’AI è straordinariamente utile, anche per chi non ha una formazione statistica specifica.

Qualche esempio

Pensiamo ai controlli di range. Se il protocollo prevede che un certo parametro abbia valori tra 0 e 100, chiedere all’AI di identificare tutte le righe con valori fuori da quel range è un’operazione che prima richiedeva tempo, attenzione e una buona dose di fortuna per non perdersi qualcosa su centinaia o migliaia di righe. Adesso l’AI lo fa in secondi, con precisione assoluta. Lo stesso vale per i duplicati, per le date impossibili, per le visite fuori finestra temporale — a patto che tu le dica qual è la finestra prevista.

O pensiamo alla codifica. Quando una variabile è stata inserita da persone diverse in momenti diversi — cosa che succede in qualsiasi studio con più operatori — le inconsistenze sono quasi inevitabili. “Sì”, “SI”, “si”, “1”, “positivo”: cinque modi di dire la stessa cosa che l’AI tratterà come cinque categorie distinte, a meno che tu non le chieda esplicitamente di identificare le varianti e proporre una mappatura. Quella mappatura, una volta prodotta, tu la verifichi rispetto al data dictionary — e decidi se è corretta.

E ancora, la produzione del data validation report: un documento strutturato che elenca le anomalie trovate, i controlli effettuati, le decisioni prese. Prima era un documento da costruire da zero — un lavoro lungo, spesso trascurato proprio perché lungo. Adesso l’AI produce la bozza in tempi impensabili. Tu la leggi, controlli che corrisponda esattamente, la integri con il tuo giudizio, la firmi.

Il principio è semplice e vale per tutta la data validation: tu pianifichi, l’AI esegue, tu giudichi. L’AI accelera il lavoro operativo, tu porti la conoscenza contestuale che trasforma quell’output in una decisione informata. Non è una divisione gerarchica: è una divisione di competenze. E funziona straordinariamente bene quando entrambe le parti fanno la loro parte.

Data validation: la sequenza da non invertire

Un processo di data validation ben costruito ha una sequenza precisa. Prima l’export del dataset grezzo, così com’è. Poi il data validation report: una revisione sistematica delle anomalie, prodotta con o senza AI, ma sempre interpretata da qualcuno che conosce lo studio — non solo i suoi documenti ufficiali — e sa cosa sta cercando. Successivamente il data cleaning: la correzione delle anomalie secondo regole predefinite, con tracciabilità di ogni modifica: ogni cambio va documentato, con la motivazione. Infine il lock: il dataset viene congelato, e da quel momento non si tocca più. Solo allora inizia l’analisi.

Il lock è il passaggio più importante e più sottovalutato dell’intero processo di data validation. Secondo alcuni è una mera formalità tecnica. Non lo è: il lock è il momento in cui chi è responsabile dell’analisi dice: su questi dati, validati in questo modo, con queste regole, condurrò l’analisi. È una firma nel senso pieno, una dichiarazione in cui ci si assume la responsabilità di quello che viene dopo. L’AI non può assumersi questa responsabilità. Non perché non sia abbastanza intelligente, ma perché la responsabilità non è un’operazione computazionale. È umana, per definizione. E in uno studio clinico, quella responsabilità ha un nome e un cognome che risponde di fronte alla comunità scientifica in termini etici, deontologici e di replicabilità.

L’abitudine che l’AI non può togliere

Ho iniziato questa professione prima dell’AI e negli anni ho sviluppato l’abitudine di aprire sempre il dataset prima di fare qualsiasi altra cosa. Non per fare l’analisi, non per modificarlo: semplicemente per guardare. Scorrere le colonne, leggere i valori, cercare quello che non torna. È un gesto quasi fisico, come sfogliare le pagine di un libro prima di leggerlo.

È un’abitudine lenta, apparentemente inefficiente nell’era dell’AI. Ma l’AI non può toglierla — anzi, sta dimostrando più che mai quanto sia necessaria. Perché ora che un’analisi si produce in pochi minuti (beati coloro che riescono a crederci, ad analisi siffatte), la fase in cui qualcuno guarda davvero il dataset è l’unica cosa che distingue un risultato valido da uno che sembra valido.

Per i tanti ricercatori clinici che gestiscono i propri dati senza una formazione statistica e metodologica specifica, questa abitudine non è naturale. Nessuno l’ha insegnata. Ma si può imparare. E l’AI, usata nel momento giusto e con le domande giuste, può diventare il miglior alleato per svilupparla: sistematica, veloce, instancabile nei controlli di routine, capace di lasciare a te il giudizio che conta.

Guardare prima di toccare non è un rallentamento. È la condizione perché tutto quello che viene dopo abbia senso.