Le linee guida AgID sull’intelligenza artificiale nella pubblica amministrazione sono definitive, e chi vende software con IA a un Comune, a una Regione o a una società pubblica se le troverà davanti alla prossima gara.

Sono scritte per gli enti. Dicono cosa un’amministrazione deve verificare prima di usare un sistema di IA, dalla classificazione del rischio alla documentazione tecnica, dall’informativa ai cittadini alla sicurezza dei dati.

Molte di quelle risposte le ha soltanto chi il sistema l’ha costruito. Le chiederanno quindi a te, in gara, nel capitolato e nel contratto.

Per chi vende alla PA il lavoro si sposta prima del bando. Documentazione, condizioni d’uso e nomina a responsabile del trattamento vanno messe in ordine adesso, finché c’è tempo per farlo bene.

1. Linee guida AgID: a chi parlano davvero

Le linee guida si rivolgono alle pubbliche amministrazioni. Ogni obbligo che pongono a un ente su un sistema di IA comprato all’esterno diventa però una richiesta al fornitore, perché l’ente non può adempierlo senza le sue informazioni. Documentazione tecnica, contenuti dell’informativa, garanzie sui dati e sulla sicurezza sono le voci che chi vende alla PA si troverà davanti.

Le ha adottate l’Agenzia per l’Italia Digitale con la determinazione n. 169 del 9 novembre 2026, seguendo la procedura dell’art. 71 del Codice dell’amministrazione digitale. Sono 140 pagine, versione 1.0. Il testo nasce dal Tavolo di concertazione del Piano triennale per l’informatica nella PA. Ci hanno lavorato, fra gli altri, ACN, ANAC, ANCI, Conferenza delle Regioni, Consip, INPS, ISTAT e PagoPA, cioè anche chi scrive i bandi e chi compra per conto di altri enti. L’annuncio dell’Agenzia è all’indirizzo https://www.agid.gov.it/it/notizie/agid-pubblica-le-linee-guida-ladozione-di-ia-nella-pubblica-amministrazione

Il perimetro è più largo dei soli ministeri e Comuni. Il documento vale per i soggetti dell’art. 2, comma 2, del Codice dell’amministrazione digitale. Oltre alle amministrazioni, sono le autorità indipendenti, i gestori di servizi pubblici e le società a controllo pubblico. Chi fornisce un’azienda di trasporto locale o una multiutility partecipata è dentro.

Vale per ogni sistema e modello di IA come lo definisce l’art. 3 dell’AI Act, a qualunque livello di rischio. Un assistente che risponde ai cittadini, uno strumento che classifica i documenti in entrata, un modello che stima i tempi di un procedimento rientrano tutti.

Il testo dice anche quanto pesa ogni frase.

• DEVE e DEVONO indicano un requisito obbligatorio, e il funzionario non può saltarlo.
• NON DEVE e NON DEVONO indicano un divieto assoluto.
• DOVREBBE chiede di pesare le conseguenze prima di scegliere un’altra strada.
• PUÒ e OPZIONALE lasciano la scelta all’ente.

Quando un capitolato riprende una prescrizione marcata DEVE, la richiesta al fornitore ha alle spalle un obbligo dell’amministrazione, ed è difficile che l’ente ci rinunci.

Sullo sfondo c’è la legge italiana sull’IA. L’art. 14 della L. 132/2025 vuole l’intelligenza artificiale nella PA in funzione strumentale e di supporto, e la persona resta l’unica responsabile del provvedimento. Chiede anche che il funzionamento sia conoscibile e l’utilizzo tracciabile. Le linee guida traducono quel principio in procedure.

2. Cosa la PA deve verificare, e chiederà a te

Le richieste che toccano il fornitore stanno soprattutto nei capitoli 5, 7, 9, 10 e 11. Per alcune le linee guida dicono in modo espresso che vanno rivolte al fornitore, e accade per cloud, responsabili del trattamento e sicurezza. Per le altre è la conseguenza di un obbligo che l’ente non può adempiere da solo, ed è la lettura che ne diamo noi.

2.1 Classificazione e ruoli, nero su bianco

