Governance AI in sanità: come Concurrence controlla l’AI clinica

100,8 miliardi di token in 30 giorni: è la scala della governance AI in sanità di Concurrence, un’azienda che fornisce agenti AI clinici e non è un ospedale. Su un anno fanno circa 1.200 miliardi di token (è il «trillion» dei titoli americani), governati su Databricks con regole di conformità, permessi e tracciabilità, e in parte già sotto un unico punto di controllo, Unity Gateway. A raccontare il caso sono tre persone di Concurrence e una di Databricks, sul blog di Databricks. È quindi un racconto pubblicato, e cofirmato, da chi vende la piattaforma. I problemi che affronta però sono gli stessi di chi in Italia porta l’AI in corsia tra GDPR e AI Act: chi usa quale modello, con quali dati e lasciando quale traccia.

In questo articolo scoprirai:

• quanto traffico AI gestisce Concurrence e quanto valgono davvero quei numeri;
• come l’azienda sceglie il modello guardando prima alla conformità e poi al costo;
• come si provano gli agenti clinici su pazienti simulati prima che su quelli veri;
• perché gli agenti che scrivono codice sono i primi a passare da Unity Gateway;
• cosa si può portare in Italia, e cosa no, tra GDPR e AI Act.

Governance AI in sanità: il caso Concurrence

Concurrence sviluppa agenti AI per l’assistenza ai pazienti e ne governa dati, modelli e permessi su Databricks. Secondo il case study di Concurrence, il catalogo comprende medici, infermieri e coordinatori dell’assistenza «virtuali». A questi si aggiungono la documentazione ambientale (l’AI ascolta la visita e la trasforma in una nota clinica), i riassunti dei piani di cura e la ricerca nella letteratura medica.

AI clinica su miliardi di token: i numeri di Concurrence

Questi sono i dati misurati sull’intero ambiente AI di produzione: 100,8 miliardi di token in input e 11,2 milioni di chiamate a modelli linguistici ogni 30 giorni. Un token è un pezzo di parola, l’unità con cui i modelli leggono e fatturano il testo. I 1.200 miliardi l’anno invece sono una proiezione di quel mese. Il volume mensile, scrive Concurrence, è cresciuto di circa 5 volte tra la fine del 2025 e luglio 2026. C’è poi il «world model», la rappresentazione dello stato dei pazienti su cui lavorano gli agenti: registra 2,7 milioni di eventi al mese, con picchi di 90.000 al giorno.

I limiti del case study sulla governance AI sanitaria

Prima di prenderlo come modello, un avvertimento. È un case study firmato da tre persone di Concurrence e una di Databricks, uscito il 23 settembre 2026 sul blog del fornitore. Non riporta risultati clinici né verifiche indipendenti: racconta come l’azienda controlla l’AI, non se i pazienti stanno meglio. Ed è proprio questo il suo interesse. Finora l’AI clinica ha fatto notizia per quello che i modelli sanno fare, come nel caso della superintelligenza medica di Microsoft. Questo caso invece parla di come si tengono sotto controllo quelle capacità quando lavorano sui dati di pazienti veri.

Routing dei modelli clinici e ruolo di Unity Gateway

Unity Gateway è lo strato di Databricks che si mette tra chi usa l’AI e i modelli. Decide chi può chiamare cosa, con quale budget e lasciando quale traccia. È disponibile per tutti dal 4 agosto 2026 e, secondo l’annuncio di Databricks, controlla agenti, fornitori di modelli (da Anthropic e OpenAI a Gemini), server MCP, skill, tool e assistenti per scrivere codice. È un’estensione di Unity Catalog, il sistema che su Databricks gestisce già permessi e tracciabilità dei dati. L’obiettivo dichiarato è governare dati e AI in un solo posto, con tetti di spesa, controlli in tempo reale, riconoscimento dei dati personali e audit trail, cioè il registro di chi ha fatto cosa e quando.

