La governance AI nella pubblica amministrazione non è più una questione da rimandare a quando le linee guida AgID saranno definitive: i sistemi di intelligenza artificiale sono già dentro gli enti, spesso senza censimento, senza policy, senza responsabilità chiare. È da questa distanza tra adozione reale e governo formale che parte la riflessione che segue.
Indice degli argomenti
Undici sistemi AI, nessun censimento: la scena da cui parte tutto
Qualche settimana fa, durante un incontro con i responsabili IT di un consorzio di comuni lombardi, ho posto una domanda semplice: quanti sistemi AI state usando oggi nei vostri enti? Silenzio. Poi una risposta cauta: tre, forse quattro. Poi, dopo cinque minuti di verifica incrociata tra i presenti, il numero era salito a undici. Strumenti per la trascrizione delle delibere, assistenti per la redazione di atti, chatbot per il front office, plugin AI integrati nei gestionali. Nessuno aveva un censimento. Quasi nessuno aveva un contratto che specificasse come venivano trattati i dati. Nessuno aveva una policy che dicesse chi poteva adottare nuovi tool e con quali criteri.
Questa è la fotografia reale di molti enti italiani nel 2027. Non è una critica: è un punto di partenza. E il punto di partenza da cui chiunque abbia una responsabilità digitale in una pubblica amministrazione deve cominciare a ragionare.
Le linee guida AgID non sono il punto di partenza
AgID ha recentemente pubblicato la bozza di linee guida per lo sviluppo e l’adozione di sistemi AI nella PA, in coerenza con il Piano Triennale 2024-2026. Il documento tratta architettura logica, stack AI, orchestratori, modelli, dati, tool, ciclo di vita. Una seconda bozza di linea guida parla del procurement. Sono un riferimento importante, e ci torneremo. Ma non è il punto centrale di questo articolo.
Il punto centrale è un altro: cosa deve fare concretamente chi ha la responsabilità digitale in un ente pubblico, oggi, indipendentemente dal fatto che le linee guida siano in bozza o definitive? Perché la governance AI non aspetta i documenti. I sistemi AI sono già dentro gli enti. La domanda è chi li governa.
La fotografia: l’AI è già dentro, ma nessuno la governa
Negli ultimi due anni, l’adozione di strumenti AI nella PA italiana è avvenuta in modo prevalentemente bottom-up. Un funzionario motivato ha iniziato a usare un assistente AI per velocizzare la redazione degli atti. Un altro ha attivato un abbonamento a uno strumento di trascrizione automatica. Un responsabile IT ha integrato un plugin AI nel gestionale documentale senza una valutazione formale. Singolarmente, ognuna di queste scelte era comprensibile. Sommandole, si ottiene un ecosistema non governato.
Il problema non è tecnologico. Il problema è di governance: non si sa cosa gira, chi ne è responsabile, quali dati tratta, con quali fornitori e a quali condizioni contrattuali. In assenza di un censimento e di una policy, ogni nuovo strumento aggiunge superficie di rischio senza che nessuno la misuri.
Aggiungete a questo quadro l’AI Act europeo, che è in vigore, e le linee guida AgID, che stanno arrivando. Il perimetro normativo si sta chiudendo. Chi non ha ancora strutturato una governance AI si troverà presto a rincorrere requisiti invece di anticiparli. La differenza tra le due posizioni, in termini di costi, tempi e rischi, è significativa.
Il RTD davanti allo specchio: cosa significa avere la delega digitale oggi
Il Responsabile per la Transizione al Digitale (RTD) è la figura che, almeno sulla carta, dovrebbe coordinare la trasformazione digitale dell’ente. In molti comuni italiani, specialmente quelli di medie e piccole dimensioni, il RTD è anche il responsabile IT, a volte anche il responsabile della privacy, a volte anche qualcos’altro. È una figura con competenze richieste sempre più ampie e risorse spesso invariate.
Cosa significa, concretamente, avere la delega digitale in un ente che sta adottando AI in modo non governato? Significa essere responsabile di qualcosa che non si conosce completamente. Significa che se un sistema AI genera un atto amministrativo errato, o se un tool AI fa trapelare dati sensibili, la catena di responsabilità porta inevitabilmente a quella figura.
Le linee guida AgID chiariscono un punto che i RTD devono interiorizzare: l’adozione AI non è una scelta tecnica delegabile all’IT. È una scelta organizzativa che impatta su processi, responsabilità, contratti e conformità. Il RTD deve guidare questo processo, non limitarsi a ratificare dopo che è già avvenuto.
In pratica, questo significa tre cose. Prima: il RTD deve sapere quali sistemi AI sono in uso nell’ente, non perché li ha scelti lui, ma perché è responsabile di governarli. Seconda: deve avere voce in capitolo (o avere voce definitiva) su ogni nuova adozione AI, con un processo formale di valutazione. Terza: deve essere il punto di raccordo tra le esigenze operative degli uffici, le valutazioni dell’IT, i vincoli della privacy e i requisiti normativi. Non è un ruolo tecnico. È un ruolo di coordinamento con responsabilità crescente.
Il CIO e il catalogo che non esiste: il primo atto è censire
Se c’è una cosa che emerge con chiarezza dal framework AgID e dalla logica dell’AI Act, è che non si può governare ciò che non si conosce. Il primo atto concreto per qualsiasi responsabile IT o CIO di un ente pubblico è costruire un catalogo dei sistemi AI in uso.
Non si tratta di un esercizio burocratico. Si tratta di una fotografia operativa che risponde a domande semplici ma critiche: quali sistemi AI sono attivi? Quali dati trattano? Qual è il fornitore e qual è il contratto vigente? Esiste documentazione del modello utilizzato? Chi è il referente interno? Il sistema è in produzione o in sperimentazione?
Nella mia esperienza con enti di varie dimensioni, questo censimento produce quasi sempre sorprese. Strumenti adottati da singoli uffici senza comunicazione all’IT. Abbonamenti personali usati per attività lavorative. Integrazioni AI dentro gestionali che l’ente non sapeva fossero state abilitate dal fornitore. Ogni elemento di questo tipo è un rischio non mappato.
Il catalogo non deve essere un documento complesso. Anche un foglio condiviso con dieci colonne è meglio di niente. L’importante è che esista, che sia aggiornato e che sia il punto di riferimento per qualsiasi decisione successiva sull’AI nell’ente. Da quel catalogo, il CIO può fare una prima valutazione del rischio: quali sistemi trattano dati sensibili? Quali mancano di documentazione contrattuale adeguata? Quali non hanno un referente interno identificato?
Questo lavoro richiede ore, non mesi. È il punto di partenza senza cui tutto il resto, comprese le linee guida AgID, rimane astratto.
Il procurement che va riscritto: tre clausole minime da oggi
Il secondo fronte su cui i responsabili PA devono agire riguarda il procurement. Le categorie tradizionali con cui si acquistano servizi digitali non sono attrezzate per l’AI. Un sistema AI non è un software con funzionalità fisse: è un sistema che cambia nel tempo, che dipende dai dati, che può comportarsi in modo diverso a seconda del contesto d’uso e che introduce dipendenze dal fornitore molto più profonde di quelle di una normale licenza applicativa.
Le linee guida AgID indicano criteri specifici per il procurement AI. Traducendoli in pratica, ci sono almeno tre clausole che ogni capitolato di gara per servizi con componenti AI dovrebbe includere da subito.
Trasparenza sul modello e sugli aggiornamenti
Il fornitore deve dichiarare quale modello AI viene utilizzato, se è di terze parti o sviluppato internamente, e come vengono gestiti gli aggiornamenti. In particolare: l’ente deve essere informato con congruo anticipo se il modello base viene sostituito o aggiornato in modo significativo, perché questo può cambiare il comportamento del sistema senza che l’ente se ne accorga. Un modello che risponde in modo diverso oggi rispetto a sei mesi fa, senza che nessuno lo abbia notificato, è un rischio reale.
Portabilità dei dati e condizioni di uscita
I dati che l’ente immette nel sistema AI, inclusi i documenti usati per contestualizzare le risposte e le interazioni degli utenti, devono rimanere nella disponibilità dell’ente. Il contratto deve specificare: i dati vengono usati per addestrare il modello del fornitore? Rimangono in Italia o nell’UE? Come vengono cancellati alla fine del contratto? Queste domande non sono optional da rimandare alla negoziazione finale: devono essere requisiti nel capitolato.
Metriche di qualità in produzione e diritto di audit
Un sistema AI non si testa solo in fase di collaudo: va monitorato continuamente, perché le sue prestazioni possono degradare nel tempo. Il contratto deve prevedere metriche di qualità concordate, con soglie e penali, e deve riconoscere all’ente il diritto di audit sul sistema, inclusa la possibilità di verificare le logiche di funzionamento e i log delle interazioni. Senza questo diritto, l’ente è cieco su quello che il sistema sta facendo davvero.
Queste tre clausole non richiedono competenze legali specialistiche per essere introdotte. Richiedono consapevolezza e volontà. Gli uffici gare che ancora non le prevedono nei capitolati AI stanno lasciando l’ente esposto a rischi che potrebbero essere evitati con una riga di testo in più nel disciplinare.
Il CISO e i nuovi vettori: dove nasce davvero il rischio
Per chi si occupa di sicurezza informatica in un ente pubblico, i sistemi AI introducono una superficie di attacco che le analisi del rischio tradizionali faticano a coprire. Non perché i principi cambino, ma perché i punti critici si spostano.
I dati di training sono il primo vettore. Se l’ente ha partecipato a un processo di fine-tuning o ha fornito dati per personalizzare un modello, quei dati sono entrati in un processo che può essere difficile da tracciare e da auditare. I modelli possono memorizzare informazioni contenute nei dati di training e restituirle in contesti imprevisti, anche a utenti non autorizzati a vederle. La minimizzazione dei dati usati per addestrare non è solo un principio GDPR: è una misura di sicurezza concreta.
I dati operativi sono il secondo vettore. Ogni query che un utente invia al sistema AI, ogni documento caricato nel contesto di una conversazione RAG, ogni risposta generata è loggata da qualche parte. Da chi? Per quanto tempo? Con quali condizioni di accesso per il fornitore? Questi dati in transito sono un bersaglio, e spesso non sono protetti con la stessa attenzione che si riserva ai dati nei database tradizionali.
L’orchestratore è il terzo vettore, il più insidioso. Nelle architetture AI più evolute, l’orchestratore non si limita a coordinare il modello: può attivare tool, chiamare API esterne, leggere database, inviare dati a sistemi di terze parti. È un componente con privilegi elevati che opera in modo spesso opaco. Un orchestratore mal configurato, o compromesso, può diventare un vettore di data leakage o di privilege escalation molto difficile da rilevare con i sistemi di monitoraggio tradizionali.
Infine, il supply chain risk. I sistemi AI moderni sono raramente monolitici: si appoggiano su modelli base di terze parti, usano librerie open source, si integrano con servizi esterni. Ogni elemento della catena è un potenziale punto di compromissione. Le linee guida AgID richiedono una mappatura di questi componenti: è esattamente quello che un CISO dovrebbe già fare come parte del software supply chain management, adattato alle specificità dell’AI.
La conseguenza pratica per i CISO è che l’AI deve entrare nel perimetro del vulnerability management, del penetration testing e della gestione degli incidenti, con metriche e strumenti specifici. Un sistema AI compromesso non mostra gli stessi segnali di un server compromesso. Il segnale può essere una risposta anomala, un dato che appare dove non dovrebbe, una variazione nelle performance. Rilevarlo richiede sensori nuovi e personale formato su questi scenari.
Il ciclo di vita come responsabilità: chi monitora, chi decide, chi dismette
Quasi nessun progetto AI nella PA italiana ragiona sull’uscita. Si pensa all’adozione, si pensa alla manutenzione se le cose vanno bene, raramente si pensa a cosa succede quando il sistema deve essere aggiornato in modo significativo, sostituito o dismesso.
Le linee guida AgID introducono esplicitamente il concetto di ciclo di vita del sistema AI, con fasi precise: progettazione, sviluppo o acquisizione, validazione, messa in produzione, monitoraggio continuo, aggiornamento e decommissioning. Per ognuna, indicano responsabilità e criteri di qualità. È un framework utile, ma il suo valore reale dipende da una domanda che ogni ente deve rispondere internamente: chi fa cosa?
Il monitoraggio in produzione è la fase più sottovalutata. A differenza del software tradizionale, un sistema AI può degradare silenziosamente: continua a rispondere, ma le risposte diventano meno accurate, meno pertinenti, potenzialmente discriminatorie. Questo fenomeno, spesso chiamato data drift o model drift, richiede metriche di controllo definite a priori. Chi le legge? Con quale frequenza? Chi ha la facoltà di sospendere il sistema se i valori scendono sotto soglia?
Il decommissioning pone domande che oggi quasi nessuno si pone. Cosa succede ai dati che il sistema ha trattato? Come si garantisce che il modello smetta di essere usato per scopi diversi da quelli originali? Come si gestisce la transizione verso un sistema sostitutivo senza perdere continuità operativa? Queste non sono domande per quando il sistema viene dismesso: sono domande da porre prima di adottarlo, perché le risposte condizionano le clausole contrattuali e le scelte architetturali.
In pratica: ogni sistema AI in produzione dovrebbe avere un responsabile nominato, un documento di ciclo di vita anche minimo, e una revisione periodica pianificata. Tre elementi che la maggior parte degli enti oggi non ha.
Il decalogo AgID come esame di coscienza
Tra i materiali allegati alle linee guida, il decalogo per la PA merita un uso specifico. Non da appendere in bacheca. Non da citare in delibera. Da usare come check di maturità su ogni sistema AI che l’ente ha già adottato o sta valutando.
I dieci principi coprono trasparenza verso i cittadini, supervisione umana nelle decisioni rilevanti, qualità e rappresentatività dei dati, sicurezza by design, spiegabilità algoritmica, non discriminazione, privacy, responsabilità, sostenibilità e aggiornamento continuo delle competenze.
Preso un qualsiasi sistema AI in uso nell’ente, proviamo a rispondere onestamente: i cittadini destinatari del servizio sanno che c’è un sistema AI coinvolto? C’è sempre un essere umano che può intervenire sulle decisioni rilevanti? I dati su cui si basa il sistema sono rappresentativi della popolazione che serve, o ci sono gruppi sottorappresentati? Sai spiegare, anche in modo semplice, perché il sistema ha dato una certa risposta?
Per la maggior parte dei sistemi AI oggi in uso nella PA italiana, la risposta onesta a molte di queste domande è non lo so o no. Il decalogo non è una punizione: è uno specchio. È meglio guardarsi adesso, in fase di adeguamento volontario, che quando arriva un audit o, peggio, un caso problematico che finisce sui giornali.
La governance AI non è un progetto: è una postura organizzativa
C’è un equivoco ricorrente nella PA italiana: trattare la governance AI come un progetto da avviare, con un inizio, una fine e un deliverable. Non è così. La governance AI è una postura organizzativa che si costruisce nel tempo, con azioni continue, revisioni periodiche e adattamenti al mutare della tecnologia e del quadro normativo.
Questo non significa che non ci siano passi iniziali concreti. Ce ne sono, e sono urgenti. Il censimento dei sistemi AI esistenti. Una policy minima di adozione. L’aggiornamento dei capitolati di gara. La nomina di responsabili per ogni sistema in produzione. Un ciclo di revisione periodica. Ognuno di questi passi è raggiungibile in settimane, non in anni, se c’è la volontà di farlo.
Le linee guida AgID danno un framework di riferimento prezioso. Il Piano Triennale dà la direzione. Ma né le linee guida né il Piano Triennale agiscono al posto dei responsabili negli enti. Agiscono RTD, CIO e CISO che decidono di trasformare indicazioni normative in pratiche operative.
Torno alla scena iniziale: quei responsabili che non sapevano quanti sistemi AI giravano nel loro ente. A fine incontro avevano un elenco di undici strumenti, una lista di domande senza risposta e una consapevolezza nuova. È già un punto di partenza migliore di prima.
La domanda non è se la PA italiana sarà pronta per l’AI. La domanda è quali responsabili, in quali enti, decidono di esserlo adesso.
Partecipa alla community