scenari

AI medical scribe: il quadro giuridico che i medici devono conoscere



Indirizzo copiato

Gli AI medical scribe trascrivono i colloqui clinici e generano documentazione sanitaria automatica. Il loro regime normativo dipende dalla destinazione d’uso dichiarata, con implicazioni rilevanti per GDPR, MDR, AI Act e responsabilità professionale medica

Pubblicato il 28 apr 2026

Gianluca Marmorato

avvocato, Associate partner P4I



AI in corsia: esempi concreti di supporto ai professionisti nelle decisioni cliniche; riforma sanitaria
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti

Stiamo assistendo a una rapida diffusione dei sistemi di AI medical scribe, software basati su modelli di intelligenza artificiale generativa integrati con tecnologie di riconoscimento vocale automatico (Automatic Speech Recognition – ASR) e di elaborazione del linguaggio naturale (Natural Language Processing – NLP), progettati per registrare i colloqui clinici tra medico e paziente e generare automaticamente documentazione sanitaria strutturata, come note cliniche, referti, lettere di dimissione, codifiche ICD, sintesi in formato SOAP (Simple Object Access Protocol) e altri documenti tipici del processo assistenziale.

Indice degli argomenti

Ambient listening e trascrizione automatica: come lavora il sistema

Il modello operativo prevalente si fonda sulla tecnica dell’ambient listening, mediante la quale il sistema elabora l’interazione clinica, converte la registrazione delle conversazioni in testo, individua automaticamente le entità ritenute clinicamente rilevanti, quali ad esempio sintomi, durata dei disturbi, anamnesi, terapie in corso, prescrizioni o indicazioni operative, e le colloca nelle sezioni appropriate del documento sanitario finale, secondo modelli predefiniti.

Sotto il profilo funzionale, questi sistemi sono progettati per svolgere un’attività di supporto documentale e organizzativo, finalizzata alla redazione automatica della documentazione clinica, senza poter intervenire nel processo decisionale sanitario.

Nella loro configurazione tipica, infatti, gli AI scribe non formulano diagnosi, non suggeriscono trattamenti e non generano raccomandazioni terapeutiche, limitandosi invece a trascrivere, sintetizzare e strutturare informazioni già espresse dal professionista.

Quando l’AI scribe non è un dispositivo medico: la qualificazione regolatoria

Proprio questa natura meramente documentale e non decisionale rappresenta l’elemento sul quale si fonda, allo stato attuale, la prevalente qualificazione regolatoria di tali sistemi come meri strumenti di supporto amministrativo o redazionale, con conseguente esclusione dall’ambito di applicazione del Regolamento (UE) 2017/745 sui dispositivi medici, che richiede la presenza di una finalità medica diretta quale diagnosi, prevenzione, monitoraggio, predizione o trattamento di una patologia.

I profili di rischio che restano aperti anche senza classificazione MDR

Questo inquadramento classificatorio costituisce oggi la principale leva giuridica che consente l’utilizzo diffuso degli AI medical scribe nei contesti sanitari, ma non elimina i profili di rischio, ben presenti con riguardo ai delicati temi della protezione dei dati personali, della sicurezza delle informazioni, della responsabilità professionale sanitaria e della corretta qualificazione regolatoria del software, soprattutto nei casi in cui le funzionalità del sistema superino la mera trascrizione e si avvicinino a forme di sintesi interpretative o di supporto alla decisione clinica.

Funzione documentale o funzione decisionale: il confine che cambia tutto

La distinzione tra funzione documentale e funzione decisionale costituisce un elemento decisivo sotto il profilo operativo e regolatorio e dipende in modo determinante dalla destinazione d’uso dichiarata dal fabbricante (intended purpose), che nel diritto europeo dei dispositivi medici assume valore centrale ai fini della qualificazione giuridica del software.

Proprio questo profilo, apparentemente tecnico, rappresenta in realtà il punto nevralgico dell’intero quadro applicativo.

