Acquistare intelligenza artificiale in sanità in condizioni di sicurezza: le linee guida di procurement per la cybersecurity dell’IA sanitaria alla prova dell’AI Act, della NIS2 e del GDPR

Abstract

Il presente lavoro prende spunto da un documento frutto di un interessante contributo che si propone di definire le linee guida di procurement dedicate alla cybersicurezza dei sistemi di intelligenza artificiale acquisiti da ospedali ed erogatori di prestazioni sanitarie (AI&Partners: Procurement guidelines for AI cybersecurity within healthcare), e che propone di spostare il baricentro del presidio di sicurezza dal momento dell’esercizio a quello dell’acquisto, articolando le misure lungo uno strato strategico di governance e tre fasi di approvvigionamento denominate “plan”, “source” e “manage”. L’impianto è ancorato al Regolamento (UE) 2024/1689 (AI Act), alla Direttiva (UE) 2022/2555 (NIS2) e al decreto legislativo 138/2024, ai Regolamenti (UE) 2017/745 e 2017/746 sui dispositivi medici e sui diagnostici in vitro, al Regolamento (UE) 2016/679 (GDPR), al Regolamento (UE) 2025/327 sullo Spazio europeo dei dati sanitari e al Regolamento (UE) 2024/2847 (Cyber Resilience Act). Il contributo principale del presente lavoro di commento non risiede nel catalogo delle misure — in larga parte noto — bensì nella traduzione degli obblighi del deployer in clausole contrattuali e criteri di aggiudicazione verificabili, e proprio su tale traduzione si misura la tenuta della funzione del DPO nelle organizzazioni sanitarie.

Premessa

In premessa va detto che il perimetro dell’analisi è circoscritto. Non si tratta qui di valutare l’opportunità clinica dell’adozione di sistemi di intelligenza artificiale in ambito sanitario, questione che esula dalle competenze giuridiche e che attiene alla governance clinica e alle valutazioni di health technology assessment. Si tratta, piuttosto, di affrontare un problema di diritto applicato assai concreto: come un’organizzazione sanitaria — soggetto che nella tassonomia dell’AI Act riveste, nella generalità dei casi, la qualifica di “deployer” ai sensi dell’articolo 3, punto 4, del Regolamento (UE) 2024/1689, e che nella tassonomia della NIS2 è verosimilmente soggetto essenziale o importante del settore sanitario — possa adempiere obblighi che la legge le impone in fase di esercizio attraverso leve che essa esercita, di fatto, soltanto in fase di acquisto.

Il punto merita di essere esplicitato perché è il presupposto logico dell’intero ragionamento. Il deployer di un sistema di IA ad alto rischio è tenuto, in forza dell’articolo 26 dell’AI Act, ad adottare misure tecniche e organizzative idonee a garantire l’uso del sistema conformemente alle istruzioni del fornitore, ad assicurare la sorveglianza umana da parte di persone dotate di competenza e autorità, a verificare la pertinenza e rappresentatività dei dati di input nella misura in cui esercita il controllo su di essi, a monitorare il funzionamento del sistema e a conservare i log generati automaticamente. Trattasi di obblighi che presuppongono, tutti, che il sistema acquistato sia stato progettato e 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 sottostante né le sue sostituzioni, il deployer non potrà monitorare il funzionamento in modo significativo; se la documentazione d’uso non esplicita i limiti di accuratezza e le popolazioni sulle quali le metriche sono state stabilite, la sorveglianza umana si riduce a un adempimento formale.

Come noto, il medesimo meccanismo opera sul versante NIS2. 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 alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi”, e il decreto legislativo 138/2024 ha recepito tale impostazione nell’ordinamento nazionale. Anche qui, l’obbligo è di esercizio ma l’adempimento è di acquisto: la sicurezza della catena di fornitura si costruisce in sede di capitolato, non in sede di incident response.

L’analisi e il commento al documento che segue, muove da questa constatazione e si interroga su tre profili: la coerenza della tassonomia proposta dal documento con le qualificazioni giuridiche europee; l’effettiva azionabilità delle clausole contrattuali suggerite nel contesto, anche pubblicistico, degli affidamenti sanitari italiani; i limiti che una logica di procurement incontra quando l’oggetto dell’acquisto è un sistema il cui comportamento muta nel tempo.

Il contesto: perché il settore sanitario è il banco di prova della sicurezza dell’IA

L’intelligenza artificiale è ormai diffusa in diagnostica per immagini, supporto alle decisioni cliniche, monitoraggio dei pazienti, triage, automazione amministrativa e, in misura crescente, in strumenti generativi che redigono documentazione clinica. Si tratta di una ricognizione fattuale che trova riscontro nella prassi e che non necessita di enfasi.

Ciò che rileva, per quanto di stretto interesse in questa sede, è la combinazione di tre fattori che rendono il settore sanitario particolarmente esposto. Il primo è la natura dei dati trattati: dati relativi alla salute, categoria particolare ai sensi dell’articolo 9, paragrafo 1, del GDPR, il cui trattamento è vietato salve le condizioni di liceità del paragrafo 2 e la cui violazione produce, nella generalità dei casi, un rischio elevato per i diritti e le libertà degli interessati. Il secondo è la qualificazione del settore come altamente critico ai fini NIS2, con la conseguente applicazione del regime di gestione del rischio e di notifica degli incidenti. Il terzo è la sovrapposizione, frequente e non sempre percepita, con la disciplina dei dispositivi medici: quando il software di IA costituisce un dispositivo medico o un componente di sicurezza di un dispositivo, esso rientra nell’ambito dell’articolo 6, paragrafo 1, dell’AI Act e viene qualificato come sistema ad alto rischio, con tutto ciò che ne consegue in termini di requisiti di cui al Capo III, Sezione 2, del Regolamento.

