Un recente contributo internazionale (AI&Partners: Procurement guidelines for AI cybersecurity within healthcare) pone l’accento sulla sicurezza dell’IA clinica, dimostrando come la stessa non si costruisca in esercizio, ma nelle clausole contrattuali e nei criteri di gara firmati al momento dell’acquisto.
Perché le strutture sanitarie sono il laboratorio della sicurezza IA
La combinazione di tre fattori rende il settore sanitario particolarmente esposto. I dati trattati appartengono a categorie particolari ai sensi dell’articolo 9 del Regolamento (UE) 2016/679, la cui violazione produce rischio elevato per i diritti degli interessati. Il settore è qualificato altamente critico dalla Direttiva (UE) 2022/2555 e sottoposto a gestione del rischio e notifica degli incidenti. Un medesimo applicativo — un modulo di triage radiologico — può essere contemporaneamente dispositivo medico soggetto al Regolamento (UE) 2017/745, sistema di IA ad alto rischio ai sensi del Regolamento (UE) 2024/1689, trattamento di dati sanitari coperto dal GDPR e asset della catena di fornitura rilevante ai fini del decreto legislativo 138/2024. La difficoltà operativa principale non è l’assenza di regole, bensì la composizione di obblighi concepiti separatamente con logiche di conformità differenti.
La struttura sanitaria agisce nella qualifica giuridica di deployer dell’IA e di soggetto essenziale o importante ai fini della cybersicurezza nazionale. In questa veste, è tenuta ad adempiere obblighi di esercizio — sorveglianza umana, monitoraggio, registrazione — che presuppongono però che il sistema sia stato già contrattualizzato in modo da renderli materialmente eseguibili. Se il contratto non prevede l’accesso ai log, il deployer non potrà conservarli; se il fornitore non dichiara il modello di base e le sue modifiche, il monitoraggio diviene formale; se la documentazione non esplicita i limiti di accuratezza per sottogruppi di pazienti, la sorveglianza umana si riduce a un’attestazione.
Gli obblighi europei e il doppio vincolo dell’acquisto
L’articolo 26 del Regolamento (UE) 2024/1689 impone al deployer di sistemi di IA ad alto rischio di adottare misure tecniche e organizzative per garantire l’uso conforme alle istruzioni del fornitore, assicurare sorveglianza umana, verificare la rappresentatività dei dati di input, monitorare il funzionamento e conservare i log. L’articolo 21, paragrafo 2, lettera d), della Direttiva (UE) 2022/2555 impone misure di gestione dei rischi relative alla sicurezza della catena di approvvigionamento, compresi aspetti relativi ai rapporti con fornitori diretti e indiretti. In entrambi i casi, l’obbligo è di esercizio ma l’adempimento è di acquisto: occorre costruire la sicurezza nella fase di procurement, non in quella di incident response. Il documento in commento propone di articolare le misure secondo uno strato strategico di governance e tre fasi — pianificazione, selezione e gestione — traducendo gli obblighi del deployer in clausole contrattuali e criteri di aggiudicazione verificabili.
Tale traduzione rappresenta il contributo principale del documento: non il catalogo delle misure di sicurezza, in larga parte noto, bensì la loro trasposizione in linguaggio negoziale e procedurale. Su tale traduzione si misura la funzione del DPO nelle organizzazioni sanitarie, chiamato a presidiare contemporaneamente la conformità GDPR, l’adempibilità degli obblighi AI Act e la gestione della catena di fornitura secondo NIS2.
Le minacce specifiche dell’IA tipizzate dalla norma
L’articolo 15, paragrafo 5, del Regolamento (UE) 2024/1689 enumera minacce specifiche dei sistemi di IA e qualifica la loro prevenzione come requisito di legge. L’avvelenamento dei dati consiste nella manipolazione dei dati di addestramento per corrompere il comportamento del modello in modo sistematico e non rilevabile da controlli perimetrali. Gli esempi antagonistici sono input costruiti per indurre output errati in fase di inferenza — perturbazioni impercettibili di un’immagine diagnostica. L’inversione del modello e l’inferenza di appartenenza ricostruiscono dati di addestramento partendo dal modello, o determinano se i dati di un paziente siano stati utilizzati nell’addestramento. Tali attacchi producono violazione di dati personali di categorie particolari. Il furto del modello comporta appropriazione di un asset e rimozione delle salvaguardie incorporate. L’iniezione di prompt e il jailbreaking riguardano sistemi generativi e manipolano il comportamento mediante input nascosti. La catena di fornitura insicura rende difficile verificare provenienza e integrità di modelli preaddestrati e librerie open source. La deriva del modello consiste nel degrado progressivo delle prestazioni. Il bias di automazione, l’opacità e l’allucinazione interessano infine la dimensione umana: l’eccessivo affidamento su output con limitata spiegabilità.
Richiedere al fornitore evidenza del presidio di tali minacce non è discrezione negoziale: è verifica di un requisito legale. Tuttavia, la loro operatività clinica passa sempre attraverso un comportamento umano — il clinico che accetta output senza verifica. Le misure di sorveglianza umana dell’articolo 14 dell’AI Act non sono efficaci se concepite come mera previsione formale: occorre che la persona disponga del tempo, delle informazioni e dell’autorità per dissentire, e che l’organizzazione non abbia costruito indicatori di performance che penalizzino tale scostamento.
Cosa devono fare le imprese
Il primo adempimento è la qualificazione giuridica preventiva del sistema prima della redazione dei capitolati: stabilire se sia dispositivo medico o componente di dispositivo, se sia sistema di IA ad alto rischio e per quale allegato, quale sia il ruolo del fornitore nei confronti del GDPR e della NIS2. Da tale qualificazione discende l’intero impianto documentale esigibile. Si suggerisce di formalizzare l’esito in documento sottoscritto congiuntamente dalla funzione tecnica, dal DPO e dalla funzione legale. Discende il trasferimento dei requisiti nel capitolato, traducendo gli obblighi di legge in specifiche tecniche verificabili e, per contrattualistica pubblica, in criteri di valutazione dell’offerta o clausole di esecuzione. La richiesta di documentazione sul modello — finalità, limitazioni note, metriche con popolazioni di riferimento, provenienza dei dati — si presta a criterio di valutazione qualitativa; l’obbligo di notifica delle vulnerabilità entro termine definito a clausola di esecuzione presidiata da penali; le certificazioni di sistema di gestione a elemento premiale ma non escludente.
La definizione contrattuale della disciplina dei dati deve coprire quattro profili: divieto di utilizzo dei dati del committente per addestramento salva autorizzazione scritta e specifica; localizzazione del trattamento con giurisdizioni ammesse per prompt, file, output e dati derivati; catena dei sub-responsabili con autorizzazione preventiva e comunicazione delle variazioni; restituzione e cancellazione al termine, menzionando espressamente non soltanto input ma anche output, log, embedding e dataset di messa a punto, con attestazione di avvenuta cancellazione. L’omessa menzione degli embedding e dei dataset di messa a punto costituisce lacuna ricorrente che rende la cancellazione inefficace.
Il governo dell’esercizio tra monitoraggio e notifica
In fase di esercizio, il presidio centrale è il monitoraggio delle prestazioni e della deriva, che richiede definizione preventiva di soglie di accettabilità e azioni conseguenti al loro superamento — dalla sospensione al ritorno al flusso manuale — e presuppone capacità di registrazione garantita contrattualmente. Il documento correttamente colloca il monitoraggio della deriva fra gli obblighi essenziali, non fra i “nice-to-have”: l’articolo 26, paragrafo 5, dell’AI Act impone al deployer di monitorare il funzionamento sulla base delle istruzioni per l’uso; il MDR impone sorveglianza post-commercializzazione. In assenza di monitoraggio, tali obblighi non risultano adempibili. Un aggiornamento di modello non può essere trattato alla stregua di una patch di sicurezza tradizionale, poiché ne muta il comportamento statistico.
Occorre predisporre raccordo delle notifiche mediante procedura interna che, a fronte di un evento, attivi contestualmente la valutazione ai fini dell’articolo 33 GDPR, dell’articolo 23 NIS2 (preallarme entro ventiquattro ore, notifica entro settantadue ore), dell’articolo 73 AI Act e della vigilanza sui dispositivi medici. La causa più frequente del mancato rispetto dei termini non è ignoranza della norma bensì assenza di soggetto individuato cui spetti qualificazione dell’evento nelle prime ore. È necessario mantenere inventario dei sistemi e modelli, registrando finalità, fornitore, categorie di dati, sub-responsabili, versione in esercizio e cronologia delle modifiche sostanziali, includendo funzionalità IA incorporate in prodotti acquisiti per altra finalità, che sfuggono con maggiore frequenza alla ricognizione.
La valutazione d’impatto e i limiti del modello di procurement
La valutazione d’impatto deve avviarsi in fase di selezione e non in fase di collaudo, estesa — ove ricorrano presupposti dell’articolo 27 AI Act o comunque in via prudenziale per sistemi che incidono su percorsi assistenziali — ai diritti fondamentali. Si suggerisce che non si limiti alla mappatura dei flussi ma affronti espressamente il rischio di prestazioni differenziate fra sottogruppi di pazienti, di contenuti erronei nei sistemi generativi, di eccessivo affidamento da parte del personale. Tuttavia, il documento incontra alcuni limiti critici. Il primo attiene al rapporto fra logica istantanea del procurement e natura adattiva dei sistemi: i sistemi di IA mutano continuamente, talora per decisione unilaterale del fornitore del modello sottostante, con il quale il committente non ha rapporto contrattuale. Il documento richiede comunicazione preventiva delle modifiche sostanziali, collocando l’omessa comunicazione come inadempimento, ma la sua efficacia pratica dipende da fattore esterno al contratto: capacità del fornitore intermedio di ottenere tale informazione dal fornitore del modello di base.
Il secondo profilo attiene all’asimmetria informativa e potere negoziale. Le clausole proposte — divieto di riuso dei dati per addestramento, localizzazione del trattamento, restituzione e cancellazione verificabile, notifica tempestiva delle vulnerabilità — sono tecnicamente ineccepibili. La loro negoziabilità però è inversamente proporzionale alla standardizzazione dell’offerta: un grande ospedale può imporle; una piccola struttura che sottoscrive condizioni generali di un servizio cloud internazionale difficilmente vi riuscirà. La via realistica non è il contratto individuale ma aggregazione della domanda mediante centrali di committenza e capitolati-tipo istituzionali. Non esiste, allo stato, un capitolato-tipo nazionale dedicato specificamente alla cybersicurezza dell’IA sanitaria.
Risorse e formazione per una governance stabile
Sul piano organizzativo è indispensabile la costituzione di un presidio interfunzionale stabile, che associ ingegneria clinica, sicurezza informatica, funzione clinica, DPO e funzione legale, con tracciamento documentale degli apporti e del benestare clinico. Tale tracciamento non è burocratico bensì fornisce evidenza di accountability spendibile davanti all’autorità di controllo per la protezione dei dati, in sede di verifica NIS2 o di sorveglianza post-commercializzazione. Il DPO partecipa in posizione consultiva e di sorveglianza ai sensi dell’articolo 39 GDPR e non assume responsabilità decisionali sull’acquisto: è opportuno esplicitare tale confine nel regolamento interno del presidio, per evitare conflitti con il requisito di indipendenza dell’articolo 38, paragrafo 3.
Si raccomanda formazione differenziata: per personale clinico, sui limiti dichiarati dello strumento, sul bias di automazione e sulla documentazione del disaccordo; per personale tecnico, sulle minacce specifiche e sulla gestione degli endpoint; per personale che redige contratti, sulla capacità di valutare l’evidenza di conformità prodotta dai fornitori. Quest’ultimo profilo è il più trascurato, poiché la qualità del capitolato dipende dalla competenza di chi lo scrive. Nessuna clausola, per quanto ben redatta, supplisce all’incapacità di valutare la risposta ricevuta. Infine, è opportuno collaudare periodicamente le procedure di ricaduta sui flussi di lavoro non assistiti dall’IA, verificando che il personale operi in assenza del sistema: una continuità operativa documentata ma mai provata non fornisce evidenza di effettiva operatività.
L’approfondimento completo di questo articolo è disponibile su 01magazine.it.