Il primo passo della PA è stabilire se ha davanti un sistema di IA e di che livello di rischio. Le linee guida le chiedono di classificare il sistema secondo l’art. 6 dell’AI Act e di riconoscere il proprio ruolo. Per l’AI Act l’ente può essere fornitore o deployer, cioè chi usa il sistema sotto la propria autorità. Per il GDPR può essere titolare o responsabile del trattamento.

Per classificare l’ente deve sapere a cosa serve il sistema, per quale finalità l’hai progettato e quali componenti contiene. Se integra un modello per finalità generali, il documento avverte che la classificazione iniziale può cambiare e il sistema può diventare ad alto rischio.

Come si fa la verifica è spiegato nella guida: sistemi AI ad alto rischio e GPAI.

2.2 Documentazione anche a rischio minimo

Questa è la richiesta che sorprenderà di più chi vende sistemi semplici. Anche per i sistemi a rischio limitato o minimo, la PA deve garantire che la documentazione tecnica ci sia e sia completa. Deve contenere gli elementi utili a verificare trasparenza e spiegabilità dei risultati, e va aggiornata per tutto il ciclo di vita del sistema.

Le linee guida la chiedono alla PA per ogni sistema, e la PA la può ottenere soltanto da te.

Il monitoraggio va nella stessa direzione. Fra le attività che il documento elenca ci sono la raccolta di relazioni sulle caratteristiche del sistema, i test in condizioni reali e l’analisi dei reclami di cittadini e operatori. Il sistema deve inoltre registrare le operazioni svolte, perché il principio sulle registrazioni chiede meccanismi che le tracciano e le conservano nel tempo.

2.3 Le informazioni per l’informativa

La PA deve spiegare ai cittadini come usa l’IA con un’informativa che va oltre quella sul trattamento dei dati personali. Il paragrafo 7.2 elenca cosa deve aggiungere.

• Il tipo di IA impiegata, indicando gli elementi architetturali del sistema.
• Le finalità per cui il sistema è usato.
• I criteri su cui si basano le decisioni, ai diversi livelli di automazione.
• Se il sistema analizza dati storici o usa modelli statistici per previsioni o raccomandazioni.
• I possibili effetti delle decisioni sui cittadini, compreso l’accesso a servizi o benefici.

Quando la decisione è automatizzata, l’ente deve descrivere la logica e i dati che hanno pesato sull’esito, senza pregiudicare la tutela dei segreti commerciali. Quella clausola protegge anche te. Conviene stabilire nel contratto quali informazioni dai per l’informativa e quali restano riservate, prima che sia la PA a chiedere tutto.

C’è poi la trasparenza dell’AI Act. Un chatbot deve dire alla persona che sta parlando con una macchina, e i contenuti generati vanno marcati come artificiali, come dispone l’art. 50 dell’AI Act. Le linee guida chiedono alla PA di verificare che questi requisiti siano applicati, quindi la verifica arriverà sul tuo prodotto.

2.4 Subfornitori e niente addestramento

Se il sistema gira in cloud, la PA deve individuare con chiarezza i fornitori e gli eventuali subfornitori della catena. Deve anche avere garanzie che i fornitori non usino i dati per finalità proprie o incompatibili con quelle dell’ente. Un elenco completo dei subfornitori, con il fornitore di infrastruttura e quello del modello, diventa un allegato da tenere pronto.

Sui dati personali le linee guida sono le più nette. Se la PA usa un responsabile del trattamento con strumenti di IA, deve vietargli in modo esplicito di addestrare o riaddestrare con quei dati modelli destinati a terzi. Il divieto di addestramento va scritto anche nella nomina a responsabile del trattamento prevista dall’art. 28 GDPR.

Molte condizioni d’uso consentono di usare i dati dei clienti per migliorare il servizio. Chi ha una clausola così deve quindi preparare per la PA una versione che la escluda. Cosa deve contenere la nomina a responsabile del trattamento lo spieghiamo nella guida: nomina a responsabile del trattamento e Data Processing Agreement (DPA).

