AgID il 12 marzo 2026 ha avviato la consultazione pubblica sulla bozza di linee guida per il procurement di IA nella Pubblica Amministrazione. Si va così ampliando il perimetro delle Linee Guida pubblicate da AgID che delineano regole e standard nel settore pubblico ICT. In questo caso le critiche sono davvero gradite e opportune, almeno fino all’11 aprile 2026.
C’è davvero qualcosa di specifico da dire sul procurement dell’AI? Il documento declina nell’ambito AI i principi di procurement che già valgono per qualsiasi fornitura ICT articolata. Da quando AGID ha scelto la strada difficile di specializzare verticalmente le linee guida per settore merceologico all’interno dell’ICT, quelle sul procurement IA dovevamo aspettarcele.
Indice degli argomenti
Dove il procurement IA nella Pubblica Amministrazione aggiunge valore
Il lock-in tecnologico, la governance del dato, le clausole di portabilità, la valutazione del ciclo di vita, il rischio di dipendenza dal fornitore, la difficoltà di definire SLA su sistemi evolutivi, l’esigenza di flessibilità sono problemi noti da decenni nel procurement dei sistemi informativi. Li ritroviamo nelle stesse forme nel procurement di ERP, di piattaforme cloud, di sistemi di gestione documentale, di cybersecurity.
Il documento dunque paventa rischi e fornisce raccomandazioni che nell’informatica sono prassi da un ventennio ma lo fa anche con riferimento ai problemi nuovi e specifici dell’AI quali ad esempio il model drift ossia la degradazione delle prestazioni nel tempo senza che alcun indicatore contrattuale tradizionale lo rilevi o l’explainability ossia la comprensibilità delle decisioni, elemento fondante per la trasparenza di un sistema che non agisce in modo deterministico.
Il timore è che in tal modo non si riesca a raggiungere l’incisività per risolvere problemi reali e il documento sia utile come lista di consapevolezza solo per funzionari che non hanno mai acquistato sistemi AI. In questi casi sarebbe più opportuno raccomandare esplicitamente di affidare lo studio di fattibilità e la progettazione della gara a esperti esterni. È una prassi tanto diffusa quanto ingiustamente stigmatizzata dal pregiudizio che la consulenza non produca valore, e probabilmente proprio per questo il documento non ha avuto il coraggio di dirlo, perdendo l’occasione di dare un’indicazione concreta proprio laddove ce n’era più bisogno.
I confini del procurement IA nella Pubblica Amministrazione e le sovrapposizioni
Il documento rimanda spesso alle Linee guida per l’adozione di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione per definizioni, architettura logica, ciclo di vita. L’ambito delle due linee guida è dichiaratamente il procurement e l’adozione ma nella pratica si sovrappongono sistematicamente perché si tratta di due aree senza un confine unico e definito. I principi del procurement di IA sono in larga parte corollari di principi già enunciati nelle linee guida sull’adozione, semplicemente tradotti in linguaggio contrattuale. La frammentazione in documenti separati aggiunge complessità di navigazione per la PA e aumenta il rischio di sovrapposizioni e di disallineamento tra i due documenti, considerando anche l’elevata volatilità dei contenuti.
Quando il procurement IA nella Pubblica Amministrazione incontra l’aggregazione
È noto che l’aggregazione della domanda produce benefici solo quando sussistono contemporaneamente tre presupposti:
- la prestazione è sufficientemente standardizzabile da poter essere definita in modo uniforme per più committenti;
- il mercato è maturo e concentrato in fornitori di grandi dimensioni con i quali la domanda aggregata accresce il potere negoziale;
- i fabbisogni degli enti aggregati sono sufficientemente omogenei da non richiedere personalizzazioni sostanziali che annullino i vantaggi delle economie di scala.
Nel settore AI nessuna delle tre condizioni si verifica pienamente, e lo stesso documento lo dimostra spiegando che ogni sistema AI è contestuale, dipendente dai dati specifici dell’amministrazione, dall’architettura dei sistemi informativi preesistenti, dalle sue competenze interne, dal suo livello di maturità digitale. Tuttavia il documento conclude che si dovrebbe aggregare la domanda creando una inopportuna tensione e sfiorando la contraddizione.
Nel procurement AI, peraltro aggregare la domanda rischia di avvantaggiare ulteriormente i pochissimi operatori che hanno la dimensione per rispondere a gare aggregate riducendo di fatto la concorrenza anziché aumentarla e creando concentrazioni di mercato, come è accaduto nel settore della consulenza strategica e ICT e nel settore dello sviluppo applicativo.
Ulteriore conferma della gratuità del tributo a Consip e alle Centrali di Committenza viene dalla giusta affermazione che il fabbisogno non pienamente determinato, l’incertezza tecnologica, la necessità di sperimentazione e la forte componente innovativa tipici dell’IA rendono adeguato il ricorso agli strumenti quali il dialogo competitivo o la procedura competitiva con negoziazione, circostanza in piena antitesi con la pratica della aggregazione della domanda.
I principi del Codice nel procurement IA nella Pubblica Amministrazione
Il Codice dei Contratti Pubblici D.Lgs. 36/2023 ha introdotto i principi di risultato, della fiducia e dell’accesso al mercato come principi regolativi dell’intera attività di progettazione di una gara, non riducendoli a meri criteri per definire i requisiti dell’appalto come invece le Linee Guida sembrano affermare. E infatti:
- il principio del risultato governa come si esercita la discrezionalità, ossia come la stazione appaltante deve scegliere la procedura, i criteri di aggiudicazione e le condizioni contrattuali che massimizzano il conseguimento dell’interesse pubblico concreto;
- Il principio della fiducia fa da contrappeso a tutti gli altri principi sollevando il funzionario da timori di responsabilità quando esercita correttamente la propria discrezionalità;
- Il principio dell’accesso al mercato orienta l’intera impostazione della procedura di gara, imponendo che nessuna scelta, dai requisiti di partecipazione alla struttura del contratto, sia ingiustificatamente restrittiva o discriminatoria nei confronti degli operatori economici.
- Il documento invece applica questi principi in modo atipico e riduttivo ai requisiti dell’appalto svuotandoli del loro contenuto sistemico, affermando che:
- il principio del risultato implica la definizione di obiettivi chiari, prestazioni misurabili e il monitoraggio;
- il principio della fiducia implica la responsabilizzazione delle amministrazioni e la valorizzazione delle competenze interne;
- il principio dell’accesso al mercato implica la promozione di standard aperti, architetture modulari e soluzioni interoperabili.
Il Codice ha introdotto quei principi proprio per orientare le scelte procedurali e autorizzare la PA a superare il timore di prendere decisioni come ad esempio scegliere tipi di negoziazione meno comuni ma più appropriati quali il dialogo competitivo, la procedura competitiva con negoziazione o la procedura negoziata, evitare di cadere nel massimo ribasso, gestire modifiche contrattuali ed altro ancora, ma il documento non sfrutta in alcun modo questa opportunità.
La logica sottesa al principio di accesso al mercato dovrebbe indurre estrema cautela nell’uso di convenzioni e accordi quadro per l’AI, strumenti pensati per merceologie standardizzate con mercati presidiati da Grandi Imprese e fabbisogni omogenei, che rischiano di produrre effetti anticoncorrenziali in un mercato frammentato e ancora in rapida evoluzione come quello dell’intelligenza artificiale.
Come cambia il procurement IA nella Pubblica Amministrazione nelle gare
Quasi a giustificare l’esistenza delle linee guida, la sezione esordisce affermando che per redigere la documentazione di gara occorre superare modelli standardizzati mutuati da altre tipologie di forniture ICT e ripensare le modalità attraverso cui il fabbisogno viene tradotto in requisiti di gara. E prosegue suggerendo di “privilegiare una definizione del fabbisogno orientata ai risultati e alle prestazioni attese, piuttosto che a specifiche tecnologiche rigide e prescrittive”, pur omettendo di osservare come rafforzativo che questa giusta soluzione è una prassi comune per molte altre tipologie di forniture e servizi ICT. E infatti la sezione inerente al Capitolato Tecnico declina molto bene le best practice del procurement al comparto dell’AI, pur essendo applicabile tal quale anche a contratti informatici se si eliminano un paio di termini molto specifici inerenti all’AI.
Ma lascia l’amaro in bocca la sezione inerente ai criteri di aggiudicazione e di valutazione della qualità che ricade nell’approccio precedentemente stigmatizzato di non valutare la prestazione ma solo aspetti tecnologici – qualità architetturale, sostenibilità economica, ciclo di vita, capacità evolutiva, ecc. – su cui difficilmente la PA ha competenze e soprattutto che molto spesso non sono in connessione diretta con la qualità effettivamente erogata.
In una merceologia ove le stesse Linee Guida suggeriscono che la definizione del fabbisogno sia orientata ai risultati e alle prestazioni attese anziché a specifiche tecnologiche rigide e prescrittive, la comparazione tra offerte in una gara pubblica non dovrebbe avere ad oggetto le tecnologie usate come mezzo ma la capacità di conseguire l’obiettivo della stazione appaltante e la misura in cui esso è raggiunto. È la stessa logica con cui si valuta qualsiasi appalto di servizi complessi: non si valuta il mezzo ma la prestazione. E il vantaggio è che in questo caso non si valutano promesse non verificabili ma prestazioni concrete che possono essere disciplinate come livelli di servizio nel contratto e tutelate da penali.
Soluzioni API e procurement IA nella Pubblica Amministrazione
Le API (Application Programming Interface) sono interfacce che consentono a un’applicazione di utilizzare le funzionalità di un modello AI esterno senza installarlo e gestirlo internamente, pagando in funzione dell’utilizzo. Non si tratta di una soluzione riservata solo alla sperimentazione, le API sono correntemente utilizzate anche come componenti di progetti complessi, se la domanda su un determinato modulo non giustifica gli investimenti per un’infrastruttura dedicata. Il vantaggio principale è la riduzione drastica degli investimenti e dei tempi di messa in esercizio, con benefici diretti sulla capacità della PA di rispondere a fabbisogni emergenti senza impegnarsi in investimenti pluriennali difficilmente reversibili, circostanze del tutto non contemplate dalle Linee Guida. Circa il vantaggio riguardante gli investimenti elevati, non si tratta di noleggiare una automobile anziché acquistarla, ma di acquistare un biglietto aereo anziché acquistare un aereo di linea.
Le Linee Guida tuttavia attribuiscono alle soluzioni basate su API un “livello di controllo limitato” e un “rischio di lock-in medio-alto“, raccomandandole solo per fabbisogni incerti, sperimentazioni o servizi a domanda variabile.
Ciò non è condivisibile anche perché significa considerare il controllo una proprietà intrinseca del modello di deployment anziché una proprietà del contratto e della governance. Una soluzione API con clausole ben costruite su portabilità dei dati, condizioni di uscita, SLA verificabili e obblighi di audit può garantire alla PA un controllo operativo anche superiore a quello di un’installazione on-premises che richiede competenze e trasferisce la dipendenza dal fornitore del software al system integrator responsabile dell’installazione e della manutenzione.
Orientare le PA verso soluzioni on-premises o architetture ibride complesse laddove non è indispensabile favorisce inoltre i grandi system integrator e scoraggia i prodotti SaaS nativi che costituiscono il modello di business prevalente delle startup e delle PMI innovative nel settore AI. Questo contrasta con lo stesso principio di accesso al mercato sancito dall’art. 3 del Codice, che non si applica solo alla costruzione dei requisiti di partecipazione ma soprattutto orienta l’intera impostazione del procurement.
Il nodo del lock-in
È anche discutibile la sussistenza del lock-in derivante dall’uso di API laddove la committente non ha sostenuto investimenti né altro e non vi è dipendenza strutturale. Si ritiene altresì modesto o comunque gestibile il rischio di dipendenza funzionale, e lo stesso documento lo conferma raccomandando le API per la sperimentazione, che è esattamente il contesto in cui – se la sperimentazione ha successo – si costruisce la dipendenza funzionale più profonda. Se esistesse un concreto e significativo rischio di lock-in, la soluzione API dovrebbe essere usata con estrema cautela anche per la sperimentazione.
Vi è inoltre un problema di realismo tecnico: per le capacità AI più rilevanti quali modelli linguistici di grandi dimensioni, sistemi multimodali, visione computazionale avanzata, l’opzione on-premises non è concretamente accessibile alla gran parte delle PA italiane per ragioni di costo infrastrutturale e di competenze. Il documento lo riconosce implicitamente nella sezione sulla Generative AI, ma non ne tiene conto nella classificazione che presuppone acriticamente che tutte le opzioni di deployment siano equivalentemente praticabili.
Il mercato reale del procurement IA nella Pubblica Amministrazione
In sintesi le Linee Guida danno l’impressione di essere redatte secondo il presupposto del grande appalto pluriennale ad alto investimento su cui esse hanno indubbia utilità. Non contemplano infatti il caso dei contratti di valore limitato o di durata breve e le soluzioni verticali pronte all’uso. Questo presupposto implicito si riflette su tutti i temi trattati: la classificazione del deployment, i requisiti architetturali, la compliance, la spinta all’aggregazione della domanda, il pregiudizio nei confronti delle API.
La scelta ha conseguenze concrete sul mercato e sulla qualità degli acquisti. Sul piano del mercato, un framework calibrato sul grande appalto pluriennale scoraggia strutturalmente l’accesso delle startup e delle PMI innovative, che proprio nei contratti di valore limitato, durata breve e soluzione verticale pronta all’uso esprimono la loro competitività. In molti casi la soluzione ottimale – rapida, economica, proporzionata – non viene neanche valutata perché il framework non la contempla.
Se le Linee Guida nella versione attuale fossero usate in modo generalizzato per tutti gli appalti IA:
- provocherebbero una ulteriore concentrazione del mercato a favore dei grandi system integrator, con riduzione della pressione competitiva e dell’innovazione nell’offerta;
- orienterebbero la PA verso soluzioni sovradimensionate rispetto al fabbisogno reale, con investimenti iniziali elevati, lunghi tempi di messa in esercizio e rigidità contrattuale che mal si conciliano con la velocità di evoluzione tecnologica dell’AI.
Per tali motivi il framework oggetto di consultazione pubblica non è ancora adeguato a una parte significativa dell’attuale mercato AI, pertanto dovrebbe essere largamente rivisto e integrato a meno di chiarire che l’ambito di applicazione è limitato esclusivamente ai progetti di grande rilievo.
