AI nella PA locale, i dieci ostacoli che frenano i comuni italiani

C’è una scena che molti RTD dei comuni italiani conoscono bene. È il pomeriggio di un giovedì, hai appena finito un webinar su come l’AI generativa sta rivoluzionando i servizi pubblici. Il relatore ha mostrato chatbot che rispondono ai cittadini in linguaggio naturale, agenti che processano pratiche edilizie in automatico, strumenti che analizzano anni di delibere in pochi secondi. Torni in ufficio con la mente piena di possibilità.

Poi apri il gestionale.

Il gestionale non ha API. I dati dell’anagrafe sono in un formato proprietario che nessuno sa più leggere. Il collega che sapeva qualcosa di digitale è andato in pensione a marzo. Il budget ICT è quello di tre anni fa, congelato. E soprattutto, non hai nessuno a cui telefonare domani mattina per capire da dove iniziare.

L’AI non manca. Mancano le condizioni per usarla.

Non è una questione di volontà o di visione. È una questione di infrastruttura, organizzazione, cultura e sistema. Nei miei lavori con i comuni del territorio cremasco e lombardo, ho provato a mappare sistematicamente questi ostacoli. Il risultato è una lista di dieci nodi, dieci cause strutturali che rendono l’adozione dell’AI nella PA locale un percorso a ostacoli invece che una trasformazione progressiva.

Li presento qui, raggruppati per livello. Non come una lista della spesa, ma come un framework diagnostico: prima di comprare qualsiasi strumento AI, vale la pena chiedersi quanti di questi nodi il proprio comune è in grado di sciogliere.

Primo livello: infrastruttura e dati

L’AI ha bisogno di dati. I dati vivono nei sistemi gestionali.

Nodo 1. API e interoperabilità

I sistemi gestionali dei comuni italiani, nella maggior parte dei casi, non espongono API. Parlano tra loro poco o niente, e con il mondo esterno ancora meno.

Il Piano Triennale per l’Informatica nella PA indica la strada da anni: interoperabilità attraverso la PDND, standard aperti, integrazione tra banche dati. Ma tra la norma e la realtà operativa dei 7.904 comuni italiani c’è un abisso. Ho condotto una verifica empirica su tredici fornitori di software gestionale per comuni nella provincia di Cremona: uno solo ha consegnato un file Swagger, ovvero la documentazione tecnica minima per sapere se e come le proprie API sono fruibili. Uno su tredici.

Senza API, l’AI si ferma alla porta. Non perché il modello non funzioni, ma perché non ha nulla su cui lavorare. O peggio, lavora su dati esportati manualmente, non aggiornati, non certificati, non strutturati.

Nodo 2. Standard di comunicazione

Anche quando i dati ci sono, spesso non si parlano. Formati diversi, codifiche diverse, campi che cambiano nome da un sistema all’altro. Il nome del contribuente è scritto in maiuscolo in un gestionale e in minuscolo in un altro. Le date in formato italiano in un file e in formato anglosassone nell’altro. L’indirizzo con CAP nel campo errato.

L’assenza di standard condivisi non è un dettaglio tecnico: è un moltiplicatore di errori. Ogni ora di lavoro che un tecnico passa a normalizzare dati è un’ora non spesa a costruire servizi utili ai cittadini. E ogni dataset non standardizzato è un ostacolo in più per qualsiasi modello di AI che provi a ragionare su quei dati.

Nodo 3. Governance del dato

I comuni producono dati in quantità industriale ogni giorno: pratiche, delibere, variazioni anagrafiche, pagamenti, permessi, esposti. Raramente però li governano.

Governare il dato significa avere un data owner per ogni dominio, una politica di qualità, un ciclo di vita definito: quando il dato nasce, quando si aggiorna, quando scade, quando va archiviato. Significa sapere chi è responsabile se un dato è sbagliato.

Il GDPR ha portato nei comuni la figura del DPO. Non ha portato però una cultura del dato. Il DPO si occupa di protezione e privacy: è una funzione di garanzia, non di produzione di qualità. Il dato sporco, incompleto, non aggiornato continua a circolare indisturbato finché non produce un errore visibile. A quel punto, di solito, la risposta è umana: ci pensa qualcuno a mano. L’AI su spazzatura produce spazzatura. Prima di investire in intelligenza artificiale, vale la pena investire in igiene del dato.

