IA nella PA: le Linee Guida AgID tra rischio “lock-in”, sovranità digitale e il ruolo (dimenticato?) delle PMI

L’intelligenza artificiale nella Pubblica Amministrazione non è più una questione di mera innovazione organizzativa. È diventata una questione di architettura dello Stato, di capacità istituzionale, di governo del dato e, in ultima analisi, di sovranità. Le bozze delle Linee guida AgID dedicate allo sviluppo e al procurement dei sistemi di IA nella PA arrivano infatti in un momento in cui l’Italia, come il resto d’Europa, deve decidere se limitarsi a comprare tecnologie prodotte altrove oppure se usare la spesa pubblica come leva per costruire controllo, autonomia e filiera industriale. La cornice normativa che le bozze richiamano è già ampia e comprende AI Act, GDPR, Data Act, NIS2, Cyber Resilience Act, Codice dei contratti, Piano triennale per l’informatica nella PA e regolamentazione cloud ACN. Ma il punto decisivo non è l’elenco delle norme. Il punto decisivo è capire se queste Linee guida sapranno trasformare la conformità in potere amministrativo reale, cioè nella possibilità per le amministrazioni di adottare IA senza diventare dipendenti da piattaforme opache, standard chiusi, competenze non trasferibili e modelli economici costruiti per favorire i grandi operatori globali.

Due testi che decidono come lo Stato userà l’IA

Le due bozze si muovono su piani formalmente distinti ma sostanzialmente inseparabili. La prima riguarda lo sviluppo dei sistemi di intelligenza artificiale, la seconda il loro procurement, cioè il modo in cui quelle stesse soluzioni vengono acquistate, contrattualizzate, governate e mantenute nel tempo. Proprio qui si gioca la partita più importante: uno Stato che progetta bene ma compra male resta ostaggio del fornitore; uno Stato che compra senza una visione architetturale trasforma l’innovazione in semplice outsourcing. Nel documento dedicato allo sviluppo, AgID adotta una grammatica prescrittiva molto netta, esplicitando il significato di termini come “DEVE”, “DEVONO”, “DOVREBBE” e “PUÒ” secondo le direttive ISO/IEC. Questo dettaglio lessicale non è una formalità da giuristi o normatori. È il meccanismo con cui si fissano gli obblighi tecnici minimi, si definiscono i confini della discrezionalità e si costruisce l’auditabilità delle scelte. In altre parole, è il passaggio che trasforma l’IA da slogan amministrativo a materia governabile. Da qui nasce uno dei punti più forti dell’analisi strategica: se nello sviluppo il linguaggio è cogente, nel procurement la stessa cogenza deve sopravvivere e diventare obbligazione contrattuale esigibile. Perché è proprio nella gara, nella stipula e nell’esecuzione che i principi di trasparenza, reversibilità, interoperabilità e controllo dei dati rischiano di annacquarsi. E se lì il lessico si fa elastico, il rischio è che l’amministrazione si ritrovi con soluzioni formalmente conformi ma sostanzialmente chiuse.

Il problema vero: dal requisito tecnico al vincolo contrattuale

Le bozze AgID insistono correttamente sul fatto che il procurement deve evitare dipendenze rigide, privilegiare standard aperti, documentare le API, favorire interoperabilità, continuità del servizio e pluralità di operatori. Le clausole su accesso, proprietà, utilizzo e riuso dei dati, così come gli obblighi di portabilità e restituzione in formati aperti, vengono richiamati come aspetti centrali della stipula contrattuale. È un passaggio importante, perché riconosce che il dato pubblico non è un dettaglio operativo, ma la sostanza stessa del potere amministrativo nell’era digitale. Il nodo, però, è politico prima ancora che tecnico. Una pubblica amministrazione che non riesce a tradurre i requisiti architetturali in clausole contrattuali robuste rischia di comprare sistemi formalmente efficienti e sostanzialmente ingestibili. Il problema non è solo il prezzo. È la perdita di leva negoziale nel tempo: costi di uscita, migrazioni complesse, adeguamenti normativi onerosi, impossibilità di sostituire moduli, dipendenza da skill esclusive del fornitore, scarsa auditabilità. Le stesse Linee guida sullo sviluppo chiariscono che i sistemi devono essere comprensibili, gestibili e governabili dal personale interno, e che i contratti devono prevedere formazione continua, documentazione completa e affiancamento operativo strutturato. Inoltre, il procurement deve evitare soluzioni che richiedano competenze esclusive o non trasferibili. Questo significa che la sovranità non coincide solo con dove stanno i server, ma anche con chi capisce davvero il sistema e con la possibilità per la PA di non essere eternamente dipendente da chi lo ha implementato.

