Governance dell'IA nella sanità: Conformità e sicurezza

Le organizzazioni sanitarie hanno adottato l'IA più rapidamente di quanto abbiano sviluppato la governance per gestirla. L'ottantotto percento dei sistemi sanitari utilizza già l'IA internamente, mentre solo il 18% dispone sia di una struttura di governance matura che di una strategia IA completa.

La Healthcare Financial Management Association ha riportato entrambe le cifre in Health System Readiness for AI, da un sondaggio di maggio 2025 su oltre 230 dirigenti di sistemi sanitari.

L'IA arriva raramente tramite acquisti, ed è così che supera l'inventario. Una licenza Microsoft 365 Copilot viene aggiunta a un accordo esistente, una funzione di documentazione ambientale viene integrata nella cartella clinica elettronica (EHR) o un medico utilizza un dispositivo personale.

Il Shadow AI Report di Wolters Kluwer di dicembre 2025 Shadow AI Report ha intervistato 518 fornitori e amministratori ospedalieri e ha rilevato che il 57% aveva incontrato o utilizzato uno strumento di IA non autorizzato.

Non sapere a cosa può accedere uno strumento di IA diventa un problema di responsabilità nel momento in cui un membro del consiglio o un revisore chiede quali strumenti trattano informazioni sanitarie protette (PHI), chi ne è il proprietario e cosa dimostra che i controlli funzionano.

Cos'è la governance dell'IA nella sanità?

Governance dell'IA nel settore sanitario è la disciplina che consiste nel sapere dove i sistemi di IA accedono a PHI, chi è responsabile per ogni caso d'uso e se i controlli su tale accesso possono essere dimostrati efficaci. Le organizzazioni sottovalutano il terzo elemento perché considerano una politica scritta come prova, quando descrive solo l'intento.

Un comitato del consiglio o un revisore esterno sta verificando se l'organizzazione può dire, sul momento, a cosa accede uno specifico strumento di IA e chi ne è il proprietario. La maggior parte delle organizzazioni sanitarie non può, perché Copilot pilots, l'IA integrata del fornitore e gli strumenti conversazionali raggiungono sistemi adiacenti a PHI prima che la sicurezza finisca di catalogarli.

Le conseguenze emergono nei dati delle violazioni. Il Netwrix 2026 Data and Identity Security Report ha registrato un tasso di violazioni del 43% negli ultimi 12 mesi nelle organizzazioni in cui l'IA ha aumentato significativamente l'impronta di identità, contro l'11% dove l'IA non l'ha modificata in modo significativo.

L'indagine alla base di quel rapporto ha anche rilevato che solo il 21% delle organizzazioni ha completa visibilità, monitoraggio e controlli su quali dati sensibili utilizzano gli strumenti, i modelli o i copiloti di IA.

Perché il settore sanitario comporta un livello diverso di rischio AI

Il caso generico per la governance dell'IA si basa sul rischio reputazionale e operativo. Nel settore sanitario, l'esposizione è regolamentata, i dati sono particolarmente preziosi e la responsabilità rimane al fornitore, non a chi ha costruito il modello. La cybersecurity sanitaria già presenta questa asimmetria.

Una cartella clinica rubata non scade mai

La maggior parte dei dati regolamentati ha una durata limitata, che determina il valore di una violazione. Una carta di pagamento rubata viene annullata e riemessa entro pochi giorni. Una cartella clinica contiene diagnosi, dettagli assicurativi, dati demografici e un numero di Social Security, nessuno dei quali può essere riemesso, quindi rimane sfruttabile per anni dopo la violazione che l'ha generata.

Il settore sanitario quindi non può fare affidamento sul contenimento che altri settori ottengono gratuitamente. Uno strumento di IA che raggiunge PHI crea un’esposizione senza data di scadenza, aumentando il costo di un errore nel design degli accessi, non solo la probabilità che accada.

Il fornitore si assume la responsabilità anche quando un venditore causa la violazione

