Conformità HIPAA e IA: che cosa un BAA non copre

In sintesi

• Il BAA, il contratto che HIPAA impone verso i fornitori, ripartisce la responsabilità sul dato. Nulla dice sull’accuratezza, sull’equità o sulla sicurezza clinica del modello, che è poi dove si concentra la maggior parte del rischio.
• HIPAA ha rinunciato a disciplinare l’intelligenza artificiale. La proposta di riforma della Security Rule presentata nel gennaio 2025 si limita a una richiesta di contributi sull’IA e non introduce alcuna garanzia specifica.
• La regola che vincola davvero l’IA clinica negli Stati Uniti si chiama Section 1557. Gli obblighi sugli strumenti di supporto alle decisioni di cura sono esigibili dal 1° maggio 2025.
• HTI-1 impone ai software sanitari certificati di esporre 31 attributi di origine per il supporto decisionale predittivo, che valgono anche come questionario di due diligence già pronto per qualsiasi fornitore di IA.
• Una conformità HIPAA applicata all’IA regge quando un unico insieme di controlli risponde insieme a HIPAA, alla Section 1557, a HTI-1, alla FDA e, per chi opera su entrambe le sponde dell’Atlantico, all’AI Act europeo.

Che cosa copre davvero HIPAA quando l’IA tocca i dati sanitari

Quasi tutti i contenuti dedicati alla conformità HIPAA e all’IA partono dallo stesso punto: scegliere un fornitore disposto a firmare un BAA, verificare la cifratura, accertarsi che lo strumento non addestri i propri modelli sulle vostre richieste. Il consiglio è corretto ed è anche la parte più piccola del problema. HIPAA si articola in due blocchi operativi. La Privacy Rule disciplina come le informazioni sanitarie protette, le cosiddette PHI, possano essere utilizzate e comunicate. La Security Rule disciplina le garanzie amministrative, fisiche e tecniche applicate alla loro forma elettronica. Un fornitore di IA che riceve, conserva o tratta PHI per conto di un soggetto coperto diventa un business associate, ed entrambe le regole lo raggiungono attraverso il contratto. Ciò che HIPAA non fa è disciplinare il modello. Il testo tace sulla provenienza dei dati di addestramento, sull’accuratezza per sottopopolazione, sulla deriva di calibrazione e sull’appropriatezza clinica di una raccomandazione. Sono questioni che appartengono ad altri regimi, e sono proprio quelle che determinano se un impiego di IA danneggia un paziente. Due zone di confine pesano più di quanto i team immaginino. La prima riguarda l’anonimizzazione. I dati trattati con il metodo Safe Harbor o certificati tramite Expert Determination escono dal perimetro HIPAA, ed è la ragione per cui tanti progetti di IA sanitaria poggiano su corpora anonimizzati. I modelli di grandi dimensioni erodono questa tranquillità, perché la memorizzazione e l’incrocio di elementi all’interno di testo clinico ricco possono riportare un insieme di dati verso l’identificabilità, lungo percorsi che la valutazione originaria non aveva previsto. Se il vostro attestato di anonimizzazione è anteriore al modello, non copre il modello. La seconda zona di confine è il perimetro stesso. HIPAA si applica in base a chi detiene il dato, non in base a quanto il dato sia sensibile. Un verificatore di sintomi rivolto al pubblico, un’applicazione per il benessere o un assistente conversazionale destinato direttamente al paziente, se non stipulano alcun contratto con un soggetto coperto, restano in genere del tutto fuori da HIPAA e ricadono semmai sotto il FTC Act e la Health Breach Notification Rule. Il dato sanitario non porta HIPAA con sé. Lo fa la relazione contrattuale. Questa distinzione ricalca quella che governa ogni altra valutazione d’impatto svolta nella vostra organizzazione, e conviene leggerla accanto alle differenze fra valutazione d’impatto sulla privacy, DPIA e FRIA, dal momento che un programma di IA sanitaria raramente ne richiede una sola.

Il BAA è necessario e non sufficiente