L’intended purpose come criterio centrale nella qualificazione giuridica

I sistemi di intelligenza artificiale, infatti, possono essere qualificati come semplice strumento amministrativo di supporto alla redazione documentale oppure come software dispositivo medico (Software as a Medical Device – SaMD) a seconda del perimetro funzionale dichiarato dal produttore, delle modalità di presentazione del prodotto e dell’uso previsto in ambito clinico.

Ai sensi dell’art. 2 del Regolamento (UE) 2017/745 (MDR), ciò che rileva ai fini della qualificazione non è tanto la complessità tecnica del sistema, quanto la finalità medica attribuita dal fabbricante, quale diagnosi, prevenzione, monitoraggio, predizione, prognosi o trattamento di una malattia.

Ne consegue che software basati su tecnologie analoghe (riconoscimento vocale, modelli linguistici generativi, sintesi automatica) possono rimanere fuori dal perimetro dei dispositivi medici se limitati alla mera trascrizione, oppure rientrarvi quando producano elaborazioni idonee a incidere sul processo clinico.

MDR e AI Act: le conseguenze della qualificazione come dispositivo medico

Le conseguenze di tale qualificazione sono rilevanti.

Nel primo caso il software resta soggetto principalmente alla disciplina in materia di protezione dei dati personali, sicurezza informatica e responsabilità professionale; nel secondo trovano applicazione gli obblighi previsti dal MDR, tra cui marcatura CE, valutazione di conformità, gestione del rischio, sorveglianza post-commercializzazione e rispetto delle regole di classificazione dell’Allegato VIII, in particolare della regola 11 relativa ai software medicali.

L’impatto dell’AI Act: sistemi ad alto rischio e obblighi rafforzati

A tali profili si aggiunge l’impatto del Regolamento (UE) 2024/1689 (AI Act), che può qualificare questi sistemi come IA ad alto rischio quando utilizzati in ambito sanitario o quando incidano su dati relativi alla salute, con conseguenti obblighi rafforzati in materia di governance, qualità dei dati, tracciabilità, supervisione umana e gestione del rischio.

Ne deriva che la linea di confine tra strumento documentale e dispositivo medico non dipende dalla tecnologia in sé, ma dalla configurazione funzionale, dalla destinazione d’uso dichiarata e dalle concrete modalità di impiego nel contesto sanitario, con effetti diretti non solo per il fabbricante, ma anche per le strutture sanitarie utilizzatrici, che possono assumere responsabilità rilevanti qualora impieghino software non correttamente qualificati o utilizzati al di fuori delle indicazioni previste.


Il mercato globale degli AI medical scribe: dimensioni e frammentazione dell’offerta

Il mercato globale dei software di trascrizione medica basati su intelligenza artificiale si stima abbia raggiunto nel 2025 un valore di circa 3 miliardi di dollari, con un’offerta commerciale estremamente eterogenea che spazia da soluzioni destinate ad organizzazioni complesse, profondamente integrate nei sistemi informativi ospedalieri, fino a strumenti destinati all’uso individuale da parte dei singoli medici.

Comprendere le differenze funzionali tra i principali prodotti disponibili sul mercato non è rilevante soltanto ai fini della scelta tecnologica, ma risulta soprattutto essenziale per individuarne correttamente il regime normativo applicabile, con particolare riguardo alla qualificazione come software amministrativo oppure come Software as a Medical Device (SaMD) ai sensi del Regolamento (UE) 2017/745 (MDR).

Nuance DAX e il modello enterprise con quality assurance umana

Di seguito una breve illustrazione dei sistemi maggiormente utilizzati:

Nel mercato nordamericano, Nuance DAX, sviluppato da Microsoft, rappresenta uno dei principali riferimenti nelle implementazioni enterprise di AI medical scribe. La piattaforma si distingue per la profonda integrazione con i sistemi EHR Epic e Meditech e per l’adozione di un modello di human quality assurance, in base al quale ogni nota generata viene sottoposta a revisione umana prima della consegna al clinico, riducendo il rischio di errori documentali.