Il routing, cioè la scelta automatica del modello a cui mandare ogni richiesta, oggi lo decide un componente di Concurrence, l’endpoint resolver, sui carichi di lavoro che girano su Databricks. La regola, spiega il team di Concurrence, è precisa: «i modelli devono prima soddisfare i requisiti di conformità di un carico di lavoro, e solo dopo l’azienda ne considera qualità, prestazioni o costo». In pratica passano solo i modelli che rientrano in un perimetro coperto da BAA, il Business Associate Agreement. È il contratto che la legge sanitaria americana HIPAA richiede quando un fornitore tratta dati dei pazienti per conto di una struttura sanitaria, come spiega il Dipartimento della Salute americano (HHS). Nel caso descritto, in quel perimetro c’è Claude, il modello di Anthropic, servito su Databricks. Nessun dato sanitario protetto (PHI) arriva a un modello non coperto.

Il catalogo governato conta 46 modelli, ma solo 14 sono in produzione, riporta il case study. C’è però un punto che dal titolo del case study non si capisce: l’inferenza clinica in tempo reale, quella che dialoga con pazienti e medici, oggi gira ancora sull’infrastruttura del fornitore già in uso. L’integrazione con Unity Gateway è costruita e pronta, dietro un feature flag (un interruttore software che la accende quando si decide), e per ora dal gateway passano in produzione soprattutto gli agenti di coding.

Isolamento dei dati sanitari per ogni cliente

Ogni cliente di Concurrence ha il proprio schema in Unity Catalog e il proprio service principal, un’identità tecnica separata con cui le applicazioni si autenticano. Così i dati di un’organizzazione restano separati da quelli delle altre anche a livello di permessi. A questo si aggiungono eventi che non si possono modificare, il lineage (la tracciabilità dell’origine di ogni dato) e gli audit trail. Sul fronte delle certificazioni, Concurrence dichiara la conformità a HIPAA, GDPR e SOC 2. Sono invece ancora in corso HITRUST, ISO 27001 e ISO 42001, lo standard per i sistemi di gestione dell’AI.

Test e valutazioni degli agenti AI clinici

Concurrence mette alla prova i suoi agenti soprattutto in simulazione: il traffico simulato è circa 7 volte quello di produzione, secondo il case study. In altre parole, gli agenti lavorano molto di più per chi li collauda che per i pazienti. I controlli descritti sono quattro:

• synthetic canary: una richiesta finta attraversa di continuo l’integrazione con Unity Gateway già pronta per l’inferenza in tempo reale, così ci si accorge subito se qualcosa si rompe;
• replay dello stato del paziente: dagli eventi registrati si ricostruisce la situazione di un paziente e ci si fa lavorare sopra l’agente, senza toccare la cartella clinica reale;
• valutazione automatica: con ai_query, la funzione di Databricks che interroga un modello direttamente sui dati, Claude ospitato su Databricks dà un voto alla qualità e alla sicurezza delle interazioni;
• classificazione del rischio: le conversazioni vengono segnalate in caso di autolesionismo, pensieri suicidi ed emergenze mediche.

È il collaudo industriale applicato alla clinica: prima si prova tutto su pazienti finti, poi si va in reparto. In più, circolano meno dati reali. Il case study però non pubblica i numeri che servirebbero per giudicare questi controlli: quante emergenze vere il sistema riconosce, quante ne perde, quanti falsi allarmi produce. Senza tassi di errore dichiarati, la classificazione del rischio è un metodo, non ancora una prova che funzioni.

Coding agent e MCP sotto Unity Gateway

Il secondo fronte del caso sono gli agenti di coding, gli assistenti AI con cui gli ingegneri di Concurrence scrivono e modificano software. Sono loro, oggi, a passare in produzione da Unity Gateway, attraverso ug, lo strumento a riga di comando del gateway. I permessi sugli strumenti MCP vengono assegnati per gruppo di ingegneri. MCP, il Model Context Protocol, è lo standard aperto che collega un modello a strumenti esterni (qui trovi come funziona un server MCP). Per usare Databricks, Datadog o Linear ognuno accede con le proprie credenziali. Così ogni richiesta è attribuita a una persona precisa e registrata nella tabella system.ai_gateway.usage, racconta Concurrence.

I volumi non sono piccoli. A luglio 2026 14 utenti hanno generato 35,85 miliardi di token in input, più di 2,5 miliardi a testa. Il 95,37% arrivava dalla cache, cioè da parti di contesto già elaborate, che i fornitori fanno pagare meno. Dal lancio del 10 luglio le richieste sono circa 360.000, per un totale di 61 miliardi di token, secondo il case study. I modelli principali sono Claude Opus 4.8 e GPT-5.6 Sol, con Opus 5 in crescita.