La PA resta titolare del trattamento anche quando l’utilizzo passa per il fornitore. Per questo deve fare una valutazione d’impatto sulla protezione dei dati prima di trattarli con il sistema, e poi periodicamente. L’obbligo vale anche quando il sistema non è ad alto rischio. Deve inoltre controllare i trasferimenti di dati verso Paesi extra UE.

2.5 Sicurezza lungo la catena di fornitura

Il capitolo sulla sicurezza è quello che parla più apertamente ai fornitori. I componenti di un sistema di IA, dai dati ai modelli fino alle librerie e alle API esterne, devono venire da fornitori verificati ed essere protetti e documentati. Ai fornitori va chiesto che le loro misure di sicurezza siano allineate alle politiche dell’ente e alla sua analisi dei rischi.

Le organizzazioni devono svolgere audit interni ed esterni, con test di penetrazione e simulazioni di attacco. Fra le pratiche indicate per la fase di addestramento c’è la verifica della sicurezza dei modelli pre-addestrati e della loro provenienza. Il documento raccomanda anche di dire agli utenti se i loro dati servono a riaddestrare il modello o sono visti da terzi.

In pratica arriveranno un questionario di sicurezza, la richiesta di consentire verifiche e quella di dichiarare da dove viene il modello che hai integrato. Conviene raccogliere le risposte in un documento prima della gara.

3. Alto rischio: chi resta fornitore e chi no

Quando il sistema è ad alto rischio, la domanda diventa chi ne risponde come fornitore. Le linee guida riprendono l’art. 25 dell’AI Act, che sposta gli obblighi del fornitore su chiunque intervenga sul sistema in tre casi. Il primo è quando ci appone il proprio nome o marchio, il secondo quando lo modifica in modo sostanziale. Il terzo è quando ne cambia la finalità e lo rende ad alto rischio.

Anche una PA può trovarsi in quella posizione. Un ente che mette il proprio marchio su un sistema ad alto rischio comprato da te diventa fornitore, salvo che il contratto ripartisca diversamente gli obblighi. Lo stesso vale se usa per una finalità ad alto rischio uno strumento pensato per altro.

Il regolamento (UE) 2026/1744, l’Omnibus digitale sull’IA, ha riscritto il paragrafo 2 dello stesso articolo, e le linee guida non lo riportano. In quei casi chi ha immesso per primo il sistema sul mercato non è più considerato fornitore. Deve però cooperare con il nuovo fornitore, mettendo a disposizione la documentazione tecnica, le limitazioni note e un accesso tecnico mirato. L’obbligo cade se il fornitore iniziale ha specificato chiaramente che il suo sistema non deve essere trasformato in un sistema ad alto rischio.

Per chi vende alla PA un sistema che non è ad alto rischio ne discende una clausola di destinazione d’uso, scritta nel contratto e nella documentazione. Dice a cosa serve il sistema e per cosa non va usato. È una nostra lettura della norma, e regge solo se la dichiarazione è chiara.

Se invece fornisci un modello, un componente o un servizio che un altro fornitore integra in un sistema ad alto rischio, vi serve un accordo scritto. Lo chiede l’art. 25, paragrafo 4, e riguarda informazioni, capacità, accesso tecnico e assistenza.

Quando la PA usa come deployer un sistema ad alto rischio dell’allegato III, prima dell’uso deve svolgere la valutazione d’impatto sui diritti fondamentali prevista dall’art. 27 dell’AI Act. Restano fuori i sistemi per le infrastrutture critiche, elencati al punto 2 dello stesso allegato. Fra gli elementi da considerare ci sono i rischi specifici per le persone e le misure di sorveglianza umana, e parte di quelle informazioni sta nella tua documentazione. Cosa contiene lo spieghiamo nella guida: FRIA, la valutazione d’impatto sui diritti fondamentali.

4. Le date: cosa vale già e cosa arriva dopo

Le linee guida non fissano un termine entro cui le amministrazioni devono adeguarsi. Le scadenze vere arrivano dall’AI Act.

Già in vigore

• Trasparenza – Gli obblighi dell’art. 50 su chatbot e contenuti generati si applicano dal 2 agosto 2026.
• Alfabetizzazione – Dal 2 febbraio 2025 fornitori e deployer devono sostenere le competenze sull’IA del proprio personale, come chiede l’art. 4 dell’AI Act.