Le organizzazioni sanitarie soggette a HIPAA, definite dalla norma come entità coperte, rimangono legalmente responsabili per la PHI indipendentemente da chi elabori il modello. Questo è ciò che distingue l'acquisto di AI qui dall'acquisto di AI in un settore non regolamentato, dove un contratto con il fornitore può spostare il rischio. Le regole di conformità HIPAA che regolano ogni altro sistema si applicano all'AI senza modifiche.

Il Dipartimento della Salute e dei Servizi Umani (HHS) Ufficio per i Diritti Civili (OCR) considera un chatbot AI di terze parti che gestisce PHI su un portale pazienti come un business associate, lo stesso status applicato ai fornitori cloud. I business associates hanno obblighi diretti propri, e ciò non riduce quelli del fornitore. OCR ha risolto controversie con fornitori per fallimenti di vendor in passato, incluso il North Memorial settlement legato a una mancanza di Business Associate Agreement (BAA).

Un unico processo di revisione non può coprire entrambi i tipi di IA che un ospedale utilizza

La maggior parte dei settori utilizza una sola classe di AI e la governa in un modo. Un ospedale ne usa due contemporaneamente, e falliscono in modo abbastanza diverso da far sì che un singolo processo di revisione ne trascuri una.

Uno strumento diagnostico fallisce quando raggiunge un paziente con una raccomandazione errata o distorta, che è una questione di sicurezza del paziente per la leadership clinica e, spesso, per la FDA. Un assistente alla produttività fallisce quando mostra PHI a qualcuno che non avrebbe mai dovuto vederla, che è una questione di controllo degli accessi per la sicurezza. Far passare entrambi dallo stesso comitato significa che gli strumenti amministrativi ricevono un controllo in stile clinico di cui non hanno bisogno, mentre nessuno chiede a cosa possono effettivamente accedere.

Una violazione nel settore sanitario costa più che in qualsiasi altro settore

Il settore sanitario ha avuto il costo medio più alto per violazioni di dati per più di un decennio, raggiungendo 6,64 milioni di dollari nel 2026 (in calo da 7,42 milioni nel 2025) secondo IBM's Cost of a Data Breach Report. Nessun altro settore è rimasto in cima così a lungo.

Quella cifra è ciò che rende il design dell'accesso AI una questione a livello di consiglio piuttosto che IT. Determina il costo di un errore ed è solitamente il numero che il consiglio ricorda da un briefing.

La differenza tra IA clinica e IA amministrativa nell'assistenza sanitaria

La governance si divide tra l'IA che informa la cura e l'IA che gestisce il lavoro ad essa collegato. Ogni parte ha proprietari, regolatori e domande diverse da affrontare.

La validazione clinica dell'IA è una disciplina seria con un proprio apparato normativo, e non qualcosa che una piattaforma di visibilità dei dati dovrebbe pretendere di risolvere. L'IA amministrativa appartiene alla sicurezza, all'IT e alla privacy, ed è lì che si pongono realmente le domande di accesso poste da un consiglio.

Come i regolatori statunitensi rispondono all'IA nella sanità

La regolamentazione federale, l'accreditamento e la legislazione statale stanno tutte avanzando, e nessuna richiede di aspettare una regola finale prima di agire. I regolatori considerano l'IA come un'estensione degli obblighi esistenti, quindi i nuovi requisiti si applicano ai sistemi sanitari già gestiti dalla macchina HIPAA.

L'aggiornamento della HIPAA Security Rule nomina direttamente l'IA

HHS ha emesso un avviso di proposta di regolamentazione (NPRM) sulla Regola di Sicurezza HIPAA che affronta esplicitamente l'intelligenza artificiale. La sua proposta di analisi del rischio per le informazioni elettroniche protette (ePHI) nomina direttamente gli strumenti AI. Richiede "considerazione ripetuta, tra le altre cose, del tipo e della quantità di ePHI a cui accedono gli strumenti di intelligenza artificiale, a chi vengono divulgati i dati e a chi viene fornito l'output."

