Liste d’attesa: il problema non è la capacità, è la pipeline

Il 21 luglio 2026 il primo Bollettino Agenas sul monitoraggio delle liste d’attesa ha confrontato il primo semestre 2026 con lo stesso periodo del 2025, provincia per provincia. Il quadro del Trentino-Alto Adige resta nel complesso positivo, ma si sdoppia: sulle prime visite specialistiche la Provincia autonoma di Trento peggiora, dal 63,1% al 54,7% di prestazioni erogate entro i tempi massimi — insieme ad Abruzzo, Sicilia e Sardegna — mentre Bolzano sale dal 72,7% al 78,5%, restando comunque sotto la soglia dell’80% che il monitoraggio nazionale usa come riferimento. Sugli esami diagnostici Trento migliora, dal 76,7% al 77,0%, ma resta anch’essa sotto quella soglia (l’Adige, 21 luglio 2026). Il dato misura un esito, non ne spiega le cause: non dice nulla su come lavorano le strutture coinvolte, né su quali fattori pesino in ciascun territorio. Ma pone la domanda generale che tiene insieme questo articolo — valida per qualunque sistema di prenotazione, non per una struttura in particolare: e se una parte del problema non fosse quanta capacità c’è, ma quanta se ne perde per strada?

La pipeline tipica: quattro anelli, tre perdite

Una premessa dovuta: non conosciamo dall’interno la pipeline di nessuna delle aziende citate dal monitoraggio — ogni struttura ha le sue integrazioni, i suoi correttivi e le sue eccellenze. Lo schema che segue è il modello ricorrente di un percorso di prenotazione organizzato per sistemi separati, ed è su questo modello generale — non su una struttura reale — che ragiona il resto dell’articolo. In questo schema la catena che assegna un appuntamento ha quattro anelli.

Il medico assegna la classe di priorità sulla ricetta: U (urgente, entro 72 ore), B (breve, entro 10 giorni), D (differita, entro 30 giorni per le visite e 60 per gli esami) o P (programmata, entro 120 giorni) — le classi con cui il Piano nazionale di governo delle liste di attesa (PNGLA) 2019-2021 misura il paniere monitorato di 14 prime visite specialistiche e 22 esami diagnostici. Il CUP, o il call center che ne fa le veci, assegna il primo slot libero su agende compilate settimane o mesi prima. Dove i sistemi restano separati, ogni reparto e ogni sede vede solo la propria agenda: CUP, cartella clinica e turnistica non si parlano tra loro. Il paziente, se si presenta, viene erogato.

In una catena così fatta si perde capacità in tre punti — ed è capacità già pagata: la stanza è aperta, il medico è in turno.

• Domanda non prevista. I picchi — stagionali, epidemici, indotti da un evento — si scoprono quando sono già in corridoio: le agende si aprono in emergenza, non prima che il picco arrivi.
• Slot non riassegnati. Una disdetta a 48 ore dalla visita raramente viene ricollocata: nella maggior parte delle strutture non esiste una lista di riserva attiva, consultabile in tempo reale.
• No-show ricorrenti. La letteratura mostra tassi molto variabili, da pochi punti percentuali a oltre il 20-30% secondo specialità e territorio. Per la simulazione di questo articolo assumiamo, dichiarandolo, un 10% di slot persi tra mancate presentazioni e disdette non ricollocate.

Nessuno di questi tre punti è un problema di volontà. CUP e operatori lavorano bene sulle informazioni che hanno: il limite è che quelle informazioni fotografano solo il proprio pezzo di processo, mai l’insieme. Il costo di questa separazione non si vede in un solo indicatore locale: si vede a valle, nell’aggregato mensile che finisce in bollettini come quello Agenas — la stessa metrica con cui la sanità pubblica viene misurata dall’esterno, mese dopo mese.

Perché «più software» non ha risolto

