La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi allo Strumento C - Esempio LCOAI.
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).
L’attuale definizione del denominatore Q come “numero di inferenze valide (output produttivi) nel periodo considerato” proposta dallo Strumento C (paragrafo 2) risulta, in molti contesti della Pubblica Amministrazione, non effettivamente misurabile né ex ante, e spesso nemmeno ex post, rendendo il dato poco verificabile e quindi fragile ai fini comparativi. I sistemi di IA, essendo tipicamente di tipo probabilistico, producono o possono generare, a parità di input, risposte diverse se la medesima richiesta viene formulata in momenti differenti, in funzione dello stato interno, del contesto, della non determinicità del processo inferenziale e di eventuali aggiornamenti o variazioni operative.
Si potrebbe valutare di sostituire il denominatore Q definito come “numero di inferenze valide nel periodo considerato” con il “numero di Giorni/Persona (GGPP) equivalenti che sarebbero necessari per svolgere la medesima attività in assenza del sistema di IA”. In tal modo, il LCOAI esprimerebbe un costo per GGPP e consentirebbe un confronto diretto con l’alternativa manuale, superando le criticità di misurabilità e verificabilità del conteggio delle inferenze.
La formula potrebbe inoltre considerare una finestra temporale variabile “k” come numero di annualità.
In tal caso: LCOAI = (CAPEX + k*OPEX) / Q;
esprimerebbe il costo equivalente del GGPP del sistema AI su “k” anni.
Lo Strumento C esemplifica il calcolo LCOAI con voci CAPEX, tra cui “Integrazione sistemi”, “Configurazione sicurezza e compliance” e “Test e avviamento”, e voci OPEX quali “Consumo API”, “Monitoraggio e logging”, “Personale supervisione”, e nello scenario self-hosted “Manutenzione infrastruttura”, “Ri-addestramento” e “Personale tecnico”. Al §4 si afferma che l’LCOAI serve a “superare il confronto basato solo sul prezzo per token” e a “costruire basi d’asta più aderenti alla realtà operativa”; al §5 l’indicatore è usato per “evitare sottostime strategiche” e “individuare squilibri tra investimento iniziale e costi ricorrenti”.
Nell’esempio non compare alcuna voce di costo riferita al red-teaming avversariale del sistema di IA, né in CAPEX, dove la sola “Configurazione sicurezza e compliance” resta generica e non distingue verifiche avversariali da hardening, né in OPEX, dove mancano sia il red-teaming periodico sia quello a evento post-aggiornamento. L’omissione è rilevante, perché se il red-teaming non figura come voce esplicita nella metrica che guida la base d’asta, esso rischia di essere strutturalmente compresso in gara per ragioni di prezzo, in contrasto con gli stessi obiettivi dichiarati dal documento, cioè evitare sottostime strategiche e riflettere meglio la realtà operativa lungo il ciclo di vita.
Raccomandazione: integrare l’esempio LCOAI come segue:
(a) CAPEX: aggiungere una voce autonoma “Red-teaming pre-collaudo del sistema di IA”, distinta dalla generica configurazione di sicurezza, riferita all’attività di verifica avversariale propedeutica all’accettazione della fornitura.
(b) OPEX: aggiungere due voci autonome ricorrenti, “Red-teaming periodico” e “Red-teaming a evento”, entrambe distinte dalle voci di monitoraggio e logging e dal personale di supervisione. Gli eventi trigger possono includere aggiornamento del modello, modifica del system prompt, variazioni di tool/connettori, modifica del corpus RAG, nuovo fine-tuning o modifica delle guardrail.
(c) §4 – Interpretazione per il procurement pubblico: richiamare esplicitamente il red-teaming come componente non comprimibile del costo del ciclo di vita, a tutela della sicurezza e robustezza del sistema e in coerenza con quanto richiesto nello Schema di Capitolato Tecnico.
(d) §5 – Utilizzo nella determinazione della base d’asta: indicare che la stazione appaltante, nella verifica di coerenza delle offerte e nell’individuazione di sottostime strategiche, dovrebbe considerare indice di sottostima l’assenza o la compressione ingiustificata delle voci di red-teaming rispetto al profilo di rischio del sistema.
Il dettaglio degli obblighi contrattuali e dei criteri di selezione dei fornitori di red-teaming è trattato nei commenti al thread principale delle Linee guida procurement, cui si rinvia.
Contributo a cura di Traent Srl.
Si propone di integrare lo Strumento C (Esempio LCOAI) con una voce di costo esplicita dedicata all’infrastruttura di verifica e certificazione della conformità: (a) CAPEX – nuova voce «Setup infrastruttura di verifica e notarizzazione»: costo una tantum per la configurazione dell’infrastruttura di notarizzazione crittografica delle evidenze di conformità, indipendente dal fornitore del sistema IA, comprensivo di integrazione con il sistema di logging/monitoraggio, configurazione dei protocolli di marcatura temporale qualificata e setup del registro di conformità. Voce distinta e complementare alla «Configurazione sicurezza e compliance» già presente e al «Red-teaming pre-collaudo» proposto da altri commentatori. (b) OPEX – nuova voce «Costo della fiducia e della verifica certificata» (Trust Infrastructure Cost): costo ricorrente comprensivo di registrazione certificata degli esiti di audit, notarizzazione delle milestone contrattuali, alimentazione del registro federato di conformità. Questa voce rende espliciti il costo oggi nascosto che le PA sostengono per audit manuali ripetitivi, gestioni del contenzioso e verifiche ridondanti. (c) §4: richiamare il Trust Infrastructure Cost come componente strutturale del LCOAI, al pari dei costi di sicurezza e formazione. (d) §5: indicare che la stazione appaltante dovrebbe considerare indice di maturità la presenza di un’infrastruttura di notarizzazione indipendente, e indice di sottostima l’assenza di qualsiasi voce relativa alla verifica certificata. Si osserva inoltre che la misurabilità e verificabilità del denominatore Q è essa stessa una questione di infrastruttura di trust: un sistema che registra con notarizzazione crittografica le proprie metriche operative offre un denominatore più affidabile e contestabile.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.