L'intelligenza artificiale in medicina promette di salvare vite. Nessuno dice apertamente chi risponde quando invece le costa.
Immaginate la scena. Un radiologo apre il referto del sistema di analisi delle immagini. L'algoritmo classifica la lastra come negativa. Il medico convalida. Il paziente viene dimesso con un'ansia ridimensionata che durerà pochi mesi: quando il tumore viene scoperto, è allo stadio quattro. Nel frattempo, tre soggetti — il produttore del software diagnostico, il medico che lo ha usato, l'ospedale che lo ha comprato — si guarderanno a vicenda cercando un capro espiatorio.
Nel 2026 questo non è più un esperimento mentale. È il tema legale più esplosivo della medicina contemporanea, e il diritto europeo ha appena cambiato le regole del gioco.
Il quadro normativo: due regolamenti che si sovrappongono
A partire dalla fine del 2024, chiunque operi in sanità digitale deve confrontarsi con due strumenti che lavorano in parallelo.
Il primo è l'AI Act (Regolamento UE 2024/1689), entrato in vigore il 1° agosto 2024 con un'applicazione progressiva: le norme sui sistemi ad alto rischio — categoria che comprende esplicitamente i dispositivi medici con componente IA, elencati nell'Allegato III, punto 5 — sono diventate pienamente operative a partire dall'agosto 2026. I sistemi di IA che aiutano a diagnosticare, classificare patologie, suggerire trattamenti o interpretare immagini cliniche rientrano in questa categoria senza margine di dubbio.
Il secondo è la nuova Direttiva sulla responsabilità per i prodotti difettosi (Direttiva 2024/2853/UE, cosiddetta "Product Liability Directive" o PLD rivista), entrata in vigore il 9 dicembre 2024, con obbligo di recepimento negli Stati membri entro il 9 dicembre 2026. La novità dirompente rispetto alla precedente direttiva del 1985 è la seguente: il software — e quindi i sistemi di IA — è espressamente qualificato come "prodotto" ai fini della responsabilità per danno da difetto. Fine dell'era in cui il codice poteva nascondersi nell'immaterialità.
Il difetto del prodotto: cosa significa per un algoritmo diagnostico
La PLD rivista (art. 6) definisce il prodotto "difettoso" quando non offre la sicurezza che ci si può legittimamente attendere, tenuto conto di tutti i fattori rilevanti: la presentazione del prodotto, l'uso ragionevolmente prevedibile, il momento in cui il prodotto è stato immesso in commercio.
Applicato a un algoritmo diagnostico, il difetto può manifestarsi in tre forme:
Difetto di progettazione. Il modello è addestrato su dataset non rappresentativi della popolazione trattata — per esempio, prevalentemente su soggetti maschi bianchi di mezza età, mentre il paziente è una donna di cinquant'anni con caratteristiche demografiche sottorappresentate nel training set. Il tasso di errore strutturalmente più alto per certi sottogruppi è, a tutti gli effetti, un vizio di fabbricazione intellettuale.
Difetto di informazione. L'art. 7 della PLD e l'art. 13 dell'AI Act convergono su un punto: i sistemi ad alto rischio devono essere sufficientemente trasparenti da permettere agli utenti di interpretarne i risultati in modo appropriato. Se il sistema non comunica il proprio livello di confidenza, non segnala i casi limite, non avverte che la popolazione su cui è stato testato era diversa da quella del paziente davanti al medico — la mancanza di informazione è essa stessa un difetto.
Difetto da aggiornamento. La PLD rivista introduce una previsione nuova (art. 10, par. 2, lett. e): il produttore risponde anche per i difetti che emergono dopo l'immissione in commercio, quando aveva il controllo degli aggiornamenti e non ha corretto un errore noto. Un algoritmo che continua a sbagliare una certa classe di immagini dopo che il produttore ne era a conoscenza espone il produttore a responsabilità piena, anche se il dispositivo funzionava correttamente al momento della vendita.
La triade delle responsabilità
La vera partita processuale si gioca su un tavolo a tre giocatori, e ognuno ha le sue esposizioni specifiche.
Il produttore del sistema IA
È il soggetto che la PLD mette nel mirino diretto. Risponde oggettivamente — senza bisogno di provare la colpa — per il danno causato dal difetto del prodotto (art. 7 PLD). L'onere della prova sul paziente-vittima è alleviato dalla norma: l'art. 9 introduce una presunzione di causalità quando risulta provato che il prodotto era difettoso e che il tipo di danno lamentato è tipicamente ricollegabile a quel tipo di difetto.
C'è però un punto di attenzione critico. Il produttore può invocare l'esimente del "rischio da sviluppo" (art. 10, par. 1, lett. e): non risponde se il difetto era scientificamente non conoscibile al momento dell'immissione in commercio. Nelle cause sull'IA sanitaria questa sarà la trincea difensiva principale. Quanto sia sostenibile dipenderà dalle evidenze tecniche disponibili nel momento storico in cui il sistema è stato certificato.
L'AI Act aggiunge obblighi che potranno essere usati come prova della negligenza: i fornitori di sistemi ad alto rischio devono implementare sistemi di gestione della qualità (art. 17), tenere la documentazione tecnica (art. 18), effettuare la valutazione di conformità (art. 43) e registrare il sistema nella banca dati EU (art. 71). Chi non ha fatto questo ha già perso metà della causa ancora prima che il paziente presenti il ricorso.
Il medico
Il medico che usa un sistema IA non si trasforma in un passacarte algoritmico. La responsabilità professionale — in Italia regolata dalla Legge Gelli-Bianco (L. 24/2017) e dalla consolidata giurisprudenza della Cassazione — rimane personale e ineludibile.
Il punto chiave è la supervisione umana significativa: l'AI Act (art. 14) impone espressamente che i sistemi ad alto rischio siano progettati per consentire una supervisione umana effettiva. Ma questa non è solo un'opzione: è un obbligo del professionista che usa il sistema. Un radiologo che valida acriticamente l'output di un algoritmo senza applicare il proprio giudizio clinico ha violato le regole dell'arte medica, indipendentemente da cosa ha fatto l'algoritmo.
La difesa del medico si articola su due piani: primo, dimostrare di aver esercitato un giudizio professionale autonomo e non essersi limitato a ratificare il referto automatizzato; secondo, dimostrare di aver usato il sistema nei limiti e per le indicazioni previsti dal produttore. Se il sistema era stato validato per la diagnosi di carcinoma polmonare su pazienti adulti e il medico lo ha usato su un paziente pediatrico fuori dall'indicazione certificata, il problema cambia completamente geometria.
L'ospedale
La struttura sanitaria risponde su due titoli diversi.
Il primo è la responsabilità da organizzazione (art. 7 L. Gelli-Bianco, art. 2049 c.c. per i dipendenti): l'ospedale che adotta uno strumento difettoso e lo mette a disposizione del proprio personale risponde dei danni che ne derivano, salvo dimostrare che il difetto non era conoscibile con la dovuta diligenza.
Il secondo è la responsabilità da procurement negligente. La direzione sanitaria che acquista un sistema IA senza verificare che abbia superato la valutazione di conformità AI Act, senza leggere la documentazione tecnica, senza formare il personale all'uso corretto e ai limiti del sistema, sta costruendo il caso del paziente che domani li citerà in giudizio.
L'AI Act (art. 26) impone obblighi specifici anche ai "deployer" — i soggetti che usano i sistemi ad alto rischio nel loro contesto operativo. Gli ospedali sono deployer, non spettatori. Devono: usare il sistema secondo le istruzioni d'uso, assicurarsi che gli operatori abbiano le competenze necessarie, monitorare il funzionamento, segnalare incidenti gravi all'autorità nazionale di vigilanza, tenere i log per almeno sei mesi.
Il problema della scatola nera
Qui si annida la trappola più insidiosa per chi è parte in una causa.
L'art. 13 dell'AI Act impone che i sistemi ad alto rischio siano sufficientemente trasparenti da permettere ai deployer di comprendere le capacità e i limiti del sistema e di interpretarne l'output in modo appropriato. Ma "sufficientemente trasparente" non significa "completamente spiegabile". I modelli di deep learning che analizzano immagini diagnostiche operano attraverso reti neurali convoluzionali con milioni di parametri: nessun esperto umano può spiegare, punto per punto, perché il modello ha classificato quella specifica lastra in quel modo.
Questo crea un paradosso probatorio che i tribunali non hanno ancora risolto in modo uniforme. Il paziente deve provare il nesso causale tra il difetto del sistema e il danno. Ma se il sistema non spiega il proprio ragionamento, come si prova che la classificazione errata derivava da un difetto strutturale e non da un caso limite che qualsiasi sistema avrebbe sbagliato?
La risposta parziale viene dall'art. 9 PLD: la presunzione di causalità, unita all'obbligo del produttore di divulgare gli elementi di prova pertinenti in suo possesso (art. 8 PLD — nuova norma sull'accesso alla prova), sposta l'onere in modo significativo. Il produttore dovrà esibire i dataset di training, i risultati della validazione clinica, i report di audit dell'algoritmo. Se questi elementi mostrano un tasso di falsi negativi sistematicamente elevato per la classe di lesioni non rilevata, il nesso causale inizia a costruirsi anche senza l'explainability neurone per neurone.
I primi casi internazionali (da verificare)
La giurisprudenza in materia è ancora allo stadio pionieristico, ma alcuni segnali si leggono già.
Negli Stati Uniti si discute di una serie di casi — ancora in fase di discovery o di prima sentenza di merito — relativi a sistemi CAD (Computer-Aided Detection) per mammografia che avrebbero contribuito a ritardi diagnostici (da verificare). I tribunali americani stanno affrontando la questione se il produttore del software sia un "product seller" ai fini della strict liability o se il servizio computazionale prevalga sul prodotto, con esiti non ancora consolidati (da verificare).
Nel Regno Unito, la NHS ha avviato revisioni interne dopo segnalazioni su sistemi di analisi del fondo oculare per retinopatia diabetica che in alcuni deployment reali hanno mostrato performance inferiori ai dati di validazione — un fenomeno noto come "performance drift" che emerge quando il sistema incontra popolazioni diverse da quelle su cui è stato addestrato (da verificare).
In Europa, siamo ancora alla fase pre-contenziosa: la PLD rivista non è ancora stata recepita dalla maggior parte degli Stati membri, e i primi casi si annunceranno probabilmente nel biennio 2027-2028, quando si accumuleranno abbastanza danni da un sistema specifico da permettere azioni collettive o cause-pilota.
Cosa deve fare oggi un medico o un ospedale
Il tempo delle buone intenzioni è finito. Ecco il minimo sindacale per chi vuole difendersi in giudizio.
Per il medico:
- Documentare sempre il proprio ragionamento clinico autonomo, indipendente dall'output dell'algoritmo. Il referto deve mostrare che il medico ha pensato, non solo convalidato.
- Conoscere le indicazioni e i limiti certificati del sistema prima di usarlo. Se il manuale dice che il sistema è validato su determinate caratteristiche del paziente, rispettarle o documentare esplicitamente la deviazione e il motivo.
- Segnalare al produttore e alla struttura qualsiasi comportamento anomalo del sistema. L'art. 26 AI Act lo impone ai deployer; il medico che non segnala contribuisce alla catena causale del danno futuro.
Per l'ospedale:
- Verificare che il sistema abbia superato la valutazione di conformità AI Act e sia registrato nel database EU. Non è un dettaglio burocratico: è la prova che il sistema è stato sottoposto a una verifica indipendente.
- Conservare la documentazione tecnica del produttore e i contratti di acquisto, che definiscono le garanzie e le esclusioni di responsabilità.
- Formare il personale non solo sull'uso tecnico del sistema, ma sui suoi limiti: quali classi di patologie rileva con maggiore incertezza, quali caratteristiche demografiche sono meno rappresentate nel training set, come interpretare i livelli di confidenza dell'output.
- Implementare un protocollo di monitoraggio post-mercato: tenere i log obbligatori, misurare periodicamente le performance del sistema sulla propria casistica reale e confrontarle con i dati di validazione dichiarati dal produttore.
- Negoziare i contratti di acquisto con attenzione alle clausole di responsabilità, alle garanzie di performance e all'accesso ai dati di validazione: un produttore che non fornisce questi elementi in sede contrattuale è un produttore da non comprare.
La partita vera
C'è una cosa che nessuna norma dice esplicitamente ma che la logica del sistema impone: l'IA diagnostica non è un oracolo, è uno strumento. Uno strumento potente, a volte più accurato del medico su determinate task specifiche, ma pur sempre uno strumento con limiti, bias e zone cieche.
Il problema non è l'intelligenza artificiale in medicina. Il problema è la delegazione cieca. Il medico che usa l'IA come alibi — "l'algoritmo ha detto negativo" — ha già perso la causa morale prima ancora di quella legale. L'ospedale che compra un sistema certificato e poi non lo monitora pensa di aver comprato sicurezza quando ha comprato solo carta.
La Product Liability Directive colpisce il produttore. L'AI Act colpisce chi opera senza supervisione e senza documentazione. La responsabilità medica colpisce chi abdica al giudizio clinico. Tre regimi diversi, tre soggetti diversi, un unico paziente che aspettava una diagnosi corretta.
Chi paga? Nel 2026, tutti e tre. Proporzionalmente a quanto hanno fatto — o non fatto.
Duarte è il personaggio della squadra TheDevilLawyer che presidia il diritto digitale, la responsabilità da IA e i temi al confine tra tecnologia e diritto. Le analisi pubblicate sono di carattere generale e non costituiscono parere legale su casi specifici.