Negli enti locali italiani persiste un equivoco di fondo sul ruolo del dipendente pubblico. Per decenni è stato formato e valutato come produttore di atti, certificati e pratiche. Oggi, sempre più, il suo ruolo reale è diverso: è custode del dato del cittadino. Non solo in termini di sicurezza e protezione, ma anche di qualità, struttura e usabilità.

Questo passaggio non è stato accompagnato da un’evoluzione culturale e organizzativa adeguata. Il risultato è che i dati vengono ancora trattati come un sottoprodotto delle pratiche, invece che come un’infrastruttura strategica su cui costruire servizi, interoperabilità e intelligenza artificiale.

Secondo livello: organizzazione e persone

La formazione AI nella PA è quasi sempre un evento.

Nodo 4. Formazione continuativa e non puntuale

Un corso di mezza giornata, un webinar da un’ora, un convegno con i soliti relatori. L’obiettivo dichiarato è “sensibilizzare”. Il risultato reale è creare un’aspettativa senza costruire una competenza.

La differenza tra sensibilizzazione e competenza è la differenza tra sapere che esiste il nuoto e saper nuotare. Il dipendente pubblico che ha seguito un webinar sull’AI sa che l’AI esiste. Non sa usarla nel suo lavoro specifico, non sa valutare i limiti, non sa quando fidarsi di un output e quando no.

La formazione che serve è diversa: continua, contestualizzata, pratica. Non “cos’è ChatGPT” ma “come uso l’AI per elaborare questa tipologia di atti”, “come verifico un output AI su questa categoria di dati”, “qual è il processo corretto quando il sistema mi dà una risposta che non torna”. E va ripetuta nel tempo, perché gli strumenti cambiano in fretta e le competenze si deteriorano se non vengono esercitate.

Nodo 5. Unire funzionalmente i comuni sotto i 5.000 abitanti

L’Italia ha 5.617 comuni con meno di 5.000 abitanti. Rappresentano il 71% del totale. La maggior parte ha un organico ridotto, un ufficio tecnico di una o due persone, un segretario comunale condiviso con altri enti, un budget ICT che non consente scelte autonome.

Nessuno di questi comuni può permettersi da solo un esperto di AI, un data scientist, un responsabile della trasformazione digitale. Nemmeno un progetto pilota sostenibile nel tempo. La frammentazione non è un dato naturale: è una scelta politica che nessuno ha ancora il coraggio di rimettere in discussione con la necessaria urgenza.

L’aggregazione funzionale non significa fusione. Significa condivisione di risorse, competenze, infrastrutture, processi. Significa che un comune da 1.200 abitanti non deve affrontare da solo la complessità della trasformazione digitale: può farlo all’interno di un bacino sovracomunale dove le competenze sono distribuite e i costi sono spalmati.

Nodo 6. Continuità organizzativa e dipendenza dalle persone

Ogni comune che ha fatto qualcosa di interessante in ambito digitale, di solito, lo ha fatto grazie a una persona. Il funzionario appassionato, il tecnico curioso, il sindaco illuminato. Quella persona ha imparato, ha sperimentato, ha portato risultati. E poi è andata in pensione, o si è trasferita, o ha vinto un concorso altrove.

Il problema non è la persona. Il problema è che il comune non ha istituzionalizzato ciò che quella persona aveva costruito. Quando se ne va, va via tutto: le competenze, i processi, i contatti con i fornitori, la memoria delle scelte fatte. Il comune riparte da zero.

Questo è un problema di knowledge management organizzativo, non di formazione. Non si risolve facendo più corsi: si risolve costruendo processi documentati, procedure scritte, sistemi di onboarding che trasferiscono il sapere da una persona a un’organizzazione. L’AI adottata da un comune deve vivere nell’ente, non nella testa di qualcuno.

Terzo livello: strategia e sistema

Come fa un comune a sapere se un progetto AI ha funzionato?

Nodo 7. Misurazione dell’impatto e OKR

In quasi tutti i casi che ho osservato, la risposta è: non lo sa. O meglio, ha una percezione, un’impressione, un feedback verbale di qualche collega. Ma non ha dati.

Senza KPI di processo chiari, non si sa se i tempi di risposta agli esposti sono migliorati, se il carico degli sportelli si è ridotto, se gli errori nei procedimenti sono diminuiti. Senza metriche, non si può scalare ciò che funziona, non si può correggere ciò che non funziona, non si può giustificare la spesa al consiglio comunale.

