← Resources
USECASE · 2026-03-12
AI privata per la sanità: Workspace HIPAA-aligned senza lock-in cloud
L'AI HIPAA-aligned non richiede di spedire PHI a un modello di terze parti. Un Workspace on-device-first con fallback cloud BYOK opzionale, audit log, RBAC e BAA firmato dove qualsiasi cloud è toccato può soddisfare la maggior parte dei requisiti delle covered entity.
Cosa richiede davvero HIPAA da un assistente AI
*Questo articolo è una guida generale e non è consulenza legale o di compliance; l'ultima parola spetta al privacy officer della tua covered entity.*
HIPAA è stata scritta attorno ai dati, non al tool che li legge, perciò un assistente AI è trattato come qualsiasi altro membro del personale o business associate che tocchi protected health information. La Privacy Rule governa gli usi e le disclosure consentite di PHI e lo standard di minimum-necessary. La Security Rule richiede salvaguardie amministrative, fisiche e tecniche, inclusi controllo degli accessi, controlli di audit, integrità, sicurezza di trasmissione e un'analisi del rischio documentata. La Breach Notification Rule stabilisce il dovere di notificare gli individui colpiti, HHS e nei casi più ampi i media quando PHI non sicura viene disclosa senza autorizzazione.
La recente rulemaking di HHS ha segnalato che i sistemi AI che creano, ricevono, mantengono o trasmettono ePHI devono essere inventariati e sottoposti a risk-analysis come qualsiasi altro asset, con cifratura in transit e at rest, multi-factor authentication e risposta tempestiva agli incidenti. L'obbligo non cambia perché l'entità che legge la cartella è un modello.
Dove ChatGPT, Copilot e Gemini falliscono per PHI
Out of the box, i tier consumer di ChatGPT, Microsoft Copilot e Google Gemini non sono appropriati per PHI. Le sottoscrizioni free e standard non vengono con un Business Associate Agreement, e i prompt possono essere ritenuti o usati per il miglioramento del modello secondo i termini di default.
La sfumatura da tenere a mente: ogni vendor offre configurazioni enterprise che possono essere portate sotto un BAA. OpenAI firma BAA per le API e per ChatGPT Enterprise o Edu attraverso account gestiti da sales. Microsoft offre copertura BAA per Azure OpenAI Service e certi tenant Microsoft 365 Copilot, anche se GitHub Copilot e altre superfici consumer sono escluse. Google supporta un BAA per Gemini all'interno dei tier Workspace qualificanti, ma esclude esplicitamente NotebookLM e la superficie Gemini-in-Chrome.
Il rischio pratico è la deriva del personale. Un clinico che incolla un sommario di dimissione in un tab di chatbot free in un browser è, di default, una disclosure al di fuori di qualsiasi BAA, indipendentemente da ciò che il contratto enterprise dice.
L'architettura on-device-first: modello locale + BYOK opt-in
Un'architettura che minimizza l'esposizione HIPAA inverte il solito pattern SaaS. Il modello di default gira sul dispositivo dell'utente, tipicamente un LLM open-weights quantizzato servito localmente, così prompt e generazioni non lasciano mai l'endpoint. Quando un clinico ha bisogno di un modello di reasoning più forte, il Workspace può fare fallback verso un provider cloud usando la chiave API dell'organizzazione, sotto il BAA di quel provider, con un opt-in esplicito per richiesta o per Workspace.
Questo è il pattern dietro osFoundry: un runtime llama.cpp locale è il default di prima classe, e qualsiasi chiamata cloud è bring-your-own-key contro un vendor che la covered entity ha contrattualizzato indipendentemente. Non c'è un pool di inferenza multi-tenant condiviso tra il clinico e il modello.
Il beneficio di compliance è concreto. I workload che possono essere gestiti localmente non generano mai un evento di disclosure cloud. I workload che richiedono capacità cloud sono tracciati, attribuibili e soggetti al BAA che la covered entity ha già vagliato.
Audit, RBAC, DLP e minimum-necessary nella pratica
Le salvaguardie tecniche sono dove la maggior parte dei pilot AI fallisce il primo audit interno. Quattro controlli fanno il lavoro pesante.
Gli audit log devono catturare chi ha promptato, quale modello ha risposto, quali data source sono stati allegati e cosa è stato restituito, con storage tamper-evident e una finestra di retention che corrisponda alla tua policy di retention dei record. RBAC dovrebbe legare l'accesso al modello, l'accesso al dataset e l'accesso ai tool al ruolo lavorativo, così un account di front-desk non può interrogare un corpus di oncologia e un ruolo di billing non può triggerare un generatore di note cliniche.
La DLP appartiene al confine del prompt. Redazione basata su pattern e classificatori degli identificatori prima di qualsiasi chiamata cloud impone lo standard minimum-necessary programmaticamente piuttosto che solo attraverso la formazione. La data residency per Workspace mantiene i dati di uno studio dal mescolarsi con quelli di un altro.
Nessuna di queste è un'invenzione AI-specifica, ma insieme sono ciò che permette a un privacy officer di firmare il via libera a un modello che tocca una cartella.
Tre workflow: note di intake, prior auth, Q&A operativo
Le note di intake e visita sono il workload locale di maggior valore. Un clinico detta, un modello locale redige una nota strutturata e nulla lascia il dispositivo finché il clinico non firma e l'EHR riceve un record postato sulla sua interfaccia esistente. La latenza è accettabile su un laptop moderno e la superficie PHI è solo il dispositivo.
La prior authorization beneficia del retrieval. Il modello assembla una bozza di lettera dalla cartella del paziente e dai documenti di medical-policy pubblicati dal payer, con citazioni. Se viene invocato un modello cloud più forte per la stesura, l'estratto della cartella viene de-identificato al confine del prompt e re-identificato sul dispositivo dopo che la risposta torna.
Il Q&A operativo su policy HR, codici di billing e SOP raramente ha bisogno di PHI e può girare interamente su modelli locali o cloud con DLP PHI-blocking attiva. Dividere i workload in questo modo mantiene il traffico a più alto rischio sul dispositivo e quello a più basso rischio sul cloud.
BAA e rischio vendor: cosa chiedere a qualsiasi vendor AI
Prima di firmare, lavora su una breve lista. Il vendor eseguirà un BAA che copre l'esatta superficie del prodotto che userai, non un prodotto fratello? Quali endpoint, modelli e console specifici sono in scope e quali sono esclusi per iscritto? Qual è la retention di default dei dati per prompt, completion, embedding e artefatti di fine-tuning, e può essere impostata a zero?
Chiedi la lista dei subprocessor e il meccanismo di notifica quando cambia. Conferma la cifratura in transit e at rest, la postura di key management e se sono disponibili chiavi customer-managed. Richiedi tempistiche di breach notification che ti permettano di rispettare il tuo obbligo di notifica al paziente di 60 giorni con margine.
Richiedi il più recente SOC 2 Type II e qualsiasi attestato HITRUST, la cadenza dei penetration test e il runbook di incident response. Infine, conferma per iscritto che il vendor non addestrerà modelli condivisi sui dati del tuo tenant.
Rollout pilot in 30 giorni
La prima settimana è scoping. Il privacy officer, uno sponsor clinico e l'IT scelgono due o tre workflow, scrivono il diagramma del data flow e aggiornano la risk analysis. Identifica quali passi possono essere solo-locali e quali richiedono il cloud, e conferma la copertura BAA per qualsiasi superficie cloud.
La seconda settimana è provisioning. Allestisci il Workspace con i ruoli RBAC mappati ai titoli di lavoro, abilita l'audit logging verso il tuo SIEM, configura le regole di redazione DLP al confine del prompt e carica il modello locale sui dispositivi pilot. Documenta il piano di rollback.
La terza settimana è un pilot supervisionato con cinque-dieci clinici. Traccia tempo risparmiato, tasso di errore contro un gold set human-reviewed e qualsiasi trigger DLP. Tieni una review a metà settimana con il privacy officer.
La quarta settimana è il go o no-go. Aggiorna policy e materiali di formazione, finalizza la disclosure di uso AI ai pazienti dove applicabile e decidi i criteri di espansione per la coorte successiva.
Frequently asked questions
- Far girare un modello on-device evita del tutto la necessità di un BAA?
- Per l'inferenza locale in sé, sì, perché nessuna PHI viene disclosa a una terza parte. Devi ancora tenere conto del ruolo del vendor del software. Se il runtime locale, la shell del Workspace o qualsiasi piano di management potesse ricevere PHI tramite telemetria, log o sessioni di supporto, il vendor agisce come business associate e un BAA è appropriato. Il pattern sicuro è confermare per iscritto che il vendor non riceve PHI dal dispositivo di default e disabilitare qualsiasi telemetria opzionale che possa portare contenuto. I fallback cloud richiedono sempre un BAA con il cloud model provider.
- Possiamo usare ChatGPT, Copilot o Gemini in un workflow HIPAA?
- Sì, ma solo sulle configurazioni enterprise specifiche che il vendor ha accettato di coprire sotto un BAA, e solo per le superfici esplicitamente nominate in quell'accordo. OpenAI copre le API e certi tenant ChatGPT Enterprise o Edu. Microsoft copre Azure OpenAI Service e tenant Copilot qualificanti. Google copre Gemini nei tier Workspace qualificanti escludendo NotebookLM e Gemini in Chrome. I tier consumer free e standard non sono coperti. Il problema più difficile è il comportamento del personale: bloccare le superfici consumer a livello di rete o browser conta tanto quanto il contratto.
- In che modo gli audit log differiscono per AI rispetto all'accesso EHR tradizionale?
- Gli audit log EHR tradizionali catturano l'accesso al record per utente, tempo e azione. Gli audit log AI devono catturare il prompt, il modello e la versione, il contesto recuperato, la risposta, l'utente, il Workspace e qualsiasi tool invocato dal modello. Devono anche catturare le decisioni di routing cloud quando viene usato un fallback BYOK. Mantienili accanto ai log EHR sotto la stessa policy di retention, conservali in uno store tamper-evident e alimentali nello stesso SIEM che il tuo team di sicurezza già monitora così l'attività AI è parte della normale risposta agli incidenti invece di un silo parallelo.
- E i nuovi cambiamenti alla Security Rule del 2026?
- La recente rulemaking di HHS sposta diverse salvaguardie precedentemente addressable nella categoria delle required, con maggiore enfasi su cifratura, multi-factor authentication, inventario degli asset che include sistemi AI che gestiscono ePHI e tempistiche di segnalazione degli incidenti più strette. Tratta qualsiasi assistente AI come asset in-scope per la risk analysis, documenta i data flow e conferma che il tuo runbook di incident response possa rispettare le finestre di notifica più brevi. Coordinati con il tuo privacy officer sulle date di efficacia esatte e sulle aspettative di transizione applicabili alla tua organizzazione, dato che la postura di enforcement ed eventuali estensioni possono cambiare dopo la pubblicazione.
Sources