La regola rimane proposta e l'OCR continua a far rispettare l'attuale Security Rule. Le entità coperte che eseguono HIPAA risk analyses oggi dovrebbero già documentare come gli strumenti di IA interagiscono con ePHI.

La Joint Commission ora certifica la governance dell'IA

La Joint Commission ha lanciato la sua Responsible Use of AI in Healthcare certification il 1 giugno 2026, il primo programma di certificazione basato su come i sistemi sanitari governano l’IA piuttosto che sui prodotti di IA stessi.

Rilascia la certificazione a livello di organizzazione o sistema, e i suoi standard coprono governance, gestione dei dati, riduzione del rischio e dei bias, monitoraggio e validazione, trasparenza e formazione.

La certificazione è volontaria, anche se le organizzazioni accreditate dovrebbero aspettarsi che le aspettative sottostanti emergano nelle conversazioni dei sondaggi.

Le leggi statali sull'IA si stanno sovrapponendo a HIPAA

La legislazione statale aggiunge obblighi invece di sostituire quelli federali, quindi i sistemi sanitari che operano tra stati diversi ereditano requisiti che variano in base al luogo in cui viene erogata l'assistenza.

Il Texas Responsible Artificial Intelligence Governance Act richiede la divulgazione al paziente quando i fornitori utilizzano l'IA nelle cure dal 1° gennaio 2026, e l'AB 3030 della California richiede disclaimer nelle comunicazioni generate dall'IA riguardo alle informazioni cliniche del paziente.

La preminenza federale sembra improbabile che allevi questo onere. Il Senato ha votato 99 a 1 nel luglio 2025 per rimuovere una moratoria di dieci anni sulla regolamentazione statale dell'IA dal disegno di legge di conciliazione del bilancio, lasciando agli operatori multi-stato obblighi cumulativi e specifici per giurisdizione.

Gli obblighi della FDA e del EU AI Act rimangono di ambito clinico

Supervisione FDA sui dispositivi medici abilitati all'IA e le regole ad alto rischio dell'EU AI Act impongono requisiti reali e si applicano principalmente all'IA che supporta diagnosi o trattamenti. Un team che valuta l'IA amministrativa dovrebbe comunque confermare in quale categoria rientra ogni strumento, poiché la documentazione ambientale e gli strumenti di triage sono più vicini alla linea clinica di quanto suggeriscano i fornitori.

Perché Microsoft 365 Copilot merita una conversazione dedicata alla governance

Copilot è l’unico strumento amministrativo di IA che la maggior parte dei sistemi sanitari distribuisce a livello di tenant, e necessita di un trattamento separato perché non cambia nulla riguardo ai permessi ma cambia tutto su chi li nota.

La documentazione di Microsoft afferma che Copilot "mostra solo i dati organizzativi a cui gli utenti individuali hanno almeno i permessi di visualizzazione." Ogni questione di governance si basa quindi su ciò che tali permessi già consentono, e questo produce tre problemi che un documento di policy non può risolvere:

• Lo sforzo si riduce, quindi l'accesso inattivo viene utilizzato: Qualcuno che poteva già aprire un file in SharePoint o cercare in una casella di posta ora può chiedere a Copilot di riassumerlo, mostrarlo in una conversazione diversa o inserirlo in una bozza. Il permesso è sempre stato lì. Ciò che si riduce è il lavoro necessario per esercitarlo, da una ricerca deliberata a una frase in linguaggio naturale.
• La condivisione eccessiva passata diventa esposizione attuale: Link di condivisione ampi, permessi obsoleti e appartenenze a gruppi che nessuno ha rivisto dopo una riorganizzazione restano innocui finché qualcosa non inizia a leggerli rapidamente. La licenza di Copilot in un tenant sanitario è quel momento, ecco perché Copilot data security inizia con un audit dei permessi.
• Mostrare PHI al clinico sbagliato viola HIPAA: Quando quel contenuto condiviso eccessivamente è PHI, mostrarlo a utenti che non ne hanno bisogno viola lo standard minimo necessario previsto da 45 CFR 164.502(b). La crittografia con etichetta di sensibilità cambia sostanzialmente l'esposizione, perché Copilot necessita dei diritti di estrazione per riassumere il contenuto.

