Come si implementa un LLM on-premise in ospedale?

Il modo in cui falliscono i progetti di AI in ospedale non è tecnico. È partire dal caso che entusiasma la direzione sanitaria, scoprire che sotto ci sono diciotto mesi di lavoro di governance e perdere il budget prima che qualcosa arrivi in reparto.

La sequenza che funziona parte da dove i documenti sono densi, gli errori sono visibili e i dati non sono sanitari: protocolli e procedure interne, circolari regionali e nazionali, gare e regole di acquisto, documentazione per l’accreditamento, policy amministrative e del personale. Sono corpus grandi, difficili da consultare, superati di continuo, e costano ogni settimana tempo reale del personale. Un assistente di retrieval su questi documenti si ripaga e, soprattutto, costruisce la piattaforma — identità, ingestion, audit, conservazione, operatività — che un caso d’uso clinico dovrebbe altrimenti costruire da zero.

Per lo stesso motivo il deployment di riferimento su questo sito è un assistente normativo per le farmacie e non uno strumento clinico: l’attualità documentale è un problema reale e costoso, e si può risolvere senza toccare una cartella clinica.

I dati sanitari sono categorie particolari di dati ai sensi del GDPR, e il modo più economico di gestire questo obbligo è tenerli del tutto fuori dall’indice. L’esclusione in fase di ingestion è più forte della soppressione al momento della risposta sotto ogni aspetto che conta: è verificabile, resiste a una prompt injection, non lascia nulla da cancellare ed è molto più facile da spiegare a un DPO di un filtro che funziona quasi sempre.

Dove un caso d’uso richiede davvero dati dei pazienti, trattalo come un sistema diverso, con una base giuridica diversa, una policy di conservazione diversa e un percorso di approvazione diverso — non come un’estensione del perimetro di quello esistente. Il confine architetturale deve coincidere con quello giuridico, altrimenti il primo si eroderà fino a non sostenere più il secondo.

Due domande decidono il resto: i dati personali arrivano mai al passo di generazione, e escono mai dal perimetro? In un deployment ibrido sovrano la risposta onesta alla seconda è che il contesto recuperato esce, ed è esattamente per questo che la risposta alla prima deve essere no.

Un deployment ospedaliero non è un modello con davanti una pagina web. I componenti che decidono se sopravvive al primo audit sono quelli meno appariscenti:

• —Identità e accessi. Integrazione con la directory dell’ospedale, separazione dei ruoli che rispecchia quella tra ambito clinico e amministrativo, e privilegio minimo applicato al retrieval — non solo nell’interfaccia.
• —Ingestion curata. Una pipeline che conosce la linea di discendenza dei documenti, le versioni e gli intervalli di validità, così che le risposte possano dire cosa è in vigore. I corpus normativi vengono superati di continuo, e la ricerca per similarità non ha opinioni in merito.
• —Audit e ricostruibilità. Un registro a prova di manomissione di domanda, insieme recuperato, versioni, modello ed esito, con un periodo di conservazione di cui qualcuno è responsabile.
• —Supervisione umana. Approval gate espliciti ovunque un output abbia conseguenze, con l’approvatore registrato. È un requisito del workflow, non un disclaimer a piè di pagina.
• —Operatività. Backup, monitoraggio, pianificazione della capacità GPU e una reperibilità con un nome. Un sistema indisponibile in un ambiente che lavora 24 ore su 24 è un rischio clinico a sé.

Sull’hardware, la correzione utile è che un assistente documentale non ha bisogno di un cluster da laboratorio di ricerca. I deployment in produzione di questo tipo girano su una capacità GPU contenuta, perché la parte costosa è la qualità del retrieval, non il numero di parametri — il sistema Federfarma fa girare il modello locale, il filtro privacy e gli embedding su una singola GPU da 8 GB servendo oltre mille farmacie. Dimensiona l’hardware dopo il design del retrieval, non prima.

Due regimi decidono quanto diventa pesante il progetto. Un software destinato a diagnosi, prevenzione, monitoraggio, previsione o trattamento può qualificarsi come dispositivo medico ai sensi del Regolamento (UE) 2017/745, con il percorso di valutazione della conformità che ne consegue. Separatamente, l’AI Act collega gli obblighi alla finalità prevista e al ruolo, e un sistema che è componente di sicurezza di un prodotto regolamentato rientra nella sua classe più esigente.

Un assistente documentale usato dal personale per trovare e interpretare testi amministrativi e normativi è un oggetto diverso da uno strumento che propone una diagnosi, e la distinzione dipende dalla finalità prevista, sia dichiarata sia effettiva. Il che significa che l’allargamento del perimetro è un evento normativo: nel momento in cui un “assistente per le procedure” comincia a rispondere a domande cliniche, la discussione sulla classificazione va riaperta. Il confine va costruito nel sistema, non nel materiale di formazione.

Gli ospedali italiani hanno un livello in più — la normativa nazionale sull’AI e le regole di settore sull’uso secondario dei dati sanitari — di cui si parla nell’analisi della Legge 132/2025. E per le organizzazioni nell’ambito di NIS2, una piattaforma di AI fa parte della postura di sicurezza e degli obblighi di notifica degli incidenti dell’ente stesso, non è un progetto che corre in parallelo.