Adozione · Appalti · Servizi pubblici · Diritti
AI Act e pubblica amministrazione: adozione e procurement IA
Una pubblica amministrazione non è soltanto “cliente” di un fornitore. Quando usa un sistema di IA è normalmente deployer e deve governarne finalità, dati, supervisione, monitoraggio e impatto sulle persone. Se sviluppa, rimarchia o modifica il sistema, il suo ruolo può cambiare.
01Prima domanda: che cosa deve fare il sistema?
“Usare l'IA” è troppo generico per classificare il rischio. Contano la finalità prevista, il procedimento amministrativo in cui entra, le persone interessate e l'effetto dell'output. Un assistente che ordina documenti non equivale a un sistema che influenza sussidi, lavoro, sanità, istruzione o attività di polizia.
- Quale decisione o attività amministrativa viene sostenuta?
- L'output produce o orienta effetti giuridici o l'accesso a un servizio essenziale?
- Quali gruppi possono subire falsi positivi, esclusioni o trattamenti diseguali?
- Esiste un canale umano realmente utilizzabile e con potere di correzione?
02La PA può essere deployer o provider
| Situazione | Lettura iniziale | Che cosa verificare |
|---|---|---|
| La PA acquista e usa un prodotto con il marchio del fornitore | Di regola deployer | Finalità concreta, istruzioni, dati di input, persone incaricate della supervisione, log e monitoraggio. |
| La PA fa sviluppare un sistema e lo mette in servizio con il proprio nome | Può essere provider | Chi determina finalità e specifiche, sotto quale nome è messo in servizio e chi sostiene gli obblighi di conformità. |
| La PA cambia finalità o modifica sostanzialmente un sistema ad alto rischio | Può assumere il ruolo di provider | Portata della modifica, nuova finalità prevista, nuova classificazione e documentazione disponibile. |
La guida su provider e deployer approfondisce il passaggio di ruolo previsto dall'articolo 25.
Il percorso equivalente per un'impresa privata è su AI Act per le aziende.
03Checklist per il procurement di IA
Un capitolato efficace non si limita a chiedere accuratezza. Deve rendere il sistema verificabile durante tutto il contratto e permettere all'amministrazione di esercitare i propri doveri.
| Finalità e rischio | Quale problema pubblico risolve? È davvero necessario usare IA? La finalità rientra in una pratica vietata, in un caso ad alto rischio o in un obbligo di trasparenza? |
|---|---|
| Dati e prestazioni | Su quali popolazioni è stato validato? Quali errori sono misurati? I dati di input locali sono pertinenti e rappresentativi per l'uso previsto? |
| Spiegazioni e documenti | La PA riceve istruzioni, limiti, documentazione, log e informazioni sufficienti per audit, reclami e controllo dell'esecuzione? |
| Supervisione | Chi può ignorare, correggere o sospendere l'output? Ha tempo, competenza, autorità e un'interfaccia che rende possibile intervenire? |
| Aggiornamenti e incidenti | Come vengono comunicati cambi di modello, prestazioni, dati o finalità? Chi segnala un rischio grave e chi può fermare il sistema? |
| Uscita dal contratto | Come si esportano dati e log? Come si assicura continuità del servizio, reversibilità e assenza di dipendenza non governabile dal fornitore? |
04Se il sistema è ad alto rischio
L'articolo 26 attribuisce obblighi specifici al deployer. Per una PA questo può includere uso conforme alle istruzioni, supervisione affidata a persone competenti e autorizzate, controllo dei dati di input sotto la propria responsabilità, monitoraggio, conservazione dei log controllati dall'ente e segnalazione di rischi o incidenti.
- Una pubblica autorità non deve usare un sistema ad alto rischio soggetto a registrazione se non risulta registrato nella banca dati europea prevista.
- Quando un sistema dell'Allegato III decide o assiste decisioni su persone, possono applicarsi obblighi di informazione verso gli interessati.
- Per gli enti di diritto pubblico e altri deployer indicati dall'articolo 27 può servire una valutazione d'impatto sui diritti fondamentali prima del primo uso.
05La supervisione umana deve avere potere reale
Inserire una firma umana alla fine del procedimento non basta se la persona vede soltanto un punteggio, non comprende i limiti del sistema, non ha accesso ai dati necessari o non può dissentire. Nel gioco, molti rapporti diventano contestabili proprio quando il controllo umano esiste sulla carta ma non nel processo.
06AI Act e materiali AgID: livelli diversi
Il Regolamento europeo è la fonte giuridica primaria per questa guida. In Italia, AgID pubblica inoltre materiali e linee guida rivolti alle amministrazioni. La determinazione n. 43 del 10 marzo 2026 documenta l'avvio dell'iter di consultazione e informazione delle linee guida per sviluppo e procurement dell'IA nella PA, con bozze allegate.
07Il caso “La gara opaca”
Nel fascicolo del gioco, una piattaforma per l'assegnazione di appalti viene acquistata con documentazione insufficiente. Il problema non è che ogni procurement di IA sia vietato. Il problema è mettere una funzione sensibile dentro un procedimento pubblico senza sapere come è validata, chi la controlla e come contestarne l'output.
08Fonti ufficiali e limiti
Consulta il Regolamento (UE) 2024/1689 su EUR-Lex, in particolare gli articoli 3, 25, 26 e 27, le FAQ della Commissione europea e le pagine istituzionali AgID dedicate all'IA. Gli obblighi cambiano con sistema, finalità e normativa settoriale.