Un business associate agreement assolve tre funzioni utili. Vincola il fornitore alla Privacy Rule e alla Security Rule, delimita gli usi consentiti delle PHI e gli impone di notificare le violazioni. Farne a meno è indifendibile. Quando un fornitore gestisce impropriamente PHI in assenza di contratto firmato, l’Office for Civil Rights considera l’accordo mancante una violazione autonoma, che si somma a tutto il resto. La prassi sanzionatoria conferma che vada preso sul serio. Il 23 aprile 2026 l’OCR ha annunciato accordi transattivi con quattro soggetti per violazioni legate a ransomware, per un totale di 1.165.000 dollari e oltre 427.000 persone interessate, ciascuno accompagnato da un piano di azioni correttive biennale sotto monitoraggio. La supervisione dei fornitori sta alla base di una quota crescente di queste sanzioni, e il coinvolgimento di terzi nelle violazioni di dati sanitari è raddoppiato dal 15 al 30 per cento su base annua nel 2025. Firmate dunque il contratto. Poi osservate che cosa non avete comprato. Un BAA firmato non vi dice quale versione del modello sia in produzione. Non registra i dati su cui il modello è stato addestrato, né se la popolazione di addestramento assomigli alla vostra casistica. Non misura le prestazioni per età, sesso, lingua o regime di copertura. Non rileva che un fornitore abbia sostituito silenziosamente il proprio modello di base in un rilascio trimestrale. E non produce un solo documento da consegnare a un auditor che domandi perché un determinato paziente abbia ricevuto una determinata raccomandazione. Questi vuoti appartengono alla governance, non agli acquisti. Vivono nello stesso luogo in cui vive il resto del vostro modello di conformità e governance: un inventario, un responsabile, una classificazione del rischio, un esito di test, una cadenza di monitoraggio e una traccia decisionale. Il contratto ripartisce la colpa dopo il guasto. La governance rende il guasto meno probabile e dimostrabile in entrambe le direzioni.

Dove HIPAA si ferma: la riforma del 2025 ha evitato l’IA

Chi attende che sia HIPAA stessa a rispondere alla domanda sull’IA farebbe bene a leggere che cosa è accaduto nell’ultimo procedimento normativo. Il 27 dicembre 2024 il Department of Health and Human Services ha annunciato una proposta di ammodernamento della Security Rule, pubblicata nel Federal Register il 6 gennaio 2025. Si tratta della prima revisione sostanziale di quel testo da circa vent’anni. Sui fondamentali di cibersicurezza la proposta è ambiziosa: inventari degli asset, mappatura di rete, autenticazione a più fattori obbligatoria, requisiti di cifratura e rimozione di buona parte della flessibilità che consentiva di trattare le garanzie come facoltative. Sull’intelligenza artificiale, invece, non fa quasi nulla. L’IA compare soltanto in una richiesta di contributi, accanto al calcolo quantistico e alla realtà virtuale e aumentata, con cui si chiede al pubblico come la Security Rule debba trattare le PHI elettroniche impiegate dalle tecnologie emergenti. L’OCR avrebbe potuto fissare regole di base per l’IA e l’apprendimento automatico e ha invece preferito raccogliere osservazioni. La consultazione si è chiusa il 7 marzo 2025 con quasi 5.000 contributi, e il testo definitivo è ancora atteso. La lettura operativa è lineare. Quando la regola finale arriverà, alzerà il vostro livello minimo di sicurezza, il che aiuta. Non vi dirà come validare un modello, come verificare prestazioni disomogenee, né quali prove conservare a proposito di una raccomandazione algoritmica. Ridurre l’obbligo sull’IA al solo HIPAA significa chiedere a una legge scritta per gli archivi di rispondere sull’inferenza. Il quadro completo si distribuisce su più regimi contemporaneamente, ed è il motivo per cui la mappa globale delle leggi sull’IA interessa perfino un erogatore esclusivamente statunitense.

Section 1557: la regola che vincola davvero la vostra IA clinica

