L’Agenzia per l’Italia Digitale (AgID), l’ente tecnico della Presidenza del Consiglio che guida la digitalizzazione del settore pubblico, il 9 novembre 2026 ha adottato con la determinazione del Direttore generale n. 169 le Linee guida per l’adozione di intelligenza artificiale nella pubblica amministrazione. Sono centoquaranta pagine in undici capitoli, rivolte alle amministrazioni, ai gestori di servizi pubblici e alle società a controllo pubblico.
L’iter è quello dell’articolo 71 del Codice dell’amministrazione digitale (CAD, il decreto legislativo 82/2005), quello con cui AgID detta le regole tecniche: consultazione pubblica, parere della Conferenza unificata fra Stato, Regioni ed enti locali, Garante per la protezione dei dati personali. La determina non fissa una data di entrata in vigore né un termine di adeguamento: adotta il testo e ne dispone la pubblicazione, con invio del comunicato alla Gazzetta Ufficiale.
Il linguaggio, però, è prescrittivo. Le Linee guida avvertono che “deve” indica un requisito obbligatorio, “dovrebbe” una scelta da cui ci si discosta solo dopo averne valutato le implicazioni, “può” una facoltà.
Indice degli argomenti:
Che cosa chiedono le Linee guida
Il documento chiede anzitutto di classificare ogni sistema secondo le categorie di rischio indicate dall’AI Act, il regolamento europeo 2024/1689 sull’intelligenza artificiale. Introduce, poi, un modello organizzativo fondato sul ciclo cd. “PDCA” (Plan-Do-Check-Act: pianifica, esegui, verifica, correggi) e su alcune pratiche della ISO/IEC 42001, la norma internazionale sui sistemi di gestione dell’AI, indicata come «riferimento metodologico» e non come certificazione obbligatoria.
Il coordinamento della strategia sull’AI e la responsabilità della sua gestione spettano al Responsabile per la transizione digitale (RTD), la figura dirigenziale che il CAD impone a ogni amministrazione. L’RTD opera con il proprio ufficio, in collaborazione con il Responsabile della protezione dei dati e con il referente per la cybersicurezza. Le Linee guida gli attribuiscono due compiti ben definiti: assicurare che i sistemi siano conformi alla normativa e riferire agli organi di vertice dell’ente su prestazioni, controlli ed evoluzione dei sistemi.
Dove l’uso dell’AI è particolarmente intenso, l’ente può istituire anche un responsabile dell’intelligenza artificiale, che opera secondo le direttive dell’RTD. Completano il quadro gli obblighi su analisi di costi e benefici, indicatori di prestazione per ciascun caso d’uso, formazione del personale, qualità dei dati e sicurezza informatica.
Il nodo: sorvegliare ciò che non si riesce a rileggere
D’altro canto, la legge 132/2025, la legge italiana sull’intelligenza artificiale, stabilisce all’articolo 14 che nelle amministrazioni l’AI opera in funzione strumentale e di supporto all’attività provvedimentale, e che è la persona a rimanere l’unica responsabile dei provvedimenti e dei procedimenti. Le Linee guida riprendono il principio secondo cui la responsabilità ultima «rimane in capo alla PA», «qualunque sia il livello di automazione previsto», e va garantito «un livello adeguato di sorveglianza umana», tale da consentire «verifica, correzione o sostituzione da parte di personale umano».
Il principio è chiaro. La sua praticabilità lo è meno, proprio dove l’AI serve di più. Lo smistamento della posta certificata di un grande ente, la pre-istruttoria delle pratiche edilizie, l’esame delle domande per l’ottenimento di contributi sono attività nelle quali la macchina aiuta perché i numeri sono grandi. Con quei numeri il riesame di ogni singolo risultato è impossibile o, quanto meno, rischia di annullare il beneficio.
Se il funzionario deve rileggere o controllare tutto, tanto valeva non automatizzare. Se non rilegge, firma soltanto, ma in questo caso continua a rispondere di ciò che non ha potuto verificare.
Su questo punto il testo non è esaustivo. Il paragrafo sulle misure di sorveglianza riguarda i soli sistemi ad alto rischio e chiede «procedure e strumenti per assicurare il monitoraggio, l’interpretazione e, dove necessario, l’intervento umano». Affida la sorveglianza all’RTD e al suo ufficio, insieme al responsabile della protezione dei dati e al referente per la cybersicurezza. Non offre criteri su volumi, campionamento o tempi di verifica.
Si legge in questa scelta un’indicazione implicita: la sorveglianza che le Linee guida hanno in mente è quella sul sistema, non sul singolo atto. Il dubbio è che in questo modo residui, però, uno scarto con la legge: chi sorveglia non firma, e chi firma non sorveglia.
Dal controllo dell’atto al controllo del sistema
In verità, l’aggettivo «adeguato», sopra evidenziato, va riempito con il criterio di proporzionalità, magari utilizzando alcuni, pochi strumenti.
- Il primo è lavorare sugli esiti, distinguendo i diversi casi che possono prodursi. In altri termini, per gli esiti favorevoli e gli atti vincolati basta un controllo a campione; per quelli sfavorevoli o discrezionali, andrebbero esaminati tutti da un funzionario.
- Il secondo è fissare in anticipo una soglia di errore. Chi esegue i controlli a campione registra le proposte sbagliate; se la loro quota supera la soglia, l’automazione si sospende e le pratiche tornano a essere esaminate una per una, finché la causa non è individuata. Chi misura e chi decide la sospensione va stabilito, come ovvio, prima.
- Il terzo è riservare i casi dubbi al funzionario: le pratiche incomplete, quelle al limite dei requisiti e le situazioni insolite vanno sempre esaminate da una persona. I criteri si fissano prima e non si lasciano decidere alla macchina.
- Il quarto è calcolare quanto tempo serve per controllare davvero. Se ogni verifica richiede dieci minuti e a un funzionario arrivano ottanta pratiche al giorno, non può esaminarle, può solo approvarle. Quante pratiche affidare a ciascuno va deciso in base a quel tempo.
Questo potrebbe, ad esempio, dare corpo al concetto di “livello adeguato di sorveglianza umana”.
C’è poi il riesame a richiesta, che le Linee guida disciplinano con precisione maggiore del controllo preventivo. Le amministrazioni devono indicare procedure, canali e tempi di risposta per opporsi a una decisione automatizzata, e garantire la revisione da parte di un operatore umano che possa modificarla. È la traduzione in termini operativi di quanto il Consiglio di Stato aveva affermato già nel 2019, decidendo sull’algoritmo della mobilità dei docenti: la decisione deve restare conoscibile e imputabile a qualcuno.
Questi strumenti possono essere raccolti in un unico atto organizzativo, che indichi chi sorveglia il sistema e quale verifica si può ragionevolmente chiedere al funzionario che adotta il provvedimento. Così la sorveglianza che le Linee guida affidano all’RTD si salda con la responsabilità personale che la legge 132 lascia a chi decide.
Prima della tecnologia: esigenze, persone, formazione
Prima di scegliere uno strumento, le Linee guida chiedono di chiarire a che cosa serve: quale bisogno deve soddisfare, quanto costa, che cosa fa risparmiare e se esistono alternative migliori, come già prevede il CAD. È il passaggio più facile da saltare in fase di programmazione: il rischio è che si parta dallo strumento disponibile e gli si cerca un impiego all’interno della propria organizzazione.
Sul personale il testo è, per così dire, ottimista. L’AI automatizza attività ripetitive «liberando tempo di lavoro per attività a maggior valore». Le Linee guida non possono dire quante persone servano: dipende da ciascun ente; tuttavia, non chiedono all’ente di valutarlo. L’impatto sull’organizzazione compare solo come indicatore facoltativo, non come verifica da fare prima di adottare un sistema: quali mansioni cambiano, quali competenze si perdono.
Per una valutazione lucida e obiettiva dovremmo chiederci che cosa accade alla capacità di controllare la macchina quando nessuno svolge più, in prima persona, il lavoro che la macchina fa. Tema, in realtà, di grande rilevanza in tutti gli ambiti di utilizzo importante di strumenti di intelligenza artificiale.
Sulla formazione gli obblighi ci sono. Deve essere differenziata e proporzionata al ruolo, documentata, inserita nel PIAO, il Piano integrato di attività e organizzazione con cui ogni ente programma annualmente obiettivi e risorse. Il livello minimo richiesto coincide con i corsi di Syllabus, la piattaforma di formazione digitale della Funzione pubblica.
È alfabetizzazione, ma a chi deve contraddire un sistema serve qualcosa di più. E la legge 132 chiede di provvedere senza nuovi fondi, con le risorse già disponibili: in pratica la piattaforma gratuita e i bilanci dei singoli enti.
Le competenze attorno al progetto
Le Linee guida riconoscono che la gestione dell’AI richiede «un insieme multidisciplinare di conoscenze», dall’informatica al diritto delle tecnologie, fino alla sociologia e alla filosofia. Elencano, accanto ai profili tecnici, il giurista chiamato a occuparsi della «redazione e revisione dei relativi contratti e licenze» e dei «profili di responsabilità», e figure dedicate al disegno organizzativo e alla gestione del cambiamento.
Queste competenze compaiono però nel capitolo sulla formazione, come profili da coltivare. Il governo del progetto resta, in verità, una questione prevalentemente tecnica. Eppure, il testo stesso avverte che affidarsi a un fornitore non esonera l’ente: servono competenze per «formulare il fabbisogno dell’organizzazione e governare le partnership».
Molte delle questioni decisive si risolvono nel contratto: chi sopporta le conseguenze di un errore, chi accede alle registrazioni delle operazioni, che cosa accade se il fornitore cambia modello, a quali condizioni si può uscire. L’AI Act aggiunge che l’ente che modifica in modo sostanziale un sistema ad alto rischio, o ne cambia la finalità, assume gli obblighi del fornitore, obblighi più pesanti del cd. deployer.
Da quanto detto deriva che chi deve scrivere i contratti, valutando e soppesando le responsabilità che possono essere sottese alla realizzazione del progetto, e chi conosce l’organizzazione del lavoro dovrebbero sedere al tavolo programmatico sin dall’inizio, e non essere chiamati in fase di collaudo o, peggio, di analisi della compliance generale di quanto ormai definito.
Il bilancio di un progetto
Il documento impone indicatori di prestazione per ogni caso d’uso, obiettivi misurabili e la misura del «valore aggiunto per la PA». Non dice come costruirli. Anche in questo caso, proviamo ad immaginare un metodo. Un modo semplice è ragionare per attivo e passivo.
Poniamo il caso di un Comune che introduce la pre-istruttoria automatica delle pratiche edilizie. All’attivo vanno: i giorni medi di istruttoria risparmiati, l’arretrato smaltito, gli errori e il contenzioso evitati. Al passivo vanno: il canone per l’utilizzo del sistema, l’adeguamento dell’archivio necessario per il buon funzionamento del sistema stesso, la formazione, la gestione dei reclami. E, soprattutto, le ore che i tecnici dedicano a verificare le proposte del sistema. Il costo del controllo umano è una voce di bilancio. Di conseguenza, se al netto di un controllo effettivo il saldo è negativo, quel procedimento non è adatto all’automazione.
Vale anche la cautela opposta. Un assistente informativo (il classico chatbot) va misurato sulle richieste risolte correttamente, non sul numero di conversazioni. Sarebbe come valutare la sanità dalle prestazioni erogate anziché dalla ricaduta di quelle prestazioni sulla salute dei pazienti.
Il processo è fondamentale. Prima si rilevano i valori di partenza e si fissano gli obiettivi. Poi li si traduce nel capitolato e nel contratto, con livelli di servizio, penali e corrispettivo legato ai risultati. Solo dopo si verifica, ed è la fase di controllo del ciclo PDCA dal quale siamo partiti.
Studiare, programmare, innovare. Senza appesantire
Il rischio, ora, è tradurre centoquaranta pagine in un nuovo strato di carta: registri, valutazioni e codici, ciascuno con il proprio responsabile. Sarebbe un esito paradossale per una tecnologia adottata per alleggerire il lavoro.
Le Linee guida, in verità, offrono esse stesse taluni gli antidoti. La valutazione d’impatto sui diritti fondamentali richiesta dall’AI Act può integrarsi con quella sulla protezione dei dati prevista dal regolamento europeo sulla privacy. La formazione entra nel PIAO, che esiste già. Il codice etico è facoltativo e può confluire nei codici di comportamento. Per i sistemi a rischio minimo è ammesso un processo semplificato.
Quel che si deve fare è, in sostanza, semplificare. Fare poche cose, e farle sul serio: un’analisi delle esigenze, un atto organizzativo sul controllo, un contratto ben scritto, un bilancio.
Studiare prima di acquistare, programmare prima di sperimentare, innovare misurando. La compliance serve se è parte del progetto; se è, come si dice, by design.
Partecipa alla community