Le linee guida AgID sul procurement di AI, adottate in bozza con la determinazione 43 del 10 marzo 2026, spostano la conformità dentro l’oggetto dell’affidamento. Un fabbisogno definito in modo generico trasferisce al fornitore scelte che devono restare all’amministrazione, e le clausole vanno scritte in gara.
Una volta completato l’iter dell’articolo 71 del Codice dell’amministrazione digitale, che prevede il parere del Garante privacy e della Conferenza unificata, diventeranno regole di indirizzo per tutte le amministrazioni, e i disciplinari di gara per queste forniture dovranno essere sensibilmente più dettagliati di quelli oggi in uso.
Il perimetro delle decisioni da prendere è più largo di quanto un modello ICT preveda, e si apre molto prima della pubblicazione del bando: comincia in fase di programmazione, dove l’amministrazione stabilisce se serva davvero una soluzione algoritmica, e arriva fino alle condizioni di uscita dal contratto.
Indice degli argomenti
Il processo per bandire una gara di AI
Il responsabile di progetto che deve bandire una gara per un sistema di intelligenza artificiale apre, nella quasi totalità dei casi, l’ultimo capitolato ICT pubblicato dall’ente e lo usa come modello. La scelta ha una sua logica, perché quel documento ha superato i controlli e non ha prodotto contenzioso, e produce comunque un risultato inadeguato: un capitolato per fornitura software descrive un prodotto che resta uguale a sé stesso, mentre un sistema basato su modelli linguistici può cambiare comportamento mentre il contratto è in corso. Il segno di quella inadeguatezza compare già nell’oggetto dell’affidamento.
“Fornitura di un sistema di intelligenza artificiale a supporto dell’istruttoria delle pratiche” è una formulazione che sembra sufficiente e non dice nulla di quello che servirebbe sapere: quale attività viene automatizzata, quale grado di autonomia è riconosciuto al sistema, quali risultati sono attesi e con quali indicatori si verificano. Ogni cosa che il capitolato tace viene decisa dal fornitore, e il momento in cui l’amministrazione se ne accorge è quasi sempre quello in cui vorrebbe cambiare qualcosa.
Il tema ha smesso di essere una questione di buone pratiche con la bozza di linee guida Agid.
Capitolato di gara AI: norme e conformità nei documenti di gara
Chi bandisce una gara per un sistema di intelligenza artificiale lavora all’incrocio di due corpi normativi che parlano linguaggi diversi. Il Codice dei contratti pubblici disciplina come si individua il fabbisogno, si seleziona l’operatore e si definiscono le prestazioni. Il quadro sull’intelligenza artificiale, fra AI Act e legge 132/2025, individua requisiti e responsabilità collegati alle caratteristiche del sistema e al modo in cui viene impiegato.
I due corpi si incontrano in un punto solo, la documentazione di gara e il contratto, ed è lì che gli obblighi regolatori diventano specifiche tecniche, condizioni di partecipazione, criteri di valutazione e obbligazioni esigibili. Quello che non passa da quel punto resta un principio senza strumenti.
Fonte: elaborazione dell’autore
La conseguenza operativa è netta e cambia il modo di impostare la procedura: la conformità normativa del sistema smette di essere qualcosa che si verifica in esecuzione e diventa parte dell’oggetto dell’affidamento. Un’amministrazione che rimanda la verifica al collaudo si trova a contestare un sistema già costruito, con una leva contrattuale ridotta e tempi che nessun servizio pubblico può permettersi.
Capitolato di gara AI: fabbisogno, oggetto e dati
Se il punto di convergenza è quello, la domanda successiva riguarda il momento in cui le clausole vanno pensate. Le linee guida insistono sulle fasi iniziali, programmazione, progettazione e affidamento, perché lì l’amministrazione definisce il fabbisogno, individua la finalità del sistema e valuta se serva davvero una soluzione algoritmica.
Sull’oggetto la regola è evitare le formulazioni ampie fondate sul richiamo generico all’intelligenza artificiale, e sostituirle con prestazioni, risultati attesi, limiti operativi e indicatori di qualità verificabili. Il grado di autonomia riconosciuto al sistema va dichiarato in modo esplicito, perché è la variabile che determina tutto il resto: un sistema che propone una bozza di istruttoria e uno che produce un esito da controfirmare hanno lo stesso nome commerciale e regimi di responsabilità completamente diversi.
Dati e modifiche del sistema
Sui dati il capitolato deve specificare provenienza, qualità, aggiornamento e rappresentatività di quelli usati per addestramento, validazione e funzionamento, insieme ai diritti di accesso, utilizzo, conservazione e restituzione. Va aggiunto un obbligo informativo che quasi nessun capitolato ICT tradizionale prevede: il fornitore deve comunicare le modifiche ai dataset, al modello o alle modalità di funzionamento che possano incidere su prestazioni e rischi.
Quest’ultimo punto merita una sottolineatura, perché è la differenza strutturale rispetto a un appalto software ordinario. Un gestionale acquistato a marzo è lo stesso a novembre, un sistema basato su modelli linguistici può cambiare comportamento senza che l’amministrazione abbia toccato niente. Senza una clausola di notifica preventiva e un diritto di verifica sulle modifiche, l’amministrazione scopre il cambiamento dai reclami.
Fonte: elaborazione dell’autore su linee guida AgID, determinazione 43/2026
Capitolato di gara AI: sicurezza della catena di fornitura
Definiti oggetto e dati, il presidio non si esaurisce lì. Il perimetro è più largo del sistema stesso. L’acquisto e il funzionamento dipendono da infrastrutture digitali, servizi cloud e catene di fornitura ICT articolate, e la stazione appaltante deve considerare anche gli obblighi in materia di protezione dei dati personali, sicurezza informatica, accessibilità, conservazione documentale e continuità operativa.
Va valutata già in fase di progettazione della gara la localizzazione delle infrastrutture, l’impiego di subfornitori, le dipendenze da componenti esterne e le condizioni di accesso ai dati da parte di terzi. Il quadro si sta irrigidendo anche a monte: la proposta di revisione del Cybersecurity Act, in corso di approvazione a livello europeo, mira a rafforzare la sicurezza delle catene di fornitura ICT e potrebbe incidere sulle condizioni di partecipazione degli operatori di paesi terzi alle procedure di affidamento.
Un capitolato che non chiede queste informazioni non le otterrà spontaneamente, e ricostruirle a valle su un sistema in esercizio è un lavoro che costa molto più di una clausola scritta prima.
Capitolato di gara AI: evitare il lock-in e disciplinare l’uscita
C’è poi la domanda che quasi nessuno pone al primo incontro, e che va invece messa nel capitolato. Il rischio di dipendenza da un fornitore o da una soluzione proprietaria assume in questi progetti una fisionomia particolare. Non deriva solo dall’assenza di interoperabilità, deriva dalla difficoltà di trasferire dati e configurazioni a un altro operatore e dalla mancata disponibilità delle informazioni necessarie a comprendere il funzionamento del sistema.
Le clausole da inserire riguardano requisiti di interoperabilità e portabilità, uso di standard aperti dove possibile, obblighi di collaborazione in caso di cessazione del rapporto o subentro di un nuovo fornitore, restituzione dei dati, trasferibilità delle configurazioni, disponibilità della documentazione tecnica e limiti all’uso di componenti proprietarie non sostituibili.
Le linee guida chiariscono un punto che vale la pena riportare, perché smonta l’obiezione più frequente dei fornitori: evitare la dipendenza non comporta la divulgazione completa del codice sorgente o di ogni informazione riservata. Impone che l’amministrazione disponga di un livello di conoscenza e di accesso sufficiente a controllare il sistema, verificarne le prestazioni, accertare le anomalie e garantire la continuità del servizio pubblico. È una soglia funzionale, non una richiesta di apertura totale, e come tale è negoziabile senza compromettere il segreto industriale.
Capitolato di gara AI: supervisione umana e monitoraggio
L’ultimo profilo è quello che più spesso viene scritto male. La supervisione non può essere prevista in termini formali, attraverso la generica presenza di un operatore, perché una supervisione così definita non protegge nessuno e non regge in sede di contenzioso.
Poteri e competenze dell’operatore
Serve individuare soggetti dotati di competenze, poteri e informazioni adeguati per comprendere l’output, verificarne l’attendibilità e, quando necessario, non applicarlo, sospendere l’uso del sistema o richiederne la revisione. Tradotto in clausole significa formazione a carico del fornitore, accesso alla documentazione, tempi di risposta sulle richieste di chiarimento, e una procedura definita per la sospensione.
Controlli in corso di esecuzione
Il contratto deve disciplinare anche il monitoraggio successivo, con indicatori di prestazione, controlli periodici, obblighi di segnalazione degli incidenti e procedure per la gestione degli errori, insieme alla possibilità di verificare il sistema in corso di esecuzione attraverso audit, test e obblighi di cooperazione. E vanno previste clausole specifiche per il caso in cui il sistema venga modificato, aggiornato o riaddestrato durante il rapporto, con l’amministrazione messa in condizione di valutare se quelle modifiche richiedano nuove verifiche o una revisione delle condizioni d’uso.
Il procurement, in questo quadro, smette di essere il passaggio strumentale attraverso cui l’intelligenza artificiale entra nel settore pubblico e diventa lo strumento principale con cui l’amministrazione la governa. Le garanzie che la normativa richiede si costruiscono quasi tutte prima che il sistema venga acceso, dentro documenti che oggi molte stazioni appaltanti stanno scrivendo con i modelli degli appalti ICT tradizionali. Riscrivere quei modelli adesso costa qualche settimana di lavoro, e vale l’intera differenza fra un sistema che l’amministrazione controlla e uno che si limita a subire.
Partecipa alla community