Le aziende sanitarie non sono a corto di strumenti. Hanno gestionali, CUP evoluti, cruscotti di reportistica — e spesso funzionano bene, ciascuno nel proprio perimetro. Il problema non è mai stato lo strumento preso singolarmente: è l’architettura. Ogni sistema verticale fotografa il proprio pezzo — le prenotazioni, la turnistica, lo storico erogato — e lo fa anche meglio di ieri. Ma resta un pezzo.

Aggiungere l’ennesimo applicativo, per quanto sofisticato, aggiunge un nuovo silos: un’altra fotografia, non la visione d’insieme che permetterebbe di prevedere un picco prima che diventi un corridoio pieno. Un cruscotto in più mostra il problema meglio; non lo risolve, perché il problema vive tra i sistemi, non dentro nessuno di essi. Il problema non si risolve con più dati o più cruscotti. Serve un livello che stia sopra i sistemi esistenti — che li legga tutti insieme — non un applicativo in più che si aggiunge accanto a loro, competendo per la stessa attenzione degli operatori.

Cinque livelli, non un applicativo in più

CSIDIA affronta la stessa catena — prescrizione, prenotazione, agenda, erogazione — con un’architettura diversa, non con un applicativo in più: la stessa pipeline dati → ontologia → agenti AI → operatore umano → azione descritta in generale su AI operativa, qui applicata alle liste d’attesa.

Dati. Le sorgenti esistenti si connettono in sola lettura, dal primo giorno: prenotazioni CUP, anagrafica delle agende, turnistica, storico erogato, disdette e no-show, accessi di pronto soccorso — utili per leggere la domanda indotta. Nessun big bang, nessuna sostituzione dei sistemi che la struttura già usa: i gestionali restano al loro posto, CUP compreso — sopra vi si aggiunge il livello che li vede tutti insieme.

Ontologia. È il livello che fa la differenza, e vale la pena spiegarlo bene. Un database descrive un evento come righe scollegate in tabelle diverse: una disdetta è una riga che cambia stato in una tabella di prenotazioni. L’ontologia lo descrive come un oggetto operativo: uno slot di cardiologia domani alle 15 a Rovereto, compatibile con la classe B, con 41 pazienti in lista che potrebbero occuparlo. Prestazione, Slot, Agenda, Sede, Medico, Classe di priorità, Prenotazione diventano oggetti in relazione tra loro, non tabelle scollegate — ed è questa rappresentazione che rende i dati azionabili da un agente, invece che semplicemente consultabili da una persona. I dati personali entrano minimizzati e pseudonimizzati: l’ontologia ragiona su slot e code, non su cartelle cliniche.

Agenti AI. Non sono chatbot. Sono processi che osservano l’ontologia, calcolano e propongono azioni. Sulle liste d’attesa sono quattro: recall dei no-show (chi rischia di non presentarsi, contattato prima), riempimento delle disdette (chi in lista può occupare subito lo slot appena liberato), previsione della domanda (quali agende rischiano di saturarsi tra tre settimane) e ribilanciamento tra sedi (dove spostare una seduta per assorbire un picco già previsto) — il dettaglio, con i numeri, nella prossima sezione.

Operatore umano. Le soglie di autonomia sono esplicite, non implicite. Un’azione a basso impatto — un promemoria, una ricollocazione già accettata dal paziente — corre da sola. Un’azione critica — aprire un’agenda straordinaria, spostare una seduta tra sedi — arriva come proposta e viene approvata da chi ha la responsabilità organizzativa. Le scelte cliniche non vengono mai delegate all’AI: gli agenti propongono, i clinici decidono, e ogni azione critica passa da un operatore.

Azione. La decisione approvata torna sull’agenda reale — write-back — e l’esito alimenta di nuovo il modello: il sistema impara dalla propria operatività, non da un archivio statico aggiornato una volta l’anno.

È, a grandi linee, il paradigma ontologia-più-agenti reso celebre a livello enterprise da piattaforme come Palantir Foundry — un’analogia di paradigma, non un confronto di prodotto né un’affiliazione, portata a misura di azienda sanitaria italiana, con i dati che restano in Europa e la stessa cautela, descritta sopra, su cosa un agente può fare da solo e cosa no.