Tale approccio ibrido uomo-macchina garantisce elevata qualità della documentazione clinica, ma comporta tempi di elaborazione più lunghi, processi di implementazione complessi — spesso di alcuni mesi — e costi elevati, stimati in circa 830 dollari al mese per ciascun utilizzatore.

Abridge e la generazione di note semanticamente strutturate tramite LLM

Abridge adotta invece un’architettura basata su large language models (LLM) e si caratterizza per la capacità di generare note cliniche semanticamente strutturate, organizzate secondo categorie tipiche della pratica medica, superando la mera trascrizione del colloquio.

L’integrazione avanzata con Epic consente al sistema di ricostruire la struttura narrativa della visita (motivo della consultazione, anamnesi, valutazione clinica e piano terapeutico) estendendo la funzionalità dalla semplice identificazione di informazioni alla riorganizzazione del contenuto clinico.

Anche Abridge è progettato come soluzione esclusivamente enterprise, richiedendo integrazione con infrastrutture informatiche ospedaliere complesse.

Suki: comandi vocali, prescrizioni e gestione automatizzata del flusso clinico

Suki amplia ulteriormente il perimetro funzionale dello scribe, introducendo funzionalità di ricerca documentale e gestione automatizzata del flusso clinico. Oltre alla generazione delle note, il sistema consente al medico di richiamare informazioni del paziente, creare prescrizioni e interagire con il sistema mediante comandi vocali, configurando una modalità di gestione automatizzata del flusso clinico.

L’integrazione con i principali EHR nordamericani (Epic, Athena, Meditech e Cerner) richiede tuttavia un significativo coordinamento con i servizi IT della struttura sanitaria.

DeepScribe e la codifica E&M: quando il software si avvicina al supporto decisionale

DeepScribe ha sviluppato la propria proposta con particolare specializzazione in ambito oncologico e cardiologico, includendo suggerimenti automatici di codifica Evaluation & Management (E&M).

Tale funzionalità, rilevante nel sistema sanitario statunitense per finalità di fatturazione e compliance, implica una forma di inferenza sulla complessità clinica dell’incontro e si avvicina al supporto decisionale clinico, con possibili conseguenze classificatorie ai sensi della Regola 11 dell’Allegato VIII del MDR, relativa ai software che influenzano decisioni diagnostiche o terapeutiche.

Il mercato europeo: soluzioni native MDR e marcatura CE

Nel contesto europeo, il mercato appare orientato verso soluzioni progettate fin dall’origine per la qualificazione come dispositivo medico.

Tandem Health (Svezia), ad esempio, ha ottenuto la marcatura CE come dispositivo medico di classe I ai sensi del MDR, anche a seguito dell’acquisizione della piattaforma olandese Juvoly.

Corti (Danimarca) e Tortus (Regno Unito) si collocano nello stesso segmento, con architetture sviluppate per soddisfare i requisiti di gestione del rischio, validazione delle prestazioni e sorveglianza post-commercializzazione previsti dal regolamento europeo.

Nabla, Heidi Health e Freed: conformità GDPR, multilingue e PMI

Nabla (Francia) ha costruito la propria offerta con particolare attenzione alla conformità al GDPR e al mercato europeo, prevedendo generazione di note in pochi secondi, supporto multilingue e funzionalità di codifica ICD, con architettura progettata per la localizzazione dei dati nello Spazio Economico Europeo, elemento distintivo rispetto a diversi concorrenti nordamericani.

Heidi Health (Australia/Regno Unito) si rivolge prevalentemente al mercato anglofono extra-statunitense, con un’interfaccia basata su comandi naturali che consente modifiche in tempo reale durante la visita e generazione automatizzata di comunicazioni e note cliniche.

