Ormai i fornitori entrano negli enti parlando di “AI”, perché è la parola che apre porte e budget. Ma se sotto non ci sono processi, dati, interoperabilità e persone pronte al cambiamento, l’AI resta una demo: bella, fragile, e spesso inutile.
O un chatbot, di facciata ma poco impattante. La posta in gioco non è “avere l’AI”, è far funzionare l’automazione intelligente senza rompere qualità, sicurezza e fiducia, e un rapporto tra tecnologia e umani che è sempre stato di supporto e collaborazione.
Indice degli argomenti
Il problema reale: processi rotti che l’AI non può risolvere da sola
La scena è familiare. Riunione con un dirigente: “Vogliamo usare l’AI per velocizzare le pratiche”. Dopo dieci minuti emerge il paradosso: la pratica non è “lenta” perché manca l’AI, è lenta perché il flusso è pieno di eccezioni, passaggi manuali e responsabilità sfumate. Il dato che serve per decidere sta in tre gestionali diversi, un file Excel “del settore”, e una PEC stampata e protocollata. Nel mezzo, ci sono software che non si parlano e persone che fanno da ponte con copia-incolla come fossero interoperabilità umana.
Si parte da “usare l’AI” (aziendale/ente, personale, o, peggio, AI privata non governata), ma il cuore è l’Intelligent Automation, e attorno ci sono i mattoni veri: processi e procedure, interoperabilità (PDND), cultura del dato, continuous quality, privacy e cybersecurity, più la fascia spesso sottovalutata: persone e gestione del cambiamento.
Qui inciampa la PA locale: si compra l’etichetta “AI” e si scopre che l’organizzazione sotto non regge. E quando non regge, l’AI non “aiuta”: amplifica il disordine. Automatizzare un processo rotto significa farlo girare più veloce se è più veloce nella direzione sbagliata.
L’AI nella PA locale oggi: tra uso personale e rischio di sistema
L’AI ha abbassato la soglia d’ingresso: anche un ufficio può “provare” in pochi minuti a realizzare un progetto, un documento, una bozza, un piccolo software. Questo però produce un effetto collaterale potente: la nascita di un’AI parallela, usata “di testa propria” (AI personale) o addirittura su strumenti esterni (AI privata), con rischi immediati su dati, trasparenza e responsabilità.
In un Comune, “non è solo tecnologia” per un motivo semplice: ogni attività è un intreccio di procedura, atto, responsabilità e tracciabilità. Se l’AI entra come scorciatoia, va subito a sbattere contro tre muri:
Il primo è organizzativo: chi decide cosa si può automatizzare, con quali controlli, e con quale presidio?
Il secondo è informativo: senza dati coerenti e reperibili, l’AI diventa un esercizio di stile o un generatore di risposte plausibili ma non verificabili.
Il terzo è sistemico: se i software non dialogano, si “automatizza” solo la superficie, lasciando intatto il lavoro manuale nel back-office.
Ecco perché, nel grafico, la freccia “Aspetti organizzativi” non è un dettaglio: è l’innesco. L’AI è un acceleratore; ma prima serve lo sterzo.
Cosa cambia davvero: meccanismi, non slogan
“Intelligent Automation” non significa “mettere un chatbot allo sportello”. Significa ripensare un pezzo di catena del valore: dalla richiesta del cittadino, alla lavorazione interna, fino all’esito. E farlo combinando tre ingredienti, ciascuno con i suoi trade-off.
Processi chiari: BPMN e BPR come punto di partenza
Mappare i flussi non è burocrazia: è scoprire dove si annida il lavoro non dichiarato. Il trade-off è evidente: richiede tempo e può far emergere conflitti (“chi firma cosa”, “chi controlla cosa”, “quali sono gli edge case”, “davvero è tutto così particolare?”). Se lo fai male, crei diagrammi perfetti che nessuno usa. Se lo fai bene, riduci eccezioni e rendi l’automazione possibile.
Dati e interoperabilità: la PDND come leva concreta
Se l’informazione resta “silos per ufficio”, l’automazione intelligente si ferma al copia-incolla. L’interoperabilità non serve per “fare moderni”: serve per ridurre passaggi manuali e aumentare affidabilità. Trade-off: integrazioni e responsabilità sui dati richiedono governance (chi è titolare del dato, chi lo aggiorna, chi risponde degli errori). Se lo fai male, moltiplichi punti di rottura e scarichi il problema su un Excel “di riconciliazione”.
Qualità continua e gestione del cambiamento
Nel grafico compaiono “Continuous Quality” e, accanto, un blocco che vale più di molte piattaforme: OKR, continuous learning, rumor filtering, soft skill. Tradotto: obiettivi misurabili, formazione continua, anticorpi contro la disinformazione interna (“l’AI ci sostituisce”, “l’AI decide al posto nostro”), e capacità di lavorare in modo nuovo.
Trade-off: serve leadership e costanza. Se lo fai male, ottieni resistenza passiva: l’AI resta “il progetto dell’ICT” e in ufficio si torna alle vecchie abitudini.
Il punto è qui: l’AI è utile quando smette di essere “un oggetto” e diventa un pezzo del sistema operativo dell’ente. Con ruoli, regole, integrazioni, controlli.
Due scenari concreti in comune
Un uso tipico che “sembra AI” è: riassumere PEC, estrarre informazioni, preparare bozze di risposta o di atto. Funziona, ma solo se sotto ci sono binari.
Scenario 1 – Dal testo all’atto: automazione intelligente su comunicazioni e istruttorie
Operativamente, l’ente deve decidere: dove entra il testo (protocollo, gestione documentale), dove si conserva la bozza, chi valida, come si tracciano le fonti. Senza questi passaggi, la bozza diventa un file volante.
Il valore vero non è “scrivere più veloce”: è ridurre variabilità e aumentare completezza (checklist automatiche, campi obbligatori, richiamo delle norme interne, standard di linguaggio).
Il rischio, se si corre, è doppio: da un lato il personale usa AI personali o esterne e incolla contenuti non verificati; dall’altro si produce un atto “ben scritto” ma con presupposti sbagliati, perché il dato di partenza era incompleto o non aggiornato.
Qui l’AI va trattata come un assistente: propone, non decide. E soprattutto deve lavorare su basi documentali governate (archivio, versioning, tracciabilità).
Scenario 2 – Back-office che respira: interoperabilità e automazione dei passaggi ripetitivi
Il secondo scenario è meno “wow”, ma spesso più impattante: togliere attrito ai passaggi ripetitivi tra uffici e sistemi.
Esempi: acquisire automaticamente dati già presenti in altre banche dati, precompilare campi, instradare pratiche in base a regole, segnalare incongruenze prima che diventino richieste di integrazione al cittadino. Il data entry per certi aspetti.
Qui l’AI può entrare in modo pragmatico: classificare richieste, individuare priorità, suggerire assegnazioni, riconoscere allegati mancanti. Ma la condizione è che esistano processi standard e integrazioni (anche progressive) tra sistemi, e che la qualità sia monitorata: se l’algoritmo sbaglia classificazione, serve un circuito di correzione, non una lamentela in corridoio.
Il rischio, se lo fai male, è la “automazione del caos”: notifiche ovunque, regole incoerenti, eccezioni non gestite. Alla fine gli operatori disattivano tutto e tornano al manuale.
Rischi e false scorciatoie: privacy, sicurezza, competenze e procurement
Il rischio più sottovalutato oggi non è “l’AI sbaglia”: è l’uso non governato. Nel grafico c’è una distinzione utile: AI dell’ente, AI personale, AI privata. In un Comune questa distinzione deve diventare politica interna, non un dibattito astratto.
La scorciatoia tipica: “intanto proviamo con account personali”. È la strada più breve verso problemi di protezione dati, perdita di controllo sui contenuti trattati, assenza di tracciabilità. Anche quando non succede nulla di eclatante, si crea una zona grigia: nessuno sa cosa entra, cosa esce, e con quali criteri.
Poi c’è il rischio procurement: comprare “la piattaforma AI” come se fosse una stampante. In realtà stai acquistando un pezzo di processo e di governance. Se nel capitolato non ci sono requisiti su integrazione, auditabilità, logging, gestione dei ruoli, e modalità di addestramento/uso dei dati, ti ritrovi con un oggetto costoso che non si innesta nei sistemi e nelle responsabilità dell’ente.
Infine le competenze: non serve che tutti diventino data scientist, ma serve una triade minima che spesso manca: process owner (RTD o responsabile di settore — chi governa il flusso), ICT/integrazione (chi fa parlare i sistemi), DPO e sicurezza (chi imposta i paletti e i controlli). Se manca uno dei tre, “si rompe” qualcosa: o l’ufficio non adotta, o l’ICT non integra, o si apre un buco di rischio.
La via praticabile: roadmap in tre mosse
Una roadmap realistica per un Comune non parte dall’AI: parte da un perimetro chiaro e cresce per cicli.
Fase 1 – Mettere in sicurezza l’uso e scegliere un perimetro
Definisci regole: cosa si può fare con AI personale, cosa no; quali dati non devono uscire; quali strumenti sono autorizzati. Scegli 1 processo con volumi e dolore reale, e mappalo senza pietà: dove si inceppa, dove si duplica, dove manca il dato.
Fase 2 – Sistemare le fondamenta: processi, dati, integrazioni essenziali
Qui entra il lavoro “sotto”: BPMN/BPR per standardizzare, prime integrazioni dove serve (anche minime), definizione del dato “fonte” e del dato “copia”. Attiva controlli di qualità: errori tipici, tempi, eccezioni.
Fase 3 – Automatizzare in modo intelligente e misurare
Solo ora l’AI diventa leva: assistenza su testi e istruttorie, classificazione richieste, suggerimenti, controlli. Ma sempre con un loop di validazione e miglioramento continuo (continuous quality), e obiettivi chiari (OKR) che dicano se stai davvero migliorando o stai solo “giocando con l’AI”.
L’AI funziona solo quando il sistema è già governato
L’AI, nei Comuni, funziona quando smette di essere una promessa e diventa un acceleratore di un sistema già governato: processi leggibili, dati affidabili, software interoperabili, persone accompagnate. Se provi a costruire dall’alto, l’AI ti regala una cosa sola: velocità nel fare confusione.
La domanda, allora, è semplice e scomoda: nel tuo ente, oggi, l’AI sta migliorando un processo… o sta solo coprendo un problema che non avete ancora deciso di affrontare?