In termini più pragmatici, un medesimo applicativo — poniamo, un modulo di triage radiologico — può essere contemporaneamente un dispositivo medico soggetto al Regolamento (UE) 2017/745, un sistema di IA ad alto rischio soggetto al Regolamento (UE) 2024/1689, un trattamento di dati sanitari soggetto al GDPR e un asset della catena di fornitura rilevante ai fini della NIS2. Si ritiene che proprio questa stratificazione, e non la novità tecnologica in sé, costituisca la difficoltà operativa principale per le strutture sanitarie: non già l’assenza di regole, bensì la necessità di comporre regimi concepiti separatamente e con logiche di conformità differenti — conformità di prodotto per il MDR e per l’AI Act, conformità di processo per il GDPR, conformità di gestione del rischio per la NIS2.

Il quadro normativo di riferimento

La disciplina europea sull’intelligenza artificiale

Il Regolamento (UE) 2024/1689 costituisce il riferimento primario. Rilevano, ai fini che qui interessano, alcune disposizioni specifiche.

L’articolo 15 stabilisce che i sistemi di IA ad alto rischio siano progettati e sviluppati “in modo tale da conseguire un adeguato livello di accuratezza, robustezza e cibersicurezza e da operare in modo coerente sotto tali aspetti durante tutto il loro ciclo di vita”. La norma prosegue specificando che le soluzioni tecniche volte ad affrontare le vulnerabilità specifiche dell’IA devono comprendere, se del caso, misure “di prevenzione, accertamento, risposta, risoluzione e controllo per quanto riguarda gli attacchi che cercano di manipolare il set di dati di addestramento (avvelenamento dei dati) o i componenti preaddestrati utilizzati nell’addestramento (avvelenamento dei modelli), gli input concepiti per far sì che il modello di IA commetta un errore (esempi antagonistici o evasione dal modello), gli attacchi alla riservatezza o i difetti del modello”. Si tratta di un dato normativo di notevole importanza pratica: le minacce che il documento in commento elenca nella sua sezione dedicata ai rischi specifici dell’IA non sono una costruzione dottrinale, ma categorie espressamente tipizzate dal legislatore europeo. Di conseguenza, richiedere al fornitore evidenza del presidio di tali minacce non è una pretesa negoziale discrezionale: è la verifica di un requisito legale di prodotto.

L’articolo 10 disciplina la governance dei dati di addestramento, validazione e prova, imponendo che tali set siano pertinenti, sufficientemente rappresentativi e, nella misura del possibile, privi di errori e completi in funzione della finalità prevista, con attenzione alle caratteristiche proprie del contesto geografico, comportamentale o funzionale di utilizzo. L’articolo 12 impone la registrazione automatica degli eventi (log) lungo il ciclo di vita. L’articolo 13 impone la trasparenza verso il deployer e la fornitura di istruzioni per l’uso contenenti, tra l’altro, il livello di accuratezza e le metriche pertinenti, nonché le circostanze prevedibili che possono condurre a rischi. L’articolo 14 disciplina la sorveglianza umana.

Sul versante del deployer rilevano l’articolo 26, già richiamato, e l’articolo 27, che impone la valutazione d’impatto sui diritti fondamentali a determinati soggetti, tra cui gli organismi di diritto pubblico, per i sistemi ad alto rischio di cui all’allegato III. Va detto che la portata applicativa dell’articolo 27 agli enti del Servizio sanitario nazionale merita un vaglio caso per caso, poiché il riferimento è all’allegato III e non all’allegato I, e numerosi sistemi di IA sanitari rientrano nell’alto rischio proprio in forza dell’allegato I, cioè per il tramite della normativa di prodotto. Non si ha evidenza, allo stato, di orientamenti interpretativi consolidati che risolvano in modo definitivo il punto; si suggerisce pertanto prudenza, nel senso di condurre comunque una valutazione di impatto sui diritti fondamentali integrata alla valutazione d’impatto sulla protezione dei dati, quando il sistema incide su percorsi assistenziali.

Rileva infine l’articolo 4, che impone a fornitori e deployer di adottare misure per garantire un livello sufficiente di alfabetizzazione in materia di IA del proprio personale. Si tratta di una disposizione applicabile a decorrere dal 2 febbraio 2025, la cui attuazione nel settore sanitario presenta una specificità: il destinatario della formazione non è soltanto il personale tecnico, ma il clinico che utilizza l’output del sistema e che, per effetto del bias di automazione, può attribuirgli un’affidabilità superiore a quella dichiarata.

La disciplina sulla sicurezza delle reti e dei sistemi informativi

La Direttiva (UE) 2022/2555, recepita in Italia con il decreto legislativo 138/2024, impone ai soggetti essenziali e importanti del settore sanitario misure di gestione dei rischi di cui all’articolo 21 e obblighi di notifica degli incidenti significativi secondo le scansioni temporali dell’articolo 23 — preallarme entro ventiquattro ore, notifica entro settantadue ore, relazione finale entro un mese. L’Agenzia per la cybersicurezza nazionale è l’autorità competente nell’ordinamento interno.