Il framework degli OKR (Objectives and Key Results) non è uno strumento da startup: è un metodo per collegare ambizioni strategiche a risultati misurabili. In una PA che vuole adottare l’AI in modo serio, gli OKR permettono di rispondere a domande concrete: cosa vogliamo ottenere? Come lo misuriamo? In quanto tempo? Con queste risorse? La misurazione non è un accessorio del cambiamento: è la condizione per sapere se il cambiamento sta avvenendo.

Nodo 8. Cultura del rischio e sperimentazione

La PA italiana è strutturalmente avversa all’errore. Non per pigrizia o mancanza di coraggio: perché l’errore ha conseguenze reali. Contabili, disciplinari, a volte penali. Il funzionario che firma un atto sbagliato risponde personalmente. Il dirigente che autorizza una spesa non corretta rischia il danno erariale.

In questo contesto, l’AI introduce una variabile nuova e scomoda: l’incertezza dell’output. Un sistema AI non garantisce sempre la risposta giusta. Può sbagliare, allucinare, produrre risultati plausibili ma incorretti. Chiedere a un dipendente pubblico di adottare uno strumento che può sbagliare, in un sistema che punisce l’errore, è una contraddizione che nessuna circolare ministeriale ha ancora risolto.

Serve una sandbox: normativa prima ancora che tecnologica. Uno spazio in cui sperimentare e consentire gli errori che sono occasioni di apprendimento e non atti da sanzionare, e chi tenta soluzioni nuove è protetto almeno quanto chi non fa nulla. Senza questa protezione culturale e giuridica, l’innovazione rimane sulla carta.

Nodo 9. Comunicazione del cambiamento ai cittadini e alle imprese

I comuni possono fare AI perfettamente, adottarla con criterio, misurarla con rigore, e farla odiare dai cittadini se non spiegano cosa stanno facendo, perché lo fanno, con quali garanzie.

La fiducia algoritmica non si dà per scontata. Un cittadino che riceve una risposta automatica a un esposto non sa se dietro c’è un sistema AI, un operatore, o una combinazione dei due. Non sa se i suoi dati sono usati per addestrare un modello. Non sa se può contestare una decisione assistita dall’AI e a chi rivolgersi se lo vuole fare.

La comunicazione del cambiamento in corso non è un’attività di marketing: è un atto di responsabilità democratica. I comuni che adottano l’AI devono spiegare ai propri cittadini cosa cambia, cosa rimane uguale, e dove si trovano le garanzie. Senza questa trasparenza, arriva inevitabilmente la resistenza politica, che blocca anche i progetti migliori.

Il decimo nodo è diverso dagli altri: lo sherpa sovracomunale

I nove nodi che ho descritto fin qui hanno una caratteristica comune: possono essere affrontati, almeno in teoria, da un singolo comune con risorse, volontà e competenze sufficienti. Sono nodi tecnici, organizzativi, culturali. Complessi, costosi, lenti da sciogliere, ma almeno identificabili e assegnabili.

Il decimo nodo è diverso. Non è un problema che un comune può risolvere da solo. È un problema sistemico che richiede una risposta sistemica.

Chiamiamolo così: lo sherpa sovracomunale nella valle dell’AI.

Lo sherpa non è la guida che porta il turista in cima con le mani tenute. È la figura che conosce il territorio, sa quale sentiero è praticabile in quella stagione, riconosce i segnali del maltempo, porta il materiale tecnico che il viaggiatore non sa trasportare da solo. Senza lo sherpa, la montagna è sempre lì. Ma le probabilità di arrivare sano e salvo si riducono drasticamente.

Nella valle dell’AI, lo sherpa sovracomunale è la figura o la struttura che accompagna un bacino di comuni nel tempo: non un formatore spot che appare per un corso e sparisce, non un venditore di software che ha interesse a vendere il suo prodotto, non un consulente che fattura giornate. È qualcuno che conosce profondamente il territorio, le sue specificità normative, le sue debolezze organizzative, le sue possibilità concrete, e che lavora a fianco dei comuni in modo continuativo, come un medico di base che segue i propri pazienti nel tempo invece di riceverli al pronto soccorso solo quando la situazione è già critica.

Il modello esiste già

In Italia esistono già strutture che svolgono una funzione analoga per la digitalizzazione dei comuni: i Consorzi di informatica, le unioni di comuni, le centrali di committenza territoriali, i centri di competenza. Entità sovracomunali che servono decine di comuni coordinando l’acquisto di servizi, la gestione di infrastrutture, il supporto tecnico. Conoscono i comuni dall’interno, hanno relazioni di lunga data con le amministrazioni, parlano il linguaggio del funzionario pubblico, non quello del consulente di strategia.

