C’è una scena che, chi lavora a contatto con i Comuni, ha imparato a riconoscere. Un funzionario apre il browser, va su ChatGPT, incolla un testo, ottiene una risposta. Non lo sa il fornitore del gestionale. Non risulta a nessun registro. Non è autorizzato da nessuna delibera. Eppure funziona, risolve un problema reale, fa risparmiare mezz’ora.
Questa è la shadow AI nella pubblica amministrazione italiana: non un fenomeno di nicchia, non una curiosità da convegno, ma una pratica diffusa, silenziosa e, soprattutto, rivelatrice.
Rivelatrice di cosa? Che la PA è pronta. Non universalmente, non ovunque allo stesso modo, ma molto più di quanto i soliti discorsi sul dipendente pubblico refrattario al cambiamento lascino intendere. Chi usa la shadow AI lo fa perché ha capito che certi strumenti funzionano, che il suo lavoro può essere fatto meglio, che c’è un’alternativa al copia-incolla manuale di dati tra sistemi che non si parlano.
La shadow AI è, in questo senso, un segnale di mercato. Non va criminalizzata, va capita. E ci dice che la domanda di automazione esiste, è robusta, e ha radici molto più concrete di qualsiasi piano strategico triennale.
Indice degli argomenti
Non è un lusso. È sopravvivenza
Dietro la shadow AI non c’è solo curiosità tecnologica. C’è un problema strutturale che la PA locale conosce bene e che raramente viene detto con la necessaria chiarezza: il personale si riduce, gli adempimenti no.
I dati parlano chiaro. Negli ultimi quindici anni i Comuni italiani hanno perso una quota significativa di organico, tra blocchi del turn-over, pensionamenti non sostituiti e vincoli di spesa che hanno ristretto i margini di assunzione. Nel frattempo le competenze richieste si sono moltiplicate: PNRR, transizione digitale, GDPR, nuove norme in materia di appalti, rendicontazioni sempre più articolate. L’effetto netto è che gli stessi uffici devono fare di più, con meno persone.
In questo contesto, l’automazione non è una scelta strategica da inserire nel Piano Triennale per l’Informatica. È una necessità operativa quotidiana. Chi usa ChatGPT per redigere una determina, o un foglio Excel per automatizzare un calcolo che prima faceva a mano, non sta sperimentando: sta sopravvivendo. E lo sta facendo con gli strumenti che ha, nel modo più pragmatico possibile.
Questa è la PA reale. Non quella dei convegni, quella degli uffici. E quella PA, a suo modo, è già avanti.
Il paradosso del PNRR: i fondi ci sono stati, la visione no
Se la PA ha fame di automazione, viene naturale chiedersi: e i fornitori? Dove sono le software house che negli ultimi tre anni hanno beneficiato di flussi di investimento pubblico senza precedenti?
La risposta è scomoda. I fornitori della PA locale, nella maggioranza dei casi, hanno usato il PNRR come una rendita, non come un’opportunità di trasformazione. Il meccanismo è stato semplice: i bandi arrivano, i contratti si firmano, i SAL avanzano, i pagamenti arrivano. Fine. Nessun incentivo reale a innovare il prodotto in ottica API, a ragionare in termini di ecosistema e interoperabilità. Il contratto è firmato. Perché fare di più? (A onor del vero qualcuno ci ha provato, ma non in ottica interoperabilità, tra poco vedremo perché)
Il risultato è un mercato bloccato in una configurazione paradossale: da un lato una PA che ha sviluppato competenze e appetito per gli strumenti AI, dall’altro un ecosistema di fornitura rimasto ancorato alla logica del gestionale chiuso, del dato ingabbiato, del formato proprietario. La PA vuole correre. I fornitori hanno costruito muri.
Non si tratta di malafede. Si tratta di incentivi. E di una governance degli appalti pubblici che, fino ad oggi, non ha mai reso l’apertura tecnologica un criterio di aggiudicazione rilevante.
Tredici software house, uno Swagger, dieci silenzi
Potrei continuare con l’analisi di sistema. Ma preferisco un dato concreto, perché certi numeri valgono più di mille parole.
Nell’ambito di un progetto di integrazione tra sistemi gestionali comunali, ho contattato tredici software house. L’obiettivo era semplice: capire se fosse possibile realizzare un’integrazione via API, e per farlo avevo bisogno della documentazione tecnica di base, cioè uno Swagger ad esempio, il formato standard per descrivere le API REST. Niente di esoterico, niente di straordinario: è la normalità nel mondo dello sviluppo software moderno.
Ecco com’è andata. Una software house ha mandato lo Swagger. Una ha risposto chiedendo cosa intendessi per Swagger (non è una battuta). Una ha detto che ci sta lavorando. Le altre dieci non hanno risposto.
Dieci su tredici. Silenzio. Non un rifiuto, non una spiegazione tecnica, non un ‘la nostra architettura non lo prevede’. Silenzio.
Questo non è un problema tecnico. Un problema tecnico si risolve con risorse e tempo. Questo è un problema culturale e di mercato: l’interoperabilità non è percepita come un valore, non è richiesta dai contratti, non è attesa dai clienti. Quindi non esiste.
Il catalogo API di ACN: tutto giusto, ma siamo su un altro pianeta
Qualcuno, a questo punto, potrebbe obiettare: ma esiste il catalogo di ACN che obbliga ad esporre API per essere catalogati. Esistono le linee guida di interoperabilità del Piano Triennale. Esiste il Modello di Interoperabilità della PA italiana, con le sue specifiche tecniche, i suoi profili di interazione, i suoi standard.
Tutto vero. Ed è tutto meritorio. Il problema è la distanza siderale tra quella documentazione e il gestionale del Comune di Rocca di Fianco, o di Castello di Mezzo, o di qualsiasi altro ente sotto i cinquemila abitanti che ha acquistato il suo software vent’anni fa da un fornitore locale che nel frattempo è stato acquisito tre volte.
Il catalogo di ACN è un punto di arrivo. Ma noi siamo ancora fermi alla partenza. O meglio: siamo alla partenza di una gara in cui alcuni corridori stanno dormendo nell’area riscaldamento.
La visione c’è. L’infrastruttura normativa c’è. Manca il collegamento con la realtà operativa dei Comuni.
Un n8n per la PA: la soluzione che esiste, se ci sono le API a cui agganciarsi
La soluzione tecnica, per chi conosce il mondo degli strumenti di automazione, esiste ed è relativamente accessibile. Strumenti come n8n, Make o equivalenti open source permettono di costruire flussi di automazione visuale tra sistemi diversi, senza dover scrivere codice personalizzato per ogni integrazione. Sono la risposta concreta alla domanda: come faccio a far parlare il mio gestionale tributi con il mio software dei pagamenti se non ho le API?
Il problema è che questi strumenti hanno bisogno di API a cui agganciarsi. Senza API, n8n è un martello senza chiodi. Puoi costruire il flusso più bello del mondo, ma se i dati sono chiusi dentro un sistema che non espone nulla, il flusso si ferma davanti a un muro. Si pensi invece se oltre ad Asana, Slack o Google potessi collegare Maggioli, APK, Halley, Dedagroup o altri.
Ecco perché il problema dei dieci silenzi non è solo una questione di fastidio operativo. È un collo di bottiglia sistemico. La PA è pronta ad automatizzare. Gli strumenti per farlo esistono e sono maturi. Ma il presupposto fondamentale, cioè che i sistemi esistenti espongano i dati in modo accessibile, non è soddisfatto. E non lo sarà finché non cambiano gli incentivi.
Cosa si può fare davvero
Non basta diagnosticare. Proviamo a indicare alcune direzioni praticabili, anche se nessuna di esse è semplice o immediata.
Clausole API-first nei nuovi contratti
Il punto di leva più efficace è nei contratti. Ogni nuovo affidamento di software gestionale per la PA dovrebbe includere, come requisito minimo obbligatorio, la disponibilità di API documentate secondo standard aperti. Non come optional, non come futura roadmap: come condizione di aggiudicazione. Se il fornitore non espone API, non vince la gara. Semplice in teoria. Difficile in pratica, perché richiede stazioni appaltanti competenti e capitolati tecnici che oggi quasi nessun Comune piccolo o medio riesce a redigere da solo.
Il ruolo di ACN e AgID nella pressione sul mercato
ACN e AgID hanno gli strumenti normativi per creare pressione sul mercato. Le linee guida di interoperabilità potrebbero diventare requisiti vincolanti per l’iscrizione al mercato elettronico della PA, o per accedere a determinati fondi. Non si tratta di sanzionare chi non ha le API oggi, ma di creare un percorso chiaro e obbligatorio verso l’apertura, con scadenze realistiche ma non rinviabili.
Community di RTD che condividono swagger e integrazioni
Nel frattempo, dal basso, qualcosa si può fare. I Responsabili per la Transizione al Digitale dei Comuni italiani sono spesso soli, con risorse limitate e problemi identici. Una community strutturata, che permetta di condividere documentazione API ottenuta faticosamente, flussi di automazione già testati, esperienze di negoziazione con i fornitori, moltiplicherebbe il valore di ogni singola conquista. Le altre centrali di committenza possono giocare un ruolo importante in questa direzione.
Una notizia che vale la pena di dire ad alta voce
Siamo abituati a parlare della PA come del soggetto lento, refrattario, ingessato. È un frame che ha una sua utilità narrativa, ma che in questo momento descrive male la realtà.
La PA, o almeno una parte significativa di essa, è già avanti. Ha capito che ha bisogno di automatizzare. Sa che non può permettersi di fare le stesse cose con sempre meno persone senza cambiare i processi. Sta usando, spesso in modo non ufficiale, strumenti AI che funzionano. Sta chiedendo ai fornitori di aprire le API e riceve silenzi.
Il collo di bottiglia non è più la PA. È il mercato della fornitura software, viziato da anni di appalti senza requisiti tecnici ambiziosi, che ha smesso di innovare perché non ne aveva bisogno.
Dieci silenzi su tredici non sono una statistica. Sono una fotografia. E quella fotografia dice che il problema, questa volta, non è a casa del Comune.
La buona notizia è che il problema è identificato, e che gli strumenti per risolverlo esistono. Contratti migliori, pressione normativa, community di pratiche, gare aggregate. Non servono rivoluzioni. Serve volontà.
Nel frattempo, nei Comuni, qualcuno sta ancora aprendo ChatGPT in una finestra del browser che non compare nei log aziendali. Sta risolvendo un problema reale. E aspetta, giustamente, che il sistema si metta al passo.
Partecipa alla community