Quando si parla di intelligenza artificiale nelle pubbliche amministrazioni, si finisce quasi sempre per discutere di tecnologia. Di modelli, algoritmi, piattaforme, chatbot. È comprensibile: la tecnologia è la parte più visibile, quella che si può mostrare in una riunione, quella che affascina e intimorisce insieme.
Il problema è duplice. Il primo errore è introdurre AI senza sapere perché. Il secondo — meno ovvio ma altrettanto grave — è introdurre AI quando non serve: quando il problema potrebbe essere risolto con una più semplice automazione di processo, più economica, più trasparente, più facile da controllare. Gli errori più gravi che un ente pubblico commette in questo campo non sono mai tecnici. Sono organizzativi, giuridici, procedurali. Riguardano la governance, i dati, le responsabilità. E riguardano, prima ancora, il fatto di non essersi chiesti se lo strumento scelto fosse davvero quello giusto.
Questo articolo nasce da una convinzione semplice: prima di introdurre qualsiasi sistema di intelligenza artificiale in un ente pubblico, vale la pena conoscere gli errori che quasi tutti commettono. Non per scoraggiare, ma per non dover imparare a proprie spese.
Gli errori più ricorrenti
1. Partire dalla tecnologia invece che dal problema
È l’errore più comune, e il più difficile da riconoscere perché spesso nasce da intenzioni genuine.
L’ente decide di “fare intelligenza artificiale”. Cerca un fornitore, valuta piattaforme, magari acquista un chatbot o una licenza per un assistente generativo. Poi, una volta acquistato, si chiede dove utilizzarlo.
È esattamente il contrario di come dovrebbe funzionare.
La domanda corretta non è “quale strumento AI possiamo usare?” ma “quale problema amministrativo concreto vogliamo risolvere?”. I tempi di smistamento del protocollo sono troppo lunghi? Le ricerche negli archivi documentali richiedono ore? I dirigenti non hanno una visione chiara sullo stato delle opere pubbliche? Si parte da qui, non dal prodotto.
Un sistema AI acquistato senza un problema chiaro alle spalle produrrà, nel migliore dei casi, un progetto vetrina. Nel peggiore, un impegno di risorse su qualcosa che nessuno usa.
2. Confondere intelligenza artificiale e automazione
Non tutto ciò che si può migliorare richiede intelligenza artificiale. Anzi, in molti casi l’AI è la risposta sbagliata a un problema che potrebbe essere risolto in modo più semplice, economico e trasparente.
Se arriva una richiesta tramite un modulo digitale in cui il cittadino ha selezionato “accesso agli atti”, assegnare automaticamente la pratica all’ufficio competente è un problema di workflow, non di intelligenza artificiale. Serve una regola semplice del tipo: se accade X, fai Y. Introdurre un modello AI per fare questa cosa significa aumentare la complessità, i costi, i rischi e la dipendenza dal fornitore, senza alcun beneficio reale.
L’AI diventa necessaria quando il problema è genuinamente complesso: leggere il testo libero di una PEC e capire a quale ufficio va assegnata anche se il cittadino ha usato parole imprecise, riassumere fascicoli lunghi, individuare anomalie non evidenti in dati contabili, classificare documenti non strutturati. In tutti gli altri casi, la soluzione più corretta è spesso quella più semplice.
La maturità digitale di un ente non si misura dalla quantità di AI introdotta, ma dalla capacità di scegliere consapevolmente lo strumento più adeguato al problema.
3. Trattare l’AI come un modulo software
L’AI non si installa come un gestionale. Non si configura una volta per tutte e non si dimentica nel cassetto.
Un sistema di intelligenza artificiale che lavora su dati pubblici, atti amministrativi, procedimenti, interazioni con i cittadini, è un sistema organizzativo, informativo, giuridico e tecnologico insieme. Cambia nel tempo. Sbaglia. Può produrre output incorretti. Dipende dalla qualità dei dati che gli vengono forniti. Richiede supervisione, manutenzione, aggiornamento.
Delegare tutto al fornitore e non occuparsene più è un errore che si paga caro, di solito quando è troppo tardi per rimediare facilmente.
4. Usare dati disordinati
Garbage in, garbage out. È una regola vecchia quanto l’informatica, ma nella pubblica amministrazione viene ignorata con una frequenza sorprendente.
Un sistema AI che lavora su atti e protocolli in cui lo stesso ufficio viene indicato con nomi diversi, in cui i fascicoli non sono chiusi, in cui le determine mancano di metadati corretti, in cui i regolamenti superati convivono con quelli vigenti senza distinzione, produrrà risposte fragili e inaffidabili. Non per un difetto del modello, ma perché i dati su cui si basa sono sporchi.
Prima di introdurre qualsiasi sistema AI, l’ente deve fare un lavoro che non è glamour ma è decisivo: censire le proprie banche dati, valutarne la qualità, pulirle, organizzarle, stabilire chi ne è responsabile e per quale finalità possono essere utilizzate.
5. Non sapere chi governa i dati
Nelle organizzazioni pubbliche i dati esistono, ma spesso nessuno sa con precisione chi ne è davvero responsabile. I dati “stanno nel gestionale”, ma chi garantisce che siano aggiornati? Chi autorizza il loro utilizzo per nuovi scopi? Chi risponde se vengono usati in modo improprio?
Per ogni banca dati rilevante, bisogna individuare un ufficio responsabile e una persona che la conosce davvero nella pratica quotidiana. Non servono titoli elaborati. Basta chiarire: questo dato è dell’ufficio tributi, lo gestisce il funzionario X, può essere usato per queste finalità e non per altre.
Senza questa chiarezza, un sistema AI finisce per usare dati senza che nessuno ne abbia davvero autorizzato l’utilizzo, e senza che nessuno possa rispondere se qualcosa va storto.
6. Collegare l’AI direttamente ai gestionali senza uno strato di controllo
Un errore tecnico con conseguenze molto pratiche.
Collegare un sistema AI direttamente alle banche dati di produzione, senza uno strato intermedio che filtri, controlli e registri gli accessi, significa rinunciare a qualsiasi forma di governo reale sul sistema. Chi ha chiesto cosa? Su quali dati? Quando? Con quale risultato? Se non c’è uno strato di log e controllo, queste domande restano senza risposta.
L’AI non deve “possedere” il dato. Deve interrogare dati governati dall’ente, attraverso connettori controllati, profili autorizzativi, ambienti separati. È una distinzione che sembra tecnica, ma è prima di tutto una scelta organizzativa e giuridica.
7. Decidere invece di supportare
Nella pubblica amministrazione esiste un confine che non si può attraversare senza conseguenze: quello tra supporto istruttorio e decisione amministrativa.
Un sistema AI può cercare atti, sintetizzare fascicoli, segnalare anomalie, proporre bozze di provvedimenti, suggerire l’ufficio competente per una pratica. Non può concedere benefici economici, formare graduatorie, negare istanze, irrogare sanzioni, sostituire il responsabile del procedimento.
Quando un sistema AI produce un output che poi viene recepito senza verifica in un atto amministrativo, il funzionario ha firmato qualcosa che non ha davvero valutato. L’atto può essere impugnato, il funzionario può rispondere a titolo personale, e il sistema AI – che non ha personalità giuridica – non risponde di niente.
La supervisione umana non deve essere dichiarata nei documenti e poi ignorata nella pratica. Deve essere reale: chi controlla, con quale frequenza, con quali competenze, cosa succede se l’output è errato.
8. Ignorare il rischio e trattare tutti i casi allo stesso modo
Ricercare una delibera del 2019 e decidere chi ha diritto a un contributo economico sono due operazioni radicalmente diverse dal punto di vista del rischio.
La prima è un’attività di supporto documentale, a rischio contenuto, il cui errore nel peggiore dei casi produce un risultato di ricerca impreciso che il funzionario verifica.
La seconda incide su diritti soggettivi di persone reali. Un errore può produrre discriminazioni, decisioni illegittime, contenziosi, danni patrimoniali ai cittadini e responsabilità per l’ente.
Prima di avviare qualsiasi progetto AI, bisogna classificarne il rischio. Non in modo accademico, ma in modo pratico: questo sistema può incidere su diritti, obblighi o situazioni soggettive di persone? Se la risposta è sì, le cautele devono essere proporzionalmente più forti: valutazione di impatto sulla protezione dei dati, supervisione umana rafforzata, tracciabilità, trasparenza verso i cittadini coinvolti.
L’AI Act europeo costruisce proprio su questo principio: l’intensità degli obblighi cresce con il livello di rischio. E alcune applicazioni sono semplicemente vietate.
9. Saltare il test reale
Una demo che funziona in sala riunioni non è un collaudo.
Il collaudo di un sistema AI deve essere sostanziale: si prendono casi reali, si sottopongono al sistema, si verificano le risposte. Le risposte sono corrette? Le fonti citate esistono e sono pertinenti? Il sistema inventa contenuti? Rispetta i profili di accesso? Gestisce correttamente i dati personali? Gli operatori capiscono quando fidarsi e quando verificare ulteriormente?
Solo dopo aver risposto positivamente a queste domande, in un ambiente separato dalla produzione, ha senso mettere in esercizio il sistema.
10. Non formare il personale
Un sistema AI consegnato agli uffici senza formazione produce quasi certamente uno di due risultati: iper-fiducia (gli operatori si fidano ciecamente degli output senza verificarli) o rifiuto (gli operatori non lo usano perché non si fidano e nessuno ha spiegato loro come funziona).
Il personale deve sapere cosa può fare il sistema e cosa non può fare. Deve sapere quando l’output va accettato, quando va verificato, quando va respinto. Deve sapere quali dati non caricare, come segnalare gli errori, quali responsabilità rimangono sempre in capo all’essere umano.
L’AI Act parla esplicitamente di alfabetizzazione AI come obbligo per chi impiega questi sistemi. Non è un requisito burocratico: è la condizione minima perché il sistema funzioni in modo responsabile.
11. Caricare dati pubblici su strumenti non contrattualizzati
Nella pratica quotidiana, molti dipendenti pubblici usano già strumenti AI generici, gratuiti o consumer, per riassumere atti, scrivere note, correggere testi. In molti casi, senza rendersene conto, caricano dati personali, documenti riservati, atti non pubblici, informazioni su contenziosi in corso.
Questo è un problema serio. I dati escono dal perimetro dell’ente, non c’è un contratto che garantisca il trattamento corretto, non c’è certezza su dove vengono conservati, se vengono usati per addestrare modelli generali, come possono essere cancellati.
Ogni ente dovrebbe adottare una policy interna sull’uso degli strumenti AI che distingua quelli autorizzati da quelli non autorizzati, e che stabilisca quali categorie di dati non possono in nessun caso essere condivise con sistemi esterni non governati.
12. Contratti deboli con il fornitore
Il fornitore non è un partner neutro. Ha interessi propri, che non necessariamente coincidono con quelli dell’ente.
Nel contratto devono essere chiariti almeno questi punti: dove vengono trattati i dati, se il fornitore può usarli per addestrare i propri modelli generali, chi conserva i log, come si esportano dati e configurazioni se si decide di cambiare fornitore, chi risponde degli errori tecnici, come vengono gestiti gli aggiornamenti del modello, quali misure di sicurezza sono adottate.
Un contratto vago su questi aspetti produce lock-in, opacità e una dipendenza che diventa molto difficile da sciogliere.
13. Non misurare i risultati
Un progetto AI senza indicatori di risultato è una promessa che non si può verificare. Prima dell’avvio bisogna stabilire cosa si vuole misurare: riduzione dei tempi di ricerca, accuratezza dello smistamento, numero di uffici che usano il sistema, qualità delle risposte, errori rilevati. Solo così è possibile capire se il progetto sta funzionando, se vale la pena estenderlo, o se è necessario correggerlo.
Un percorso ordinato: come fare le cose per bene
Dopo gli errori, il percorso. Non esiste una ricetta universale, ma esiste una sequenza logica che vale per quasi ogni ente pubblico, indipendentemente dalla dimensione.
Prima di tutto: decidere perché
Il punto di partenza è una decisione politica e amministrativa consapevole. La giunta o il vertice amministrativo devono chiarire perché vogliono introdurre l’AI, quali problemi vogliono risolvere, quali ambiti sono prioritari e quali invece – almeno inizialmente – devono restare fuori. Questa decisione va formalizzata in un atto, anche semplice: un documento di indirizzo che impegna l’ente e dà mandato a chi deve operativamente costruire il percorso.
Senza questo passaggio, ogni iniziativa successiva galleggia nel vuoto. Con questo passaggio, si ha una direzione.
Poi: capire cosa si ha
Prima di qualsiasi soluzione tecnica, l’ente deve fare un censimento serio del proprio patrimonio informativo. Quali banche dati esistono? Chi ne è responsabile? Sono aggiornate e affidabili? Contengono dati personali? Per quale finalità possono essere usate? Esistono connettori tecnici per accedervi?
Questo lavoro produce un catalogo delle banche dati comunali, che è il primo vero deliverable del progetto. Senza di esso, qualsiasi soluzione AI si costruisce su sabbia.
Quindi: scegliere pochi casi d’uso concreti
Non “fare AI su tutto”, ma scegliere due o tre problemi reali, descriverli in modo preciso, valutarne fattibilità e rischio.
Per un ente pubblico che parte da zero, il caso d’uso ideale è quasi sempre lo stesso: un sistema di ricerca intelligente su atti, delibere, determine, regolamenti e fascicoli documentali. È utile a tutti gli uffici, valorizza dati già disponibili, non prende decisioni al posto dell’amministrazione, e consente di sperimentare l’AI in un contesto controllato prima di estenderla ad ambiti più delicati.
I casi d’uso ad alto rischio – servizi sociali, graduatorie, benefici economici, controlli su singoli cittadini – vengono dopo. Non perché non siano importanti, ma perché richiedono una maturità organizzativa e una solidità dei dati che si costruisce nel tempo.
Poi si progetta, si testa, e solo allora si va in produzione
La fase tecnica – progettazione della soluzione con il fornitore, sviluppo, configurazione – arriva solo dopo aver chiarito obiettivi, dati e rischi. Segue una fase di sperimentazione in ambiente controllato, con casi reali ma separati dalla produzione, e un collaudo sostanziale che verifica la correttezza degli output, la sicurezza, la protezione dei dati, l’usabilità.
Solo a quel punto il sistema va in produzione. E non finisce lì: inizia il monitoraggio continuo, con indicatori definiti, procedure per gestire gli errori e aggiornamenti periodici delle fonti e della valutazione del rischio.
Chi fa cosa: ruoli interni e cosa delegare
Un ente pubblico di medie dimensioni non ha bisogno di creare una struttura dedicata all’AI. Ha bisogno di chiarire le responsabilità all’interno di quella che già esiste.
Lo sponsor istituzionale – il sindaco, l’assessore competente o il vertice amministrativo – dà l’indirizzo politico, approva obiettivi e risorse, e difende il progetto verso l’esterno. Senza questo ruolo, il progetto non ha legittimazione.
Il responsabile del progetto AI coordina l’intero percorso operativo. In un ente piccolo, questa figura può coincidere con il Responsabile per la Transizione al Digitale, con il segretario generale o con un dirigente incaricato. Non deve essere un tecnico: deve essere qualcuno che capisce l’organizzazione, sa coinvolgere gli uffici, sa tenere insieme obiettivi, tempi e fornitore.
Il RTD garantisce la coerenza con l’architettura ICT dell’ente, le regole di interoperabilità, la sicurezza, il collegamento con la piattaforma nazionale di interoperabilità. È il garante tecnico-istituzionale del percorso digitale.
I responsabili degli uffici sono i proprietari funzionali dei dati. Loro sanno cosa contengono le proprie banche dati, a cosa servono, quali dati sono affidabili e quali no. Il loro coinvolgimento non è opzionale: senza di loro, il censimento dei dati non si fa e i casi d’uso non vengono definiti correttamente.
I referenti operativi – funzionari e istruttori che usano quotidianamente i gestionali – conoscono la realtà concreta dei dati: le anomalie, le prassi non scritte, i problemi ricorrenti. Sono essenziali nella fase di test e collaudo, e sono i primi utenti reali del sistema.
Il DPO valuta le implicazioni privacy di ogni caso d’uso, verifica le basi giuridiche dei trattamenti, indica dove serve una valutazione di impatto e dove le cautele devono essere rafforzate. Non può essere coinvolto solo a progetto avanzato: deve entrare fin dalle prime fasi.
Il segretario generale presidia la legalità complessiva del percorso, il raccordo con i controlli interni, la coerenza con le responsabilità procedimentali. È il garante istituzionale che il progetto non derivi verso aree grigie sul piano amministrativo e giuridico.
Il RUP gestisce la procedura di affidamento al fornitore, il contratto, il collaudo e il controllo dell’esecuzione. È la figura che traduce i requisiti in obblighi contrattuali esigibili.
Prima di interagire col prossimo venditore di i.a.
L’introduzione dell’intelligenza artificiale in una pubblica amministrazione può produrre benefici concreti e misurabili. Meno tempo perso a cercare atti, maggiore capacità di monitorare procedimenti e opere pubbliche, supporto più efficace agli operatori, servizi più accessibili ai cittadini. Ma questi risultati si ottengono solo percorrendo una strada precisa: partire dai problemi reali, non dagli strumenti; costruire sui dati, non sulle aspettative; definire responsabilità chiare prima ancora di scrivere un capitolato.
La domanda che ogni ente dovrebbe porsi prima di qualsiasi decisione non è “come possiamo usare l’AI?” ma “qual è lo strumento più adatto a risolvere questo problema?”. A volte la risposta è un sistema di intelligenza artificiale. Spesso è un workflow digitale, una regola di instradamento automatico, un alert su una scadenza, una dashboard costruita su dati già disponibili. Scegliere lo strumento sbagliato — anche se più sofisticato, anche se più di moda — non è innovazione. È spreco, e nella PA è spreco di risorse pubbliche.
Quando l’AI è davvero la risposta giusta, il percorso per introdurla richiede tempo, rigore e coinvolgimento interno che molti sottovalutano. Non si tratta di acquistare una licenza e aspettare i risultati. Si tratta di censire i dati, pulirli, governarli; di scegliere casi d’uso proporzionati al rischio; di testare prima di mettere in produzione; di formare chi userà il sistema ogni giorno; di presidiare nel tempo qualcosa che cambia e può sbagliare.
Il fornitore può costruire la soluzione tecnica. Ma il governo del sistema — le regole, i controlli, i log, la supervisione sugli output, le decisioni su cosa il sistema può e non può fare — deve restare in capo all’amministrazione. Sempre.
La maturità digitale di un ente pubblico non si misura dalla quantità di intelligenza artificiale che ha introdotto. Si misura dalla capacità di scegliere consapevolmente: quando serve l’AI, quando basta un’automazione più semplice, quando la priorità è riordinare i processi prima ancora di automatizzarli. Questa consapevolezza non è tecnica. È amministrativa, nel senso più pieno del termine.