I sistemi sanitari che hanno svolto questo lavoro riportano che la correzione delle autorizzazioni arriva a milioni di correzioni individuali di condivisione prima di un rollout a livello di tenant, il che rende la preparazione un progetto anziché una semplice casella da spuntare.

Come costruire un programma di governance dell'IA sanitaria

Ognuna di queste decisioni appartiene a un leader che la prende e poi delega il lavoro, e devono avvenire in ordine. Nomina un responsabile prima che l'inventario esista, e quella persona non ha ancora nulla da gestire.

Nomina un unico responsabile

"Il comitato di governance dell'IA se ne occuperà," senza una persona nominata dietro, è così che questi programmi si bloccano. Non importa se quella persona è in sicurezza, conformità o IT, conta che una persona sia responsabile, proprio come un responsabile della privacy HIPAA è responsabile della privacy.La guida della Joint Commission richiede un proprietario nominato che guidi l'implementazione dell'IA durante tutto il ciclo di vita.

Basare l'inventario su ciò che ogni strumento può effettivamente raggiungere

Catalogare ogni sistema di IA che coinvolge flussi clinici, amministrativi o incorporati, e mappare ciascuno ai dati PHI o adiacenti a PHI che può raggiungere. Inoltrare ogni voce al proprietario che può valutare come fallisce, inviando strumenti diagnostici alla revisione clinica e strumenti di produttività alla sicurezza.

La maggior parte degli inventari parte da zero, perché la scoperta stessa è solitamente informale. Un sondaggio di dicembre 2025 su 51 organizzazioni sanitarie condotto da Censinet e dalla CHIME Foundation ha rilevato che il 51% si affidava a una scoperta informale ad hoc o alle note di rilascio del fornitore per sapere quale AI stavano utilizzando. I rischi di sicurezza di Shadow AI si accumulano finché quella scoperta rimane informale.

Conferma che la copertura del fornitore e del BAA corrisponda all'effettivo utilizzo dell'AI

Ogni fornitore di AI che crea, riceve, mantiene o trasmette PHI necessita di un BAA che affronti come l'AI del fornitore elabora, archivia e conserva PHI. Un BAA standard firmato prima che l'AI entrasse nel prodotto lascia una reale lacuna di responsabilità anche se l'accordo è ancora in vigore, quindi gli aggiornamenti del prodotto del fornitore dovrebbero innescare la revisione piuttosto che le date di rinnovo.

Esamina specificamente il servizio coperto, l'uso dei dati, la conservazione, i subappaltatori e i termini di sicurezza. Controlla il contratto di servizio standard insieme al BAA, poiché un BAA firmato non annulla termini separati che concedono al fornitore ampi diritti di utilizzo dei dati del cliente. La copertura varia anche in base alla linea di prodotti. OpenAI offre BAA per le implementazioni idonee di ChatGPT Enterprise che utilizzano un Regulated Workspace, mentre ChatGPT Business rimane non idoneo.

Imposta controlli su dati e identità in base a quanto trovato nell'inventario

Le restrizioni di accesso e il monitoraggio devono affrontare l'esposizione effettivamente emersa dall'inventario. Il linguaggio di minimo privilegio scritto prima che qualcuno sapesse a quali sistemi l'IA potesse accedere non supererà la domanda di approfondimento di un revisore. Una valutazione del rischio di identity and access management limitata ai sistemi inventariati produce quella specificità.

Il controllo risultante deve essere concreto, non una dichiarazione di policy. Se l'inventario mostra che Copilot può accedere a una condivisione di file contenente fogli di calcolo del censimento dei pazienti, il controllo è una remediation dei permessi su quella condivisione, con data e responsabile.

Implementa un percorso di monitoraggio e escalation

