Capitolati IA nelle gare pubbliche: le clausole che le PA non possono più ignorare

lentepubblica.it

IA nella PA, il capitolato diventa decisivo: così le nuove linee guida AgID cambiano le gare.

La vera partita dell’intelligenza artificiale nella Pubblica Amministrazione non si gioca quando il software viene acceso, ma molto prima: nel momento in cui l’ente progetta la gara e scrive il capitolato. È questa la chiave di lettura che emerge dalla bozza delle Linee guida AgID per il procurement di IA nella PA, pensate per accompagnare le amministrazioni nell’acquisizione di strumenti sempre più presenti nei servizi pubblici.

Non si tratta soltanto di comprare una tecnologia più moderna. Un sistema di IA può elaborare grandi quantità di informazioni, proporre classificazioni, generare testi, individuare anomalie o supportare il lavoro degli uffici. Ma, proprio perché può incidere sull’organizzazione, sui dati e in alcuni casi su procedimenti che coinvolgono cittadini e imprese, non può essere acquistato come un normale programma informatico.

Le linee di indirizzo invitano quindi le PA a definire con precisione, già prima dell’affidamento, quale bisogno concreto si vuole soddisfare, quali funzioni saranno affidate alla soluzione digitale e quali resteranno necessariamente nelle mani del personale pubblico. In altre parole, il contratto deve trasformare principi generali e obblighi normativi in impegni effettivamente controllabili.

Prima della gara serve una domanda chiara: a cosa serve davvero l’IA?

Uno degli errori più frequenti nel dibattito sull’innovazione è partire dallo strumento invece che dal problema. Le indicazioni AgID ribaltano questo approccio: una Pubblica Amministrazione dovrebbe innanzitutto analizzare il proprio fabbisogno, verificare se l’uso dell’intelligenza artificiale sia proporzionato e valutare le alternative disponibili.

Non ogni attività richiede un modello generativo o un sistema complesso basato su apprendimento automatico. In alcuni casi possono bastare strumenti tradizionali, procedure meglio organizzate o soluzioni statistiche più semplici e prevedibili. La scelta deve tenere conto dell’obiettivo atteso, del contesto in cui il sistema opererà, delle competenze interne e del livello di rischio.

Un’applicazione che aiuta a ordinare richieste ripetitive non presenta gli stessi problemi di una soluzione impiegata per sostenere valutazioni che incidono su diritti, prestazioni o accesso a servizi. Per questo il capitolato non può limitarsi a descrivere le funzionalità desiderate: deve chiarire il grado di autonomia del sistema, le modalità di intervento umano e le responsabilità di chi utilizza gli output prodotti dall’algoritmo.

La titolarità della decisione, infatti, resta in capo alla PA. L’IA può supportare, segnalare, elaborare o suggerire, ma non può diventare una scatola nera alla quale affidare senza controllo una scelta amministrativa. Servono ruoli definiti, procedure di verifica e la possibilità di sospendere o correggere il funzionamento della piattaforma quando emergono criticità.

Dati, accesso e portabilità: evitare la dipendenza dal fornitore

Il cuore di qualunque sistema di intelligenza artificiale è rappresentato dai dati. Da qui la necessità di stabilire sin dall’inizio quali informazioni saranno utilizzate, da dove provengono, chi può accedervi e per quali finalità. La bozza richiama la necessità di distinguere accuratamente i dati già disponibili presso l’amministrazione da quelli eventualmente generati, arricchiti o rielaborati dalla soluzione acquistata.

Questo passaggio ha conseguenze molto pratiche. Nel contratto vanno indicati i diritti di accesso, utilizzo, conservazione, riuso e restituzione delle informazioni. Occorre inoltre disciplinare in modo esplicito l’eventuale impiego dei dati da parte del fornitore per addestrare, migliorare o sviluppare altri prodotti. Un dato pubblico non può diventare, senza regole trasparenti, materia prima per finalità estranee al servizio affidato.