Ecco la regola che quasi nessuna guida alla conformità HIPAA per l’IA menziona, ed è già in vigore. La Section 1557 dell’Affordable Care Act vieta le discriminazioni fondate su razza, colore, origine nazionale, sesso, età e disabilità nei programmi e nelle attività sanitarie che ricevono finanziamenti federali. L’HHS ha adottato una regola definitiva il 6 maggio 2024, in vigore dal 5 luglio 2024, che estende espressamente quei principi a ciò che definisce strumenti di supporto alle decisioni di cura. La definizione è volutamente ampia. Comprende strumenti, meccanismi, metodi e tecnologie, automatizzati e non, impiegati a sostegno di una decisione clinica, e vi rientrano quindi algoritmi clinici, punteggi di rischio, logiche di triage e modelli di apprendimento automatico. I soggetti coperti hanno avuto 300 giorni dall’entrata in vigore per adeguarsi alle disposizioni sul supporto decisionale, il che ha fissato la scadenza al 1° maggio 2025. L’obbligo si compone di due parti. Anzitutto, compiere sforzi ragionevoli per individuare gli strumenti di supporto decisionale in uso che impiegano razza, colore, origine nazionale, sesso, età o disabilità come variabile di ingresso. In secondo luogo, compiere sforzi ragionevoli per mitigare il rischio di discriminazione che ne deriva. Entrambi gli obblighi sono continuativi. Non si tratta di un’attestazione da firmare una volta e archiviare. Mettete questi due verbi accanto ai consigli di acquisto che dominano i risultati di ricerca. Nessuna cifratura individua una variabile di ingresso. Nessun BAA mitiga una disparità. La regola raggiunge il modello, e l’obbligo grava sul soggetto coperto, non sul fornitore.

Come si presentano gli sforzi ragionevoli in termini di prove

Le autorità non accettano le intenzioni. Accettano le registrazioni. Per ciascuno strumento di supporto alla decisione clinica, un fascicolo difendibile contiene una scheda di inventario con denominazione, versione e finalità clinica; una revisione documentata delle variabili di ingresso che segnali ogni caratteristica protetta o suo immediato surrogato, come codice di avviamento postale, lingua preferita o stato assicurativo; risultati di prestazione disaggregati secondo i sottogruppi che la regola elenca; una decisione di mitigazione scritta e motivata, compresa quella di accettare un rischio residuo; una cadenza di monitoraggio con soglie definite; e un responsabile designato per nome. Questo corredo probatorio risponde anche alla maggior parte di ciò che chiederà un auditor dell’IA, e si accompagna naturalmente a una posizione chiara su dove si collochi il clinico nel processo. Per uno strumento consultivo, la differenza tra supervisione umana nel processo e sul processo determina esattamente se una misura di mitigazione sia reale oppure soltanto nominale.

HTI-1 e lo strato di trasparenza dentro la cartella clinica

Mentre l’OCR rinunciava a disciplinare i modelli, il programma di certificazione dei software sanitari lo stava facendo comunque. La regola definitiva HTI-1, adottata dall’Assistant Secretary for Technology Policy, già ONC, ha istituito un criterio di certificazione dedicato alle Decision Support Interventions. Esso introduce i primi requisiti di trasparenza del loro genere sugli algoritmi predittivi incorporati in software sanitari certificati. I sistemi certificati devono esporre al clinico attributi di origine strutturati: 13 per il supporto decisionale basato sulle evidenze, 31 per quello predittivo. Sono proprio quei 31 attributi la parte interessante. Descrivono finalità e uso previsto dell’intervento, il processo di sviluppo, i dati impiegati per addestrare e validare il modello sottostante, le modalità di misurazione delle prestazioni, il modo in cui è stata valutata l’equità e la manutenzione dell’intervento nel tempo. L’obiettivo dichiarato consiste nel consentire a un’organizzazione di giudicare se un intervento predittivo sia equo, appropriato, valido, efficace e sicuro, un test che il programma sintetizza nell’acronimo FAVES. Da qui discendono due conseguenze per qualsiasi percorso di conformità HIPAA applicata all’IA. In primo luogo, se il vostro strumento predittivo risiede in un software sanitario certificato, quella documentazione esiste già e voi avete diritto di ottenerla. Molti team compliance non l’hanno mai richiesta. In secondo luogo, e con maggiore utilità pratica, quei 31 attributi costituiscono un questionario fornitori immediatamente riutilizzabile per le IA che non sono certificate da nessuno. Un fornitore che non sappia descrivere la propria popolazione di addestramento, il proprio metodo di validazione o la propria valutazione di equità vi sta dicendo qualcosa, e l’amministrazione federale ha già stabilito che a quelle domande si può rispondere. Servitevene quando dovete decidere se una capacità di IA appartenga alla vostra piattaforma governata oppure alla costellazione di strumenti che le ruota attorno.