Il profilo che qui interessa è duplice. Da un lato, la già citata sicurezza della catena di approvvigionamento, che impone di considerare la qualità dei prodotti e le pratiche di sicurezza dei fornitori, ivi compresi i loro processi di sviluppo sicuro. Dall’altro, l’articolo 20 della Direttiva, che attribuisce agli organi di gestione la responsabilità di approvare le misure e li obbliga a seguire formazioni specifiche: di conseguenza, la decisione di acquistare un sistema di IA che incide su funzioni cliniche critiche non è una scelta tecnica delegabile, ma una decisione che investe la responsabilità dell’organo amministrativo.

Si osserva inoltre che la nozione di “incidente” ai fini NIS2 e quella di “incidente grave” ai fini dell’articolo 73 dell’AI Act non coincidono, così come non coincidono con la nozione di violazione dei dati personali di cui all’articolo 4, punto 12, del GDPR né con quella di incidente da vigilanza del MDR. Un medesimo evento — poniamo, l’esfiltrazione di dati di addestramento tramite attacco di inversione del modello — può attivare simultaneamente quattro canali di notifica verso quattro autorità diverse, con scansioni temporali differenti. La predisposizione contrattuale di obblighi informativi tempestivi a carico del fornitore è, pertanto, condizione di adempibilità degli obblighi pubblicistici del committente.

La disciplina di prodotto: dispositivi medici e Cyber Resilience Act

I Regolamenti (UE) 2017/745 e 2017/746 contengono, nei requisiti generali di sicurezza e prestazione di cui all’allegato I, prescrizioni relative al software, alla sua affidabilità, alla ripetibilità e alla sicurezza informatica, nonché obblighi di sorveglianza post-commercializzazione e di vigilanza. La qualificazione come dispositivo medico comporta la marcatura CE e la valutazione di conformità secondo le procedure applicabili alla classe di rischio.

Il Regolamento (UE) 2024/2847, Cyber Resilience Act, introduce requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali. I prodotti coperti dal MDR o dall’IVDR sono trattati nell’ambito di quei regimi anziché del CRA: si tratta di un coordinamento necessario a evitare duplicazioni di valutazione di conformità, ma che in sede di procurement richiede al committente di accertare preliminarmente quale disciplina di prodotto si applichi, poiché da essa discende la natura dell’evidenza documentale esigibile dal fornitore.

La protezione dei dati personali e lo Spazio europeo dei dati sanitari

Il Regolamento (UE) 2016/679 governa il trattamento dei dati sanitari che costituiscono l’input, l’output e, talora, il materiale di addestramento dei sistemi in questione. Rilevano in particolare l’articolo 9 sulle categorie particolari, l’articolo 22 sul processo decisionale automatizzato, l’articolo 25 sulla protezione dei dati fin dalla progettazione e per impostazione predefinita, l’articolo 28 sui responsabili del trattamento e sulle autorizzazioni ai sub-responsabili, l’articolo 32 sulla sicurezza del trattamento e l’articolo 35 sulla valutazione d’impatto.

L’articolo 32, paragrafo 1, del GDPR merita di essere richiamato nella sua formulazione testuale, poiché costituisce il fondamento normativo dell’approccio proporzionale che il documento in commento adotta: il titolare e il responsabile mettono in atto misure tecniche e organizzative adeguate “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche”. In sostanza, la norma consente — anzi impone — di graduare le misure. In termini più pragmatici, essa giustifica la distinzione, proposta dal documento, fra un livello di base per strumenti amministrativi a basso impatto e un livello rafforzato per sistemi che intervengono su processi clinici critici: la differenziazione non è un cedimento sul piano della tutela, ma l’applicazione del principio di adeguatezza.

Quanto all’articolo 35, la valutazione d’impatto è obbligatoria quando il trattamento può presentare un rischio elevato; le Linee guida WP248 rev.01 in materia di valutazione d’impatto sulla protezione dei dati, fatte proprie dal Comitato europeo per la protezione dei dati, individuano criteri fra i quali il trattamento su larga scala di dati appartenenti a categorie particolari, l’uso innovativo di soluzioni tecnologiche e la valutazione o attribuzione di punteggio. Nell’ordinamento interno, il provvedimento del Garante per la protezione dei dati personali n. 467 dell’11 ottobre 2018 ha adottato l’elenco delle tipologie di trattamenti soggetti al requisito di valutazione d’impatto, nel quale figurano trattamenti di dati sanitari in ambito di assistenza mediante l’uso di tecnologie innovative. Appare chiaro allo scrivente che, nella quasi totalità dei casi di IA clinica, la valutazione d’impatto sia dovuta e non costituisca oggetto di apprezzamento discrezionale.

Il Regolamento (UE) 2025/327 sullo Spazio europeo dei dati sanitari aggiunge un livello ulteriore, disciplinando l’uso primario e secondario dei dati sanitari elettronici e i requisiti dei sistemi di cartella clinica elettronica. Le sue scansioni applicative sono dilazionate nel tempo, ma la circostanza non esime il committente dal prevedere, già oggi, clausole di adeguamento prospettico: un sistema acquisito nel 2026 con un ciclo di vita di sette anni dovrà operare in un contesto normativo nel quale l’EHDS sarà pienamente efficace.

Il quadro nazionale

Nell’ordinamento interno, oltre al decreto legislativo 138/2024 e al decreto legislativo 196/2003 come modificato dal decreto legislativo 101/2018, rileva la legge 132/2025 recante disposizioni e deleghe in materia di intelligenza artificiale, che contiene previsioni di principio sull’impiego dell’IA in ambito sanitario, sull’informazione del paziente e sulla riserva della decisione in capo al professionista sanitario, nonché sull’architettura delle autorità nazionali competenti ai fini dell’AI Act. Si segnala altresì, per gli acquisti delle amministrazioni e degli enti del Servizio sanitario nazionale, la rilevanza del decreto legislativo 36/2023, il cui articolo 30 disciplina l’uso di procedure automatizzate nel ciclo di vita dei contratti pubblici e il cui impianto generale sui criteri di aggiudicazione e sui requisiti di esecuzione offre la base giuridica per tradurre in criteri di gara le esigenze di sicurezza qui discusse.

