Nei progetti digitali della PA, quando il risultato non è quello atteso, il primo imputato è quasi sempre la tecnologia: piattaforme troppo complesse, competenze insufficienti, dati disordinati. È una spiegazione solo in parte vera. Sempre più spesso, infatti, il problema non è ciò che la tecnologia promette, ma il modo in cui la PA la acquista, la governa e la mantiene nel tempo.
Indice degli argomenti
Il capitolato come illusione di controllo
Nella PA il capitolato è spesso percepito come lo strumento principale di controllo del progetto: più è dettagliato, più si ritiene che la soluzione sarà solida. Nel procurement dell’innovazione, però, questa convinzione può trasformarsi in un limite: irrigidisce il progetto, congela soluzioni ancora immature e impedisce di adattare la fornitura al contesto amministrativo. Questo è ancor più vero quando entra in gioco l’Intelligenza Artificiale, dove cioè non si compra un software deterministico ma un sistema probabilistico, dinamico e soggetto a deterioramento nel tempo; ciò cambia radicalmente la natura del capitolato, del collaudo e della gestione contrattuale, perché se la PA scrive la gara come se stesse acquistando un applicativo tradizionale finisce per imporre vincoli che non proteggono il progetto, ma lo rendono fragile.
Un punto cruciale risiede nell’attenzione ancora eccessiva al prezzo; spesso nella scelta delle variabili della procedura di acquisto di soluzioni ad alto valore tecnologico, anche quando la normativa consente e impone l’offerta economicamente più vantaggiosa, nella pratica molte procedure continuano a premiare chi riesce a comprimere il costo iniziale, a scapito della qualità progettuale, dell’accompagnamento al cambiamento e della sostenibilità nel tempo.
Nel caso dei sistemi digitali avanzati, e in particolare dell’IA, questa impostazione è miope: il prezzo iniziale è solo una parte, spesso minoritaria, del costo reale che l’amministrazione sosterrà nel tempo.
Il LCOAI e il costo reale dell’Intelligenza Artificiale
Per valutare in modo più consapevole le offerte, può essere utile introdurre il concetto di LCOAI (Levelized Cost of Artificial Intelligence), mutuato dal settore energetico e dal più noto LCOE. Il LCOAI rappresenta il costo totale livellato dell’IA lungo l’intero ciclo di vita, rapportato al valore o all’output generato.
Questa metrica consente di superare la sola lettura dei costi iniziali. Non considera soltanto il CAPEX, cioè hardware, licenze e sviluppo, né il solo OPEX, legato a cloud, API, inferenza e manutenzione. Include anche costi spesso trascurati: formazione, change management, governance, compliance, monitoraggio, riaddestramento ed exit costs.
Il vero valore strategico della metrica risiede infatti nell’inclusione di due variabili spesso sottostimate: i costi organizzativi, indispensabili per il reskilling del personale, il change management e l’adeguamento degli assetti di governance e compliance, e i costi di uscita (exit costs). Questi ultimi fotografano gli oneri finanziari e operativi necessari per la migrazione dei dati, la dismissione dei modelli obsoleti o il vendor lock-in. Solo attraverso una visione come quella offerta dal LCOAI è possibile calcolare il reale ROI dell’innovazione, trasformando l’adozione dell’IA da una scommessa tecnologica a un investimento strutturale e sostenibile nel tempo.
Figura 1 – LCOAI: il costo livellato dell’IA nella PA
È un cambio di prospettiva importante, perché rende visibili quelle voci che normalmente restano fuori gara: inferenza, manutenzione evolutiva, riaddestramento, monitoraggio, transizione, portabilità; molte offerte apparentemente convenienti sono tali solo perché spostano i costi nel tempo, con la PA che risparmia in gara, ma paga dopo, con interessi amministrativi, tecnici e organizzativi.
Un modello a 7 fasi per il ciclo di vita dell’IA nella PA
Sulla base della letteratura scientifica e manageriale in materia di AI Procurement, AI Governance e ingegneria dei sistemi informativi (tra cui spiccano i framework ISO/IEC 42001 sul sistema di gestione dell’IA e i requisiti operativi dell’AI Act), un modello solido e strutturato per l’adozione dell’Intelligenza Artificiale nella Pubblica Amministrazione e nelle grandi organizzazioni deve superare la logica puramente tecnologica per abbracciare una visione olistica ed evolutiva.
Una proposta per un Modello a 7 Fasi per l’Adozione e il Ciclo di Vita dell’IA (Framework LCOAI-Driven), ridisegnato per riflettere lo stato dell’arte della letteratura settoriale, è rappresentato nella figura seguente:
Figura 2 – Framework olistico a 7 fasi per il governo e l’ingegnerizzazione dell’IA nella PA conforme agli standard ISO/IEC 42001 e ai requisiti dell’EU AI Act
Questo modello organizza le attività lungo un ciclo di vita continuo, in cui ogni fase rilascia output fondamentali per alimentare la successiva, mettendo al centro la sostenibilità economica e il controllo algoritmico.
Fase 1: Strategia e governance dell’IA
• Definizione: Definizione del perimetro etico, legale e strategico dell’organizzazione.
• Implicazioni operative: Sulla scorta dello standard ISO/IEC 42001, in questa fase si istituisce l’AIMS (AI Management System). Per la PA, questo significa mappare i requisiti dell’AI Act, eseguire le valutazioni di impatto sui diritti fondamentali (FRIA) e stabilire compliance e responsabilità distribuita prima di scrivere una sola riga di codice.
Fase 2: Dati e infrastrutture
• Definizione: Valutazione e ingegnerizzazione del patrimonio informativo e delle tecnologie abilitanti.
• Implicazioni operative: L’IA è un’entità data-driven. Questa fase assicura la coerenza anagrafica, la pulizia dei dati e la compliance con il GDPR. Sotto il profilo infrastrutturale, si pianifica l’architettura, ad esempio cloud o ambienti hybrid/multi-tenant, garantendo l’interoperabilità nativa tramite API documentate e formati aperti per scongiurare il vendor lock-in.
Fase 3: Procurement e costo livellato
• Definizione: Gestione della contrattualizzazione basata sul reale costo livellato dell’investimento.
• Implicazioni operative: Sganciandosi dal procurement IT tradizionale, qui si applica il modello LCOAI (Levelized Cost of AI), calcolando come detto non solo CAPEX e OPEX, ma anche i costi organizzativi, come la formazione, e i costi di uscita (exit strategy). I bandi e i contratti devono prevedere clausole di portabilità dei modelli, proprietà pubblica dei dati di sintesi e SLA probabilistici, come soglie massime di errore o allucinazione.
Fase 4: Deployment & MLOps
• Definizione: Sviluppo, integrazione e messa in produzione dei modelli algoritmici.
• Implicazioni operative: Sfruttando le pratiche di MLOps (Machine Learning Operations), il sistema viene integrato nei gestionali d’ente, ad esempio flussi delle risorse umane o videosorveglianza. Questa fase garantisce il provisioning programmatico, il logging continuo di sistema (audit trail) per la tracciabilità a ritroso delle decisioni e i meccanismi di Disaster Recovery.
Fase 5: Supervisione umana e cambiamento
• Definizione: Reskilling del personale e definizione dei livelli di supervisione umana.
• Implicazioni operative: Il successo dell’IA risiede nella fiducia del capitale umano. Si progettano i modelli di interazione uomo-macchina, stabilendo i protocolli in cui il funzionario può sovrascrivere o disattivare l’output algoritmico, e si avviano piani strutturati di reskilling e change management per ridurre le resistenze interne e contrastare il divario digitale.
Fase 6: Reingegnerizzazione dei processi
• Definizione: Riprogettazione dei processi operativi focalizzata sulla generazione di valore concreto.
• Implicazioni operative: Si sposta la valutazione dalla semplice conformità contrattuale alla performance reale sul campo. I flussi di lavoro storici vengono modificati, ad esempio tramite automazione di compiti ripetitivi o moduli Speech-to-Text, misurando l’efficacia dell’inferenza statistica rispetto alle metriche di efficienza, riduzione dei tempi ed equità del servizio erogato al cittadino.
Fase 7: Rischio e assurance continua
• Definizione: Monitoraggio proattivo, mitigazione dei rischi e contrasto al degrado del modello.
• Implicazioni operative: Un sistema IA non è statico e tende a degradare nel tempo. Questa fase attiva presidi di monitoraggio continuo contro il model drift, cioè la deriva delle prestazioni dovuta al mutamento dei dati del mondo reale, e le allucinazioni. Al superamento delle soglie critiche tollerabili, la fase attiva automaticamente i trigger contrattuali di riaddestramento (retraining) a carico del fornitore, chiudendo il ciclo e riportando i dati alla Fase 1 per l’aggiornamento della governance.
Dal go-live alla capacità di aggiornamento permanente
In questa maniera si supera tra l’altro uno dei difetti più strutturali dei progetti pubblici, il considerare il go-live come un punto di arrivo. In realtà, per le tecnologie digitali il rilascio è solo l’inizio della fase più delicata: adozione, monitoraggio, correzione, adattamento.
Questo principio vale per qualunque progetto di innovazione tecnologica, ma diventa ancora più rilevante quando entra in gioco l’IA. In questi casi emergono fenomeni come il data drift e il concept drift, cioè il degrado fisiologico dei sistemi quando cambiano il contesto, le norme, i linguaggi e i comportamenti degli utenti. In altre parole, un modello può funzionare bene al momento del collaudo ma peggiorare progressivamente nei mesi successivi. Proprio per questo il contratto deve prevedere continuous training, logging, audit e monitoraggio delle performance, per evitare che la soluzione diventi rapidamente obsoleta pur restando formalmente attiva.
Da questo aspetto emerge un dato essenziale: la PA non deve comprare solo una piattaforma, ma una capacità di aggiornamento permanente. Senza questa dimensione, il digitale si trasforma in una semplice trasposizione elettronica dell’inefficienza analogica.
La dipendenza dal fornitore
Quando la governance interna è debole, il fornitore tende a diventare il vero proprietario operativo del progetto; non solo della tecnologia, ma anche della conoscenza necessaria a farla funzionare. È il classico effetto lock-in, che nel caso dell’IA assume forme ancora più insidiose: dipendenza dai modelli, dai dati, dai connettori, dalle logiche di integrazione e perfino dai meccanismi di interpretazione dei risultati.
È un rischio rilevante non solo per le finanze pubbliche, ma soprattutto per l’autonomia della PA, in cui l’amministrazione si ritrova legata a doppio filo a un singolo fornitore tecnologico, rendendo una futura migrazione a un altro partner o il ritorno a sistemi interni economicamente insostenibili o tecnicamente impossibili. Per la PA, dove la continuità operativa e la sovranità tecnologica sono requisiti democratici prima ancora che gestionali, prevenire questa dipendenza è un dovere strategico.
La vera sfida non si gioca nella fase di implementazione, bensì nei dettagli dei capitolati d’appalto e nell’architettura contrattuale iniziale. Proteggere l’interesse pubblico significa governare quattro pilastri fondamentali: la proprietà dei dati (garantendo che le informazioni dei cittadini e la conoscenza generata rimangano asset pubblici), la clausola di portabilità del software e dei modelli addestrati, l’effettiva esportabilità delle basi dati in formati aperti e interoperabili e, infine, una solida exit strategy. Solo pianificando il giorno in cui il contratto terminerà, e definendo fin da subito i costi e le modalità di uscita, la PA può declinare l’innovazione dell’IA nel segno della sostenibilità economica a lungo termine, altrimenti si rischia di perdere il controllo del sistema già dal primo ciclo contrattuale, generando un problema che non è solo di carattere economico, ma istituzionale, in cui un’amministrazione che non sa cambiare fornitore non controlla davvero il proprio patrimonio digitale.
Per questo l’innovazione non si misura soltanto sulla qualità della soluzione acquistata, ma sulla capacità dell’ente di non diventare dipendente da essa.
Portabilità, esportabilità e sovranità digitale
Per disinnescare il rischio di lock-in, la Pubblica Amministrazione deve smettere di contrattualizzare l’Intelligenza Artificiale come una “scatola nera” chiusa, concentrandosi invece sull’architettura dei flussi e sui diritti di trasferimento. In questo contesto, le clausole di portabilità e l’esportabilità dei dati non sono meri tecnicismi legali, ma garanzie di sovranità digitale. La portabilità non deve limitarsi ai dati grezzi in ingresso (input data), ma deve estendersi ai dati di sintesi, ai metadati di addestramento e, ove tecnicamente possibile, ai pesi e alle configurazioni dei modelli personalizzati (fine-tuning). Se un’amministrazione non può trasferire la conoscenza accumulata dal sistema a un nuovo fornitore, l’algoritmo diventa un ostaggio economico.
Parallelamente, l’esportabilità deve essere garantita “by design” attraverso l’adozione rigorosa di formati aperti, standardizzati e indipendenti dalla piattaforma del fornitore, evitando formati proprietari che richiederebbero costose conversioni. I capitolati d’appalto della PA devono quindi imporre al fornitore il rilascio di API (Application Programming Interface) documentate e standardizzate per l’estrazione massiva e sicura delle informazioni in tempo reale, consentendo l’esportabilità e assicurando che l’amministrazione mantenga il controllo totale del proprio patrimonio informativo.
Trasparenza e responsabilità algoritmica
Il tema della dipendenza tecnologica conduce direttamente a un secondo nodo: la trasparenza. Senza trasparenza sui dati, sui modelli e sui meccanismi decisionali, infatti, non esiste vera autonomia amministrativa.
Nel procurement dell’innovazione, la trasparenza viene spesso evocata come principio generale o nobile dichiarazione d’intenti. Con l’adozione dell’Intelligenza Artificiale nella Pubblica Amministrazione, tuttavia, questo concetto deve essere portato a una dimensione più concreta, in cui da formula etica passa a requisito tecnico e contrattuale vincolante. Per l’attore pubblico, infatti, non è più sufficiente certificare che un sistema funzioni o che rispetti determinati livelli di accuratezza statistica: è importante capire come giunga a determinate conclusioni, con quali dati sia stato alimentato, quali siano i suoi limiti intrinseci e quali livelli di supervisione umana siano previsti. L’IA, infatti, non è un oggetto chiuso o un software statico, ma un ecosistema dinamico e interconnesso in continua evoluzione, con aggiornamenti continui e responsabilità distribuite.
Questa complessità sistemica si traduce direttamente in obblighi operativi nuovi e stringenti, che i responsabili della transizione digitale devono saper tradurre in clausole contrattuali puntuali.
• Tracciabilità e Audit Trail: Diventa fondamentale pretendere clausole di logging dettagliate, capaci di registrare ogni singola decisione del sistema per consentire una ricostruzione a ritroso del processo decisionale (fondamentale in caso di ricorsi amministrativi).
• Gestione del Rischio e FRIA: La documentazione tecnica non è più un manuale d’istruzioni, ma un presidio di legalità che deve includere una rigorosa valutazione dell’impatto sui diritti fondamentali (FRIA, Fundamental Rights Impact Assessment), ove richiesta dalle normative europee come l’AI Act.
• Supervisione Umana (Human-in-the-loop): I meccanismi di governance devono esplicitare come e quando il funzionario pubblico possa intervenire per correggere, validare o disattivare l’output algoritmico.
• Ciclo di Vita e Uscita: La trasparenza deve infine coprire la manutenzione evolutiva e i meccanismi di uscita dal contratto, svelando fin dal principio i costi nascosti e le dipendenze tecnologiche.
In definitiva, la trasparenza non è un costo accessorio né una concessione del fornitore, ma è la precondizione stessa del governo del territorio e dei servizi. Senza una trasparenza così contrattualizzata non c’è controllo algoritmico, fondamentale per una legittima e sicura innovazione pubblica.
Metriche di impatto e performance reale dell’IA
Un altro dei limiti più gravi dei progetti digitali nella PA è la debolezza delle metriche. Molto spesso si controlla se il progetto ha rispettato tempi, costi e specifiche, ma si misura poco o nulla il valore generato, in termini di tempi di risposta, qualità del servizio, riduzione degli errori, soddisfazione degli utenti e miglioramento dei processi.
Nel contesto del procurement pubblico, l’introduzione dell’Intelligenza Artificiale impone di superare infatti i tradizionali schemi di validazione basati sulla mera “disponibilità tecnica” del sistema. Fino ad oggi, i capitolati d’appalto per il software si sono concentrati su metriche statiche quali ad esempio l’uptime dei server o il rispetto dei tempi di risposta.
Comprare IA, tuttavia, significa acquistare un’entità probabilistica, non deterministica, il che comporta che le stazioni appaltanti devono spostare il baricentro della valutazione dalla semplice conformità formale alla performance reale e continua sul campo. I bandi di gara e i relativi Service Level Agreements (SLA) devono quindi integrare indicatori di qualità avanzati e dinamici, capaci di misurare l’efficacia intrinseca dell’inferenza.
Questo cambio di paradigma si traduce nella necessità di mappare, monitorare e sanzionare contrattualmente parametri fino a ieri confinati nei laboratori di data science:
• Qualità e Accuratezza dell’Inferenza: Valutare la precisione dei risultati generati rispetto ai dati reali del contesto pubblico (evitando che modelli addestrati su contesti esteri o commerciali falliscano una volta applicati alla burocrazia o al welfare italiano).
• Tasso di Allucinazione ed Errore: Per i sistemi basati su IA generativa, è vitale stabilire soglie massime tollerabili di generazione di informazioni false o non verificate, associando meccanismi correttivi e penali proporzionate in caso di superamento dei tassi di guardia.
• Data e Model Drift (Deriva del Modello): Un sistema IA non rimane uguale a se stesso. Con il variare dei dati d’ingresso nel tempo, le sue performance tendono a degradare. Il procurement deve richiedere metriche di monitoraggio del drift e l’obbligo per il fornitore di procedere a riaddestramenti periodici inclusi nel canone.
• Affidabilità e Robustezza: Misurare la capacità del sistema di mantenere livelli di prestazione costanti anche a fronte di dati d’ingresso anomali, incompleti o, nel peggiore dei casi, di attacchi avversariali (adversarial attacks).
Ancorare il procurement pubblico a questi indicatori significa proteggere l’investimento della PA lungo tutto il ciclo di vita del progetto; infatti, se la conformità contrattuale si esaurisce al momento del collaudo, la valutazione della performance reale garantisce che l’IA rimanga uno strumento efficiente, equo e sicuro; senza metriche di impatto, la PA non può distinguere tra un progetto riuscito e un progetto semplicemente completato.
Perché serve un procurement dell’innovazione
In sintesi, la trasformazione digitale non si realizza comprando tecnologia, ma costruendo condizioni di governabilità. Questo richiede capitolati meno rigidi e più intelligenti, criteri di aggiudicazione capaci di valorizzare qualità e sostenibilità, governance interna più forte, metriche di impatto e una gestione contrattuale che accompagni l’intero ciclo di vita del sistema; nel caso poi dell’IA, questa esigenza è ancora più evidente, non trattandosi di un mero acquisto di prodotto, ma di governare una relazione tecnica, economica e istituzionale che continua nel tempo.
Partecipa alla community