Per una struttura sanitaria il motivo è semplice: un agente di coding può leggere log, database e ticket. Metterlo sotto un gateway con credenziali nominative chiude la porta alla shadow AI, l’uso di strumenti non autorizzati con account personali. È un tema che riguarda ogni azienda, e che abbiamo affrontato parlando di policy e ruoli per gli agenti AI.

Governance AI sanitaria: GDPR e AI Act

Dal caso Concurrence si possono portare in Italia i principi, non gli strumenti contrattuali americani. Quattro valgono ovunque: la conformità si verifica prima del costo, ogni richiesta ha un responsabile con nome e cognome, ogni passaggio lascia una traccia, gli agenti si provano su dati simulati. Cambia però il quadro giuridico. In Europa i dati sanitari rientrano nelle «categorie particolari di dati personali», come ricorda la Commissione europea. L’articolo 9 del GDPR ne vieta il trattamento salvo eccezioni precise, come la diagnosi e la cura. Il quadro completo è nella nostra guida su sicurezza, GDPR e AI.

AI Act in sanità: le scadenze dal 2026 al 2028

Dal 2 agosto 2026 si applica l’articolo 50 dell’AI Act sulla trasparenza. Come riassume Metacommunications, «chi mette a disposizione un sistema che dialoga con le persone, come un chatbot, deve fare in modo che l’utente sappia di parlare con una macchina». Un agente «infermiere» usato in Europa ricadrebbe già in questo obbligo. Gli obblighi per i sistemi ad alto rischio, invece, sono stati rinviati con l’accordo sul Digital Omnibus del maggio 2026. Secondo lo studio legale Gibson Dunn, i sistemi dell’Allegato III partono dal 2 dicembre 2027, quelli integrati in dispositivi medici dal 2 agosto 2028. La trasparenza non slitta. C’è solo un margine fino al 2 dicembre 2026 per la marcatura dei contenuti prodotti da sistemi già in commercio. Tutte le date sono nella nostra guida all’AI Act e alle sue scadenze.

BAA HIPAA e GDPR: perché non sono equivalenti

Il BAA è uno strumento della legge americana HIPAA: lo disciplina la sezione 164.504 del codice federale USA, e l’HHS ne pubblica un modello di clausole. Nel GDPR non ha un equivalente automatico. Il riferimento più vicino è l’articolo 28, il contratto con cui il titolare dei dati affida il trattamento a un responsabile esterno. Ma è solo un’analogia: il GDPR chiede anche una base giuridica, un’eccezione prevista dall’articolo 9 e, per i dati sanitari trattati su larga scala, una valutazione d’impatto. C’è poi un secondo limite: il caso non dimostra che questo modello funzioni fuori da Databricks. È costruito sui suoi strumenti ed è pubblicato sul suo blog, e sulla parte clinica in tempo reale descrive un’integrazione pronta, non ancora in produzione.

Resta un metodo che vale ovunque: scegliere il modello guardando prima alla conformità e poi al prezzo, attribuire ogni richiesta a una persona, provare gli agenti su pazienti simulati prima che su quelli veri. Nessuna di queste regole richiede una piattaforma specifica. Serve un’organizzazione che le pretenda, e il problema, come per il ROI dell’AI generativa, è organizzativo prima che tecnico. Chi vuole costruire i propri agenti può partire da come si progettano agenti AI su misura.

Se vuoi seguire ogni giorno come l’AI entra nei settori più regolati, ne parliamo anche su MimírCast, il nostro podcast quotidiano sull’AI.

Fonti:

• Databricks: come Concurrence governa l’AI clinica con Unity Gateway (case study, 23 settembre 2026)
• Databricks: Unity Gateway disponibile per tutti (annuncio, 4 agosto 2026)
• Gibson Dunn: accordo sull’Omnibus dell’AI Act e rinvio delle scadenze per l’alto rischio
• EUR-Lex: Regolamento (UE) 2016/679 (GDPR), testo ufficiale
• EUR-Lex: GDPR, versione HTML (CELEX 32016R0679)
• Commissione europea: quali dati personali sono considerati sensibili
• HHS: i business associate nella normativa HIPAA
• HHS: modello di clausole per il Business Associate Agreement
• eCFR: 45 CFR 164.504, requisiti dei contratti con i business associate