Va infine menzionato, con riferimento allo scenario della documentazione clinica generata in modo ambientale mediante registrazione delle consultazioni, l’articolo 4 della legge 300/1970, nella misura in cui strumenti di registrazione continua all’interno di ambulatori possano determinare, anche solo in via indiretta, un controllo a distanza dell’attività del personale sanitario dipendente. Si ritiene che il profilo giuslavoristico sia frequentemente sottovalutato nella valutazione di tali soluzioni.

L’architettura proposta: strato strategico e fasi di pianificazione, selezione e gestione

Si possono articolare le misure secondo uno strato generale e tre fasi, già suggerito in contributi internazionali (AI&Partners: Procurement guidelines for AI cybersecurity within healthcare) assegnando a ciascuna misura un codice identificativo. L’impostazione riprende modelli consolidati di procurement e vi innesta le specificità dell’IA. Conviene esaminarne i contenuti nella prospettiva della loro traducibilità giuridica.

Lo strato strategico comprende l’adozione di una strategia e di una governance che incorporino il rischio IA fra i requisiti di ogni decisione di acquisto, eventualmente allineate a un sistema di gestione dell’intelligenza artificiale secondo la norma ISO/IEC 42001; l’allocazione di risorse finanziarie e di competenze specifiche; il mantenimento di un inventario aggiornato dei sistemi, dei modelli e dei fornitori, definito “AI bill of materials”; l’identificazione e la remediation delle vulnerabilità specifiche mediante threat intelligence e test antagonistici; la governance degli aggiornamenti e del riaddestramento, con monitoraggio della deriva; un’architettura sicura che isoli i sistemi di IA e controlli l’accesso a modelli, dati di addestramento ed endpoint di inferenza; la continuità delle funzioni cliniche dipendenti dall’IA con ricaduta sicura su flussi di lavoro non assistiti; la registrazione e il monitoraggio continui di input, output e comportamento; la tutela di riservatezza, integrità e disponibilità dei dati utilizzati e derivati, inclusi prompt, output ed embedding; l’alfabetizzazione del personale, con specifico riguardo al bias di automazione; la valutazione dell’efficacia delle misure.

Diverse di queste voci non sono raccomandazioni di buona pratica ma riformulazioni operative di obblighi legali. L’inventario dei sistemi corrisponde, nella sostanza, a quanto necessario per adempiere l’articolo 30 del GDPR quanto ai trattamenti e l’articolo 21 della NIS2 quanto agli asset; l’alfabetizzazione corrisponde all’articolo 4 dell’AI Act; la registrazione degli eventi corrisponde agli articoli 12 e 26, paragrafo 6, dell’AI Act; la continuità operativa corrisponde all’articolo 21, paragrafo 2, lettera c), della NIS2 e all’articolo 32, paragrafo 1, lettera b), del GDPR.

La fase di pianificazione concerne l’identificazione dei rischi — di sicurezza, di sicurezza clinica e per i diritti fondamentali — la determinazione della qualificazione giuridica del sistema prima dell’avvio della procedura, l’adozione di una politica di sicurezza della catena di fornitura estesa a modelli, dataset, componenti preaddestrati e servizi di terzi, la definizione dei requisiti di sicurezza nella documentazione di gara, la predisposizione di clausole contrattuali specifiche, l’inserimento di clausole dedicate ove l’IA sia erogata come servizio cloud o tramite interfaccia applicativa, e il coinvolgimento trasversale delle funzioni interne.

La fase di selezione concerne la preferenza per fornitori che dimostrino una postura certificata o valutata indipendentemente, l’esecuzione della valutazione d’impatto sulla protezione dei dati e, ove pertinente, sui diritti fondamentali, la verifica effettiva — e non meramente dichiarativa — dei requisiti tecnici, l’approvvigionamento dei modelli attraverso canali autorizzati con verifica di provenienza e integrità, la richiesta di un ciclo di sviluppo sicuro e la trasparenza sui componenti di terzi e open source.

La fase di gestione concerne l’obbligo contrattuale di remediation delle vulnerabilità e dei difetti di modello lungo il ciclo di vita, il mantenimento dell’inventario con versioni e modifiche sostanziali, la notifica degli incidenti coerente con AI Act, NIS2 e MDR/IVDR, il miglioramento continuo con monitoraggio della deriva e delle attività antagonistiche, e le procedure di dismissione sicura comprensive della cancellazione di modelli, prompt, output, embedding e dataset di messa a punto.

I rischi specifici dell’intelligenza artificiale e la loro rilevanza giuridica

Le guide lines esaminate enumerano le minacce proprie dei sistemi di IA. Conviene riprenderle definendole in modo incrementale e indicandone la rilevanza sul piano della conformità.

L’avvelenamento dei dati consiste nella manipolazione dei dati di addestramento o di messa a punto al fine di corrompere il comportamento del modello. In sostanza, l’attaccante non violenta il sistema in esercizio, ma ne contamina a monte la fonte di apprendimento, inducendolo a classificare erroneamente determinati input. In termini più pragmatici: un modello diagnostico addestrato su un dataset contaminato può sistematicamente omettere il riconoscimento di un reperto in presenza di un determinato marcatore, senza che alcun controllo di sicurezza perimetrale possa rilevarlo. La rilevanza giuridica è immediata, poiché l’articolo 15, paragrafo 5, dell’AI Act menziona espressamente tale minaccia e l’articolo 10 impone presidi sulla qualità dei dati.

