La scena si ripete, con variazioni minime, in quasi tutti gli enti con cui lavoro. Un dirigente, un RTD, a volte un sindaco lungimirante, apre il laptop e mostra con una certa soddisfazione come il suo ufficio stia usando Copilot, o ChatGPT, o qualche strumento AI integrato nella suite. “Ce l’abbiamo anche noi.” La dimostrazione funziona. Qualcuno annuisce. E lì, in quel momento, si innesca un equivoco che potrebbe costare caro.L’equivoco non riguarda il tool in sé, che spesso è buono. Riguarda la domanda che non viene fatta: “ok, l’AI ce l’abbiamo. Ma su cosa gira?”Perché l’AI non produce valore nell’astratto. Lo produce nel concreto, sul contesto che le dai. E quel contesto, nelle organizzazioni pubbliche italiane, ha due nomi poco glamour ma decisivi: dati e processi.Indice degli argomenti
AI nella pubblica amministrazione: il pattern della commodityIl vero moat dell’AI è l’alimentazione dei datiDati e processi nella PA: il problema è la qualitàLa qualità del dato non è un progetto, è un ritmo organizzativoPerché chi viene dalla BI è già avvantaggiatoRagionare per definizioni e semanticaPretendere tracciabilità e controlliCapire che il valore sta nei processi, non nelle risposteAI nella PA: una regola pratica per investire bene adessoCosa si può fare concretamente: tre mosse per partire benePrima mossa: fai un inventario onesto dei tuoi dati più criticiSeconda mossa: scegli un processo e formalizzalo davveroTerza mossa: investi nelle persone, non solo negli strumentiLa parte che resta quando il rumore passaAI nella pubblica amministrazione: il pattern della commodityPrima di parlare di PA, vale la pena fermarsi un momento sul ciclo di vita di qualsiasi tecnologia abilitante. Perché l’AI sta percorrendo un percorso che non è nuovo, ed è utile riconoscerlo.Pensiamo all’email. Negli anni Novanta, avere la posta elettronica era un differenziatore. Chi ce l’aveva comunicava più velocemente, poteva coordinarsi meglio, aveva un vantaggio. Poi l’email è diventata standard. Oggi non vince chi “ha l’email”. Vince chi ha costruito un’organizzazione capace di usarla bene: con processi chiari, responsabilità definite, flussi di comunicazione che funzionano.Stesso pattern con il cloud. Prima era una scelta strategica, poi è diventata infrastruttura. Chi non ce l’ha è in difficoltà. Ma chi ce l’ha non vince automaticamente.Con l’AI succede la stessa cosa, solo più in fretta. I modelli migliorano rapidamente. I costi scendono. Le funzionalità AI entrano nelle suite che già usiamo (Microsoft 365, Google Workspace, i gestionali, i CRM). Diventano una feature, non un progetto. Diventano, appunto, commodity.Questo non significa che l’innovazione sparisce. Significa che la parte più visibile dell’AI, i modelli, le interfacce, i copiloti, è anche la parte più facile da copiare, integrare, standardizzare. Quando una tecnologia entra in quella fase, la domanda non è più “chi ha l’AI migliore”. Diventa: chi ha il contesto migliore per farla rendere.Il vero moat dell’AI è l’alimentazione dei datiC’è una metafora che uso spesso quando faccio formazione con i dipendenti pubblici. L’AI è un amplificatore. Come gli amplificatori audio: non crea suono dal nulla, prende quello che gli dai e lo ingrandisce. Se gli dai un segnale pulito, produce qualcosa di buono. Se gli dai rumore, amplifica rumore.Tradotto nelle organizzazioni: se l’AI lavora su dati affidabili, processi chiari e responsabilità definite, moltiplica efficienza e qualità. Se lavora su dati frammentati, processi impliciti e ambiguità organizzative, moltiplica il caos. Con un’aggravante rispetto al passato: l’errore non si limita a un KPI sbagliato su una dashboard. L’errore diventa un output plausibile, convincente, operativo. Un testo ben scritto ma fattualmente sbagliato. Una risposta al cittadino basata su un dato obsoleto. Una procedura automatizzata che replica un’eccezione come se fosse la regola.È qui che il concetto di “moat”, il fossato competitivo, si sposta. Quando il modello diventa commodity, resta in piedi ciò che non è replicabile. E ciò che non è replicabile in fretta è proprio il contesto informativo e operativo: dati accessibili, dati affidabili, dati con significato stabile, processi espliciti, ripetibili, misurabili, con responsabilità e controlli chiari.Non “i dati” in astratto. Non “i processi” scritti su una slide. Ma la capacità di mantenerli nel tempo, aggiornarli, governarli. Questa è la materia prima che manca nella maggior parte delle sperimentazioni che funzionano in demo ma non scalano in produzione.Dati e processi nella PA: il problema è la qualitàQualcuno potrebbe obiettare: ma la PA i dati li ha. Anagrafi, SUAP, atti, delibere, pratiche. Archivi che in alcuni casi risalgono a decenni fa. Terabyte di informazioni.Giusto. Ma c’è una differenza fondamentale tra “dati disponibili” e “dati affidabili”, tra “dati archiviati” e “dati utilizzabili”. E nella PA questa differenza è spesso abissale.Pensiamo ai problemi più comuni che chiunque abbia lavorato con i dati comunali conosce bene: codici fiscali duplicati o errati nell’anagrafe; pratiche SUAP chiuse “formalmente” ma con iter ancora aperti in altri sistemi; delibere protocollate senza allegati o con allegati non leggibili; dati di bilancio non riconciliati tra il gestionale finanziario e i report di controllo di gestione; informazioni su forniture, contratti, scadenze disperse in email, fogli Excel, sistemi verticali che non si parlano.Questo non è un problema tecnico risolvibile con un software. È il risultato di anni di sedimentazione organizzativa: cambi di sistema, migrazioni parziali, responsabilità frammentate, assenza di governance del dato. E, spesso, assenza di cultura del dato.Perché il punto è questo: non puoi comprare la qualità del dato come compri una licenza software. Puoi comprare uno strumento di data quality. Ma lo strumento non sostituisce le definizioni condivise, le regole di inserimento, i controlli periodici, la responsabilità, l’ownership. Queste cose richiedono tempo, disciplina e scelte organizzative. Sono, letteralmente, l’effetto cumulativo di anni di lavoro. E sono difficili da replicare in fretta.La qualità del dato non è un progetto, è un ritmo organizzativoChi ha vissuto davvero la Business Intelligence, non la “dashboard appesa al muro” ma la BI operativa collegata a decisioni reali, ha imparato una lezione che oggi vale oro: la qualità del dato non si “fa”, si mantiene.Non è un deliverable, è un ciclo continuo. Definisci le regole, misuri la qualità, correggi le anomalie, monitori nel tempo, aggiorni le definizioni quando cambiano le norme o i processi, gestisci le eccezioni, governi la ownership dei dati. E poi ricomincia.È una forma di igiene organizzativa. Proprio come l’igiene personale: non la “fai” una volta, la mantieni ogni giorno. E proprio perché è igiene, non fa hype. Non si presenta bene nelle slide dei convegni. Ma fa performance. Crea il substrato su cui l’AI può lavorare bene.Nella PA questo principio ha un corollario importante. Il Piano Triennale per l’Informatica nella PA, le linee guida AGID sull’interoperabilità, il paradigma “once only” del PNRR digitale, il modello dati del National Digital Twin (UK), la stessa architettura della PDND: tutte queste iniziative convergono, chi più chi meno esplicitamente, su una direzione. Serve governance del dato pubblica. Serve che ogni ente sappia quali dati ha, chi ne è responsabile, con quale qualità, con quali vincoli normativi (GDPR, codice dei contratti, normativa settoriale). Serve, in sostanza, la stessa igiene che la BI ha insegnato al settore privato da trent’anni.La differenza è che nella PA questa igiene si scontra con vincoli strutturali che il privato non ha: turn over del personale, assenza di figure dedicate alla data governance, silos organizzativi consolidati, sistemi verticali comprati in anni diversi che non dialogano. Non è un alibi: è un punto di partenza realistico da cui progettare.Perché chi viene dalla BI è già avvantaggiatoC’è una categoria di professionisti che, paradossalmente, è più pronta di molti “AI entusiasti” ad affrontare questa sfida: chi ha fatto BI sul serio.Non per nostalgia del passato. Ma perché chi ha costruito data warehouse, riconciliato fonti eterogenee, gestito definizioni condivise tra uffici che non si parlano, ha sviluppato tre competenze che nell’era AI sono strategiche.Ragionare per definizioni e semanticaLa BI insegna che senza definizioni condivise il dato è solo rumore. Cosa si intende per “pratica aperta”? Da quando si conta? Con quale stato? Chi decide? L’AI senza semantica produce testi eleganti ma scollegati dalla realtà operativa dell’ente. Il professionista BI sa che la prima domanda non è “come lo calcolo”, ma “cosa stiamo misurando esattamente”.Pretendere tracciabilità e controlliIn BI esistono concetti come data lineage, riconciliazione tra fonti, audit trail dei calcoli. In AI serve la stessa disciplina: quali fonti ha usato il modello, con quale versione dei dati, quali log ci sono, quali limiti ha l’output. Non per burocrazia, ma per affidabilità. Perché l’output di un sistema AI che serve un procedimento amministrativo deve essere verificabile, spiegabile, difendibile davanti al cittadino e al giudice amministrativo.Capire che il valore sta nei processi, non nelle risposteLa BI fatta bene è sempre stata collegata a una decisione e a un flusso: il report di fine mese non era fine a sé stesso, serviva al ciclo di budgeting, alla gestione delle forniture, al controllo di gestione. L’AI porta la stessa logica un passo oltre: non solo insight, ma azione dentro quel flusso. Ma se il flusso non esiste o non è formalizzato, l’insight non porta da nessuna parte.Per la PA la traduzione pratica è diretta: i casi d’uso AI più promettenti non sono quelli che creano funzioni nuove. Sono quelli che si innestano su processi già esistenti, ben definiti, con responsabilità chiare. Il supporto alla protocollazione, la categorizzazione automatica delle richieste, la verifica di coerenza nelle delibere, il monitoring delle scadenze PNRR: tutti processi che nella PA già esistono e che hanno bisogno di qualità del dato prima che di intelligenza artificiale.AI nella PA: una regola pratica per investire bene adessoSe l’AI diventa commodity, la strategia non è inseguire il modello più nuovo o la suite più integrata. È investire dove la commodity non basta. E il criterio è semplice, anche se difficile da seguire: prima metti ordine in dati e processi, poi automatizzi. Se automatizzi prima, automatizzi disordine.In termini operativi, per un ente pubblico questo si traduce in una sequenza precisa.Il primo passo è scegliere pochi use case di processo, non demo. Non “usiamo l’AI”, ma “usiamo l’AI per questa funzione specifica, in questo procedimento, con questi dati, per questo output”. La specificità non è un limite, è una condizione per il successo.Il secondo passo è costruire il set minimo di dati affidabili per quei casi. Non il dato perfetto, che non esisterà mai. Il dato “abbastanza buono” per quel caso d’uso specifico. Questo richiede di capire quali dati servono davvero, da dove vengono, chi li aggiorna, con quale frequenza, con quale qualità attuale.Il terzo passo è formalizzare regole, eccezioni e responsabilità. Chi decide quando l’output dell’AI è accettabile? Chi verifica? Chi corregge? Chi risponde in caso di errore? Queste domande non sono ostacoli all’innovazione: sono la condizione perché l’innovazione regga nel tempo e nella realtà operativa dell’ente.Il quarto passo è mettere i controlli: audit trail, log delle decisioni assistite, meccanismi di human-in-the-loop dove il rischio lo richiede. Non per frenare l’automazione, ma per renderla sostenibile. Anche dal punto di vista normativo: il Regolamento europeo sull’AI (AI Act) impone obblighi di trasparenza e supervisione umana per i sistemi AI ad alto rischio, e molti procedimenti amministrativi rientrano in questa categoria.Solo dopo questi quattro passi ha senso spingere sull’automazione. È meno “scenico” di lanciare un progetto AI con una presentazione di venti slide. Ma è ciò che crea vantaggio sostenibile.Cosa si può fare concretamente: tre mosse per partire beneNon si tratta di mettere tutto in ordine prima di toccare l’AI: quello richiederebbe anni e significherebbe aspettare a lungo. Si tratta di procedere in parallelo con intelligenza. Costruisci fondamenta e sperimenti insieme, ma sullo stesso territorio.Prima mossa: fai un inventario onesto dei tuoi dati più criticiNon serve un progetto di data governance da sei mesi. Serve una mappa di tre pagine: quali dati usi di più, chi ne è responsabile, con quale qualità reale (non teorica), con quali vincoli di utilizzo. Questa mappa è il punto di partenza per qualsiasi caso d’uso AI che voglia stare in piedi.Seconda mossa: scegli un processo e formalizzalo davveroPrendi un procedimento che vuoi automatizzare con l’AI e scrivilo per come funziona oggi: passi, responsabili, input, output, eccezioni, tempi. Non come dovrebbe funzionare: come funziona. Questa formalizzazione, spesso ritenuta noiosa, è il vero lavoro di design del sistema AI. Senza di essa, il modello di AI non saprà cosa fare con le eccezioni. E le eccezioni nella PA sono la normalità.Terza mossa: investi nelle persone, non solo negli strumentiIl PNRR ha messo miliardi sulla trasformazione digitale della PA. Una parte significativa è andata in infrastrutture e software. Una parte molto più piccola è andata sulla formazione delle persone che quelle infrastrutture devono usare e governare. Il risultato si vede: piattaforme adottate formalmente ma usate in modo parziale, processi digitali che replicano le logiche analogiche di prima. La cultura del dato, l’unica che permette di usare bene l’AI, non si scarica come un update. Si costruisce con formazione continua, esempi pratici, feedback sul campo.La parte che resta quando il rumore passaTra non molto, “avere l’AI” non sarà una differenza. Sarà la normalità, come avere un sito web, avere la firma digitale, avere la PEC. Nessuno dirà “siamo innovativi perché abbiamo Copilot”, così come oggi nessuno si vanta di avere l’email.La differenza la farà qualcos’altro: chi avrà dati affidabili, chi avrà processi governati, chi avrà costruito nel tempo un ritmo di qualità continua. Non la PA che ha il modello più recente, ma la PA che sa cosa dargli da mangiare.E qui la BI, quella vecchia e poco glamour, smette di essere il passato e diventa, paradossalmente, il prerequisito più moderno. Chi ha vissuto gli anni della qualità del dato, della governance, del lineage, è stato inconsapevolmente allenato per questa fase. Sa che il valore non sta nel tool, sta nel contesto in cui il tool opera.Alla fine, quando i modelli si assomigliano e le feature si commoditizzano, resta una sola domanda strategica. Non “quale AI usi”, ma: quanto è solido il tuo contesto informativo e operativo?Lì si decide se l’AI è un gadget dimostrativo per il prossimo convegno, o un moltiplicatore reale di capacità pubblica.