Open source, open weight e standard aperti non possono restare una premialità

Uno dei punti più sensibili riguarda il rapporto fra open source, open weights, API documentate e standard aperti. Le Linee guida sullo sviluppo affermano che lo sviluppo deve basarsi su standard aperti riconosciuti a livello europeo e internazionale, che le architetture devono adottare API standard compatibili con ecosistemi multi-fornitore e che il procurement deve privilegiare standard aperti, API documentate e formati interoperabili. Aggiungono inoltre che l’innovazione pubblica deve favorire riuso, modularità, ecosistemi aperti e, ove appropriato, componenti open source e open weights. È una base importante, ma non ancora sufficiente. Perché nel mercato dell’IA contemporanea la differenza tra una soluzione davvero aperta e una soltanto “compatibile” è enorme. Se il codice non è verificabile, se i pesi del modello non sono disponibili o almeno sostituibili, se l’orchestrazione dipende da ambienti proprietari, se l’API diventa l’unico punto di accesso con costi variabili e opacità infrastrutturale, allora l’apertura resta una formula retorica. E la PA finisce dentro un vendor lock-in evoluto, più sofisticato del software chiuso di ieri perché camuffato da servizio intelligente. Le stesse bozze riconoscono che le architetture devono evitare dipendenze tecnologiche rigide, garantire sostituibilità e continuità del servizio nel tempo. Ma un principio di questa portata, per diventare realmente efficace, dovrà essere tradotto in bandi che non si limitino a “valorizzare” l’apertura bensì la trattino, nei casi strategici, come condizione di accesso alla commessa. Senza questo salto, la PA rischia di continuare a comprare black box solo leggermente più trasparenti delle precedenti.

Sovranità digitale significa continuità dello Stato, non solo protezione del dato

Il passaggio più importante dell’intera discussione resta però quello sulla sovranità digitale. Troppo spesso il termine viene usato come slogan, quasi fosse sinonimo di semplice localizzazione del dato o di preferenza politica per il made in Europe. In realtà la sovranità, nel contesto dell’IA pubblica, significa qualcosa di molto più profondo: significa che lo Stato deve mantenere il controllo effettivo sui propri processi essenziali, sulla disponibilità dei dati, sull’aggiornabilità normativa dei sistemi, sulla possibilità di migrare, sostituire, verificare e dismettere senza traumi. Le bozze AgID vanno in questa direzione quando collegano il procurement alla governabilità, alla resilienza, alla portabilità, alla reversibilità e alla piena disponibilità del dato lungo il ciclo contrattuale. Quando richiedono architetture a servizi con orchestrazione controllata dalla PA, separazione dei componenti, gestione centralizzata o federata e soluzioni riusabili, condivisibili e interoperabili tra più amministrazioni, indicano chiaramente che la partita non si gioca solo sulla performance del modello ma sulla tenuta istituzionale dell’infrastruttura. In questo quadro, l’analisi strategica coglie un punto centrale: il focus va spostato dalla sola protezione del dato alla continuità operativa dello Stato in presenza di pressioni di mercato, tensioni geopolitiche, regimi extraterritoriali e concentrazione del potere tecnologico. Il tema del cloud per la PA, richiamato dalle Linee guida attraverso il regolamento ACN sulle infrastrutture e i servizi cloud, non è dunque un dettaglio amministrativo, ma il perimetro materiale entro cui si decide se la PA userà l’IA come strumento di emancipazione o come nuova forma di dipendenza.

La questione dei dati pubblici e il divieto di uso secondario

Un’altra faglia critica è quella relativa all’uso secondario dei dati pubblici. Le Linee guida sul procurement attribuiscono alla fase di stipula un ruolo decisivo su accesso, proprietà, utilizzo, riuso, portabilità, restituzione in formati aperti, interoperabilità e meccanismi di audit. È una formulazione che riconosce la centralità del dato come oggetto contrattuale e non solo come input tecnico. Ma proprio qui l’analisi strategica alza il livello del confronto. Se un’amministrazione affida un sistema di IA che tratta dati pubblici, specie in contesti sensibili o strategici, non basta “limitare” usi impropri. Occorre vietare con chiarezza che quei dati diventino materia prima gratuita per l’addestramento dei modelli proprietari del fornitore, salvo autorizzazione esplicita, specifica e normativamente compatibile. Perché altrimenti la PA finisce per finanziare due volte lo stesso ecosistema: una prima volta acquistando il servizio, una seconda volta cedendo implicitamente valore informativo che alimenta il vantaggio competitivo di operatori terzi. Le bozze sullo sviluppo distinguono correttamente tra training data e operational data, sottolineando che i dati usati per addestramento o fine-tuning e quelli trattati in esercizio hanno natura e implicazioni differenti sul piano della compliance, della sicurezza, della tracciabilità e del monitoraggio. Questa distinzione è fondamentale, perché consente di capire che non tutti i flussi informativi possono essere trattati allo stesso modo e che la sovranità digitale si difende anche costruendo perimetri di uso legittimo.