La questione riguarda anche la continuità dell’azione amministrativa. Se al termine del contratto l’ente non riesce a recuperare i propri dati, a trasferirli in formati utilizzabili o a far subentrare un altro operatore, il rischio è quello del cosiddetto lock-in: una dipendenza tecnica ed economica dal fornitore che rende difficile, se non impossibile, cambiare soluzione.

Le linee guida spingono perciò verso standard aperti, formati interoperabili, architetture documentate e clausole di portabilità. Non è un dettaglio tecnico: è una garanzia per la PA, che deve poter mantenere il controllo delle proprie informazioni e continuare a erogare il servizio anche in caso di migrazione verso un’altra piattaforma o di cessazione del rapporto contrattuale.

Sicurezza e trasparenza non possono restare formule generiche

La cybersicurezza è un altro snodo centrale. Un sistema di IA può esporre l’amministrazione a rischi legati alla riservatezza dei dati, alla manipolazione degli input, alla compromissione dei modelli oppure a utilizzi impropri delle informazioni prodotte. Per questo le misure di protezione non dovrebbero comparire soltanto nelle informative o nelle dichiarazioni del fornitore, ma tradursi in requisiti tecnici e organizzativi verificabili.

La PA dovrà poter conoscere il comportamento della soluzione, disporre della documentazione necessaria, accedere alle evidenze utili per i controlli e verificare la qualità delle prestazioni nel tempo. La trasparenza, in questa prospettiva, non significa obbligare ogni amministrazione a comprendere nel dettaglio il codice sorgente di un modello, ma garantirle una visibilità adeguata su configurazioni, regole operative, log, dati trattati e limiti del sistema.

Particolare attenzione viene riservata ai sistemi più complessi, come quelli di IA generativa, spesso forniti attraverso servizi cloud o API. Qui diventano rilevanti il controllo dei costi legati al consumo, la registrazione delle operazioni, la gestione degli input e degli output, l’auditabilità e la possibilità di sostituire componenti critiche. Un contratto costruito male può trasformare un progetto innovativo in un costo crescente e poco governabile.

Dal collaudo al monitoraggio: l’IA va seguita per tutto il contratto

Un’altra novità di impostazione riguarda il tempo. A differenza di molte forniture informatiche tradizionali, l’intelligenza artificiale può cambiare il proprio comportamento in relazione ai dati, agli aggiornamenti e alle configurazioni. Per questo non basta verificare il sistema il giorno del collaudo: servono metriche, livelli di servizio e controlli periodici.

Il capitolato dovrebbe prevedere indicatori misurabili sulla qualità degli output, sulla disponibilità del servizio, sulla gestione degli incidenti, sui tempi di risposta e sulle eventuali anomalie. Gli uffici devono poter effettuare audit, chiedere correzioni, validare gli aggiornamenti e disporre di strumenti per monitorare le prestazioni durante l’intera esecuzione del contratto.

Le linee guida propongono inoltre di superare una lettura limitata al prezzo di acquisto. Per valutare una soluzione di IA è necessario considerare il costo lungo l’intero ciclo di vita: infrastrutture, consumi, manutenzione, addestramento, aggiornamenti, assistenza, sicurezza, personale e migrazione finale. Una proposta apparentemente economica può risultare onerosa se richiede risorse continue o vincola l’ente a tecnologie difficili da sostituire.

Il messaggio di fondo è chiaro: la PA non deve subire l’innovazione, ma governarla. Il capitolato diventa così il primo presidio di interesse pubblico, perché è il documento nel quale vengono fissati confini, diritti, responsabilità e condizioni di controllo. Prima di affidare un sistema di IA, l’amministrazione deve quindi essere in grado di rispondere a una domanda essenziale: sapremo davvero controllare ciò che stiamo acquistando?

La bozza dell’AgID

Qui il documento completo.

The post Capitolati IA nelle gare pubbliche: le clausole che le PA non possono più ignorare appeared first on lentepubblica.it.