Un programma ha bisogno di un modo per rilevare l'esposizione a PHI guidata dall'IA mentre accade, e una persona nominata a cui segnalare quando la rilevazione si attiva. La rilevazione significa monitorare i repository da cui gli strumenti IA leggono, che è un normale monitoraggio degli accessi ai file rivolto a un nuovo consumatore. Senza la parte di escalation, il primo segno di un problema è un rapporto di incidente dove avrebbe dovuto esserci una revisione della governance.

Utilizzo di NIST AI RMF e HIPAA come modello operativo

NIST AI RMF fornisce la struttura per un programma di governance dell'IA sanitaria, e HIPAA fornisce le specifiche legali; insieme eliminano la necessità di un framework su misura.

Le quattro funzioni di NIST si integrano perfettamente in un programma di governance. Govern è il proprietario responsabile nominato, Map è l'inventario, Measure è la valutazione dei rischi effettivi di ogni caso d'uso, e Manage sono i controlli e il monitoraggio continui. Il ciclo è continuo, non una configurazione una tantum.

L'aspettativa di inventario è esplicita, poiché Subcategory GOVERN 1.6 richiede meccanismi per inventariare i sistemi di IA, e l'inventario degli asset tecnologici proposto dal NPRM renderebbe tale aspettativa normativa.

Le Regole sulla Privacy e Sicurezza di HIPAA forniscono quindi gli obblighi legali sotto quella struttura ogni volta che è coinvolta la PHI. Insieme, producono un quadro ampio e comprensibile, e nessuna delle due strutture richiede una certificazione formale.

La prova che dimostra che l'accesso a PHI è effettivamente controllato

Gli auditor e i comitati del consiglio richiedono gli artefatti, e il recupero è il punto in cui la maggior parte dei programmi fallisce: fanno il lavoro, poi disperdono le prove su sei sistemi e nelle caselle di posta di quattro persone. Ogni artefatto deve esistere prima che arrivi la domanda.

Un inventario attuale del sistema AI con un proprietario nominato

Ogni sistema catalogato, ciascuno legato a un individuo nominato, non a un dipartimento, che possa rispondere quando un revisore chiede chi ha approvato una determinata espansione di Copilot. La voce dovrebbe anche registrare quali PHI il sistema può raggiungere, così l'inventario e la mappa del flusso dei dati rimangono riconciliabili anziché diventare due documenti separati.

Una mappa del flusso di dati che mostra dove la PHI entra in uno strumento di IA

Ogni luogo in cui PHI entra in uno strumento AI, un prompt, un file, un embedding o un output, localizzato da strumenti di scoperta dati sensibili lungo ogni percorso. La proposta della HIPAA Security Rule richiederebbe una mappa di rete ePHI aggiornata almeno annualmente, quindi questo artefatto sta diventando un requisito normativo più che una buona pratica.

Documentazione del fornitore e BAA specifica per ogni strumento di IA

Documentazione legata alla specifica capacità di IA fornita da ogni fornitore, non una cartella BAA generale, confrontata con la copertura confermata durante la configurazione del programma. Una cartella del genere non risponde alla domanda che un revisore pone realmente.

Report di accesso e permessi che mostrano chi può raggiungere sistemi adiacenti a PHI

Una risposta istantanea su ciò che uno strumento di IA può vedere, ovvero le identità e i gruppi che hanno accesso ai repository sottostanti, non la schermata di configurazione dello strumento. Le impostazioni di Copilot descrivono cosa farà con i permessi che già possiede, quindi un rapporto basato solo sullo strumento sottovaluta la portata. Un revisore chiede dei permessi effettivi, incluso l'accesso ereditato tramite gruppi nidificati.

Un registro delle modifiche che mostra quando è cambiato quell'accesso

La variazione negli accessi nei mesi trascorsi dall’ultimo snapshot, più ampia o più ristretta rispetto a prima, qualcosa che un singolo report di accesso non può mostrare da solo. Questa tendenza è ciò che un auditor vuole effettivamente vedere.

Registri di revisione della governance che mostrano che il programma è effettivamente in esecuzione