Gli esempi antagonistici, o evasione, consistono in input appositamente costruiti per indurre output errati in fase di inferenza — ad esempio perturbazioni impercettibili di un’immagine diagnostica. Anche qui la norma tipizza la minaccia.

L’inversione del modello e l’inferenza di appartenenza consistono, rispettivamente, nella ricostruzione di dati di addestramento a partire dal modello e nella determinazione del fatto che i dati di un determinato paziente siano stati utilizzati per l’addestramento. Si tratta di attacchi che producono, con elevata probabilità, una violazione di dati personali rilevante ai sensi degli articoli 33 e 34 del GDPR, con il profilo aggravante dell’appartenenza alle categorie particolari.

Il furto del modello o dei pesi comporta l’appropriazione di un asset e, inoltre, la possibilità di rimuovere le salvaguardie incorporate. L’iniezione di prompt e il jailbreaking riguardano i sistemi generativi e consistono nella manipolazione del comportamento del modello mediante input appositamente costruiti, eventualmente nascosti all’interno dei documenti che il modello elabora. La catena di fornitura insicura riguarda la difficoltà di verificare provenienza, integrità e sicurezza di modelli preaddestrati, dataset di terzi e librerie open source. La deriva del modello consiste nel degrado progressivo delle prestazioni al mutare della pratica clinica, delle popolazioni o delle distribuzioni dei dati. Il bias di automazione, l’opacità e l’allucinazione concernono infine la dimensione umana: l’eccessivo affidamento sull’output, aggravato dalla limitata spiegabilità e, nei sistemi generativi, dalla produzione di contenuti plausibili ma errati.

Su quest’ultimo punto si ritiene di dover insistere. La traduzione di un difetto tecnico in un danno clinico passa, quasi sempre, attraverso un comportamento umano: il clinico che accetta un output senza verifica. Di conseguenza, le misure di sorveglianza umana di cui all’articolo 14 dell’AI Act non sono efficaci se concepite come mera previsione formale di un “uomo nel circuito”: occorre che la persona incaricata disponga del tempo, delle informazioni e dell’autorità per discostarsi dall’output, e che l’organizzazione non abbia costruito indicatori di performance che penalizzino tale scostamento.

Profili critici dell’impostazione proposta

Pur apprezzandosi l’utilità sistematica del documento, si ritiene che alcuni profili meritino un vaglio critico.

Il primo attiene al rapporto fra logica di procurement e natura adattiva dei sistemi. Il procurement è, per sua struttura, un atto istantaneo che fotografa un oggetto in un dato momento; i sistemi di IA — in particolare quelli basati su modelli di base accessibili tramite interfaccia applicativa — mutano continuamente, talora per decisione unilaterale del fornitore del modello sottostante, soggetto con il quale il committente non ha alcun rapporto contrattuale. Le guide lines esaminate affrontano il problema richiedendo la comunicazione preventiva delle modifiche sostanziali e qualificando l’omessa comunicazione come inadempimento. Appare chiaro allo scrivente che si tratti del presidio corretto sul piano giuridico, ma che la sua efficacia pratica dipenda da un fattore esterno al contratto: la capacità del fornitore intermedio di ottenere, a sua volta, tale informazione dal fornitore del modello. Si suggerisce pertanto di richiedere non soltanto l’obbligo di comunicazione, ma l’evidenza documentale che tale obbligo sia stato trasferito a monte nella catena, secondo una logica di flow-down coerente con l’articolo 28, paragrafo 4, del GDPR quanto ai sub-responsabili.

Il secondo profilo attiene all’asimmetria informativa e al potere negoziale. Le clausole proposte — divieto di utilizzo dei dati del cliente per l’addestramento salva autorizzazione espressa, localizzazione del trattamento in giurisdizioni determinate, restituzione e cancellazione verificabile di input, output, log, embedding e dataset di messa a punto, notifica tempestiva delle vulnerabilità — sono tecnicamente ineccepibili. Tuttavia, la loro negoziabilità è inversamente proporzionale alla standardizzazione dell’offerta: un grande ospedale che acquisisce una soluzione su misura può imporle; una struttura di piccole dimensioni che sottoscrive condizioni generali di un servizio cloud internazionale difficilmente vi riuscirà. Le guide lines dimostrano consapevolezza del problema, poiché articolano il presidio su due livelli e dedicano uno scenario specifico allo studio medico di base. Si ritiene nondimeno che occorra una riflessione ulteriore, di ordine sistemico: nella misura in cui le strutture minori non dispongono di potere negoziale, la via realistica non è il contratto individuale ma l’aggregazione della domanda, mediante centrali di committenza e capitolati-tipo, ovvero la disponibilità di condizioni contrattuali standard elaborate a livello istituzionale. Non si ha evidenza, allo stato, di capitolati-tipo nazionali dedicati specificamente alla cybersicurezza dei sistemi di IA sanitari.