Le quattro leve, in ordine di accensione

Le quattro leve non si attivano tutte insieme: seguono la timeline dell’innesco, non quella di un progetto IT tradizionale — dove i primi risultati arrivano di solito dopo mesi di analisi preliminare, non nelle prime settimane. È lo stesso schema che raccontiamo, con altri casi d’uso, nella pagina dedicata alla sanità.

Settimana 1 — innesco. Si collegano i connettori sulle sorgenti, si costruisce l’ontologia di base sulle agende già in uso — non un ambiente di test separato — e il primo caso d’uso entra in produzione. Non è un claim vago: operativi sui vostri dati in 7 giorni, primo caso d’uso in produzione dalla prima settimana.

Mesi 1-2 — quick win. Si accendono le prime due leve. Il recall dei no-show invia promemoria e richiede conferma su più canali; se il paziente non conferma o disdice, l’agente libera lo slot in anticipo invece di scoprirlo vuoto in sala d’attesa — canali, toni e regole di contatto restano una scelta degli operatori. Il riempimento delle disdette confronta, nei secondi in cui uno slot si libera, la lista di riserva compatibile per priorità, sede e disponibilità dichiarata; i casi ambigui restano agli operatori. Il punto da tenere a mente: questi primi punti percentuali non richiedono nuovo personale né nuovo budget. Sono slot già pagati che smettono di andare persi.

Mesi 3-6 — previsione. Con lo storico consolidato, un terzo agente stima accessi e richieste con giorni o settimane di anticipo, su stagionalità ed eventi, e propone ribilanciamenti di sedute tra sedi e ambulatori — sempre come proposta che un responsabile approva, mai come spostamento automatico. È la leva che richiede più tempo perché richiede più storico: prima di tre mesi non c’è abbastanza dato per distinguere un picco reale da un rumore statistico. Le agende si aprono prima del picco, non durante.

Mesi 7-12 — regime. Ottimizzazione continua di percorsi e priorità, sempre con validazione umana. Le quattro leve restano attive insieme da questo punto in poi: non si spengono a vicenda, si sommano. Nello scenario simulato — la parola conta, è una simulazione — la soglia Agenas dell’80% viene superata intorno all’ottavo mese.

I numeri di una simulazione dichiarata

Lo scenario che segue è una simulazione illustrativa, non un dato misurato: le assunzioni sono dichiarate, il modello è disponibile su richiesta, e l’etichetta resta visibile su ogni grafico e tabella. Il punto di partenza è una struttura-tipo con 100 slot prenotabili a settimana sul paniere monitorato, il 10% persi tra no-show e disdette non ricollocate — quindi 90 visite erogate a settimana — un’attesa media di 60 giorni e il 68% di prenotazioni entro i tempi massimi. Sono numeri ipotetici ma realistici: si ricalibrano sui dati reali della struttura, quando disponibili.

Nello scenario a 12 mesi le visite erogate salgono da 90 a 108 a settimana per 100 slot (+20%), l’attesa media scende da 60 a 47 giorni, e il rispetto dei tempi massimi passa dal 68% all’81% — sopra la soglia Agenas dell’80%. Il numero più concreto per chi legge: circa 630 visite in più erogate nel primo anno, per ogni 100 slot settimanali di partenza.

Il +20% è lo scenario a regime, non una promessa: il risultato reale dipende dalla baseline di no-show della struttura, dalla quota di disdette ricollocabili, dalla capacità di attivare sedute aggiuntive nei picchi. Il claim corretto resta questo: primi risultati in poche settimane, scenario fino al +20% dopo 12 mesi.

Governance: tracciabilità, non promesse

Ogni proposta di un agente è spiegabile e tracciata: chi ha approvato cosa, quando, su quali dati. Non è un dettaglio tecnico: è la condizione per cui un direttore sanitario può firmare una decisione senza doversi fidare di una scatola nera.