Verbali, approvazioni o note di revisione che dimostrano una reale cadenza. Il framework di governance informatica AI del Health Sector Coordinating Council di maggio 2026 AI cyber governance framework raccomanda report strutturati trimestrali sui rischi AI per il consiglio.

Un'organizzazione che può fornire ciascuno di questi su richiesta ha un programma. Una che impiega una settimana per raccoglierli ha una politica.

Come Netwrix supporta il livello di evidenza

Netwrix fornisce il livello di visibilità dei dati e prove di audit sotto un programma che l'organizzazione sanitaria costruisce e possiede, rispondendo a quali repository contengono PHI, chi può accedervi e cosa è cambiato. La governance delle informazioni in ambito sanitario dipende dalla possibilità di recuperare queste risposte.

Visibilità dei dati sensibili

Netwrix 1Secure identifica i repository contenenti PHI a cui Copilot e altri strumenti di IA possono accedere e valuta la preparazione di Copilot prima del rilascio, non dopo. Netwrix Access Analyzer aggiunge la scoperta automatica di PHI e la mappatura predefinita della conformità HIPAA su file server, SharePoint e ambienti ibridi, con modelli di rilevamento che coprono codici ICD-10, numeri di cartelle cliniche e nomi di farmaci prescritti.

Contesto di Identity e accesso

Netwrix Access Analyzer segnala i permessi effettivi sui dati adiacenti a PHI, inclusi gli accessi eccessivi e ereditati che gruppi ampi acquisiscono senza che nessuno se ne accorga. Netwrix 1Secure e Netwrix Auditor segnalano l’attività e le modifiche dei permessi in Active Directory e Microsoft Entra ID nel tempo.

King's College Hospital ha utilizzato Netwrix Auditor per rafforzare il controllo sui privilegi che accedono ai dati dei pazienti, con piena visibilità su una rete di 10.000 utenti a supporto della reportistica di conformità del National Health Service.

Prove di audit

Netwrix Auditor registra le modifiche di accesso e permessi, catturando chi ha accesso a cosa, quando e cosa è cambiato, con valori prima e dopo. Il suo Archivio a Lungo Termine conserva le prove più vecchie, che mantengono il registro delle modifiche utilizzabile durante l’intero ciclo di audit e non solo dalla chiusura dell’ultima finestra di conservazione.

Netwrix 1Secure copre l’aspetto AI della stessa domanda. Riporta le interazioni di Microsoft 365 Copilot e traccia quali dati sensibili Copilot ha accesso e mostrato, che è l’elemento che risponde a ciò che uno strumento ha effettivamente raggiunto piuttosto che ciò a cui era autorizzato.

Dove Netwrix si ferma

Netwrix non fornisce la governance dell'IA sanitaria come categoria e non garantisce la conformità HIPAA. Non governa né applica politiche a Copilot o ad altri strumenti di IA, né convalida modelli clinici o rileva bias clinici. Il suo ruolo è lo strato di evidenza sotto un programma di governance di proprietà dell'organizzazione.

Scopri cosa possono effettivamente raggiungere i tuoi strumenti di IA prima che lo chieda un revisore

La maggior parte delle organizzazioni sanitarie non riesce ancora a rispondere a cosa raggiungono Copilot e gli altri strumenti amministrativi di IA, e la ragione raramente è una politica mancante. Nessuno l'ha mappato.

Quella mappatura è il punto di partenza del programma, perché indica al proprietario responsabile quali repository sono importanti e trasforma un elenco di artefatti richiesti in report che qualcuno può effettivamente eseguire. I team che valutano un livello di evidenza dovrebbero verificare se può mappare l'esposizione PHI, calcolare l'accesso effettivo, preservare la cronologia delle modifiche delle autorizzazioni e produrre tali registri su richiesta.

Richiedi una demo per vedere a quali repository adiacenti a PHI possono accedere i tuoi strumenti di IA, chi ha il permesso su quei dati e come è cambiato l’accesso nel tempo.