Perché le Linee Guida sullo sviluppo dell’IA nella PA mi sembrano davvero inapplicabili
Analisi critica della bozza in consultazione pubblica
⏱️ Lettura: ~10 minuti.
☕ Caffè necessari: uno, ma doppio.
Nota, prima di cominciare
È un articolo palloso (sì, è palloso!) ma se lavorate nella PA, vi riguarda. Se andate di fretta o non capite nulla di questioni tecniche, fate correre gli occhi lungo i titoli e i paragrafi in grassetto.
Il 12 marzo 2026 l’Agenzia per l’Italia Digitale ha pubblicato, con Determinazione del Direttore Generale n. 43/2026, due documenti in consultazione pubblica: le Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione e le Linee Guida per il procurement di IA nella Pubblica Amministrazione1. Il primo documento si propone di definire principi, architetture, requisiti di sicurezza e clausole contrattuali per orientare lo sviluppo e l’integrazione di sistemi IA nell’intero perimetro della PA italiana. Il secondo fornisce il quadro metodologico e operativo per l’acquisizione, la gestione e il monitoraggio delle soluzioni IA, trasformando il procurement in una leva strategica che collega le scelte tecnologiche agli aspetti economici, organizzativi e contrattuali. I due documenti sono concepiti come complementari: le Linee Guida sullo sviluppo collegano i principi delle precedenti Linee Guida sull’adozione con il quadro operativo del procurement, garantendo, nelle intenzioni, coerenza lungo l’intero ciclo di vita dei sistemi di IA nelle PA.
Entrambi i documenti sono emanati ai sensi dell’art. 71 del Codice dell’Amministrazione Digitale2 e del Piano Triennale per l’informatica nella PA 2024-2026. La consultazione pubblica è aperta fino all’11 aprile 2026: chiunque può inviare commenti, suggerimenti e proposte di modifica attraverso Forum Italia3.
Sono documenti attesi. L’AI Act4 europeo è in vigore, la Legge 132/20255 ne ha recepito e integrato i principi a livello nazionale, e le amministrazioni pubbliche si trovano nella condizione concreta di dover acquistare, sviluppare o integrare sistemi di IA senza un quadro di riferimento tecnico-operativo chiaro. Queste Linee Guida intendono colmare quel vuoto.
Ho analizzato nella sua interezza il documento sullo sviluppo, e ciò che segue riguarda esclusivamente quel testo. La struttura complessiva è solida: lo stack IA a cinque livelli (Energy, Chip, Infrastruttura, Modelli, Applicazioni) offre un’astrazione didattica utile; la tassonomia degli attacchi AI-specifici è competente e allineata alla letteratura ENISA6 e NIST7; l’insistenza sull’anti-lock-in e sulla portabilità è politicamente e strategicamente corretta; il modello a quattro profili operatore (base, avanzato, esperto, controllore) è un tentativo ragionevole di differenziare le aspettative in base alla capacità istituzionale.
Tuttavia il documento presenta criticità rilevanti, molte delle quali rischiano di renderlo, nella pratica, inapplicabile.
Quello che segue è un esame sistematico di questi punti, che costituiscono anche il nucleo delle osservazioni che intendo sottoporre formalmente alla consultazione pubblica, non appena il sistema di verifica delle iscrizioni al Forum Italia, attualmente affetto da un eccesso di zelo securitario, vorrà concedermi il permesso di farlo.
Criticità gravi: punti irrealizzabili o al limite della realizzabilità
1. L’obbligo di neutralità hardware e fallback CPU-only è tecnicamente irrealistico per molti casi d’uso
Il documento prescrive ripetutamente con formula obbligatoria (”DEVE”) che i sistemi siano “hardware-agnostic” e prevedano “esecuzione su infrastrutture CPU-only”. Il Principio 11, le clausole contrattuali esemplificative (sezione 6.4) e le tabelle di ogni fase del ciclo di vita lo ribadiscono come requisito strutturale. La clausola 6.4.3, in particolare, prescrive che il sistema debba “prevedere modalità di esecuzione alternative [...] che consentano l’utilizzo anche su infrastrutture CPU-only”.
Il problema è che questa prescrizione è incompatibile con la realtà tecnica dei modelli di IA generativa di scala media o grande. Un LLM8 da 70 miliardi di parametri su CPU-only non è “degradato nelle prestazioni” , è inutilizzabile per inferenza interattiva. I benchmark disponibili parlano chiaro: su 32 vCPU, un modello 70B quantizzato a 4 bit produce 3-4 token al secondo, contro i 20 e più di una singola GPU A100. In termini pratici: una risposta che su GPU richiede 10 secondi, su CPU ne richiederebbe diversi minuti, ammesso che il modello entri in memoria, il che per un 70B non quantizzato (circa 140 GB) su un server PA standard è già di per sé un atto di fede.
Il documento, va detto, contiene un inciso rilevante: la stessa clausola 6.4.3 parla di “livelli di servizio proporzionati al contesto di utilizzo”, e la sezione 6.2 ammette che l’esecuzione su CPU è possibile “in molti casi”, non in tutti. È un’apertura alla proporzionalità, ma che resta sospesa nel vuoto operativo, perché il documento non definisce né soglie di accettabilità, né criteri per stabilire quando il fallback su CPU sia plausibile (Small Language Models9, modelli tabulari, classificatori di machine learning classico) e quando semplicemente non lo sia (LLM di grandi dimensioni, modelli multimodali, diffusion models10).
Imporre questo requisito con “DEVE” in modo indifferenziato rischia di produrre capitolati di gara tecnicamente assurdi, che i fornitori aggireranno formalmente, magari certificando che il sistema “può” girare su CPU, senza menzionare che un cittadino che chiede un certificato anagrafico al chatbot comunale farebbe in tempo a recarsi personalmente allo sportello, prendere il numero, attendere il proprio turno, sbrigare la pratica, prendere un caffè al bar di fronte, e tornare a casa, prima che il modello finisca di elaborare la risposta.
2. L’architettura agentica come prescrizione obbligatoria universale
La sezione 2.1 prescrive testualmente: “le Pubbliche Amministrazioni DEVONO privilegiare architetture agentiche e a servizi, supportate da un orchestratore di servizi di IA”. Il verbo “privilegiare” è tecnicamente più morbido di “adottare”: in gergo giuridico-amministrativo indica una preferenza qualificata, non un obbligo assoluto. Ma accoppiato al “DEVONO” che lo precede, il risultato pratico è una prescrizione obbligatoria di preferenza, un ibrido che, nei capitolati di gara, verrà inevitabilmente interpretato come un requisito. E questa formulazione è problematica sotto almeno tre profili.
Primo: le architetture agentiche11 sono una frontiera della ricerca, non una tecnologia matura e consolidata. Lo stesso documento lo ammette quando classifica il Livello 5 (agenti completamente autonomi) come limitato “solo ad attività di ricerca”, e il Livello 4 (agenti semi-autonomi) come circoscritto ad “ambienti di esercizio limitati in ambienti vincolati”. Trasformare una direzione di ricerca in un obbligo regolamentare è quantomeno prematuro.
Secondo: la stragrande maggioranza delle PA italiane rientra nella categoria degli “Operatori base” definita dal documento stesso — enti che utilizzano soluzioni IA as-a-service senza intervenire sui componenti architetturali sottostanti. Il documento stesso li descrive come “la maggioranza delle amministrazioni”, includendo “enti centrali, regionali e locali, agenzie, istituti scolastici, università, aziende sanitarie”. Imporre a un istituto scolastico o a un piccolo comune di “privilegiare architetture agentiche supportate da un orchestratore” è sproporzionato rispetto alle loro capacità e ai loro casi d’uso, e contraddice il principio di proporzionalità che il documento stesso enuncia.
Terzo: non esiste ad oggi uno standard consolidato per l’orchestrazione agentica. I framework disponibili sono ecosistemi proprietari o semi-proprietari, in rapida evoluzione e con API instabili. Imporre questa architettura con “DEVE” rischia paradossalmente di creare una nuova forma di lock-in verso i pochi framework di orchestrazione oggi disponibili, contraddicendo il principio anti-lock-in che permea l’intero documento.
3. Il gap tra competenze richieste e competenze reali della PA italiana
Il documento definisce con cura quattro profili di operatore (base, avanzato, esperto, controllore), ma il Principio 19 prescrive che lo sviluppo “DEVE essere accompagnato da trasferimento strutturato di competenze verso il personale della PA” e che i sistemi “DEVONO essere progettati in modo da essere comprensibili, gestibili e governabili dal personale interno”.
Chiunque abbia familiarità con la situazione reale delle competenze digitali nella PA italiana sa che questa prescrizione, per la grande maggioranza delle amministrazioni, è irrealizzabile nel medio termine senza investimenti massicci in formazione e un piano di reclutamento radicalmente diverso dall’attuale. Stiamo parlando di un sistema in cui molte amministrazioni faticano a gestire un CMS12 per il proprio sito web: pretendere che il personale interno comprenda e governi architetture agentiche con orchestrazione multi-modello è un salto in una differente dimensione quantica.
Il documento riconosce implicitamente il problema nella tassonomia dei ruoli, gli Operatori base “non possono contare su competenze specialistiche avanzate”, ma poi non ne trae le conseguenze operative. Non prevede periodi di transizione differenziati per categoria di operatore, non indica soglie minime di competenza misurabili, non definisce meccanismi di supporto interamministrativo obbligatori, non identifica centri di competenza che possano fungere da volano. Il risultato è una prescrizione di principio corretta ma operativamente sospesa nel vuoto.
Criticità significative: punti realizzabili ma con grande difficoltà
4. La separazione obbligatoria tra dati, modelli e servizi è sovrasemplificata
Il Principio 4 dei principi per lo sviluppo e il procurement, quello relativo alla protezione dei dati personali, da non confondere con il Principio 4 della Legge 132/2025 che riguarda la tutela del metodo democratico, prescrive una “netta separazione tra dati, modelli e servizi”. L’architettura di riferimento della sezione 3.2 struttura questa separazione nei suoi componenti (Modelli, Fonti dati, Tool applicativi, Orchestratore). Nei sistemi IA moderni, specialmente quelli basati su Retrieval-Augmented Generation13, fine-tuning o approcci ibridi, questa separazione è tuttavia un continuum, non un binario.
Un modello sottoposto a fine-tuning su dati della PA incorpora quei dati nei propri pesi: la “separazione” diventa una fiction tecnica. Lo stesso vale per le tecniche PEFT e LoRA14 citate dal documento stesso: producono adattatori che sono funzione diretta dei dati su cui sono stati addestrati. Si possono separare architetturalmente (l’adattatore è un file distinto dal modello base), ma non epistemologicamente (l’adattatore è una rappresentazione compressa di quei dati).
Il documento dovrebbe distinguere con maggiore rigore tra separazione architetturale, possibile e auspicabile, da perseguire nella progettazione dei sistemi e separazione epistemologica, spesso impossibile dopo il training, e di cui va piuttosto gestito il rischio residuo.
5. La sostenibilità ambientale come obbligo senza metriche
Il Principio 18 e le prescrizioni per ogni fase del ciclo di vita impongono di “progettare tenendo conto dell’efficienza energetica e computazionale” e di includere “criteri di sostenibilità ambientale riferiti all’intero stack IA”. Le procedure di gara “DEVONO favorire soluzioni che dimostrino misurabilità e riduzione dell’impatto ambientale nel tempo”.
Misurabilità, appunto. Ma il documento non indica nessuna metrica concreta, nessun benchmark, nessuna metodologia di misurazione. Come si quantifica il consumo energetico di un ciclo di inferenza? Quale unità di misura adottare nei capitolati — kWh per query? CO₂-equivalente per token generato? Quale baseline utilizzare per dimostrare la “riduzione nel tempo”? Senza risposte a queste domande, il requisito di sostenibilità ambientale rischia di restare una dichiarazione di intenti priva di forza operativa — un ornamento retorico in un documento che aspira ad essere un regolamento tecnico.
6. L’Operatore controllore è un modello che oggi non esiste nella PA italiana
L’Operatore controllore viene descritto come la PA che possiede “pieno governo tecnologico, infrastrutturale e operativo su ogni componente del sistema AI” e gestisce “in modalità end-to-end l’intera catena del valore dell’IA, dal dato alla messa in produzione”. Il documento lo presenta come una delle quattro categorie operative in cui le PA possono classificarsi.
Una nota a piè di pagina del documento (la n. 7) precisa che questi profili sono “famiglie di utilizzatori” e che una singola PA potrebbe ricoprire profili diversi per casi d’uso diversi: non serve, dunque, possedere l’intera filiera per tutto, ma per uno specifico sistema. Questa precisazione è ragionevole, ma non risolve il problema di fondo: nessuna Pubblica Amministrazione italiana possiede oggi la filiera end-to-end nemmeno per un singolo sistema IA, dall’energia ai modelli fondazionali. Nemmeno i grandi centri di ricerca nazionali — CINECA, CNR, gli enti vigilati, la possiedono completamente: CINECA dispone di capacità computazionale HPC15 di eccellenza, ma non sviluppa modelli fondazionali propri; nessun ente pubblico italiano controlla un proprio Energy Layer dedicato all’IA.
Presentare questo profilo come una categoria operativa attuale, invece che come un obiettivo strategico di lungo termine che richiede investimenti dell’ordine di miliardi e decisioni di politica industriale, genera aspettative irrealistiche e confonde il piano prescrittivo con quello aspirazionale.
Criticità formali e strutturali
7. Ridondanza e clausole contrattuali duplicate
Il documento ripete sistematicamente gli stessi concetti in almeno tre forme diverse: nella descrizione discorsiva dei principi, nella tabella riassuntiva dei principi (Tabella 1, che da sola occupa circa sei pagine), e nelle tabelle per fase del ciclo di vita (capitolo 4). Le 109 pagine potrebbero essere 50-60 senza alcuna perdita di contenuto informativo. Per un documento destinato a funzionari pubblici che devono tradurlo in atti amministrativi, delibere di giunta, capitolati di gara e determine dirigenziali, la prolissità non è un difetto estetico: è un ostacolo operativo concreto che ne riduce l’utilizzabilità.
La ridondanza produce anche errori concreti: la sezione 6.4.1 (Neutralità hardware) e la sezione 6.4.2 (Portabilità e reversibilità) contengono un testo identico, parola per parola. La sezione sulla portabilità ripete la clausola sulla neutralità hardware senza aggiungere nulla sul proprio oggetto dichiarato. In un documento normativo destinato a generare clausole contrattuali vincolanti, un errore di copia-incolla non è un dettaglio trascurabile.
8. Riferimento a strumenti non ancora disponibili
Il documento cita ripetutamente degli “strumenti” di supporto operativo — lo Strumento A (Termini e definizioni), lo Strumento B (Training, validazione, fine-tuning di Modelli di IA e RAG) — e indica un link “da definire in fase di pubblicazione” per l’elenco aggiornato. Sottoporre a consultazione pubblica un documento il cui contenuto operativo concreto dipende da allegati non ancora disponibili è strutturalmente incompleto. I partecipanti alla consultazione non possono valutare l’adeguatezza del quadro complessivo se ne mancano le componenti attuative.
9. Trattamento superficiale del Federated Learning
Il Federated Learning16 è presentato nella Tabella 4 come terza opzione di deploy per il training, con la formula: “training distribuito senza condivisione dati”. Questa descrizione è corretta nella sua essenza, ma il documento non accompagna questa opzione con i caveat tecnici che la letteratura scientifica considera ormai consolidati: la vulnerabilità ad attacchi di inferenza sui gradienti (che possono ricostruire dati individuali dagli aggiornamenti del modello), l’overhead comunicativo significativo, le difficoltà di convergenza con dati non-IID17 (come è inevitabile tra PA diverse), e la complessità implementativa che richiede competenze ben superiori a quelle di un Operatore base o avanzato.
Va riconosciuto che il capitolo 5, nella sezione sulla sicurezza (paragrafo 5.5.2), discute esplicitamente la vulnerabilità dell’apprendimento federato agli attacchi di model poisoning tramite aggiornamenti malevoli. Il documento, dunque, non è del tutto silente sui rischi del FL, ma lo è proprio nel punto in cui servirebbe: nella tabella operativa di deployment che orienta le scelte progettuali. Un funzionario che consulta la Tabella 4 per decidere come configurare il training troverà un’opzione apparentemente accessibile; per scoprire che presenta rischi specifici, dovrà leggere un capitolo diverso, cinquanta pagine più avanti.
La questione di fondo
Il problema strutturale di questo documento non risiede in nessuna delle singole criticità elencate, ma nella loro radice comune: l’oscillazione irrisolta tra due nature diverse.
Se le Linee Guida intendono essere una guida di principi, un documento strategico che orienta le scelte delle PA verso obiettivi desiderabili, allora i “DEVE” dovrebbero essere “DOVREBBE”, le prescrizioni tecniche dovrebbero essere indicazioni di massima, e il documento andrebbe bene così com’è, forse un po’ più asciutto.
Se invece intendono essere un regolamento tecnico operativo e l’uso pervasivo del “DEVE”, la presenza di clausole contrattuali esemplificative e il riferimento al CAD suggeriscono questa ambizione, allora servono metriche misurabili, soglie quantitative, standard verificabili, strumenti operativi concreti, e una differenziazione molto più granulare tra ciò che è realisticamente esigibile da un Operatore base e ciò che è esigibile da un Operatore esperto.
Nella sua forma attuale, il documento abita una terra di mezzo tra queste due identità. Il rischio concreto è quello che si osserva frequentemente nella regolamentazione tecnica italiana: un quadro normativo ambizioso e ben intenzionato che, nell’impatto con la realtà amministrativa del Paese, produce adempimenti formali svuotati di sostanza o, peggio, paralisi decisionale per eccesso di prescrizioni percepite come irrealizzabili.
Sitografia di riferimento
AgID — Agenzia per l’Italia Digitale, Linee guida su IA nella PA: al via la consultazione pubblica su sviluppo e procurement, 12 marzo 2026. https://www.agid.gov.it/it/notizie/linee-guida-su-ia-nella-pa-al-la-consultazione-pubblica-su-sviluppo-e-procurement
AgID, Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella pubblica amministrazione, marzo 2026. https://www.agid.gov.it/sites/agid/files/2026-03/LLGG_Sviluppo_per%20consultazione%20pubblica.pdf
AgID, Bozza di Linee Guida per il procurement di IA nella Pubblica Amministrazione, marzo 2026. https://www.agid.gov.it/sites/agid/files/2026-03/LLGG%20procurement_per%20consultazione%20pubblica.pdf
ENISA — European Union Agency for Cybersecurity, AI Cybersecurity Challenges, 2020. https://www.enisa.europa.eu/publications/artificial-intelligence-cybersecurity-challenges
Forum Italia, Consultazione Linee Guida Sviluppo IA nella PA. https://forum.italia.it/c/documenti-in-consultazione/lg-per-lo-sviluppo-di-sistemi-ia-nella-pa/108
Forum Italia, Consultazione Linee Guida Procurement IA nella PA. https://forum.italia.it/c/documenti-in-consultazione/lg-per-il-procurement-di-ia-nella-pa/109
Gazzetta Ufficiale della Repubblica Italiana, Legge 23 settembre 2025, n. 132 — Disposizioni e deleghe al Governo in materia di intelligenza artificiale.
https://www.gazzettaufficiale.it/eli/id/2025/09/25/25G00143/sg
NIST — National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), gennaio 2023. https://www.nist.gov/artificial-intelligence/executive-order-safe-secure-and-trustworthy-artificial-intelligence
Parlamento Europeo e Consiglio dell’Unione Europea, Regolamento (UE) 2024/1689 — AI Act, 13 giugno 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
Spare Cores, LLM Inference Speed Benchmarks, 2025. https://sparecores.com/article/llm-inference-speed
Le due bozze sono state adottate con la Determinazione del Direttore Generale n. 43 del 10 marzo 2026 e pubblicate il 12 marzo 2026 sul sito AgID.
CAD — Codice dell’Amministrazione Digitale (D.Lgs. 7 marzo 2005, n. 82 e successive modifiche). L’art. 71 disciplina le regole tecniche e le linee guida emanate da AgID.
Al momento della stesura di questo articolo, il sistema di verifica delle iscrizioni a Forum Italia presenta difficoltà che impediscono ad alcuni utenti di completare la registrazione e partecipare alla consultazione. La consultazione sulle Linee Guida Procurement è accessibile a un link separato.
Regolamento (UE) 2024/1689 del Parlamento Europeo e del Consiglio, che stabilisce regole armonizzate sull’intelligenza artificiale nell’Unione Europea.
Legge 23 settembre 2025, n. 132, recante “Disposizioni e deleghe al Governo in materia di intelligenza artificiale”. Recepisce e integra a livello nazionale i principi dell’AI Act.
ENISA — European Union Agency for Cybersecurity. L’agenzia dell’UE per la sicurezza informatica, autrice tra l’altro del rapporto AI Cybersecurity Challenges (2020).
NIST — National Institute of Standards and Technology. Ente federale statunitense che ha sviluppato, tra l’altro, l’AI Risk Management Framework (AI RMF 1.0, 2023).
Large Language Model. Modello di linguaggio di grandi dimensioni, addestrato su vasti corpus testuali, in grado di generare e comprendere testo in linguaggio naturale (es. GPT-4, Claude, Llama, Gemini).
Modelli di linguaggio di dimensioni ridotte (tipicamente sotto i 10 miliardi di parametri), progettati per applicazioni verticali ed efficienti, eseguibili anche su hardware limitato.
Classe di modelli generativi che producono dati (tipicamente immagini) attraverso un processo iterativo di rimozione del rumore. Esempi noti: Stable Diffusion, DALL-E, Midjourney.
Framework di progettazione in cui i modelli di IA operano come “agenti” dotati di autonomia operativa, in grado di pianificare, eseguire azioni, interagire con risorse esterne e apprendere dai risultati.
Content Management System. Sistema di gestione dei contenuti web (es. WordPress, Joomla, Drupal).
Tecnica che combina il recupero di informazioni da basi documentali con la generazione di testo da parte di un LLM, migliorando l’accuratezza fattuale delle risposte.
PEFT (Parameter-Efficient Fine-Tuning) e LoRA (Low-Rank Adaptation) sono tecniche di adattamento dei modelli fondazionali che modificano solo un sottoinsieme ridotto di parametri, riducendo costi computazionali e di storage rispetto al fine-tuning completo.
High Performance Computing. Calcolo ad alte prestazioni, tipicamente realizzato su supercomputer o cluster di calcolo. CINECA ospita Leonardo, tra i supercomputer più potenti d’Europa.
Tecnica di addestramento distribuito in cui il modello viene addestrato localmente su dati distribuiti tra più nodi, condividendo solo gli aggiornamenti dei parametri (gradienti) e non i dati grezzi.
Non Independently and Identically Distributed. Dati che non seguono la stessa distribuzione statistica tra i diversi nodi partecipanti, condizione tipica quando PA diverse contribuiscono con dataset eterogenei per struttura, volume e dominio.