La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 4. Metriche, costi, monitoraggio e gestione del contratto.
I commenti dovranno includere il numero del paragrafo o sotto-paragrafo (se presente) e un riferimento puntuale al brano di testo al quale si riferiscono (ad esempio paragrafo 4.3, terzo capoverso).
§ 4.8
Le API permettono a un’applicazione di sfruttare le funzionalità di un modello AI esterno senza necessità di installarlo e gestirlo in proprio, con un corrispettivo commisurato all’utilizzo effettivo. Non si tratta di uno strumento confinato alla sperimentazione, le API sono infatti correntemente impiegate anche come componenti di architetture progettuali complesse, nei casi in cui il volume di utilizzo di un determinato modulo non giustifichi gli investimenti per un’infrastruttura dedicata. Il beneficio principale risiede nella drastica riduzione degli investimenti iniziali e dei tempi di avvio operativo, con ricadute dirette sulla capacità delle Amministrazioni di rispondere a fabbisogni emergenti senza vincolarsi a impegni pluriennali difficilmente reversibili, circostanza non contemplata dalle Linee Guida.
Le Linee Guida attribuiscono tuttavia alle soluzioni basate su API un “livello di controllo limitato” e un “rischio di lock-in medio-alto”, raccomandandone il ricorso solo in presenza di fabbisogni incerti, attività di sperimentazione o servizi caratterizzati da domanda variabile.
Tale impostazione non è condivisibile, anche perché tratta il controllo come una proprietà intrinseca della modalità di deployment, anziché come una qualità del contratto e della governance. Un’architettura API sostenuta da clausole ben costruite - in materia di portabilità dei dati, condizioni di uscita, SLA verificabili e obblighi di audit - può garantire all’amministrazione un controllo operativo persino superiore a quello di un’installazione on-premises, la quale richiede competenze specialistiche interne e sposta la dipendenza dal fornitore del software al system integrator responsabile dell’installazione e della manutenzione. Di contro proprio quando la domanda è variabile occorre prestare attenzione all’uso delle API per poter esercitare un efficace controllo dei costi, pertanto sarebbe più opportuno citare il contesto di “domanda limitata” anziché “domanda variabile” come una delle circostanze di applicabilità delle API.
Orientare le amministrazioni verso soluzioni on-premises o architetture ibride di elevata complessità laddove non sia strettamente necessario produrrebbe inoltre un effetto selettivo a vantaggio dei grandi system integrator, penalizzando i prodotti SaaS nativi che rappresentano il modello di business prevalente di startup e PMI innovative nel settore AI. Ciò contrasta con il principio di accesso al mercato sancito dall’art. 3 del Codice che orienta l’intera impostazione del procurement.
E’ inoltre discutibile la sussistenza del lock-in derivante dall’uso di API nei casi in cui l’amministrazione non abbia sostenuto investimenti significativi e non vi sia alcuna dipendenza strutturale. Il rischio di dipendenza funzionale appare comunque gestibile, e lo stesso documento lo conferma implicitamente, raccomandando le API per la sperimentazione, che è esattamente il contesto in cui, in caso di esito positivo, si consolida la dipendenza funzionale più profonda. Se il rischio di lock-in fosse concreto e significativo, le API andrebbero trattate con estrema cautela già nella fase sperimentale anziché essere raccomandate come strumento per essa.
Il documento sembra infine sottovalutare un problema di realismo tecnico: per le capacità AI di maggiore rilevanza (es. modelli linguistici di grandi dimensioni, sistemi multimodali, visione computazionale avanzata) la soluzione on-premises non è concretamente accessibile a numerose pubbliche amministrazioni italiane per ragioni di costo infrastrutturale e di carenza di competenze. Il documento ne prende atto implicitamente nella sezione dedicata alla Generative AI, ma non ne trae le conseguenze nella classificazione delle opzioni di deployment, che presuppone acriticamente la loro equivalente praticabilità.
Segnaliamo le nostre proposte, puntualmente riferite ad alcuni passaggi.
Cordialmente
Paragrafo 4.3- Pag 56
È opportuno aggiungere una formula matematica esplicita o un box di esempio di calcolo semplificato. Ciò al fine di rendere il concetto di LCOAI immediatamente applicabile dai RUP tramite una formula visiva (es. LCOAI = (CAPEX + Somma (OPEX_t)) / Output_totale).
Paragrafo 4.9- Pag 71
A titolo di esempio è opportuno nominare alcune metriche; ad esempio:
- Metriche ambientali (LCA – Life Cycle Assessment): Carbon footprint: emissioni totali di CO₂ generate dal sistema lungo tutto il ciclo di vita, Energy consumption: consumo energetico complessivo (training, inferenza, storage, rete), Water footprint: acqua utilizzata per raffreddamento e produzione hardware, Material footprint: uso di materie prime, terre rare, componenti elettronici, E‑waste: rifiuti elettronici generati a fine vita.
- Metriche economiche (LCC – Life Cycle Costing): Costi di sviluppo: progettazione, addestramento, integrazione. Costi operativi: energia, manutenzione, aggiornamenti, licenze, Costi di dismissione: smaltimento hardware, migrazione dati, bonifica dei sistemi, Costi di rischio: incidenti, violazioni, downtime, non conformità normative.
- Metriche tecniche e prestazionali: Affidabilità: tasso di guasto, disponibilità del servizio, Scalabilità: capacità di sostenere carichi crescenti, Efficienza computazionale: FLOPS/Watt, tempo di inferenza, throughput, Obsolescenza tecnologica: tempo medio prima che hardware o modelli diventino superati.
- Metriche dei dati: Data retention: durata di conservazione dei dati, Data quality: completezza, accuratezza, aggiornamento, Data lineage: tracciabilità delle trasformazioni, Data disposal: modalità e sicurezza della cancellazione a fine vita.
- Metriche etiche e di governance: Trasparenza: documentazione del modello, dataset, decisioni, Accountability: responsabilità dei processi e delle scelte, Bias & fairness: misure di equità e assenza di discriminazioni, Compliance: aderenza a norme (GDPR, AI Act, standard ISO/IEC).
Il Comitato Scientifico dell’Osservatorio sull’Intelligenza Artificiale nelle Pubbliche Amministrazioni presenta le seguenti osservazioni:
Contributo a cura di Dedalus Italia S.p.A.
Dedalus propone che, nella sezione dedicata a metriche e gestione del contratto, le Linee Guida rendano più esplicito un set minimo di elementi contrattualmente misurabili per governare nel tempo prestazioni, costi e rischi. In particolare, oltre ai costi iniziali, si suggerisce di esplicitare la necessità di valutare e monitorare il costo totale (TCO) includendo esercizio, manutenzione evolutiva, aggiornamenti dei modelli, costi infrastrutturali/accelerazione e costi di compliance, con trasparenza sulle unità di costo rilevanti (ad es. per richiesta/per elaborazione/per chiamata a tool esterni o metriche equivalenti, dove applicabile) e sulle condizioni che possono modificarle.
Dal punto di vista del monitoraggio, si propone di richiamare esplicitamente KPI di qualità del servizio e affidabilità (SLA/SLO), indicatori di stabilità e degrado delle prestazioni nel tempo (incluse soglie e procedure di intervento), auditabilità e tracciabilità del comportamento del sistema (con particolare attenzione all’orchestrazione e alle integrazioni esterne), oltre a requisiti minimi di logging e monitoraggio utili a detection e incident response. Per sistemi generativi/agentici, può essere utile rendere “contrattabili” anche metriche di sicurezza e qualità dell’output (ad esempio tasso di output non conforme, eventi di prompt injection rilevati, fallimenti dei guardrail), così da collegare il comportamento del sistema a presìdi di governance e a piani di miglioramento.
Infine, nella parte di gestione del contratto, Dedalus suggerisce di esplicitare presìdi che abilitano il governo nel tempo: change control per modifiche e versioning, obblighi di notifica incidenti e vulnerabilità, gestione delle dipendenze e patching, diritto di audit su componenti critiche e soggetti terzi rilevanti, e revisioni periodiche tecnico‑funzionali e di sicurezza. Questi elementi rendono le Linee Guida immediatamente più utilizzabili dalle PA per capitolati e contratti, riducendo ambiguità e rischi di non governabilità.
Par 4.2 — Limiti degli approcci economici tradizionali / §4.8 — Comparabilità delle strategie di deployment
Le linee guida parrebbero esprimere diffidenza verso i modelli a consumo senza riconoscerne i vantaggi: trasparenza del costo unitario, scalabilità, assenza di costi fissi iniziali. Con adeguati strumenti di governance come, ad esempio, budget alerts, spending limits e strumenti di forecasting i modelli pay-per-use offrono prevedibilità della spesa comparabile al licensing tradizionale.
Si chiede di chiarire esplicitamente che i modelli pay-per-use sono compatibili con il procurement pubblico se accompagnati da clausole di controllo della spesa quali budget alerts, spending limits, strumenti di forecasting, che rendono questi modelli comparabili ai modelli a licenza tradizionale sul piano della prevedibilità dei costi.
Si raccomanda che il necessario confronto LCOAI non escluda a priori alcuna tipologia di deployment: la convenienza relativa tra modello a consumo, licenza tradizionale e modello open weight su infrastruttura qualificata dipende dai volumi, dal caso d’uso e dagli strumenti di governance adottati.
Contributo a cura di Zigrida Alushaj, avvocato iscritto all’Ordine degli Avvocati di Milano.
Paragrafo 4.10.
Sarebbe opportuno modificare la disposizione introducendo un criterio esplicito di proporzionalità, in linea con l’IA Act, prevedendo che l’obbligo di documentazione e di conservazione sia modulato in funzione del livello di rischio, della finalità e dell’impatto del sistema di IA.
In tale contesto, potrebbe altresì essere valorizzata l’adozione di software di AI compliance e governance, automatizzando i processi di documentazione e conservazione in modo coerente con il livello di rischio, così da rendere l’adempimento non solo formalmente corretto, ma anche sostenibile ed effettivamente funzionale al controllo dei sistemi di IA nella pubblica amministrazione.
Contributo a cura di Traent Srl.
Si propone di rivedere la Tabella 8 del §4.8 “Comparabilità delle strategie di deployment” (pag. 70), che attribuisce alle soluzioni basate su API un livello di controllo «Limitato» e alle soluzioni self-hosted un controllo «Elevato». Tale caratterizzazione presenta un bias che rischia di penalizzare soluzioni innovative e di indurre le PA verso deployment on-premises non sempre sostenibili — in contraddizione con la stessa Bozza che raccomanda di «adottare decisioni maggiormente coerenti con gli obiettivi di sostenibilità, governabilità e continuità del servizio» (§4.8, pag. 67). Si suggerisce di riformulare la colonna «Livello di controllo» distinguendo tra controllo fisico (localizzazione), controllo logico (governance dato/modello) e controllo verificabile (evidenze certificate), riconoscendo che un deployment via API con infrastruttura di trust può offrire un controllo verificabile superiore a un on-premises privo di meccanismi di certificazione.
Inoltre, si propone di integrare la Tabella 7 (§4.5, pag. 62) — che individua le categorie CAPEX, OPEX, costi organizzativi e costi di uscita/transizione — con una voce esplicita denominata «Costo della fiducia e della verifica» (Trust Infrastructure Cost), comprendente: audit e certificazione periodica, monitoraggio della conformità contrattuale, risoluzione delle controversie, verifica della portabilità. La Tabella 7 riconosce i costi di uscita come «eventuali ma strategici, con un impatto critico sul LCOAI» (pag. 63), ma non contempla il costo strutturale della verifica di conformità, che le PA sostengono in modo ricorrente. Si chiede che la formula LCOAI (§4.3) incorpori il Trust Infrastructure Cost come variabile, consentendo alle PA di confrontare soluzioni anche sulla base del costo totale della fiducia verificabile.
Si evidenzia una criticità rilevante nella definizione delle metriche e dei modelli economici, in particolare per quanto riguarda la componente qualitativa del Lifetime Cost of AI (LCOAI), che nella formulazione attuale non risulta misurabile né verificabile. Ciò espone le amministrazioni al rischio di offerte basate su benefici dichiarati ma non dimostrabili. Si propone quindi di definire la componente qualitativa attraverso indicatori concreti e misurabili, quali tasso di automazione, tasso di intervento umano, tempo medio di decisione e tasso di errori con impatto amministrativo. Inoltre, si suggerisce di rendere obbligatoria la definizione di metriche di monitoraggio operativo con soglie numeriche e frequenze di reporting, nonché di introdurre meccanismi contrattuali di sospensione del sistema in caso di degrado significativo delle prestazioni. Tale integrazione consentirebbe di rendere il monitoraggio effettivo, di migliorare la trasparenza dei costi e di rafforzare la capacità delle PA di gestire contratti complessi basati su IA.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.