Il terzo profilo attiene alla verificabilità dell’evidenza. Le guide lines raccomandano di verificare i requisiti tecnici in sede di selezione, anziché affidarsi alle dichiarazioni del fornitore, e di commissionare ove possibile test indipendenti su input rappresentativi e antagonistici. Si tratta di un’indicazione metodologicamente corretta che tuttavia presuppone competenze — ingegneria clinica, fisica sanitaria, sicurezza del machine learning — non diffusamente presenti nelle strutture sanitarie. Il rischio concreto, secondo il parere di chi scrive, è che la verifica si risolva nel riscontro formale del possesso di certificazioni, con un effetto di spostamento della fiducia dal fornitore all’organismo di certificazione che non equivale a una verifica sostanziale. La certificazione secondo la norma ISO/IEC 42001 attesta l’esistenza di un sistema di gestione, non la robustezza di uno specifico modello rispetto a specifiche minacce; analogamente, la marcatura CE attesta la conformità ai requisiti applicabili al momento della valutazione, non l’assenza di deriva successiva.

Il quarto profilo attiene al coordinamento fra i canali di notifica, già accennato. Si ritiene auspicabile che, in sede di contratto, si definisca un’unica nozione convenzionale di “evento rilevante” a carico del fornitore, più ampia di ciascuna delle nozioni legali, con obbligo di comunicazione immediata e onere a carico del committente di qualificare l’evento ai fini delle singole discipline. Diversamente, il fornitore tenderà a notificare soltanto ciò che ritiene rientrante nella propria valutazione di rilevanza, privando il committente della possibilità di rispettare il termine di ventiquattro ore per il preallarme NIS2.

Il quinto profilo, infine, attiene alla distinzione — proposta nelle guide lines esaminate — fra misure raccomandate e misure “nice-to-have”, fra le quali queste ultime includono gli audit algoritmici indipendenti, gli strumenti di spiegabilità e il monitoraggio continuo della deriva. Si ritiene che la collocazione del monitoraggio della deriva fra le misure facoltative sia, quantomeno per i sistemi che incidono su decisioni cliniche, difficilmente sostenibile sul piano giuridico: l’articolo 26, paragrafo 5, dell’AI Act impone al deployer di monitorare il funzionamento del sistema sulla base delle istruzioni per l’uso e di informare il fornitore quando ritenga che l’uso possa comportare un rischio; il MDR impone la sorveglianza post-commercializzazione. In assenza di monitoraggio delle prestazioni, tali obblighi risultano, a giudizio dello scrivente, non adempibili.

Gli scenari applicativi come metodo

Le guide lines in commento illustrano tre scenari: un sistema di triage radiologico acquisito da un grande ospedale, un servizio generativo di documentazione clinica ambientale acquisito da un centro medico privato e un chatbot amministrativo preconfezionato acquisito da uno studio di medicina generale. Il metodo è apprezzabile perché mostra la graduazione delle misure in funzione della criticità e delle risorse.

Dal primo scenario si trae la conferma che, per i sistemi che incidono sulla priorità di refertazione, il presidio essenziale non è perimetrale bensì clinico: la verifica della sensibilità e specificità reali rispetto agli esiti clinici, e non rispetto ai soli benchmark del fornitore; la stratificazione delle metriche di accuratezza per sottogruppi di pazienti; la registrazione dei casi segnalati, dei punteggi di confidenza e delle sovrascritture da parte del radiologo. Quest’ultimo dato merita attenzione: il tasso di sovrascrittura è, al tempo stesso, un indicatore di qualità del modello e un indicatore di effettività della sorveglianza umana. Un tasso prossimo allo zero può segnalare eccellenza del modello oppure bias di automazione, e la distinzione fra le due ipotesi richiede un’analisi clinica.

Dal secondo scenario si traggono i profili più delicati sul piano della protezione dei dati: il trattamento di audio di consultazione costituisce trattamento di dati relativi alla salute e, verosimilmente, di dati di terzi menzionati nel corso del colloquio; la trasmissione a un fornitore di modello di base ospitato all’estero attiva la disciplina dei trasferimenti di cui al Capo V del GDPR; la firma obbligatoria del medico prima dell’archiviazione della nota costituisce la misura di sorveglianza umana essenziale. Si aggiunge il già richiamato profilo di cui all’articolo 4 della legge 300/1970 e, non da ultimo, la necessità di informare il paziente e di disciplinare la base giuridica della registrazione.

Dal terzo scenario si trae una lezione di proporzionalità: per un chatbot amministrativo che non accede a sistemi clinici, le misure si riducono alla verifica del perimetro funzionale, al divieto di riuso dei dati conversazionali, alla disponibilità di un canale alternativo e alla verifica periodica delle risposte. Si ritiene tuttavia che un presidio non debba mai mancare, nemmeno nelle realtà minime: la delimitazione contrattuale e tecnica dell’ambito funzionale, affinché lo strumento non fornisca indicazioni assimilabili a consigli clinici. Un chatbot che, interrogato su un sintomo, formuli una risposta orientativa può collocarsi, a seconda della finalità dichiarata, nell’ambito di applicazione della normativa sui dispositivi medici, con conseguenze qualificatorie che lo studio acquirente non è in grado di gestire.

Adempimenti operativi per il DPO e per le strutture sanitarie

Sul piano pratico, il primo adempimento da collocare temporalmente è la qualificazione giuridica preventiva del sistema, da effettuarsi prima della redazione degli atti di gara e non dopo l’aggiudicazione: occorre stabilire se l’applicativo sia dispositivo medico o componente di sicurezza di un dispositivo, se sia sistema di IA ad alto rischio ai sensi dell’articolo 6 del Regolamento (UE) 2024/1689 e in forza di quale allegato, se il fornitore operi come responsabile del trattamento ai sensi dell’articolo 28 del GDPR oppure come titolare autonomo, e se il servizio rientri nel perimetro della catena di fornitura rilevante ai fini del decreto legislativo 138/2024. Da tale qualificazione discende l’intero impianto documentale esigibile, sicché un errore in questa fase si propaga a tutte le successive; si suggerisce di formalizzare l’esito in un documento sottoscritto congiuntamente dalla funzione tecnica, dal DPO e dalla funzione legale.