FDA e il confine tra funzionalità e dispositivo

Una parte dell’IA clinica costituisce un dispositivo medico regolamentato, e il confine è più sottile di quanto la maggior parte degli acquirenti supponga. La FDA aveva autorizzato oltre 1.350 dispositivi dotati di IA all’inizio del 2026, all’incirca il doppio rispetto al 2022. Un software che analizza un’immagine, calcola un punteggio di rischio per una patologia identificata o conduce a una conclusione diagnostica vi rientra di frequente. Un software che riassume una nota, redige una lettera o instrada un messaggio, di norma no. La domanda dirimente riguarda la destinazione d’uso dichiarata, ossia diagnosticare, trattare, mitigare o prevenire una malattia, e la possibilità per il clinico di esaminare in modo indipendente il fondamento della raccomandazione. L’apprendimento automatico mette sotto tensione la disciplina dei dispositivi su un punto preciso: un dispositivo autorizzato dovrebbe restare conforme all’autorizzazione, mentre un modello tende a cambiare. La risposta della FDA porta il nome di Predetermined Change Control Plan e consente al fabbricante di far preautorizzare un perimetro definito di modifiche future del modello, all’interno della destinazione d’uso approvata. L’adozione resta però limitata: circa il 10 per cento delle autorizzazioni di IA del 2025 comprendeva un piano approvato. Per chi impiega la tecnologia ne discende un controllo concreto. Chiedete a ogni fornitore di IA clinica se il modello sia soggetto a un piano di controllo delle modifiche, come verrete informati di un aggiornamento del modello e che fine faranno le vostre prove di validazione quando il modello cambierà sotto di esse. Un riaddestramento silenzioso può portare un prodotto fuori dalla destinazione d’uso autorizzata e fuori dalla vostra copertura di test nello stesso momento. È un problema di misurazione e monitoraggio, che corrisponde direttamente alle funzioni Measure e Manage del NIST AI Risk Management Framework.

Se operate anche in Europa: il livello AI Act

Molte organizzazioni che trattano PHI statunitensi non sono organizzazioni statunitensi. Fornitori europei di sanità digitale, società di ricerca a contratto, fabbricanti di dispositivi e gruppi ospedalieri con partenariati di ricerca oltreoceano portano obblighi HIPAA per contratto e obblighi europei per legge. Per loro la conformità HIPAA rappresenta soltanto il piano terra. Un’IA che sia un dispositivo medico, o che ne costituisca un componente di sicurezza, è automaticamente ad alto rischio ai sensi dell’AI Act. In concreto, i dispositivi di classe IIa, IIb e III secondo il MDR e di classe da A a D secondo l’IVDR rientrano di norma nella categoria ad alto rischio. I dispositivi di classe I del MDR, che non richiedono l’intervento di un organismo notificato, non vi accedono per questa via, ma possono esservi ricondotti se svolgono una funzione elencata nell’allegato III. L’allegato III aggiunge peraltro due impieghi vicini alla cura, ad alto rischio pur non essendo dispositivi: la gestione delle chiamate di emergenza e il triage dei pazienti nell’assistenza d’urgenza, nonché la valutazione del rischio e la tariffazione nelle assicurazioni vita e malattia. Assicuratori e piattaforme di triage presumono spesso che l’AI Act sia una questione di dispositivi. Non lo è. Le scadenze sono cambiate nel 2026. Dopo il Digital Omnibus adottato nel giugno 2026, gli obblighi per i sistemi ad alto rischio autonomi dell’allegato III si applicano dal 2 dicembre 2027, mentre l’IA collocata dentro un dispositivo regolato da MDR o IVDR dispone di tempo fino al 2 agosto 2028. A marzo 2026 i dispositivi medici dotati di IA continuavano a essere certificati esclusivamente ai sensi di MDR e IVDR, e gli obblighi ad alto rischio dell’AI Act non erano ancora loro applicabili. Quel divario è tempo di preparazione, non un esonero. Per le organizzazioni italiane conviene ricordare che il Garante per la protezione dei dati personali si è già pronunciato più volte sui trattamenti sanitari automatizzati e sul fascicolo sanitario elettronico, e che le valutazioni d’impatto prodotte in quella sede coprono buona parte di ciò che l’AI Act chiederà in seguito. Come riferimento sugli obblighi in quanto tali restano centrali i doveri di fornitori e utilizzatori previsti dall’AI Act.

