L’8 maggio 2026 la Commissione europea ha pubblicato il draft delle Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of Regulation (EU) 2024/1689, aprendo contestualmente una consultazione pubblica che si chiuderà il 3 giugno 2026. Il documento è stato rilasciato in parallelo al secondo draft del Code of Practice on marking and labelling of AI-generated content nonché a tre studi tecnici sulle soluzioni di marcatura e rilevamento dei contenuti AI-generated.
Tre atti diversi, tre funzioni diverse, un’unica scadenza che incombe: il 2 agosto 2026, data in cui gli obblighi di trasparenza ex art. 50 AI Act diventano direttamente applicabili in tutti gli Stati membri. Per le aziende pharma, i produttori di dispositivi medici, le strutture sanitarie e le software house che operano nel digital health, restano poco meno di tre mesi per allinearsi.
Indice degli argomenti
La cornice: linee guida, codice di condotta, studi tecnici
Prima di entrare nel merito, conviene fare chiarezza su un punto che genera spesso confusione.
La Commissione europea sta costruendo intorno all’art. 50 AI Act sulla trasparenza un sistema regolatorio a strati, con atti di natura giuridica diversa e funzioni complementari.
È importante distinguerli sin da subito, perché producono effetti differenti e richiedono adempimenti differenti.
Vediamoli in sintesi:
- Le Linee guida sulla trasparenza pubblicate l’8 maggio sono soft law interpretativa adottata ai sensi dell’art. 96, par. 1, lett. d), AI Act. Non sono vincolanti e non possono sostituire l’interpretazione autoritativa che spetta alla Corte di giustizia. La loro funzione è pratica: chiarire il perimetro applicativo delle obbligazioni, fornire esempi concreti di compliance e indicare alle autorità nazionali di sorveglianza del mercato un criterio uniforme di enforcement. La consultazione aperta fino al 3 giugno 2026 si rivolge a fornitori, deployers, imprese, autorità pubbliche, accademia e cittadini.
- Il Code of Practice on marking and labelling of AI-generated content è invece uno strumento di natura volontaria, redatto da esperti indipendenti nominati dall’AI Office attraverso un processo multi-stakeholder articolato in due working groups (uno dedicato ai providers, uno ai deployers). Il secondo draft è stato pubblicato il 3 marzo 2026 e la versione finale è attesa per giugno 2026. L’adesione al codice — una volta che la Commissione lo avrà dichiarato adeguato — fornirà ai sottoscrittori una presunzione semplificata di conformità agli obblighi di marcatura ex art. 50, par. 2 e par. 4, AI Act, ai sensi dell’art. 50, par. 7. Chi non aderisce non è in violazione, ma dovrà dimostrare con altri mezzi adeguati di aver implementato misure equivalenti — e, come precisa il par. 136 del draft delle linee guida, sarà esposto a un numero maggiore di richieste di informazioni e accesso da parte delle autorità di sorveglianza.
- I tre studi tecnici commissionati dalla DG CONNECT e pubblicati anch’essi l’8 maggio 2026 — uno sull’audio (Serra et al.), uno su immagini e video (Fritz), uno sul testo (Puccetti) — costituiscono la base di evidenza tecnica che ha alimentato la stesura del codice. Non hanno valore giuridico vincolante, ma definiscono lo stato dell’arte delle tecniche di watermarking, fingerprinting, metadata embedding e relativi sistemi di detection. Sono lettura obbligata per chi deve scegliere quali soluzioni implementare.
Vanno poi tenute presenti due ulteriori variabili, che sono oggi sul campo.
La prima è il pacchetto delle altre linee guida settoriali che la Commissione sta sfornando in parallelo: quelle sulle pratiche vietate ex art. 5 (C(2025) 5052, del 29 luglio 2025), quelle sulla definizione di sistema di IA (C(2025) 5053), quelle in preparazione sulla classificazione dei sistemi high-risk e sull’interplay tra AI Act e disciplina protezione dati (congiuntamente con l’EDPB).
La seconda è il Digital Omnibus on AI (COM(2025) 836), il cui accordo politico in trilogue è stato raggiunto il 7 maggio 2026 e che, secondo il par. 141 del draft delle linee guida, prevede una grandfathering rule mirata limitata agli obblighi di marcatura ex art. 50, par. 2, per i sistemi di IA generativa immessi sul mercato prima del 2 agosto 2026. Al momento della redazione del presente contributo il testo consolidato dell’Omnibus non è ancora stato pubblicato in Gazzetta ufficiale.
Una stratificazione complessa, nella quale si corre il rischio di perdere qualche “pezzo”.
Senza pretesa di poter analizzare tutto, vediamo in questo articolo cosa contiene espressamente il Draft delle Linee guida sulla trasparenza.
I quattro obblighi dell’art. 50 in sintesi
Partiamo dall’art. 50 AI Act.
Tale articolo disciplina quattro distinti obblighi di trasparenza, ciascuno dedicato a una categoria specifica di sistemi o di output.
Il par. 1 impone ai fornitori di sistemi di IA destinati a interagire direttamente con persone fisiche di progettare il sistema in modo da informare l’interlocutore che sta dialogando con una macchina; il par. 2 obbliga i fornitori di sistemi che generano o manipolano contenuti sintetici (audio, immagini, video, testo) ad apporre marcature machine-readable e a garantire la detectability dei contenuti come AI-generated; il par. 3 impone ai deployers di sistemi di emotion recognition e biometric categorisation di informare le persone esposte all’operatività del sistema; e infine il par. 4 obbliga i deployers di sistemi che generano deep fakes o testi pubblicati su matters of public interest a etichettare il contenuto come artificialmente generato o manipolato.
A questi quattro obblighi sostanziali si aggiunge la disciplina orizzontale dell’art. 50, par. 5, AI Act, che prescrive che l’informazione sia fornita in modo chiaro e distinguibile, al più tardi al momento della prima interazione o esposizione, in formato accessibile.
Sono obblighi che possono applicarsi cumulativamente sullo stesso sistema, coinvolgendo soggetti diversi della catena del valore. Ad esempio il fornitore di un chatbot di triage sanitario è tenuto agli obblighi del par. 1 (informare il paziente che sta dialogando con una IA) e del par. 2 (marcare in modo machine-readable l’output testuale); lo stesso sistema, integrato in una piattaforma di telemedicina utilizzata da un IRCCS, potrebbe rendere quest’ultimo deployer obbligato ai sensi del par. 4 per le comunicazioni pubblicate ai pazienti.
Sistemi interattivi (art. 50, par. 1): l’eccezione di obviousness e i suoi limiti in sanità
Il primo nodo che le linee guida aiutano a sciogliere riguarda l’ambito applicativo dell’obbligo di informare l’utente che sta interagendo con un sistema di IA.
Il draft individua quattro elementi cumulativi: deve trattarsi (i) di un sistema di IA, (ii) destinato a interagire, (iii) direttamente, (iv) con persone fisiche. Sono escluse — utile precisazione — le interazioni mediate o indirette, come quelle in cui un operatore umano si avvale di un assistente AI per dialogare con l’utente finale.
Il punto più delicato per il settore sanitario è l’eccezione di obviousness contenuta nello stesso art. 50, par. 1. L’obbligo informativo non si applica quando l’interazione con un sistema di IA è ovvia per una persona ragionevolmente informata, attenta e avveduta, tenuto conto delle circostanze e del contesto di uso. Le linee guida ricalcano qui, esplicitamente, lo standard del consumatore medio elaborato dalla disciplina UE di protezione dei consumatori, modulandolo però sulla composizione effettiva del pubblico destinatario.
Per il settore sanitario il draft fornisce due esempi rilevanti, di segno opposto. Da un lato — e questa è una notizia positiva — i sistemi di IA interattivi destinati esclusivamente a essere utilizzati da professionisti sanitari adeguatamente formati per supportare la diagnosi medica e suggerire i relativi trattamenti rientrano nell’eccezione di obviousness e non richiedono notifica esplicita. Stessa logica per i chatbot di code assistance riservati a sviluppatori professionali. Il presupposto è chiaro: l’audience è specialistica, il contesto d’uso conosciuto, l’aspettativa di interagire con un essere umano oggettivamente esclusa.
Dall’altro lato, lo scenario cambia radicalmente quando il sistema esce dal perimetro professionale e si rivolge — anche solo potenzialmente — a pazienti, familiari, persone fragili. Le linee guida menzionano espressamente, tra i sistemi che non beneficiano dell’eccezione, i robot da compagnia AI con sembianze di animali domestici progettati per emulare l’interazione uomo-animale (rilevanti in contesti RSA e in pediatria), i sistemi AI in ambienti immersivi (realtà virtuale e aumentata) con avatar o voci realistiche dove anziani, bambini o persone con disabilità possano fare fatica a distinguere il digitale dal reale, e i chatbot di assistenza embedded in piattaforme online dove l’utente percepisca l’output come neutro o human-generated.
Si ritiene che questo passaggio meriti particolare attenzione da parte dei provider di app di telemedicina, di piattaforme di patient engagement e di soluzioni di digital therapeutics: infatti anche quando il prodotto è formalmente destinato a uso professionale, la valutazione dell’obviousness deve tenere conto del pubblico realisticamente prevedibile, comprese le categorie vulnerabili che possano accedervi. In un PSP rivolto a pazienti oncologici, in un’app di monitoraggio dell’aderenza terapeutica per pazienti anziani, in un chatbot di prima accoglienza al CUP di un’azienda sanitaria, l’eccezione di obviousness difficilmente potrà essere invocata. Sul punto, le linee guida sono esplicite (par. 37 del draft): nelle situazioni emotivamente sensibili o dove esiste il rischio di formazione di legami emotivi, occorre persino prevedere reminder periodici e disclosure context-aware oltre alla notifica iniziale.
Quanto alla forma della notifica, il draft pone una distinzione utile (par. 35) tra tecniche considerate idonee e tecniche escluse. Non sono sufficienti — perché non percepibili dall’utente al momento dell’interazione — i disclosure relegati ai soli termini e condizioni, ai link a documentazione, alle marcature machine-readable o all’indicazione generica di un assistant senza specificazione della natura artificiale. Sono invece raccomandati gli approcci multimodali (testuali, sonori, visivi) e l’uso di badge persistenti durante l’intera interazione.
Marcatura e rilevamento dei contenuti sintetici (art. 50, par. 2): il problema dell’imaging diagnostico
L’art. 50, par. 2, AI Act è la disposizione tecnicamente più impegnativa dell’intera architettura. Impone ai provider di sistemi che generano o manipolano contenuti sintetici (audio, immagini, video, testo) un duplice obbligo: marcare gli output in formato machine-readable, e garantire la detectability come artificialmente generati o manipolati con soluzioni tecniche effective, interoperable, robust and reliable.
Le linee guida precisano (par. 65-66) che devono coesistere entrambe le componenti: marcatura e detection. Il provider deve quindi mettere a disposizione, accanto al sistema di marcatura, anche lo strumento di detection corrispondente, sviluppato in proprio o reso disponibile tramite terze parti.
Nello stato dell’arte attuale — riconosce la Commissione al par. 78 — nessuna singola tecnica di marcatura soddisfa contemporaneamente i quattro requisiti di qualità al livello richiesto. Sono necessarie combinazioni: il secondo draft del Code of Practice propone un two-layered marking approach basato su metadata securizzati e watermarking, con fingerprinting e logging opzionali. La scelta è rinviata al provider, che dovrà saperla giustificare in termini di state-of-the-art e di costi proporzionati.
Per il settore sanitario, il punto critico è la qualificazione di alcune categorie di output. Le linee guida riconoscono espressamente (par. 54) che i sistemi di IA generativa applicati a immagini mediche — pensiamo agli strumenti di image synthesis utilizzati in radiologia per la ricostruzione di immagini da dataset limitati, alle tecniche di MRI super-resolution, o ai sistemi di generazione di immagini sintetiche per addestramento di modelli — rientrano nel perimetro dell’art. 50, par. 2. Si tratta di output che, per la loro natura, possono essere utilizzati in contesti clinici, didattici o di ricerca dove la distinzione tra immagine autentica e immagine sintetica diventa dirimente.
Vanno tuttavia considerate due eccezioni.
a) La prima eccezione
a) La prima, prevista direttamente dalla norma, esclude i sistemi che svolgono funzione assistiva di standard editing o che non alterano sostanzialmente i dati di input. Le linee guida (par. 84-86) chiariscono che rientrano nell’editing standard la correzione grammaticale, gli adeguamenti formali, la riduzione del rumore, la compressione tecnica, il cropping minore, le correzioni di colore limitate. Non vi rientrano, invece — e qui sta il punto — le modifiche che alterano il significato, lo stile o l’intento del contenuto: il draft cita espressamente l’aggiunta o la rimozione di oggetti, la pixelazione di volti, l’alterazione di sagome corporee o di tonalità della pelle, ogni modifica sostanziale alla composizione dell’immagine.
Per i produttori di software diagnostico, di sistemi PACS evoluti, di piattaforme di second opinion, la lettura è chiara: la rimozione di artefatti, la normalizzazione del segnale, gli aggiustamenti di contrasto entro range fisiologici non fanno scattare l’obbligo di marcatura; le tecniche di image inpainting, di generazione di slice intermedie, di colorizzazione, di alterazione strutturale lo fanno scattare in pieno.
b) La seconda eccezione
La seconda eccezione, di matrice giurisprudenziale-interpretativa, è introdotta dalle stesse linee guida al par. 81 sotto l’etichetta delle industrial AI applications. Il draft riconosce che esistono casi in cui l’output del sistema è strettamente tecnico, destinato a una platea predefinita e limitata di professionisti all’interno dell’organizzazione, non condiviso esternamente. In tali casi — rigorosamente cumulativi — l’obbligo di marcatura non si applica. È un’apertura sensata, ma da maneggiare con cautela in ambito sanitario: il documento interno che esce dall’organizzazione, l’output del sistema utilizzato in consulto multidisciplinare con strutture esterne, il referto generato con assistenza AI e inviato al paziente, non rientrano nell’eccezione.
Emotion recognition e biometric categorisation (art. 50, par. 3): l’attenzione ai contesti di cura
L’art. 50, par. 3, AI Act riguarda due categorie di sistemi che possono trovare applicazione nel settore sanitario: i sistemi di emotion recognition (sistemi di IA finalizzati a identificare o inferire emozioni o intenzioni di persone fisiche sulla base di dati biometrici, ex art. 3, par. 39, AI Act) e i sistemi di biometric categorisation (sistemi che assegnano persone a categorie specifiche sulla base di dati biometrici, ex art. 3, par. 40, AI Act).
L’obbligo informativo grava sul deployer e si attiva a prescindere dal fatto che il sistema operi in tempo reale o ex post.
Va ricordato — e le linee guida lo sottolineano al par. 96 del draft — che tutti i sistemi di emotion recognition sono qualificati ad alto rischio ai sensi dell’art. 6 AI Act, salvo che ricadano nel divieto assoluto dell’art. 5, par. 1, lett. f), AI Act (che proibisce l’emotion recognition nei luoghi di lavoro e nei contesti di istruzione, fatte salve le finalità mediche e di sicurezza). L’obbligo di trasparenza opera quindi in aggiunta alle obbligazioni rinforzate previste per i sistemi high-risk.
Per il mondo sanitario il punto è delicato. La finalità medica della emotion recognition è esplicitamente esentata dal divieto generale: pensiamo ai sistemi di monitoraggio del dolore in pazienti incapaci di comunicare, ai tool di assessment dello stato emotivo nei trial clinici di psichiatria, alle soluzioni di supporto al monitoraggio dei pazienti con disturbi cognitivi. Sono sistemi leciti, ma il deployer (la struttura sanitaria che li utilizza) resta obbligato a informare il paziente — o i suoi familiari, se il paziente è incapace — dell’operatività del sistema. Per quanto riguarda la biometric categorisation, l’art. 50, par. 3, si applica indipendentemente dalla classificazione high-risk: ogni sistema che categorizzi persone su base biometrica deve essere accompagnato da informativa, salvo le eccezioni di legge per finalità di polizia e giustizia.
Il draft (par. 104) suggerisce che, nei casi appropriati, l’informativa ex art. 50, par. 3, AI Act possa essere integrata con l’informativa privacy ex artt. 13 e 14 del Regolamento (UE) 2016/679 (GDPR), per esempio al momento della raccolta del consenso quando questo costituisce la base giuridica del trattamento. È una soluzione pragmatica, che però — pare a chi scrive — non deve trasformare l’informativa AI in un mero rinvio o in una clausola annegata nel modulo privacy. La finalità delle due discipline è distinta: l’AI Act tutela l’autodeterminazione informativa del soggetto esposto al sistema; il GDPR tutela la liceità del trattamento. Entrambe le informazioni devono essere chiare e distinguibili.
Deep fake e pubblicazioni di interesse pubblico (art. 50, par. 4): il caso degli articoli scientifici e dei warning sanitari
L’art. 50, par. 4, AI Act articola due obblighi distinti in capo al deployer.
Il primo riguarda i deep fake — definiti dall’art. 3, par. 60, AI Act come contenuti immagine, audio o video AI-generated o manipolati che assomigliano a persone, oggetti, luoghi, entità o eventi esistenti e apparirebbero falsamente a una persona come autentici o veritieri. Il secondo concerne i testi AI-generated o manipolati pubblicati con la finalità di informare il pubblico su matters of public interest.
Il draft (par. 107-109) precisa che la qualificazione come deep fake richiede una resemblance appreciable rispetto a soggetti esistenti o suscettibili di esistenza realistica. Restano fuori, ad esempio, le scene fantastiche o irrealistiche. Sul punto sanitario, conviene segnalare due fattispecie. Un video AI-generated che ricostruisca un colloquio anamnestico utilizzando l’immagine e la voce di un medico realmente esistente — per finalità formative — costituisce deep fake e impone obbligo di labelling. Un’immagine sintetica di un quadro clinico generata per scopi didattici, che non riproduce identità reali, non rientra invece nella definizione.
Più articolato è il regime per i testi pubblicati su matters of public interest.
Il draft (par. 123) elenca, in via non esaustiva, i temi rilevanti: amministrazione e servizi pubblici, diritti fondamentali, salute pubblica, tutela ambientale, sicurezza dei consumatori, sviluppi economici, politici, scientifici, culturali con rilevanza pubblica. Tra gli esempi positivi forniti dalla Commissione figurano la sintesi AI-generated di un articolo umano sul sito di un giornale che discute una decisione del consiglio comunale, le parti AI-manipulated di un paper accademico che confronta gli effetti di diverse diete su una determinata patologia in donne di mezza età, le manipolazioni AI di report aziendali pubblicati sul sito di una società quotata con informazioni rilevanti per gli investitori, e i messaggi AI-generated diffusi sui canali social di istituti meteorologici per avvertire la popolazione di rischi maltempo.
Per le aziende del settore life science, la portata di questi esempi è notevole: una nota stampa AI-assisted su un nuovo trial clinico, un comunicato di un’azienda farmaceutica sui risultati di uno studio osservazionale, un post sul blog corporate di un produttore di dispositivi medici che illustri le evidenze cliniche di una nuova terapia digitale, possono ben rientrare nella definizione di pubblicazione su matters of public interest. E quindi richiedere etichettatura.
L’eccezione fondamentale è quella della human review ed editorial responsibility (par. 125-128 del draft). Se il testo AI-generated è stato sottoposto a un processo di revisione umana sostanziale (non mero spell-check, non approvazione di facciata, ma esame del merito da parte di soggetti con competenza professionale rilevante) e se una persona fisica o giuridica assume la editorial responsibility della pubblicazione (la cui identità e contatti devono essere facilmente reperibili), l’obbligo di labelling viene meno. Le linee guida richiamano qui — opportunamente — il concetto di editorial responsibility quale definito dall’art. 2, par. 8, del Regolamento (UE) 2024/1083 (European Media Freedom Act).
Il modello tipico esemplificato dal draft è quello dell’articolo giornalistico AI-manipulated sottoposto al controllo dell’editor-in-chief sotto la responsabilità del legal entity editore. Ma la stessa logica si estende ad altri contesti rilevanti per la sanità: un blog accademico AI-generated sottoposto a peer review interna dal centro di ricerca che ne assume la responsabilità editoriale; gli avvisi di sicurezza pubblica AI-generated approvati da un funzionario di un’agenzia di protezione civile prima della diffusione; per analogia, i bollettini epidemiologici pubblicati da un’ASL o da un IRCCS sotto la responsabilità del direttore sanitario o del responsabile scientifico, purché il processo di revisione sia sostanziale e tracciabile.
A bene vedere, il punto critico per le aziende del settore — e per le strutture sanitarie pubbliche — è proprio questo: documentare il flusso. La review umana e la editorial responsibility devono essere dimostrabili. Una redazione interna che approvi formalmente ogni testo prima della pubblicazione, con tracciatura dei controlli sostanziali effettuati, è un’organizzazione che può invocare l’eccezione. Una redazione che si limita ad approvare ex post quanto generato da strumenti di AI marketing, senza intervento sostanziale, no.
Non sarà facile stabilire con esattezza la linea di demarcazione.
I requisiti orizzontali (art. 50, par. 5): cosa significa “chiaro e distinguibile”
Da ultimo l’art. 50, par. 5, AI Act prescrive che le informazioni di cui ai paragrafi 1-4 siano fornite alle persone fisiche interessate in modo chiaro e distinguibile, al più tardi al momento della prima interazione o esposizione, nel rispetto dei requisiti di accessibilità applicabili.
Il draft delle linee guida dedica a questi requisiti orizzontali la sezione 7, con alcune precisazioni utili.
L’informazione è considerata chiara quando è facilmente comprensibile dalla persona interessata, comprese quelle con esigenze di accessibilità. È considerata distinguibile quando è facilmente identificabile come separata dalle altre informazioni e dall’ambiente di presentazione del contenuto. Il Par. 131 dichiara poi che non è conforme al dettato legislativo l’informazione relegata nel manuale d’uso o nascosta sotto livelli di menù in un’interfaccia online. Per i fornitori di app sanitarie, dispositivi medici con software embedded, piattaforme di telemedicina, il messaggio è inequivocabile: la trasparenza deve essere presente al punto di interazione, non altrove.
Quanto al timing, l’informativa deve essere fornita al più tardi al momento della prima interazione o esposizione, riferita non solo al primo utente ma a ciascun utente esposto. La disclosure a fine interazione — al termine di una sessione di chatbot, nei titoli di coda di un video — non soddisfa il requisito. Le linee guida (par. 132) ricordano che l’informazione può essere fornita anche prima della prima interazione effettiva, e che nelle trasmissioni live contenenti deep fake la disclosure va replicata in modo persistente per intercettare anche chi inizi la visione successivamente.
Le scadenze: dal 3 giugno al 2 agosto, la finestra che resta
Il calendario che le aziende e le strutture sanitarie devono tenere sotto controllo è scandito da tre date.
La prima è il 3 giugno 2026: termine della consultazione pubblica sul draft delle linee guida. È l’occasione per gli stakeholder di sollevare i punti rimasti ambigui o controversi, in particolare sull’eccezione di obviousness, sulla qualificazione dei contenuti dei matters of public interest e sulle industrial AI applications. Le aziende del settore — direttamente o tramite le associazioni di categoria (Confindustria Dispositivi Medici, Farmindustria, Assobiotec, ecc.) — farebbero bene a non perdere questa finestra.
La seconda è giugno 2026: pubblicazione attesa della versione finale del Code of Practice. Per i provider di sistemi di IA generativa sarà il momento di decidere se aderire al codice — ottenendo così la facilitazione probatoria di cui all’art. 50, par. 7, AI Act — o se predisporre, in alternativa, un proprio impianto di compliance documentato attraverso, ad esempio, una gap analysis comparativa rispetto al codice stesso.
La terza, e dirimente, è il 2 agosto 2026: applicazione diretta dell’art. 50 AI Act, ai sensi dell’art. 113 AI Act. Da quella data, le sanzioni dell’art. 99, par. 4, AI Act diventano operative: fino a 15 milioni di euro o, se l’autore della violazione è un’impresa, fino al 3% del fatturato mondiale annuo dell’esercizio precedente, a seconda di quale sia il valore più elevato. Per le istituzioni, gli organi e gli organismi dell’UE le sanzioni amministrative arrivano fino a 750.000 euro.
Una nota va dedicata al grandfathering.
L’art. 113 AI Act non prevede in via generale alcuna deroga per i sistemi già immessi sul mercato prima del 2 agosto 2026: anche essi dovranno essere conformi. La proposta di Digital Omnibus on AI introduce una grandfathering rule mirata, limitata però agli obblighi di marcatura ex art. 50, par. 2, AI Act per i sistemi di IA generativa, accordando ai provider di tali sistemi un periodo transitorio per adeguare i sistemi esistenti. Si tratta di una concessione tecnicamente sensata — il retrofit del watermarking sulle versioni già rilasciate non è banale — ma che richiede l’approvazione definitiva dei co-legislatori. Al momento il testo consolidato dell’Omnibus non è ancora pubblicato.
Implicazioni operative per aziende e strutture sanitarie
Le linee guida sono ancora in consultazione, il Code of Practice non è ancora finale, l’Omnibus non è ancora vigente. Eppure tre mesi sono pochi per rivedere flussi, contratti e processi. Si consiglia quindi di avviare ora la preparazione.
In concreto, le aziende pharma e medtech, le software house del digital health, le strutture sanitarie pubbliche e private devono affrontare alcuni adempimenti che possono essere già attivati. Una mappatura sistematica dei sistemi di IA utilizzati o forniti, distinguendo quelli interattivi, quelli generativi, quelli di emotion recognition o biometric categorisation, e per ciascuno qualificando i ruoli di provider e deployer. Una verifica delle interfacce utente di chatbot, voice assistant, robot assistivi e piattaforme di patient engagement, per accertare se la notifica di interazione con IA sia presente, chiara, distinguibile e correttamente posizionata. Una valutazione delle pipeline di generazione di contenuti — immagini diagnostiche sintetiche, video formativi, comunicazioni corporate, contenuti per studi clinici e PSP — per identificare quelli soggetti a marcatura ex art. 50, par. 2, e quelli soggetti a labelling ex art. 50, par. 4.
Per le pubblicazioni aziendali su matters of public interest — comunicati sui trial, post sul blog medico-scientifico, contenuti social a tema sanitario, articoli sponsored — è urgente la formalizzazione di un processo di human review documentabile, con identificazione del soggetto che assume editorial responsibility e con tracciatura dei controlli effettuati. Senza questa documentazione, l’eccezione del par. 125 del draft non potrà essere invocata.
Per i provider di sistemi generativi, va affrontata sin da ora la scelta della soluzione tecnica di marcatura. Il second draft del Code of Practice propone il two-layered approach (metadata + watermarking) come baseline. La scelta tra l’adesione al codice e la predisposizione di un percorso alternativo va presa con consapevolezza: aderire alleggerisce l’onere probatorio in sede di market surveillance; non aderire — anche per ragioni legittime di flessibilità — implica strutturare per tempo una documentazione di compliance che regga al confronto con il codice stesso.
Per le strutture sanitarie deployer — ASL, AO, IRCCS, ospedali privati — va affrontato il tema della contrattualistica con i fornitori. Le clausole contrattuali devono assicurare che il provider abbia adempiuto agli obblighi che gli competono (notifica di interazione, marcatura machine-readable, soluzioni di detection) e devono allocare le responsabilità tra le parti per gli obblighi che ricadono sul deployer (labelling dei deep fake utilizzati, informazione ex art. 50, par. 3, per emotion recognition e biometric categorisation). Una revisione mirata dei modelli contrattuali standard è ormai irrinunciabile.
Resta infine il coordinamento con gli altri obblighi paralleli.
L’art. 50 AI Act non sostituisce e non assorbe gli obblighi informativi del GDPR (in particolare gli artt. 13 e 14), della normativa sui dispositivi medici (Reg. UE 2017/745 e Reg. UE 2017/746, per quanto attiene alla documentazione tecnica e all’informazione del paziente), della disciplina consumeristica (Direttiva 2005/29/CE come modificata e Direttiva 2011/83/UE), del Digital Services Act per i contenuti diffusi tramite VLOP e VLOSE. Si tratta di un quadro stratificato che va letto in modo integrato — non come somma di silos.
Una scelta di campo, oltre il tecnicismo
Letto dall’alto, l’art. 50 AI Act è qualcosa di più di una norma tecnica sulla trasparenza.
È la presa d’atto, da parte del legislatore europeo, che la convivenza tra umani e sistemi generativi richiede una nuova grammatica della fiducia. In un ecosistema informativo in cui un’immagine sintetica può convincere quanto e più di una fotografia, in cui una voce clonata può sostituire un colloquio anamnestico, in cui un testo AI-generated può circolare come articolo scientifico, la trasparenza diventa il prerequisito stesso del consenso informato — anche, e soprattutto, in sanità.
L’Europa sceglie di intervenire ex ante e con strumenti modulari: una norma vincolante (l’art. 50), linee guida interpretative non vincolanti, un codice di condotta volontario ma incentivante, studi tecnici a supporto.
È un modello regolatorio — diciamocelo — sofisticato e complesso. Funzionerà se gli operatori sapranno appropriarsene, contribuendo al dibattito (la consultazione fino al 3 giugno è lì per quello) e implementando soluzioni pratiche prima del 2 agosto.
Per il mondo sanitario, in particolare, la posta in gioco è alta.
La fiducia nelle informazioni sanitarie è bene pubblico primario. Un’etichettatura chiara dei contenuti AI-generated non è un fastidio compliance, è un asset reputazionale. Le aziende e le strutture che sapranno integrare la trasparenza nel design dei propri prodotti e processi — anziché subirla come un onere — si troveranno avanti nel passaggio a un sistema sanitario sempre più ibrido tra umano e algoritmico.