Da programmare

• 2 dicembre 2026 – I sistemi generativi immessi sul mercato prima del 2 agosto 2026 devono marcare i contenuti come artificiali.
• 2 dicembre 2027 – Si applicano gli obblighi per i sistemi ad alto rischio dell’allegato III. Fra questi ci sono quelli usati dalle autorità pubbliche per valutare chi ha diritto a prestazioni e servizi di assistenza pubblica essenziali.
• 2 agosto 2028 – Si applicano gli obblighi per i sistemi ad alto rischio legati ai prodotti dell’allegato I.
• 2 agosto 2030 – I sistemi ad alto rischio destinati alle autorità pubbliche e già in servizio vanno messi in regola anche senza modifiche. Lo dispone l’art. 111, paragrafo 2, dell’AI Act.

Da tenere d’occhio

• Sviluppo e procurement – Le linee guida AgID su sviluppo e acquisto di sistemi di IA nella PA sono ancora in bozza. Quella sul procurement porta con sé uno schema di capitolato tecnico, e il documento sull’adozione vi rinvia per le indicazioni operative sui fornitori.

Se il tuo prodotto genera testi, immagini, audio o video ed era sul mercato prima del 2 agosto 2026, la marcatura dei contenuti va completata entro il 2 dicembre 2026. È la prima scadenza da mettere in calendario.

5. Checklist: cosa preparare prima della gara

Sul sistema

• Finalità prevista – Scrivi a cosa serve il sistema e per cosa non va usato.
• Classificazione – Prepara una classificazione motivata del livello di rischio secondo l’art. 6 dell’AI Act.
• Registrazioni – Verifica che il sistema registri le operazioni e conservi i log.
• Sorveglianza umana – Accertati che un operatore possa verificare, correggere o sostituire l’output.
• Trasparenza – Controlla che il chatbot si dichiari e che i contenuti generati siano marcati.

Nei documenti

• Documentazione tecnica – Prepara un fascicolo completo anche se il sistema non è ad alto rischio, con gli elementi su trasparenza e spiegabilità.
• Scheda per l’informativa – Descrivi tipo di IA, finalità, criteri di decisione e uso di dati storici o modelli statistici.
• Segreti commerciali – Individua quali informazioni restano riservate.

Nel contratto

• Subfornitori – Elenca tutti i fornitori della catena, cloud e modello compresi.
• Niente addestramento – Verifica che condizioni d’uso e nomina a responsabile del trattamento escludano l’uso dei dati della PA per addestrare modelli per terzi.
• Destinazione d’uso – Se il sistema non è ad alto rischio, inserisci la clausola che ne esclude la trasformazione in un sistema ad alto rischio.
• Aggiornamento – Prevedi chi aggiorna la documentazione per tutto il ciclo di vita, e con quale corrispettivo.

Sulla sicurezza

• Questionario – Prepara le risposte su misure di sicurezza, provenienza dei modelli e protezione dei dati.
• Verifiche – Stabilisci in anticipo come consentire audit e test di penetrazione.

Per le clausole di un contratto di sviluppo su misura vale anche la guida: contratti di sviluppo software.

Conclusioni

Le linee guida AgID obbligano le amministrazioni, e alle imprese arrivano attraverso gli uffici che comprano. Quegli uffici hanno adesso un elenco scritto di cosa verificare, con il grado di obbligatorietà accanto a ogni voce.

Per un fornitore la conseguenza è pratica. Documentazione tecnica anche per i sistemi semplici, contenuti per l’informativa, divieto di addestramento nella nomina a responsabile e risposte sulla sicurezza diventano requisiti che il funzionario deve controllare. Quando arriverà la versione definitiva delle linee guida sul procurement, con il suo schema di capitolato, è probabile che molte di queste voci entrino nei bandi.

La nostra posizione è che conviene muoversi adesso, con i contratti e i documenti che si hanno, senza aspettare il primo capitolato. Chi arriva in gara con il fascicolo pronto si fa scegliere, chi deve scriverlo sotto scadenza lo scrive male.

Punti chiave

Fonti e risorse utili