Il punto che RegTech News mette al centro: senza PMI non c’è indipendenza

È probabilmente qui che l’analisi di RegTech News tocca il nervo più scoperto della consultazione.

“L’assenza di una clausola che privilegi le piccole e medie imprese rischia di tagliare fuori dal procurement pubblico proprio quelle componenti del tessuto produttivo italiano ed europeo che dovrebbero essere rafforzate dalla commessa pubblica. Senza PMI, startup innovative e filiera locale, la sovranità resta una parola vuota.”

Il problema è reale. Le stesse bozze riconoscono che le aggregazioni di acquisto, gli accordi quadro e i soggetti aggregatori possono contribuire allo sviluppo dell’ecosistema produttivo, favorire operatori qualificati e stimolare filiere tecnologiche nazionali e territoriali. Ma riconoscono anche, implicitamente, che il procurement aggregato rafforza il potere negoziale della domanda pubblica e tende a operare su volumi, standardizzazione e complessità tecnica elevata. In altre parole: ciò che semplifica l’amministrazione può, se mal progettato, alzare barriere all’ingresso per i soggetti più piccoli. L’osservazione di RegTech è quindi più che condivisibile: senza clausole che rendano davvero contendibili le gare da parte di PMI, startup innovative e specialisti di nicchia, il procurement IA rischia di diventare un meccanismo di consolidamento del mercato, non di crescita industriale. E questo avrebbe effetti sistemici: meno concorrenza, meno competenze diffuse, meno occupazione qualificata sul territorio, più subappalto povero, meno capacità europea di reggere il confronto con i grandi player statunitensi e asiatici.

“La commessa pubblica non è soltanto approvvigionamento di beni e servizi per la pubblica amministrazione. È anche politica industriale. Se costruita bene, trattiene competenze, genera occupazione qualificata e impedisce che l’innovazione sia drenata altrove.”

È precisamente questo il punto. Il procurement IA non può essere pensato come una gara ICT tradizionale con un nuovo nome. Deve diventare uno strumento che finanzia capacità interna dello Stato e contemporaneamente rafforza la base industriale locale ed europea.

LCOAI, TCO e la falsa convenienza delle piattaforme globali

Sul piano economico, le bozze fanno un passo avanti rilevante. Il documento sul procurement chiarisce che indicatori come costo per token, costo per chiamata API, fatturazione per ora di calcolo e persino il classico Total Cost of Ownership non bastano a rappresentare correttamente il costo reale dei sistemi di IA. Il TCO, in particolare, viene considerato insufficiente quando manca una standardizzazione che rapporti i costi all’output prodotto e quando non si colgono le interdipendenze tra scelte architetturali, dati, deployment e gestione operativa. Per questo le Linee guida introducono il concetto di Levelized Cost of Artificial Intelligence, cioè una metrica di ciclo di vita che collega la spesa al valore generato dal sistema e alla sostenibilità nel tempo. Questo è un passaggio cruciale, perché smonta una delle illusioni più diffuse nelle amministrazioni: quella secondo cui le piattaforme globali, essendo più note, più facili da attivare e apparentemente più economiche all’inizio, sarebbero automaticamente la scelta più razionale. In realtà, il prezzo iniziale o unitario non fotografa i costi di integrazione, di lock-in, di riqualificazione del personale, di adeguamento normativo, di crescita dei consumi, di rinegoziazione dei canoni o di futura migrazione. L’LCOAI apre invece alla possibilità di valutare l’IA in termini di valore pubblico prodotto. E qui l’analisi strategica aggiunge un tassello che il dibattito italiano dovrebbe assumere in pieno: accanto ai costi strettamente contrattuali, andrebbero considerati anche gli effetti territoriali della spesa, come l’occupazione qualificata, il gettito fiscale, la crescita delle competenze, la permanenza del know-how e la minore esposizione a costi futuri di migrazione forzata. Non come romanticismo localista, ma come vera economia della resilienza.

Competenze interne, auditabilità e controllo operativo

