La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Durante questo periodo sarà possibile commentare le diverse parti in cui è suddiviso il documento usando gli argomenti presenti in questa categoria del forum.
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).
Le linee guida rischiano di penalizzare le startup innovative, a tutto vantaggio di fornitori tradizionali costosi e poco efficienti. Di seguito si segnalano alcune criticità dal punto di vista delle startup innovative, con alcune proposte di riformulazione.
La spinta verso aggregazioni, Consip e Accordi Quadro (Cap. 5.4)
Il documento (Sezione 5.4) incoraggia fortemente le aggregazioni di acquisto (centrali regionali, provinciali e Consip) e l’uso di Accordi Quadro per “economie di scala” e “razionalizzazione della spesa”. Si fa persino riferimento all’“obbligo di ricorrere alle convenzioni o agli accordi quadro stipulati dai soggetti aggregatori”. Gli Accordi Quadro richiedono requisiti di partecipazione inarrivabili per una startup (fatturati pregressi enormi, coperture fideiussorie, certificazioni multiple, capacità di erogazione su tutto il territorio nazionale). Le startup vengono sistematicamente escluse come prime contractor e relegate, nel migliore dei casi, a subappaltatori “spremuti” dai grandi integratori.
Penalizzazione del modello API/SaaS a favore di On-Premises/Ibrido (Cap. 4.8 e Tabella 8)
Nella valutazione delle strategie di deployment (Tab. 8), le soluzioni basate su API (il modello di business tipico delle startup AI) vengono classificate con un “Rischio di lock-in Medio-Alto”, un “Livello di controllo Limitato” e consigliate solo per “fabbisogni incerti o sperimentazioni”. Al contrario, le architetture “Self-hosted” o “Ibride” sono lodate per l’alto controllo e il basso lock-in. Le startup spesso offrono soluzioni SaaS o API altamente ottimizzate e pronte all’uso (“plug & play”). I grandi integratori, invece, vivono di progetti custom (CAPEX elevati per costruire infrastrutture self-hosted o ibride). Chiedere alla PA di privilegiare installazioni on-premises o architetture ibride complesse significa tagliare fuori i prodotti “as-a-service” delle startup a favore di lunghi e costosi progetti di system integration.
Scomposizione Architetturale e Neutralità Hardware (Cap. 3.3 e 3.5.1)
Si richiede (Cap. 3.3) che l’architettura logica separi rigidamente l’orchestratore, i modelli, i dati e i tool applicativi, pretendendo la “sostituibilità” di ogni singolo pezzo. Inoltre (Cap 3.5.1), si impongono requisiti di “neutralità hardware”, chiedendo persino piani di fallback per far girare i modelli su semplici CPU anziché su GPU. Una startup di solito costruisce un prodotto coeso e iper-ottimizzato (dove modello, orchestrazione e tool sono integrati per garantire massima efficienza). Dover disaccoppiare forzatamente il prodotto per venderlo a “pezzi” separati, o dover garantire l’esecuzione su hardware obsoleto (CPU), è un incubo ingegneristico per una startup. Per un grande System Integrator, invece, vendere l’assemblaggio di 10 componenti separati (con relativi costi di integrazione) è il modello di business ideale.
Il modello LCOAI e l’onere dell’Analisi di Ciclo di Vita (Cap. 4.3 - 4.5)
Si impone di valutare le offerte non sul prezzo iniziale, ma sul LCOAI (Levelized Cost of Artificial Intelligence), calcolando minuziosamente i costi di CAPEX, OPEX, costi organizzativi, e i “costi di uscita e transizione” (migrazione dati, dismissione, subentro). I grandi player dell’IT hanno interi reparti di “Bid Management” (esperti di gare) specializzati nel costruire complessi modelli finanziari per dimostrare che il loro TCO/LCOAI è il migliore. Inoltre, garantire e prezzare oggi i “costi di subentro e transizione” per un potenziale addio tra 5 anni è un rischio finanziario che una grande azienda può assorbire (o mascherare), ma che una startup, che non sa se esisterà tra 5 anni, fatica a garantire contrattualmente.
Capitolati “Orientati ai Risultati” ma pieni di SLA e Penali (Cap. 5.3)
Si incoraggiano capitolati funzionali con rigidi SLA (Service Level Agreements) su accuratezza, bias, tempi di risposta (Tabella 10). In caso di scostamenti, si prevedono piani di mitigazione, penali e rinegoziazioni. Firmare contratti con SLA durissimi e penali altissime in un campo probabilistico e incerto come l’IA generativa è un rischio enorme. Le grandi aziende IT mettono in conto budget legali per gestire i contenziosi con la PA o hanno la forza commerciale per “ammorbidire” l’esecuzione del contratto. Una startup non può permettersi di vedersi bloccare i pagamenti o ricevere penali per un lieve “drift” del modello.
Proporzionalità dei requisiti di Cybersecurity, Compliance e Audit (Cap. 3.6 e 3.8)
Il documento, in maniera del tutto condivisibile, pone una forte e necessaria enfasi sulla sicurezza dei sistemi IA. A tal fine, richiede l’allineamento a framework normativi e tecnici complessi (come l’AI Act, la direttiva NIS2, il CRA e il NIST AI RMF), prevedendo obblighi di audit continui, sistemi di logging avanzati e una documentazione estensiva per la mitigazione di specifiche tassonomie di attacco (Evasion, Poisoning, Prompt Injection, ecc.). Pur essendo presidi fondamentali per la tutela dei dati pubblici, un’applicazione rigida e uniforme (one-size-fits-all) di questi standard rischia di generare un’asimmetria competitiva strutturale. I grandi System Integrator dispongono di divisioni legali, uffici di compliance e team di cybersecurity dedicati, capaci di assorbire i costi di produzione della voluminosa documentazione certificativa richiesta ex-ante per partecipare alle gare. Al contrario, le startup GovTech – che spesso sviluppano soluzioni snelle e intrinsecamente sicure (security-by-design) – faticano a sostenere il peso amministrativo, burocratico e finanziario di tali adempimenti preliminari, venendo di fatto scoraggiate o escluse dalla partecipazione diretta.
Di seguito alcune proposte di miglioramento:
5.4. Valorizzare la categoria MePA Government Tech rivolta alle startup di IA
4.8. Precisare nel testo che il lock-in tecnologico di una soluzione API/SaaS può essere efficacemente neutralizzato garantendo la portabilità dei dati in formati aperti (Open Data/API standard in uscita), senza necessariamente dover possedere l’infrastruttura sottostante.
Inserire nella Tabella 8 una valutazione più equilibrata per il modello API/SaaS, suggerendolo come soluzione ottimale (e non solo sperimentale) per l’efficienza dei costi operativi in tutti i processi amministrativi a rischio basso o moderato, valorizzando la qualificazione ACN (Agenzia per la Cybersicurezza Nazionale) per i servizi cloud della PA.
3.3 e 3.5.1. Chiarire che la rigida scomposizione architetturale è richiesta quando la PA acquista una “Piattaforma o Infrastruttura IA”, ma non è strettamente necessaria quando si acquista un “Prodotto/Servizio IA verticale” (SaaS)
Ibid. Modificare il requisito del fallback su CPU. Anziché richiedere che il modello giri su hardware obsoleto (spesso impossibile per i moderni LLM), richiedere piani di “degrado controllato del servizio” (graceful degradation) o la continuità operativa tramite il routing temporaneo verso modelli cloud alternativi in caso di indisponibilità delle GPU locali.
4.3-4.5. Prevedere l’applicazione del modello LCOAI completo solo per appalti sopra la soglia di rilevanza comunitaria o per progetti ad alta intensità di CAPEX. Per l’acquisto di licenze, SaaS o servizi sotto soglia, suggerire un TCO (Total Cost of Ownership) semplificato.
5.3. Suggerire alle stazioni appaltanti di adottare, nei capitolati per l’IA, metriche di SLA “evolutive”. Anziché prevedere penali immediate per le “allucinazioni” (fisiologiche nell’IA), introdurre metriche basate sul miglioramento continuo del modello (es. tempi di fine-tuning post-segnalazione errore) e sull’efficacia dell’interazione human-in-the-loop.
3.6 e 3.8. Permettere, per i sistemi IA non classificati “ad alto rischio” (ex AI Act), di dimostrare la conformità documentale in itinere (es. durante una fase di validazione o Proof of Concept post-aggiudicazione), anziché richiederla come sbarramento iniziale. Suggerire alle PA di premiare, nei criteri di valutazione dell’offerta, le evidenze tecniche di sicurezza (es. superamento di penetration test, architetture Zero Trust) rispetto alla mera quantità di policy aziendali o certificazioni organizzative pregresse. Esplicitare nei capitolati il principio della Shared Responsibility: la startup che fornisce l’applicativo IA non deve essere gravata dall’onere di certificare l’infrastruttura sottostante, qualora questa si appoggi a Cloud Provider già qualificati secondo gli standard nazionali (ACN).