Freed, infine, è orientato a strutture di piccole e medie dimensioni, con tempi di configurazione ridotti, apprendimento dello stile individuale del medico e integrazione con EHR, favorendo la diffusione della tecnologia anche al di fuori dei contesti ospedalieri enterprise.

Le esperienze italiane: EngGPT, EmergInsight e l’analisi dei dati di pronto soccorso

Nel contesto italiano, il progetto EngGPT rappresenta un’esperienza particolarmente strutturata, finalizzata al supporto nella compilazione delle schede di dimissione ospedaliera mediante un modello ibrido di automazione e validazione clinica.

Analogamente, progetti come EmergInsight, dedicato all’analisi dei dati di pronto soccorso, hanno evidenziato come una quota significativa degli accessi classificati come codici verdi (stimata intorno al 75%) avrebbe potuto essere gestita al di fuori dei percorsi di emergenza, dimostrando il potenziale dell’intelligenza artificiale nell’analisi proattiva dei dati clinici e nell’ottimizzazione dei flussi assistenziali.

Dalla nota clinica alla sintesi interpretativa: il rischio di riqualificazione regolatoria

Una distinzione funzionale trasversale a tutti questi prodotti assume particolare rilievo ai fini della qualificazione regolatoria: quella tra sistemi che si limitano alla generazione della nota clinica e sistemi che integrano funzionalità ulteriori, quali il riepilogo clinico preliminare, sintesi della storia clinica o documenti destinati al paziente.

Tali funzionalità possono tuttavia presentare rilevanti criticità regolatorie: quanto più il software si avvicina a funzioni di sintesi clinica o di supporto al processo decisionale sanitario, tanto più si rafforzano i presupposti per la sua qualificazione come dispositivo medico.

Da un lato trovano applicazione gli obblighi previsti dalla normativa di settore, tra cui la marcatura CE, la valutazione di conformità secondo il Regolamento (UE) 2017/745 (MDR), l’adozione di un sistema di gestione del rischio, la validazione clinica delle prestazioni e gli obblighi di vigilanza post-commercializzazione.

Inoltre, con l’impiego di tecniche di intelligenza artificiale, utilizzate in ambito sanitario, potendo incidere su dati relativi alla salute o su processi clinici, si può rientrare nell’ambito dei sistemi di IA ad alto rischio ai sensi del Regolamento (UE) 2024/1689 (AI Act), con conseguente applicazione di obblighi rafforzati in materia di gestione del rischio, qualità dei dati, documentazione tecnica, tracciabilità, supervisione umana e controllo delle prestazioni.

La progressiva evoluzione degli AI medical scribe, da strumenti di mera trascrizione a sistemi capaci di generare sintesi cliniche strutturate o suggerimenti codificativi, determina quindi uno spostamento significativo del loro inquadramento giuridico, con effetti non solo per il fabbricante, ma anche per le strutture sanitarie utilizzatrici, chiamate a verificare la corretta qualificazione regolatoria del software e la conformità del suo impiego rispetto alla destinazione d’uso dichiarata.


AI medical scribe e GDPR: i dati particolari e le tensioni con la minimizzazione

I dati trattati dagli AI medical scribe rientrano generalmente tra i dati particolari ai sensi dell’art. 9 GDPR, in quanto relativi alla salute, ai quali possono aggiungersi dati biometrici vocali e informazioni incidentalmente raccolte su soggetti terzi presenti durante la visita.

L’utilizzo di sistemi basati su ambient listening, fondati sulla registrazione integrale del colloquio, pone una tensione strutturale con il principio di minimizzazione di cui all’art. 5, par. 1, lett. c), GDPR, in quanto comporta il trattamento di una quantità di dati superiore a quella strettamente necessaria.

I cinque principali rischi GDPR: server, re-identificazione, uso secondario e terzi

I principali profili di rischio riguardano, in primo luogo, la localizzazione dei server e i trasferimenti verso Paesi terzi, spesso inevitabili quando il fornitore utilizza infrastrutture cloud extra-SEE, con conseguente applicazione degli artt. 44 ss. GDPR e possibili criticità anche rispetto all’US CLOUD Act.

