Il rinvio al 2 agosto 2027 del termine entro cui gli Stati membri dovranno rendere operativa almeno una sandbox nazionale per l’intelligenza artificiale è stato letto soprattutto come uno spostamento di calendario. In parte lo è. Ma è anche un’occasione per chiarire quale funzione concreta dovranno avere questi strumenti.
Se le sandbox si limiteranno a verificare le prestazioni di un sistema, rischieranno di affrontare solo una parte del problema. Un modello di intelligenza artificiale non è separabile dai dati con cui è stato sviluppato, addestrato e verificato. Qualità, rappresentatività, trasformazioni e condizioni di accesso ai dati incidono direttamente sul suo comportamento.
Indice degli argomenti
Sandbox AI e dati: il nuovo quadro della sperimentazione
Il Regolamento (UE) 2026/1744, entrato in vigore il 27 luglio 2026, ha modificato la disciplina delle sandbox, differendo di un anno la scadenza nazionale e prevedendo anche una sandbox europea per i sistemi che rientrano nella competenza dell’AI Office. Il dibattito si è concentrato sulle nuove tempistiche e sui soggetti che potranno accedere alla sperimentazione. Meno attenzione è stata dedicata alla scelta dei dati.
Eppure è proprio lì che, in molti progetti, si forma il rischio più difficile da valutare: non soltanto nel codice o nell’architettura del modello, ma nelle informazioni utilizzate per costruirlo e nelle ragioni per cui quelle informazioni sono state messe a disposizione.
Un protocollo di sufficienza per i dati nelle sandbox AI
Una possibile evoluzione delle sandbox consiste nell’integrare nel piano di sperimentazione un protocollo di sufficienza dei dati. Non sarebbe un nuovo adempimento autonomo, ma un modo per rendere esplicita e controllabile una decisione che oggi viene spesso assunta in modo frammentato tra team tecnologici, clinici, legali e privacy.
La domanda è semplice, anche se la risposta raramente lo è: quali dati sono davvero necessari, in quale fase e con quale livello di qualità per raggiungere lo scopo dichiarato?
Un protocollo di questo tipo dovrebbe partire dal caso d’uso e dalle attività che il sistema è chiamato a supportare. Dovrebbe distinguere i dati necessari nelle diverse fasi di sviluppo, test e validazione, indicando il livello richiesto di qualità, completezza, aggiornamento e rappresentatività. Non basterebbe descrivere il dataset disponibile: occorrerebbe chiarire per quali attività possano essere sufficienti dati sintetici o altri dati meno espositivi e per quali, invece, resti necessario ricorrere a dati personali o clinici raccolti.
Il protocollo dovrebbe inoltre definire le proprietà da preservare, le metriche di utilità, i controlli sul rischio di identificazione e le soglie di accettabilità. Dovrebbe infine stabilire in quali circostanze sia necessario tornare alla fonte, rigenerare il dataset o ripetere la validazione: per esempio, quando cambia il caso d’uso, si amplia la popolazione di destinazione, emergono sottogruppi rilevanti o il sistema non conserva le prestazioni richieste.
Necessità, proporzionalità e sostituibilità
La verifica avrebbe così tre oggetti distinti. Il primo è la necessità: servono davvero quei dati per il caso d’uso? Il secondo è la proporzionalità: il livello di esposizione delle persone è giustificato dallo scopo? Il terzo è la sostituibilità: alcune attività possono essere condotte usando dataset sintetici o altri dati meno espositivi, senza compromettere l’affidabilità del risultato?
Come l’AI Act inquadra le sandbox
L’articolo 57 dell’AI Act inquadra le sandbox come ambienti controllati nei quali sviluppo, addestramento, test e validazione di sistemi innovativi possono essere svolti per un periodo limitato, prima dell’immissione sul mercato o della messa in servizio. Le attività si sviluppano secondo un piano concordato con l’autorità competente.
Non si tratta di zone franche. Partecipare alla sandbox non equivale a ottenere una certificazione preventiva della conformità, né elimina le responsabilità del fornitore. La sua utilità sta nel rendere affrontabili i nodi tecnici e giuridici mentre il progetto è ancora modificabile.
L’AI Act non impone un giudizio autonomo sulla sufficienza dei dati per ogni passaggio del ciclo di vita. Il protocollo qui proposto sarebbe quindi un’applicazione possibile dello spazio offerto dalle sandbox: non soltanto verificare se il sistema funzioni, ma documentare perché siano stati impiegati determinati dati, in quel momento e per quella finalità.
Minimizzazione e dati sintetici nelle sandbox AI
Il legame tra AI Act e dati sintetici non è soltanto teorico. Il Regolamento richiama espressamente dati sintetici e anonimizzati in due disposizioni diverse.
Gli articoli 10 e 59 sul ricorso ai dati personali
L’articolo 10, paragrafo 5, riguarda una fattispecie circoscritta. Per rilevare e correggere bias nei sistemi ad alto rischio, il fornitore può trattare categorie particolari di dati personali soltanto quando ciò sia strettamente necessario e quando l’obiettivo non possa essere raggiunto efficacemente attraverso altri dati, compresi quelli sintetici o anonimizzati.
L’articolo 59 disciplina invece il trattamento ulteriore, all’interno delle sandbox, di dati personali raccolti lecitamente per finalità diverse. La disposizione riguarda determinati sistemi di IA destinati a salvaguardare un rilevante interesse pubblico e richiede condizioni rigorose. Fra queste vi è l’impossibilità di conseguire efficacemente lo scopo mediante dati anonimizzati, sintetici o altri dati non personali.
Nessuna delle due disposizioni impone il ricorso al sintetico, né autorizza indistintamente il riuso di dati personali. Entrambe, però, esprimono una domanda di necessità: prima di esporre informazioni riferibili a persone, soprattutto se sanitarie, occorre verificare se l’obiettivo possa essere raggiunto con un’alternativa meno invasiva.
Questa impostazione è coerente con il principio di minimizzazione del GDPR. Minimizzare non significa usare dati meno utili o ridurre artificialmente la conoscenza disponibile. Significa limitare l’esposizione personale a ciò che è adeguato, pertinente e necessario per la finalità.
Dati e sandbox AI: dalla plausibilità alla prova
La valutazione di un sistema di intelligenza artificiale non può esaurirsi nella qualità apparente dei dati o nelle prestazioni dichiarate dal modello. Occorre poter ricostruire la catena dell’evidenza: da quali fonti provengono le informazioni, per quali finalità sono state utilizzate, come sono state selezionate e trasformate, quali limiti presentano e con quali verifiche siano state associate ai risultati ottenuti.
Questa esigenza riguarda tutti i dati usati nel progetto, non soltanto quelli sintetici. Un dataset può essere formalmente accessibile e tecnicamente ben costruito, senza essere adeguato alla domanda cui il sistema deve rispondere. Al contrario, un dataset ricco e molto vicino alla fonte può comportare un livello di esposizione non giustificato rispetto all’attività da svolgere.
Dalla verosimiglianza all’evidenza clinica
Gli interrogativi non sono astratti. In una recente inchiesta di Dataroom, è stata richiamata l’attenzione sulla possibilità che strumenti generativi producano pazienti fittizi, immagini diagnostiche plausibili e materiali di ricerca capaci di superare controlli superficiali. Il problema non è che un dato generato sia inutilizzabile per definizione. È che la sua verosimiglianza non può essere confusa con una prova scientifica.
Il tema si colloca dentro una questione più ampia: la distanza che può esistere tra una prestazione tecnica apparentemente convincente e la dimostrazione di un beneficio clinico effettivo.
Un’analisi pubblicata nell’agosto 2026 su PLOS Digital Health ha rilevato che, fra 1.357 dispositivi AI/ML autorizzati dalla FDA, solo 34 risultavano associati a trial prospettici registrati e solo tre erano stati valutati su esiti centrati sul paziente. Il dato non riguarda direttamente le tecniche di generazione dei dati, ma conferma che accuratezza, autorizzazione o plausibilità dell’output non sono sufficienti: ciò che conta è poter verificare il percorso che conduce dal dato alla conclusione clinica.
Tracciabilità dei dataset e soglie di verifica
Questo richiede che, per ogni dataset, siano ricostruibili la provenienza, le condizioni di accesso, i criteri di selezione e preparazione, le trasformazioni effettuate, le versioni impiegate e i limiti d’uso. Se il progetto utilizza dati sintetici, occorre inoltre dimostrare quali proprietà della fonte siano state conservate, quali possano essere state modificate e quale rischio residuo rimanga rispetto a identificazione, memorizzazione o collegamento.
La soglia della verifica non è uguale in ogni caso. Per testare una pipeline informatica o l’interoperabilità fra sistemi possono essere sufficienti controlli su struttura, completezza e coerenza del dataset. Per addestrare o valutare un sistema destinato a incidere su decisioni cliniche, invece, la domanda è più impegnativa: i dati utilizzati consentono al modello di produrre risultati affidabili sulla popolazione e nel contesto in cui sarà effettivamente impiegato?
Quando dati generati o derivati assumono un ruolo rilevante nella valutazione clinica, il modello dovrebbe essere verificato su un insieme indipendente di dati clinici raccolti, non impiegato nella preparazione o generazione dei dati di sviluppo. Se emerge un divario significativo nelle prestazioni, non ne segue automaticamente che quei dati siano inutilizzabili. Può significare che sono appropriati per attività preliminari — sviluppo, simulazione, formazione, benchmark o test di interoperabilità — ma non ancora sufficienti per sostenere una conclusione clinica più forte.
Dati generati o derivati possono quindi concorrere alla costruzione dell’evidenza, senza sostituirsi automaticamente all’osservazione clinica. Il loro valore dipende dalla capacità, dimostrata e documentata, di produrre un contributo affidabile alla domanda clinica o scientifica alla quale il progetto intende rispondere.
Le sandbox AI nel quadro dei dati sanitari
La sanità rende questa impostazione particolarmente concreta. I dati clinici devono rappresentare popolazioni, condizioni e percorsi assistenziali differenti; nello stesso tempo possono contenere informazioni molto sensibili su patologie, terapie, predisposizioni e storia personale.
EHDS e accesso sicuro ai dati sanitari
L’European Health Data Space introduce gradualmente un quadro per l’accesso e il riuso secondario di dati sanitari elettronici a fini di ricerca, innovazione e attività regolatorie. Il modello si basa su organismi di accesso, permessi e ambienti sicuri di trattamento.
Qui la sandbox AI può svolgere una funzione complementare. Una volta che l’accesso ai dati clinici è regolato, occorre stabilire in quali fasi del progetto sia necessario continuare a utilizzare quei dati e per quali attività, invece, possa essere sufficiente ricorrere a dati derivati, sintetici o comunque meno espositivi.
Dati raccolti e validazione clinica indipendente
Si può immaginare un progetto nel quale i dati clinici raccolti siano utilizzati inizialmente, in un ambiente sicuro, per caratterizzare la fonte e predisporre dati destinati alle attività di sviluppo. Questi possono servire per testare pipeline, integrazioni e interoperabilità, costruire benchmark o collaborare con soggetti che non hanno ragione di accedere ai dati personali. Quando l’uso previsto lo richiede, la validazione finale resta ancorata a dati clinici raccolti e indipendenti dalla fonte impiegata nella fase di sviluppo.
Il contributo della sandbox non sarebbe certificare un dataset per ogni possibile finalità o sostituire gli obblighi previsti dalla disciplina privacy, dall’EHDS o dalle regole cliniche applicabili. Sarebbe piuttosto offrire un luogo nel quale rendere leggibile e verificabile la catena di decisioni relativa a dati, modello e contesto d’uso.
Un metodo per valutare dati e modelli nelle sandbox AI
Per imprese, strutture sanitarie, professionisti e organismi di ricerca, il tema è già concreto. Non basta verificare se un dataset personale sia accessibile o se il trattamento sia formalmente possibile. Occorre ricostruire il ciclo di sviluppo e individuare dove il dato personale o clinico raccolto sia davvero indispensabile, dove possa essere sostituito e quali evidenze servano per giustificare quella scelta.
L’anno aggiuntivo previsto per le sandbox nazionali può servire anche a costruire questo metodo. Il test non dovrebbe riguardare soltanto l’accuratezza di un modello, ma anche la possibilità di ricostruire quali dati siano stati utilizzati, per quale ragione, con quali trasformazioni e con quali verifiche.
Un protocollo di sufficienza non rende automatica la conformità. Può però trasformare la minimizzazione da principio astratto a criterio di progettazione e fare delle sandbox un luogo nel quale modello, dati e processo decisionale vengono valutati insieme.
In fondo, non si sperimenta davvero un sistema di intelligenza artificiale se non si è in grado di spiegare anche quali dati lo hanno reso possibile — e perché, per quella finalità, non ne servivano altri o di più.
Partecipa alla community