Le bozze insistono anche su un altro punto spesso sottovalutato: un sistema di IA nella PA non è davvero sotto controllo se il personale dell’amministrazione non possiede competenze sufficienti per comprenderlo, monitorarlo, interrogarlo e contestarne il comportamento. Per questo lo sviluppo deve essere accompagnato da trasferimento strutturato di competenze e il procurement deve includere formazione continua, documentazione completa e affiancamento operativo. Questa indicazione è fondamentale. Nel mondo dell’IA, il vero lock-in non passa solo dal software o dall’infrastruttura, ma dalla asimmetria cognitiva. Se l’ente non capisce il modello, il suo orchestratore, i flussi dati, i rischi di bias, i limiti di sicurezza, le dipendenze esterne e le metriche di monitoraggio, allora non sta governando una tecnologia: sta delegando un pezzo di sovranità amministrativa a un soggetto esterno. Le Linee guida sullo sviluppo affermano inoltre che le architetture devono essere progettate con orchestrazione controllata dalla PA, separazione dei componenti e possibilità di gestione centralizzata o federata. È un’impostazione che va nella direzione giusta, perché la modularità non è solo un criterio tecnico di buona progettazione. È la precondizione per poter sostituire un modulo, cambiare fornitore, aggiornare un modello o correggere un componente senza demolire l’intero impianto applicativo.

Neutralità hardware, fallback CPU e sostenibilità reale

Un altro merito delle bozze è quello di affrontare il tema della neutralità hardware e della portabilità. Le Linee guida riconoscono che la forte integrazione verticale tra hardware, software e servizi può tradursi in dipendenza strutturale da specifiche tecnologie o fornitori, limitando la capacità della PA di migrare, adattare e valorizzare infrastrutture locali o a controllo pubblico. Per questo parlano di architetture hardware-agnostic, di esecuzione su infrastrutture computazionali eterogenee, di portabilità e reversibilità, e persino di fallback CPU basato su tecniche di ottimizzazione del modello. L’impostazione è corretta nel principio: lo Stato non può costruire servizi pubblici essenziali su stack incapaci di sopravvivere fuori da uno specifico ecosistema di acceleratori, driver, runtime e contratti cloud. Però anche qui occorre evitare illusioni. Il fallback CPU può garantire continuità in determinati contesti, ma non deve trasformarsi nella scorciatoia con cui si legittimano architetture energivore o prestazioni degradate. Le stesse Linee guida ricordano che la neutralità hardware e l’efficienza dei modelli non sono meri dettagli tecnici, ma fattori abilitanti della resilienza, della riduzione del lock-in, dello sviluppo di una filiera nazionale e della sostenibilità ambientale. Inoltre, sul versante ambientale, il documento sullo sviluppo afferma che i sistemi devono essere progettati tenendo conto dell’efficienza energetica e computazionale, e che le gare devono includere criteri di sostenibilità riferiti all’intero stack IA, favorendo soluzioni che dimostrino misurabilità e riduzione dell’impatto ambientale nel tempo. È un segnale importante, perché impedisce di trattare l’ecologia come allegato reputazionale di una tecnologia che, invece, ha costi fisici enormi in termini di potenza, raffreddamento, approvvigionamento hardware e consumo energetico.

La vera posta in gioco è politica industriale, non digitalizzazione amministrativa

L’impressione complessiva è che le bozze AgID abbiano già imboccato la strada giusta su alcuni assi fondamentali: governabilità dei sistemi, standard aperti, trasferimento di competenze, portabilità, valutazione economica di ciclo di vita, sostenibilità, controllo del dato, pluralità di operatori. Ma il salto che ancora manca, e che l’analisi strategica mette bene in evidenza, è quello dalla buona regolazione tecnica alla politica industriale esplicita.

“Se il procurement pubblico continua a essere dominato dai grandi operatori cloud e AI, in un contesto di tensioni geopolitiche e concentrazione del potere tecnologico, allora la PA non costruisce indipendenza: compra dipendenza in abbonamento.”

È una formula dura, ma sostanzialmente esatta. L’IA nella PA italiana non sarà giudicata dal numero di chatbot attivati o di processi automatizzati. Sarà giudicata dalla capacità dello Stato di usare quella spesa per rafforzare autonomia decisionale, continuità operativa, sicurezza giuridica e filiera europea. Se le Linee guida finali riusciranno a irrigidire il lessico prescrittivo, a blindare le clausole sui dati, a rendere più esigibile l’apertura tecnica, a impedire il lock-in e a creare spazi reali per PMI e startup, allora avranno fatto molto più che regolare una tecnologia: avranno definito una dottrina pubblica dell’IA. Se invece resteranno su un piano troppo elastico, il rischio è che la PA italiana continui a modernizzarsi solo in apparenza, trasferendo all’esterno la parte più strategica dell’intelligenza amministrativa. E in un’epoca in cui il potere passa per modelli, dati, infrastrutture e capacità di aggiornamento normativo, questo non sarebbe un semplice errore di acquisto. Sarebbe una rinuncia alla sovranità digitale.