Un secondo profilo concerne il rischio di re-identificazione, poiché le registrazioni vocali contengono dati biometrici difficilmente anonimizzabili in modo effettivo.

Un terzo riguarda l’uso secondario dei dati per l’addestramento dei modelli di IA, che richiede una base giuridica autonoma rispetto alle finalità di cura.

Ulteriori criticità attengono alla conservazione delle registrazioni e delle trascrizioni integrali, che dovrebbe essere limitata al tempo strettamente necessario alla validazione della nota clinica, e al trattamento di dati di soggetti terzi presenti durante la visita, spesso coinvolti senza adeguata informativa.

DPIA, AI Act e Data Processing Agreement: gli adempimenti indispensabili

In tali contesti è normalmente necessario svolgere una DPIA ai sensi dell’art. 35 GDPR e, quando il sistema rientra tra quelli di IA ad alto rischio ai sensi del Regolamento (UE) 2024/1689 (AI Act), può rendersi opportuna anche una Valutazione di impatto sui diritti fondamentali.

Sul piano contrattuale, è imprescindibile la stipula di un Data Processing Agreement ex art. 28 GDPR, con particolare attenzione ai sub-responsabili e alle infrastrutture cloud utilizzate, al fine di garantire il controllo sui trasferimenti internazionali e sulla localizzazione dei dati.


Il consenso del paziente: requisito essenziale e modalità di acquisizione valida

Il consenso del paziente all’utilizzo di sistemi di AI medical scribe è generalmente considerato, nella prassi internazionale e nelle indicazioni delle autorità di controllo, un requisito essenziale di legittimità del trattamento. La questione non riguarda tanto la sua necessità, quanto le modalità con cui acquisirlo in forma giuridicamente valida.

Quando il consenso per le finalità di cura non è sufficiente

Sebbene il trattamento dei dati sanitari per finalità di cura possa fondarsi sull’art. 9, par. 2, lett. h) GDPR, l’impiego di sistemi di registrazione audio e di elaborazione automatizzata mediante intelligenza artificiale introduce operazioni ulteriori rispetto alla normale documentazione clinica, rendendo spesso necessario un consenso specifico e distinto.

I requisiti del consenso: libero, specifico, informato ed esplicito

Ai sensi degli artt. 4, 7 e 9 GDPR, il consenso deve essere libero, specifico, informato, inequivocabile ed esplicito.

La libertà implica che il paziente possa rifiutare senza alcun pregiudizio nell’accesso alle cure; la specificità richiede che il consenso riguardi espressamente l’uso dello scribe, la registrazione audio e le elaborazioni automatiche; il carattere informato presuppone una spiegazione chiara del funzionamento del sistema; l’inequivocabilità richiede una manifestazione positiva di volontà.

Forma del consenso, obblighi di informativa e alternative organizzative

Sotto il profilo probatorio, la forma scritta rappresenta la soluzione più garantita, soprattutto nelle prime visite o in contesti ospedalieri complessi, mentre nelle visite successive può ritenersi ammissibile un consenso verbale annotato in cartella clinica, purché l’informazione e l’assenso siano espressamente documentati. Devono invece essere evitati modelli di consenso tacito o presunto, difficilmente compatibili con l’art. 9 GDPR.

L’informativa deve indicare almeno: identità del titolare e del responsabile, la natura del trattamento (registrazione, trascrizione, elaborazione automatica), eventuali sub-responsabili e trasferimenti verso Paesi terzi, tempi di conservazione, diritti dell’interessato e uso di sistemi di intelligenza artificiale. A tali obblighi si aggiungono quelli previsti dal Regolamento (UE) 2024/1689 (AI Act), che impone specifici doveri di trasparenza quando l’utente interagisce con sistemi di IA.