Costruire la conformità HIPAA dell’IA su un unico insieme di controlli

Quattro regimi, quattro vocabolari, un’unica serie di domande di fondo. Che cosa è questo sistema, chi ne risponde, che cosa può sbagliare, come ve ne accorgereste e siete in grado di dimostrarlo. Mandare avanti quattro programmi di conformità paralleli è il modo in cui le organizzazioni sanitarie bruciano un anno e non superano comunque l’audit. Partite da un inventario. Ogni sistema di IA che tocchi pazienti o informazioni sanitarie protette riceve una scheda, compresi quelli che nessuno ha dichiarato. Gli assistenti di trascrizione acquistati da un singolo reparto, una funzione di sintesi attivata dentro una piattaforma già in uso e i clinici che incollano note in un assistente conversazionale di largo consumo rientrano tutti nel perimetro, e tutti e tre i casi sono frequenti. Il problema della shadow AI pesa in sanità più che altrove, perché il beneficio clinico è immediato mentre il percorso di acquisto è lento. Classificate poi ciascun sistema con quattro domande binarie. Tratta informazioni sanitarie protette? Influenza una decisione di cura? Risiede dentro un software sanitario certificato? È, o contiene, un dispositivo regolamentato? Le risposte determinano quali obblighi si attivano.

Tenete insieme il tutto con un sistema di gestione anziché con un foglio di calcolo. ISO/IEC 42001 fornisce la struttura certificabile: politica, ruoli, trattamento del rischio, audit interno, riesame della direzione. Il NIST AI Risk Management Framework fornisce il ciclo di lavoro, ossia Govern, Map, Measure e Manage. Nessuno dei due è una normativa sanitaria statunitense, ed è esattamente per questo che funzionano come strato di collegamento: sono il luogo in cui una prova può essere prodotta una sola volta e opposta a più obblighi. È lo stesso argomento che sorregge qualunque framework di governance dell’IA serio, applicato a un settore in cui le conseguenze arrivano più in fretta.

Domande frequenti