Discende da ciò la mappatura dei requisiti nel capitolato, che consiste nel tradurre gli obblighi di legge in specifiche tecniche verificabili e, ove l’ente operi in regime di contrattualistica pubblica, in requisiti di partecipazione, criteri di valutazione dell’offerta tecnica o clausole di esecuzione a seconda della loro natura. In termini più pragmatici, la richiesta di documentazione sul modello — finalità prevista, limitazioni note, metriche di prestazione con indicazione delle popolazioni su cui sono state stabilite, provenienza dei dati di addestramento — si presta a costituire criterio di valutazione qualitativa; l’obbligo di notifica delle vulnerabilità entro un termine definito si presta a costituire clausola di esecuzione presidiata da penali; il possesso di certificazioni di sistema di gestione si presta, con le cautele sopra illustrate, a costituire elemento premiale ma non requisito escludente, per non restringere indebitamente la concorrenza.

Strettamente connessa è la definizione contrattuale della disciplina dei dati, che deve coprire quattro profili distinti e spesso confusi fra loro: l’utilizzo dei dati del committente per l’addestramento o il miglioramento dei modelli, che si suggerisce di vietare salva autorizzazione scritta e specifica preceduta da autonoma valutazione; la localizzazione del trattamento, con indicazione delle giurisdizioni ammesse per prompt, file caricati, output e dati derivati; la catena dei sub-responsabili, con obbligo di autorizzazione preventiva e comunicazione delle variazioni; la restituzione e cancellazione al termine del rapporto, che deve menzionare espressamente non soltanto i dati di input ma anche gli output generati, i log, gli embedding e gli eventuali dataset di messa a punto, con rilascio di attestazione di avvenuta cancellazione. Si osserva che l’omessa menzione degli embedding e dei dataset di messa a punto costituisce una lacuna ricorrente nei contratti esaminabili nella prassi, e che tale lacuna rende la cancellazione sostanzialmente inefficace.

Occorre poi presidiare la valutazione d’impatto, da avviarsi in fase di selezione e non in fase di collaudo, estesa — ove ricorrano i presupposti dell’articolo 27 dell’AI Act o comunque in via prudenziale per i sistemi che incidono su percorsi assistenziali — ai diritti fondamentali. Si suggerisce che la valutazione non si limiti alla mappatura dei flussi, ma affronti espressamente il rischio di prestazioni differenziate fra sottogruppi di pazienti, il rischio di contenuti clinici erronei o fabbricati nei sistemi generativi e il rischio di eccessivo affidamento da parte del personale, traducendo gli esiti in requisiti verificabili quali l’esposizione dei punteggi di confidenza, la revisione umana obbligatoria o la limitazione delle decisioni interamente automatizzate.

Sul piano organizzativo, si ritiene indispensabile la costituzione di un presidio interfunzionale stabile, che associ ingegneria clinica, sicurezza informatica, funzione clinica di riferimento, DPO e funzione legale, con tracciamento documentale degli apporti e del benestare clinico: tale tracciamento non ha finalità burocratiche, bensì costituisce l’evidenza di accountability spendibile tanto davanti all’autorità di controllo per la protezione dei dati quanto in sede di verifica NIS2 o di sorveglianza post-commercializzazione. Il DPO, va precisato, partecipa in posizione consultiva e di sorveglianza ai sensi dell’articolo 39 del GDPR e non assume responsabilità decisionali sull’acquisto: si suggerisce di esplicitare tale confine nel regolamento interno del presidio, per evitare conflitti con il requisito di indipendenza di cui all’articolo 38, paragrafo 3.

Quanto alla fase di esercizio, il presidio centrale è il monitoraggio delle prestazioni e della deriva, che richiede la definizione preventiva di soglie di accettabilità e delle azioni conseguenti al loro superamento — dalla sospensione della funzionalità al ritorno al flusso manuale — e che presuppone l’esistenza, contrattualmente garantita, di capacità di registrazione adeguate. A esso si affianca la gestione delle modifiche di modello, che impone di integrare gli aggiornamenti e i riaddestramenti del fornitore nelle procedure interne di change management e di gestione del rischio clinico, con test di regressione rispetto a parametri di sicurezza clinica prima della messa in produzione: appare chiaro allo scrivente che un aggiornamento di modello non possa essere trattato alla stregua di una patch di sicurezza di un applicativo tradizionale, poiché ne muta il comportamento statistico e non soltanto la superficie di attacco.

Va inoltre predisposto il raccordo delle notifiche, mediante l’adozione di una procedura interna che, a fronte di un evento comunicato dal fornitore o rilevato internamente, attivi contestualmente la valutazione ai fini dell’articolo 33 del GDPR, dell’articolo 23 della NIS2 come recepito dal decreto legislativo 138/2024, dell’articolo 73 dell’AI Act e della vigilanza sui dispositivi medici, con responsabilità e termini assegnati nominativamente. L’esperienza applicativa dei sistemi di gestione suggerisce che la causa più frequente del mancato rispetto dei termini non sia l’ignoranza della norma, bensì l’assenza di un soggetto individuato cui spetti la qualificazione dell’evento nelle prime ore.