Sul piano organizzativo, le strutture sanitarie devono inoltre garantire modalità alternative di documentazione clinica per i pazienti che non intendano avvalersi dello scribe, poiché la possibilità di rifiutare senza conseguenze negative costituisce condizione necessaria affinché il consenso possa considerarsi effettivamente libero.


Cybersecurity e AI medical scribe: i nuovi vettori di rischio informatico

Gli AI medical scribe introducono un ulteriore elemento di rischio nel già complesso panorama della cybersecurity sanitaria, operando in integrazione con i sistemi di cartella clinica elettronica (EHR) spesso mediante trasmissione verso infrastrutture cloud esterne.

Questa architettura amplifica criticità già note: un data breach può esporre contemporaneamente i dati di numerosi pazienti; la trasmissione dei flussi vocali verso i server del fornitore aumenta il rischio di possibili intromissioni; l’integrazione applicativa con l’EHR può costituire un punto di accesso privilegiato per la compromissione delle credenziali cliniche o l’esfiltrazione di dati sanitari.

NIS2, ISO 27001 e cifratura: le misure di sicurezza da richiedere ai fornitori

L’adozione di tali sistemi deve quindi essere valutata anche alla luce della normativa europea sulla sicurezza delle informazioni, inclusa la direttiva (UE) 2022/2555 (NIS2), che impone alle strutture sanitarie l’adozione di misure tecniche e organizzative adeguate alla gestione dei rischi informatici.

In tale contesto, è opportuno richiedere ai fornitori il possesso di certificazioni di sicurezza riconosciute, quali ISO/IEC 27001, SOC 2 Type II, nonché l’uso di meccanismi di cifratura conformi agli standard NIST per la protezione dei dati in transito e a riposo.

Responsabilità professionale: il medico risponde del contenuto, non l’algoritmo

Sul piano della responsabilità professionale, il contenuto della documentazione clinica rimane integralmente imputabile al medico.

L’AI scribe genera note, ma non formula giudizi clinici né assume decisioni terapeutiche; la validazione finale costituisce un atto professionale non delegabile. In caso di errore documentale, la responsabilità può coinvolgere il medico, la struttura sanitaria ed il fornitore, nei limiti della responsabilità contrattuale o da prodotto difettoso.

Il rischio cognitivo e l’automation bias: i limiti che la letteratura evidenzia

Accanto ai delicati profili giuridici, la letteratura evidenzia inoltre la possibile insorgenza del cosiddetto rischio cognitivo. La redazione di note cliniche è parte integrante del ragionamento diagnostico: delegarne integralmente la produzione a sistemi automatizzati può favorire fenomeni di automation bias, riducendo l’elaborazione critica delle informazioni; recenti studi mostrano come i benefici in termini di efficienza dipendano più dall’integrazione organizzativa e dalla formazione del personale che dalla sola adozione tecnologica.

Governance, protocolli e formazione: le condizioni per un uso sicuro

Ne deriva che l’introduzione degli AI medical scribe richiede non solo valutazioni tecniche, ma anche procedure organizzative, protocolli di revisione, formazione e sistemi di controllo, senza i quali il vantaggio in termini di produttività può tradursi in un aumento dell’esposizione al rischio clinico, legale e informatico.


Verso un modello di governance strutturato: la via per un utilizzo conforme

In considerazione delle notevoli opportunità e vantaggi che possono essere determinati dalla diffusione dell’utilizzo dei sistemi di AI medical scribe, accanto alle criticità che sono state brevemente illustrate, appare quantomai necessaria l’adozione di un modello di governance strutturato, fondato sulla corretta qualificazione regolatoria del software, sulla valutazione preventiva dei rischi e sulla definizione di procedure organizzative e di controllo.

Solo in presenza di tali presidi l’impiego dello strumento può ritenersi conforme al quadro normativo europeo e compatibile con le esigenze di sicurezza, affidabilità e tutela dei diritti degli interessati e soprattutto efficace ed efficiente.

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x