Si può usare l’IA rispettando HIPAA? Sì. HIPAA non vieta l’intelligenza artificiale, e nulla nella Privacy Rule o nella Security Rule impedisce a un soggetto coperto di trattare informazioni sanitarie protette con un modello. Ciò che HIPAA richiede è che il fornitore venga inserito come business associate mediante contratto scritto, che le garanzie si applichino alle PHI elettroniche coinvolte e che l’uso sia consentito dalla Privacy Rule. Una revisione della conformità HIPAA applicata all’IA dovrebbe perciò partire dalla finalità clinica anziché dal fornitore, perché la difficoltà maggiore consiste nel soddisfare le altre regole applicabili, in primo luogo la Section 1557. ChatGPT è conforme a HIPAA per un uso sanitario? La versione destinata al pubblico non lo è. Un modello non è mai conforme di per sé; conforme può esserlo un impiego. La conformità dipende dalla disponibilità del fornitore a firmare un BAA, dall’esclusione di richieste e risposte dall’addestramento, dalla politica di conservazione e dalla capacità della configurazione di gestire controllo degli accessi e registrazione. Le offerte enterprise e le API dei grandi fornitori possono sostenere un impiego conforme. Le interfacce gratuite di largo consumo di norma no, ed è la ragione per cui incollare note cliniche in un assistente pubblico figura oggi tra le violazioni più diffuse del settore. Un BAA firmato rende conforme a HIPAA uno strumento di IA? No. Un business associate agreement è una ripartizione contrattuale di obblighi sul dato. Non valuta il modello, non verifica l’accuratezza tra sottopopolazioni di pazienti e non crea alcuna traccia del perché una determinata raccomandazione sia stata formulata. Le autorità non hanno mai considerato un contratto firmato come prova dell’effettiva attuazione delle garanzie, e gli obblighi della Section 1557 gravano sul soggetto coperto a prescindere da quanto il fornitore abbia accettato. Qual era la scadenza della Section 1557 per gli strumenti di supporto decisionale? La regola definitiva è stata adottata il 6 maggio 2024 ed è entrata in vigore il 5 luglio 2024. I soggetti coperti hanno avuto 300 giorni dall’entrata in vigore per adeguarsi alle disposizioni sugli strumenti di supporto alle decisioni di cura, il che ha fissato la scadenza al 1° maggio 2025. Quegli obblighi sono ormai attivi e continuativi, sicché un’organizzazione che non abbia mai passato in rassegna i propri algoritmi clinici alla ricerca di variabili protette è già in ritardo. HIPAA si applica se la mia IA usa solo dati anonimizzati? I dati correttamente anonimizzati escono dall’ambito di HIPAA, sia per la via del Safe Harbor sia tramite Expert Determination. La cautela è d’obbligo perché l’anonimizzazione è una proprietà di un insieme di dati in un dato momento, non uno stato permanente. Testo clinico ricco, combinazioni di quasi identificatori e memorizzazione da parte del modello possono tutti far risalire il rischio di reidentificazione. Se la valutazione è anteriore all’ingresso dei dati in una catena di trattamento basata su modelli, fatela riesaminare rispetto a quella catena anziché presumerne la trasferibilità. Chi risponde quando un fornitore di IA provoca una violazione di dati sanitari? Possono rispondere entrambe le parti. I business associates rispondono direttamente ai sensi di HIPAA delle proprie violazioni, e i soggetti coperti restano responsabili della scelta e della supervisione dei fornitori. In assenza di contratto, il soggetto coperto si espone a un rilievo distinto per quella sola mancanza. Al di là di HIPAA, la responsabilità per una raccomandazione clinica dannosa si regge sul diritto della responsabilità sanitaria e da prodotto, dove la struttura curante è raramente estranea al procedimento. Il vostro processo di segnalazione degli incidenti dovrebbe quindi presupporre un’esposizione condivisa. Un’organizzazione sanitaria europea che assiste pazienti statunitensi deve rispettare sia HIPAA sia l’AI Act? Nella maggior parte dei casi sì, e davanti ad autorità diverse. HIPAA raggiunge un operatore europeo attraverso il BAA che lo lega a un soggetto coperto statunitense. AI Act, GDPR e MDR o IVDR lo raggiungono attraverso il diritto dell’Unione. Gli obblighi si sovrappongono ampiamente su gestione del rischio, registrazione, documentazione e sorveglianza umana, per cui la via efficiente consiste nel mappare un unico insieme di controlli su entrambi i regimi, anziché tenere in piedi due programmi paralleli.

Conclusione

I risultati di ricerca sulla conformità HIPAA e l’IA descrivono una decisione di acquisto. L’obbligo reale descrive invece un modo di operare. HIPAA disciplina il dato. La Section 1557 disciplina la decisione, e lo fa da maggio 2025. HTI-1 disciplina l’informazione resa. La FDA disciplina il dispositivo. Per chi opera su entrambe le sponde dell’Atlantico, l’AI Act disciplina il sistema. Nessuna di queste regole è da sola la risposta, e nessuna si accontenta di un contratto firmato accompagnato da una promessa di cifratura. Ciò che le tiene insieme non ha nulla di spettacolare ed è del tutto raggiungibile: conoscere ogni sistema di IA in esercizio, classificarlo con onestà, metterlo alla prova rispetto alle caratteristiche che la legge elenca, mettere per iscritto che cosa si è deciso e perché, e sorvegliarlo dopo l’avvio. Questa è la governance dell’IA, e in sanità segna la differenza tra un programma difendibile e una buona intenzione.