Occorre altresì mantenere l’inventario dei sistemi e dei modelli, che deve registrare per ciascun sistema la finalità prevista, il fornitore del modello o del servizio, il modello di distribuzione, le interfacce applicative, le categorie di dati trattati, i sub-responsabili, le misure di sorveglianza umana, le modalità di ricaduta e la versione in esercizio con la cronologia delle modifiche sostanziali. Si sottolinea la necessità di censire anche le funzionalità di IA incorporate all’interno di prodotti acquisiti per altra finalità — moduli predittivi all’interno di una cartella clinica elettronica, assistenti generativi all’interno di una piattaforma collaborativa, strumenti di IA utilizzati dal fornitore nell’erogazione di servizi professionali — poiché proprio tali funzionalità sfuggono con maggiore frequenza alla ricognizione.

Si raccomanda infine la formazione differenziata, che per il personale clinico deve concentrarsi sui limiti dichiarati dello strumento, sul bias di automazione e sulle modalità di documentazione del disaccordo con l’output; per il personale tecnico, sulle minacce specifiche e sulla gestione degli endpoint di inferenza; per il personale che redige e gestisce i contratti, sulla capacità di leggere e valutare l’evidenza di conformità prodotta dai fornitori. Tale ultimo profilo è, secondo il parere di chi scrive, il più trascurato: la qualità del capitolato dipende dalla competenza di chi lo scrive, e nessuna clausola, per quanto ben redatta, supplisce all’incapacità di valutare la risposta ricevuta. Non da ultimo, si suggerisce di predisporre e di collaudare periodicamente le procedure di ricaduta sui flussi di lavoro non assistiti dall’IA, verificando che il personale sappia operare in assenza del sistema: una continuità operativa documentata ma mai provata non fornisce evidenza di effettiva operatività.

Conclusioni

Il documento esaminato si colloca in una produzione di indirizzo che non ha natura vincolante e che, dichiaratamente, mappa le prassi senza qualificarne alcuna come ottimale. Tale cautela metodologica è condivisibile, in una materia nella quale gli strumenti di valutazione della robustezza dei modelli sono ancora in fase di maturazione e nella quale le norme tecniche armonizzate destinate a sostenere la presunzione di conformità all’articolo 15 dell’AI Act non risultano, allo stato, disponibili in forma definitiva. Non si ha evidenza, allo stato, di uno standard consolidato per la misurazione della robustezza antagonistica dei modelli diagnostici, e tale assenza si riverbera direttamente sulla verificabilità dei requisiti che il committente può esigere.

Restano aperte, a giudizio dello scrivente, alcune questioni specifiche. La prima concerne il riparto di responsabilità lungo la catena fra fornitore del sistema, fornitore del modello di base e struttura sanitaria deployer, in particolare quando il mutamento del modello sottostante avviene per decisione di un soggetto estraneo al rapporto contrattuale: la disciplina europea offre strumenti qualificatori, ma la loro applicazione a catene con tre o più livelli richiederà un affinamento interpretativo che potrà venire tanto dalla Commissione quanto dalle autorità nazionali.

La seconda concerne la sostenibilità del modello per le strutture di minori dimensioni. Si ritiene che l’approccio graduato proposto dal documento sia corretto, ma che esso debba essere sorretto da strumenti collettivi — capitolati-tipo, condizioni standard, qualificazione preventiva dei fornitori — in assenza dei quali il divario fra grandi aziende sanitarie e piccole strutture è destinato ad ampliarsi, con effetti sul livello complessivo di sicurezza del sistema sanitario.

La terza concerne la governance degli aggiornamenti dei sistemi di IA incorporati in dispositivi medici, laddove il riaddestramento può integrare o meno una modifica sostanziale rilevante ai fini della valutazione di conformità: la questione, nota da tempo, assume maggiore rilievo con l’entrata a regime dei requisiti dell’AI Act per i sistemi ad alto rischio di cui all’allegato I, le cui scansioni applicative sono differite rispetto al grosso del Regolamento.

La quarta, infine, concerne la posizione del professionista sanitario. Nella misura in cui l’ordinamento interno riafferma la riserva della decisione clinica in capo al medico, la sorveglianza umana cessa di essere un requisito di prodotto e diventa un presupposto di legittimità dell’atto sanitario; di conseguenza, la progettazione dei flussi di lavoro — il tempo disponibile per la verifica, le informazioni esposte a supporto, la tracciabilità del dissenso — assume rilevanza giuridica propria. Si ritiene che il procurement possa e debba farsi carico anche di questo profilo, esigendo dai fornitori non soltanto la dimostrazione che il sistema sia sicuro, ma la dimostrazione che esso sia utilizzabile in modo consapevole da chi dovrà risponderne.

Riferimenti normativi

• AI&Partners: Procurement guidelines for AI cybersecurity within healthcare
• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (UE) 2017/745 (MDR)
• Regolamento (UE) 2017/746 (IVDR)
• Direttiva (UE) 2022/2555 (NIS2)
• Regolamento (UE) 2024/1689 (AI Act)
• Regolamento (UE) 2024/2847 (Cyber Resilience Act)
• Regolamento (UE) 2025/327 (EHDS)
• legge 20 maggio 1970, n. 300
• decreto legislativo 30 giugno 2003, n. 196
• decreto legislativo 10 agosto 2018, n. 101
• decreto legislativo 31 marzo 2023, n. 36
• decreto legislativo 4 settembre 2024, n. 138
• legge 23 settembre 2025, n. 132
• Provvedimento del Garante per la protezione dei dati personali 11 ottobre 2018, n. 467
• Linee guida del Gruppo di lavoro Articolo 29 WP248 rev.01 in materia di valutazione d’impatto sulla protezione dei dati
• ISO/IEC 42001
• ISO/IEC 27001
• ISO/IEC 23894
• IEC 62304
• IEC 81001-5-1