Il problema è che queste strutture sono nate in un’epoca in cui la digitalizzazione significava ancora “installare software”. La transizione verso l’AI richiede un salto di competenze, di metodo e di approccio che non è automatico. Non basta avere una struttura: bisogna evolversi, dotarla di nuove professionalità, ripensare il ruolo da gestore di contratti a enabler di trasformazione.

Il centro di competenza del futuro non solo compra licenze per conto dei comuni: costruisce con loro la capacità di usare le licenze. Non installa strumenti: aiuta i comuni a capire quale problema vale la pena risolvere con uno strumento software o AI e quale invece richiede prima un intervento organizzativo o normativo. Non eroga formazione generica: produce apprendimento contestualizzato, misurabile, collegato ai processi reali.

Il parallelo che funziona: la medicina di gruppo

C’è un parallelo che trovo utile per spiegare cosa manca. Negli anni Ottanta, la sanità territoriale italiana era frammentata in medici di base isolati, ognuno con il proprio studio, la propria agenda cartacea, il proprio modo di fare le cose. La riforma che ha portato alla medicina di gruppo ha cambiato l’equazione: i medici continuano a essere autonomi nel loro giudizio clinico, ma condividono strutture, dati, personale di supporto, protocolli. Il paziente accede a una competenza distribuita, non più a un singolo professionista.

I comuni italiani hanno bisogno di qualcosa di analogo per l’AI. Non la fusione, non la perdita di autonomia politica. Ma la condivisione di una competenza che da soli non possono permettersi e non possono costruire. Lo sherpa sovracomunale è questa competenza condivisa, istituzionalizzata, finanziata in modo stabile, non episodico.

Chi può sciogliere i nodi, e come

Il quadro che ho descritto potrebbe sembrare sconfortante. Dieci nodi, sei dei quali richiedono interventi che vanno oltre le capacità di un singolo comune. Ma la diagnosi non è un verdetto: è una mappa di lavoro.

I centri di competenza informatica comunali hanno oggi l’opportunità e la responsabilità di evolvere il proprio ruolo. Smettere di essere semplici gestori di contratti e diventare strutture di accompagnamento alla trasformazione. Questo richiede investimento in nuove competenze (data governance, AI ethics, change management), in nuovi servizi (assessment di maturità digitale, OKR di processo, formazione contestualizzata), e in una nuova narrativa verso i comuni soci: non “vi compriamo il software”, ma “vi accompagniamo a usarlo bene”.

ANCI e IFEL hanno gli strumenti per spingere questa evoluzione a livello nazionale. Il Piano Nazionale di Formazione, i bandi PNRR per la capacità amministrativa, i tavoli con i fornitori di software: sono tutti leve che possono essere usate per creare le condizioni abilitanti che mancano. Non con nuove norme, che la PA italiana non riesce a recepire prima che ne arrivino di nuove, ma con standard di servizio, linee guida operative, esempi replicabili.

Le Regioni, infine, hanno il ruolo di connettere i puntini tra i Consorzi, le unioni di comuni, le centrali di committenza e i programmi di finanziamento europei e nazionali. La variabilità territoriale tra Lombardia e Calabria, tra Trentino e Sicilia, è reale e non va ignorata. Ma è anche una risorsa: le esperienze che funzionano in un contesto possono essere adattate e replicate.

Conclusione: la scelta è politica prima che tecnica

C’è un paradosso nell’adozione dell’AI nei comuni italiani. L’AI generativa è probabilmente lo strumento tecnologico più democratizzante degli ultimi vent’anni: costa poco, non richiede hardware specializzato, è accessibile da un browser su qualsiasi computer. Un comune da 800 abitanti ha accesso agli stessi modelli di un ministero.

Eppure rischia di ampliare il divario invece di ridurlo. Perché le condizioni abilitanti, i dieci nodi che ho descritto, non sono ugualmente distribuite. I comuni grandi, con più risorse, più personale, più capacità di spesa, scioglieranno i nodi più in fretta. I comuni piccoli, senza supporto sistemico, resteranno indietro.

La differenza tra un futuro in cui l’AI riduce le disuguaglianze nella qualità dei servizi pubblici locali e un futuro in cui le amplifica non è tecnologica. È una scelta politica. Dipende da quanta volontà collettiva c’è di costruire le infrastrutture organizzative, formative e istituzionali che servono per fare in modo che anche il comune più piccolo abbia il suo sherpa.

La montagna è la stessa per tutti. Ma non tutti partono con le stesse scarpe.