I dati sono trattati in Europa e restano di proprietà della struttura, non del fornitore della piattaforma — i dati restano vostri, sempre. Il trattamento è GDPR by design, la piattaforma risponde ai requisiti di cybersecurity della NIS2, e — punto che vale la pena ripetere perché è il più delicato — ogni decisione clinica resta a chi ne ha la responsabilità: l’AI ottimizza la logistica e la capacità, non stabilisce chi ha diritto a passare avanti. I sistemi che toccano l’accesso a servizi essenziali possono rientrare tra le categorie disciplinate dall’AI Act: una ragione in più per costruire la tracciabilità fin dal primo giorno, non per rincorrerla dopo — la stessa logica con cui consideriamo la policy interna sull’AI un obbligo di legge, non una scelta facoltativa.

Architetturalmente la piattaforma vive in due modalità, mai in un cloud pubblico generico: on-premise, installata nell’ambiente del cliente, oppure in un cloud dedicato CSIDIA — ambiente riservato al singolo cliente, accesso tramite VPN dedicata, data center in Italia, in locali presidiati.

Il primo passo

Il primo passo non è un progetto pluriennale: è un caso d’uso reale, sui dati che la struttura già possiede, in produzione dalla prima settimana — di solito il recall dei no-show o il riempimento delle disdette, dove il guadagno si vede prima. Da lì si decide se e come estendere la previsione della domanda e il ribilanciamento tra sedi, con la stessa cautela con cui si è partiti.

Volete vedere cosa direbbero questi numeri sui dati della vostra struttura? A luglio la prima sessione di 30 minuti con un nostro esperto è gratuita in promozione: prenotatela qui.

Le domande che ci fanno sempre

• Sostituite il CUP? No: ci appoggiamo sopra, il CUP resta il sistema con cui l’operatore lavora ogni giorno.
• Serve un progetto pluriennale? No: 7 giorni per il primo caso d’uso in produzione.
• E la privacy? Dati minimizzati, pseudonimizzati, trattati in Europa.
• L’AI decide chi passa avanti? No: ottimizza la logistica, la priorità clinica resta al medico.
• E se i dati storici sono sporchi? Il primo caso d’uso serve anche a farli emergere e a correggerli.

Glossario minimo

• CUP — Centro unico di prenotazione: il sistema (e il call center) che assegna gli appuntamenti.
• Classi di priorità U/B/D/P — tempi massimi del PNGLA: urgente 72 ore, breve 10 giorni, differita 30 giorni per le visite/60 per gli esami, programmata 120 giorni.
• No-show — paziente che non si presenta senza disdire: lo slot va perso.
• Data fabric — livello di integrazione che collega le sorgenti dati esistenti senza sostituirle.
• Ontologia — modello semantico che rappresenta la struttura come oggetti e relazioni operative (slot, agende, sedi, priorità), rendendo i dati azionabili.
• Agente AI — processo che osserva i dati attraverso l’ontologia, calcola e propone (o esegue, entro soglie approvate) azioni operative.
• Decision intelligence — predizione e simulazione a supporto di decisioni ad alto impatto.
• Human-in-the-loop — ogni azione critica richiede l’approvazione di un operatore; le scelte cliniche restano ai clinici.
• Soglia Agenas 80% — quota minima di prenotazioni erogate entro i tempi massimi usata nel monitoraggio nazionale.

Fonti

• “Sanità, il Trentino perde colpi: peggiorano le liste d’attesa”, l’Adige, 21 luglio 2026
• Bollettino Agenas Liste di Attesa — Numero 0 (dati al 30 giugno 2026), con il relativo comunicato Agenas del 21 luglio 2026
• Piano Nazionale di Governo delle Liste di Attesa (PNGLA) 2019-2021 — paniere di 14 prime visite e 22 esami diagnostici, classi di priorità U/B/D/P, richiamato nel Bollettino Agenas citato sopra