La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 6. Neutralità hardware, acceleratori e portabilità dei sistemi di IA.
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).
Contributo a cura della Taskforce IA dell’Autorità Nazionale Anticorruzione (ANAC)
Riteniamo che l’impostazione risulti eccessivamente ambiziosa rispetto alle reali possibilità operative delle PA. La neutralità hardware completa e il fallback su CPU, pur teoricamente auspicabili, non sono sempre sostenibili in termini di prestazioni, costi e complessità gestionale. Inoltre, il documento non esplicita in modo adeguato i trade-off tra autonomia, efficienza e sostenibilità economica.
In assenza di tali elementi, vi è il rischio che le indicazioni risultino difficilmente applicabili o che portino a soluzioni sovradimensionate rispetto ai fabbisogni reali.
Proponiamo quindi di esplicitare meglio i compromessi architetturali, introdurre livelli differenziati di neutralità (base e avanzata) e chiarire i casi in cui un certo grado di lock-in può essere accettabile, purché gestito e consapevole.
§6.2 Ottimizzazione dei modelli e uso delle CPU
Il §6.2 richiama correttamente tecniche di ottimizzazione quali riduzione delle dimensioni del modello, riduzione della precisione numerica e trasferimento delle capacità verso modelli più piccoli e specializzati, evidenziandone i benefici in termini di efficienza, portabilità e possibilità di esecuzione su CPU. Tali tecniche, tuttavia, non hanno solo effetti prestazionali: possono modificare in modo non lineare il comportamento del modello e incidere anche su proprietà rilevanti per la sicurezza, quali robustezza rispetto a input avversari, comportamento su input fuori distribuzione e interazione con eventuali alterazioni o backdoor introdotte in fasi precedenti del ciclo di vita. Per questa ragione, l’applicazione di tecniche di ottimizzazione non dovrebbe essere trattata come mera trasformazione prestazionale, ma come modifica sostanziale del modello, da sottoporre a nuova validazione di sicurezza prima della messa in esercizio. Il collegamento è coerente anche con il capitolo 5, che richiede di testare nuovamente il sistema a seguito di aggiornamenti del modello o modifiche sostanziali, anche se non formalizza ancora in modo esplicito una suite di regressione di sicurezza specifica per l’IA.
Raccomandazione: integrare il §6.2 prevedendo esplicitamente che l’adozione di tecniche di ottimizzazione del modello, quali quantizzazione, pruning, distillation o riduzione di precisione, comporti: (a) il trattamento del modello risultante come versione sostanzialmente modificata ai fini della sicurezza; (b) la riesecuzione sistematica dei test di sicurezza e robustezza previsti nelle fasi di testing e validazione del ciclo di vita, estesi ai test avversariali pertinenti al caso d’uso, prima della messa in esercizio della versione ottimizzata; (c) la documentazione della tecnica di ottimizzazione applicata, delle configurazioni adottate e dei relativi esiti dei test di sicurezza tra gli artefatti del sistema.
§6.1 Architetture hardware-agnostic
La neutralità hardware è un obiettivo condivisibile in chiave di riduzione del lock-in e di resilienza, ma il paragrafo non esplicita un effetto collaterale rilevante: l’esecuzione del medesimo modello su runtime, backend di inferenza, driver e librerie numeriche differenti amplia la supply chain tecnica del sistema di IA. Tali componenti software della catena di esecuzione devono a loro volta essere gestiti come dipendenze critiche, in termini di integrità, provenienza, aggiornamento e tracciabilità. Inoltre, differenze implementative tra piattaforme o backend possono produrre deviazioni di comportamento del modello che richiedono nuova verifica, anche in assenza di modifiche apparenti alla logica applicativa o ai pesi del modello. Questo profilo è coerente con il capitolo 5, che già richiama affidabilità delle librerie esterne, integrità degli artefatti e tracciabilità delle modifiche.
Raccomandazione: integrare il §6.1 prevedendo esplicitamente che l’adozione di architetture hardware-agnostic sia accompagnata da: (a) inclusione dei runtime di inferenza, dei backend di esecuzione, dei driver e delle librerie numeriche rilevanti in un inventario strutturato dei componenti del sistema di IA; (b) verifica di integrità e di provenienza di tali componenti, in coerenza con i controlli richiamati nel capitolo 5; (c) nuova esecuzione di test di sicurezza e robustezza a ogni cambio di runtime o backend di esecuzione in produzione, al fine di intercettare eventuali deviazioni di comportamento dovute a differenze implementative.
§6.2 / §6.3 Efficienza e fallback CPU
Nel capitolo 6 il fallback su CPU e, più in generale, l’esecuzione su hardware alternativo sono presentati soprattutto come strumenti di continuità operativa, neutralità hardware e resilienza rispetto a vincoli di mercato o approvvigionamento. Questa impostazione è corretta, ma potrebbe essere utilmente integrata con un’esplicitazione ulteriore: nei sistemi di IA, una modalità di esecuzione alternativa e controllata può svolgere anche la funzione di modalità degradata di sicurezza. In particolare, essa può consentire il mantenimento in esercizio di funzioni essenziali con capacità ridotte e perimetro operativo più ristretto nei casi in cui il modello principale debba essere sospeso per motivi di sicurezza, ad esempio a seguito di comportamento anomalo, sospetta compromissione della supply chain o esito negativo di verifiche di sicurezza. Trattato solo in chiave prestazionale, il fallback rischia invece di essere progettato con lo stesso perimetro di capability del modello principale, riducendone il valore come modalità degradata governata.
Raccomandazione: integrare il §6.2 o il §6.3, eventualmente con rinvio al capitolo 4 sull’operatività e monitoraggio, chiarendo che la modalità di fallback può essere progettata anche come modalità degradata di sicurezza, con: (a) un perimetro di capacità ridotto rispetto al modello principale, in particolare rispetto ai tool invocabili e ai sink privilegiati accessibili; (b) criteri documentati di attivazione che includano non solo indisponibilità infrastrutturale, ma anche eventi o anomalie di sicurezza che richiedano la sospensione del modello principale; (c) criteri di uscita dalla modalità di fallback subordinati al ripristino controllato della versione principale e al superamento delle verifiche di sicurezza e robustezza previste dal ciclo di vita.
Riferimento: Paragrafo 6.4.2 “Portabilità e reversibilità”, unico capoverso.
Brano di riferimento: “Il sistema di intelligenza artificiale deve essere progettato secondo principi di neutralità hardware, garantendo la possibilità di esecuzione su infrastrutture computazionali eterogenee e evitando dipendenze strutturali da specifiche architetture, acceleratori o tecnologie proprietarie.”
Osservazione: Il testo del paragrafo 6.4.2 (“Portabilità e reversibilità”) è identico parola per parola al testo del paragrafo 6.4.1 (“Neutralità hardware”). Si tratta evidentemente di un errore di copia-incolla: il paragrafo 6.4.2 dovrebbe contenere una clausola contrattuale relativa al proprio oggetto dichiarato — la portabilità e la reversibilità del sistema — e non ripetere la clausola sulla neutralità hardware già presente in 6.4.1.
Proposta di modifica: Sostituire integralmente il testo del paragrafo 6.4.2 con una clausola contrattuale dedicata alla portabilità e reversibilità, che includa almeno: (a) l’obbligo per il fornitore di garantire l’esportabilità di modelli, dati, configurazioni e pipeline in formati aperti e documentati; (b) i tempi e le modalità di restituzione del sistema all’amministrazione al termine del contratto; (c) le garanzie di assenza di vincoli proprietari che impediscano la migrazione verso fornitori alternativi; (d) la documentazione tecnica necessaria a consentire la reversibilità senza dipendenza dal fornitore uscente.
Riferimento: Paragrafo 6.4.3 “Efficienza e fallback CPU”, unico capoverso.
Brano di riferimento: “Il sistema deve prevedere modalità di esecuzione alternative, basate su tecniche di ottimizzazione dei modelli, che consentano l’utilizzo anche su infrastrutture CPU-only, garantendo continuità operativa e livelli di servizio proporzionati al contesto di utilizzo.”
Osservazione: La clausola, formulata come obbligo contrattuale generale, è tecnicamente irrealizzabile per intere classi di modelli. Per modelli linguistici di grandi dimensioni (LLM con decine di miliardi di parametri), modelli multimodali e diffusion models, l’esecuzione su CPU-only — anche dopo quantizzazione e distillazione — produce livelli prestazionali incompatibili con qualunque scenario interattivo. I benchmark pubblici indicano per un modello da 70 miliardi di parametri quantizzato a 4 bit prestazioni dell’ordine di 3-4 token al secondo su 32 vCPU, contro oltre 20 token/secondo su una singola GPU di classe data center. La clausola di proporzionalità (“livelli di servizio proporzionati al contesto di utilizzo”) è enunciata ma non operazionalizzata: il documento non fornisce criteri per stabilire quando il fallback su CPU sia tecnicamente plausibile e quando non lo sia. Il rischio concreto è che la clausola venga inserita acriticamente nei capitolati di gara, generando o adempimenti formali svuotati di sostanza, o l’esclusione di intere classi di soluzioni effettivamente utili alla PA.
Proposta di modifica: Riformulare la clausola in modo da differenziare l’obbligo per classi tecnologiche. In particolare:
Per modelli di machine learning classico, modelli tabulari, classificatori e Small Language Models (indicativamente sotto i 10 miliardi di parametri), il fallback CPU può essere mantenuto come requisito obbligatorio.
Per LLM di grandi dimensioni, modelli multimodali e diffusion models, sostituire l’obbligo di fallback CPU con un obbligo alternativo di continuità operativa documentata, da soddisfare attraverso almeno una delle seguenti modalità: (a) ridondanza su acceleratori di fornitori e architetture diverse; (b) modello di fallback funzionale degradato su classe di modelli compatibile con CPU (ad esempio, un SLM addestrato sullo stesso dominio); (c) procedure documentate di degradazione controllata del servizio.
Definire, in uno Strumento operativo dedicato, soglie quantitative di accettabilità (ad esempio: latenza massima per query, throughput minimo) che permettano di verificare la conformità della clausola in fase di collaudo.
Riferimento: Paragrafo 6.1 “Architetture hardware-agnostic”, terzo capoverso.
Brano di riferimento: “In tali architetture, l’eventuale assenza di acceleratori può comportare una riduzione delle prestazioni, ma non l’impossibilità di utilizzo del sistema.”
Osservazione: L’affermazione è corretta in linea di principio per modelli di dimensioni contenute, ma è tecnicamente errata se applicata indiscriminatamente a tutte le classi di sistemi di IA. Per modelli linguistici di grandi dimensioni e modelli multimodali contemporanei, l’assenza di acceleratori non comporta una “riduzione delle prestazioni”, ma di fatto l’impossibilità di utilizzo in qualunque scenario di servizio reale. Il testo, così come formulato, induce il lettore — in particolare il funzionario amministrativo che deve tradurlo in capitolato — a sottostimare radicalmente il problema.
Proposta di modifica: Integrare il capoverso con un riconoscimento esplicito dei limiti applicativi.
Proposta di riformulazione: “In tali architetture, l’eventuale assenza di acceleratori può comportare una riduzione delle prestazioni proporzionata alla classe e alla dimensione del modello. Per modelli di piccole e medie dimensioni e per algoritmi di machine learning classico, ciò non compromette l’utilizzo del sistema. Per modelli di grandi dimensioni — in particolare LLM, modelli multimodali e diffusion models — l’assenza di acceleratori dedicati può rendere impraticabile l’esecuzione interattiva. La progettazione hardware-agnostic deve quindi essere calibrata sulla classe tecnologica del sistema.”
Riferimento: Paragrafo 6.2 “Ottimizzazione dei modelli e uso delle CPU”, secondo capoverso.
Brano di riferimento: “L’adozione di tali tecniche permette, in molti casi, l’esecuzione dei modelli anche su infrastrutture basate su CPU general-purpose, ampliando le possibilità di distribuzione dei sistemi di IA e riducendo i costi energetici e operativi.”
Osservazione: L’inciso “in molti casi” è un riconoscimento implicito che le tecniche di ottimizzazione menzionate (riduzione dimensioni, precisione ridotta, distillazione) non sono universalmente applicabili. Tuttavia il documento non fornisce alcun criterio per identificare i casi in cui queste tecniche sono effettivamente utilizzabili, né alcuna soglia di accettabilità delle prestazioni post-ottimizzazione. Il paragrafo, così come formulato, rischia di essere letto come una garanzia generale di sostituibilità tra GPU e CPU, mentre in realtà rinvia a valutazioni tecniche caso per caso che il documento non struttura.
Proposta di modifica: Rimandare esplicitamente a uno Strumento operativo dedicato che fornisca: (a) una matrice indicativa di compatibilità tra classi di modelli, tecniche di ottimizzazione applicabili e requisiti hardware minimi; (b) le soglie di degradazione qualitativa accettabili per ciascuna tecnica (ad esempio, perdita massima di accuracy ammessa in un modello quantizzato rispetto al modello originale); (c) esempi pratici di casi d’uso PA per cui il fallback su CPU è effettivamente raccomandato.
Concordiamo con il quadro strategico del documento volto a prevenire la dipendenza strutturale da specifici fornitori o tecnologie. Tuttavia, riteniamo necessario introdurre elementi di flessibilità per evitare che questo principio si trasformi in un vincolo assoluto e controproducente.
1. Neutralità dell’hardware vs. Interoperabilità dei dati
Le Linee Guida richiedono — anche attraverso esempi di clausole contrattuali (Par. 6.4.1) — di evitare “dipendenze strutturali da specifiche architetture, acceleratori o tecnologie proprietarie”. Pur sostenendo lo spirito di questa norma, l’attuale approccio alla “neutralità dell’hardware” risulta eccessivamente rigido. L’attenzione dovrebbe spostarsi dal forzare l’intercambiabilità dell’hardware alla garanzia dell’interoperabilità dei dati e dei carichi di lavoro. Il lock-in può essere efficacemente evitato attraverso API standard, formati di dati aperti e robuste capacità di esportazione dei dati.
Una rigorosa neutralità dell’hardware dovrebbe applicarsi principalmente all’approvvigionamento di infrastrutture computazionali grezze o di modelli personalizzati ospitati autonomamente (self-hosted). Per le funzionalità di IA acquistate come Servizi Gestiti (PaaS/SaaS) tramite API, l’hardware sottostante è astratto. Proibire rigidamente soluzioni gestite che sono nativamente ottimizzate per lo stack di un Cloud Service Provider (CSP), senza una valutazione proporzionale dell’effettivo rischio di lock-in, priva la Pubblica Amministrazione di soluzioni ad alta efficienza e prestazioni elevate.
2. Sostenibilità ambientale
I CSP utilizzano spesso hardware specializzato (ad esempio, TPU proprietarie) che offre prestazioni significativamente superiori e costi di inferenza inferiori rispetto all’hardware generico. L’utilizzo di questi acceleratori specializzati dovrebbe essere consentito e attivamente incoraggiato per ragioni di sostenibilità. Le TPU, ad esempio, sono esponenzialmente più efficienti dal punto di vista energetico rispetto alle CPU in termini di rapporto prestazioni/watt per i carichi di lavoro di addestramento e inferenza. Forzare l’uso di architetture generiche e non ottimizzate per garantire la flessibilità dell’hardware aumenterà inevitabilmente il consumo energetico e le emissioni di carbonio.
3. Approcci articolati al fallback su CPU
Le linee guida pongono l’accento su tecniche di ottimizzazione dei modelli per consentire l’esecuzione su infrastrutture esclusivamente CPU. Dovrebbe essere adottato un approccio ibrido più sfumato, basato sulla specifica architettura acquistata:
On-Premise: Per l’uso on-premise, il fallback su CPU è estremamente logico. Le amministrazioni devono eseguire i carichi di lavoro su hardware diversificato, e modelli correttamente dimensionati sono perfettamente adatti a rispondere a queste esigenze di sovranità dei dati on-premise.
Cloud: Per l’uso in cloud con dati non sensibili, l’obiettivo primario dovrebbe rimanere la portabilità dei dati piuttosto che l’imposizione del fallback su CPU.
4. Feedback specifico sulle clausole contrattuali (Sezione 6.4)
Per riflettere queste realtà, suggeriamo le seguenti revisioni specifiche alle clausole contrattuali proposte nella sezione 6.4:
Portabilità e Reversibilità: Richiediamo chiarimenti sulla definizione specifica e sulle aspettative operative di “reversibilità” in questo contesto, poiché la sua attuale inclusione risulta ambigua.
Efficienza e Fallback su CPU: Proponiamo di sostituire il rigido requisito di fallback su CPU con la seguente clausola, più equilibrata:
"Il sistema dovrebbe, laddove tecnicamente fattibile e proporzionato al caso d’uso, fornire modalità di esecuzione alternative. Per sistemi di IA altamente complessi o servizi gestiti che richiedono hardware specializzato per soddisfare i requisiti di prestazioni e gli SLA (Service Level Agreement), i fornitori dovrebbero invece dimostrare la continuità operativa attraverso infrastrutture ad alta disponibilità e impegni di disaster recovery.
Contributo a cura di Dedalus Italia S.p.A.
Dedalus supporta fortemente i principi di neutralità hardware e portabilità dei sistemi di Intelligenza Artificiale, avendo maturato esperienza nello sviluppo di soluzioni eseguibili in contesti cloud, on-premise e ibridi. L’adozione di modelli ottimizzati, Small Language Model e tecniche di fallback su CPU consente di garantire continuità del servizio anche in scenari infrastrutturali vincolati, riducendo il rischio di lock-in tecnologico e contribuendo alla sostenibilità economica e ambientale dei sistemi di IA nella Pubblica Amministrazione.
Par 6.4.3 — Efficienza e fallback CPU
Come già segnalato per le linee guida procurement, il requisito di esecuzione in modalità CPU-only come fallback obbligatorio non appare proporzionato se applicato in modo uniforme all’intera fornitura IA della PA.
Il punto più critico è l’enfasi posta sull’esecuzione degli LLM su CPU e sull’uso della quantizzazione come fattori abilitanti generali: si tratta di soluzioni che possono aumentare la portabilità, ma normalmente a costo di una perdita di performance in termini di latenza, throughput e qualità del risultato. La possibilità di esecuzione su CPU non dovrebbe pertanto essere assunta come requisito generale né come indice automatico di buona progettazione. Nei sistemi basati su LLM, la dipendenza da acceleratori specializzati è spesso una condizione tecnica ordinaria: neutralità hardware, portabilità e reversibilità non coincidono, e un sistema può non essere hardware-agnostic in senso stretto e restare comunque governabile e migrabile.
Così formulate, le clausole rischiano di penalizzare soluzioni nazionali ed europee oggi diffuse senza produrre benefici tangibili in termini di autonomia operativa della PA: sarebbe preferibile concentrarsi su obiettivi più concreti e verificabili, come trasparenza delle dipendenze tecnologiche, condizioni di migrazione, continuità operativa e misure di reversibilità.
Contributo a cura di Zigrida Alushaj, avvocato iscritto all’Ordine degli Avvocati di Milano.
Si prega di notare il seguente refuso: il paragrafo 6.4.1. e 6.4.2. hanno il medesimo testo (indicato in calce). Sarà necessario dunque delineare i principi di portabilità e reversibilità.
6.4.1 Neutralità hardware
Il sistema di intelligenza artificiale deve essere progettato secondo principi di neutralità hardware, garantendo la possibilità di esecuzione su infrastrutture computazionali eterogenee e evitando dipendenze strutturali da specifiche architetture, acceleratori o tecnologie proprietarie.
6.4.2 Portabilità e reversibilità
Il sistema di intelligenza artificiale deve essere progettato secondo principi di neutralità hardware, garantendo la possibilità di esecuzione su infrastrutture computazionali eterogenee e evitando dipendenze strutturali da specifiche architetture, acceleratori o tecnologie proprietarie.
Contributo a cura di Traent Srl.
Si propone di integrare il §6.1 e il §6.4.2 “Portabilità e reversibilità” con un requisito di certificazione verificabile della portabilità. Le Linee Guida prescrivono «sistemi progettati in modo da separare il modello di IA e la logica applicativa dal livello hardware sottostante» (§6.1, pag. 106) e il §6.4.2 richiede che il sistema garantisca «la possibilità di esecuzione su infrastrutture computazionali eterogenee e evitando dipendenze strutturali da specifiche architetture, acceleratori o tecnologie proprietarie» (pag. 108). Tuttavia, queste proprietà sono verificabili solo dall’operatore stesso: una PA non ha strumenti per distinguere una portabilità effettiva da una dichiarata. Si chiede che ogni migrazione o cambio di ambiente sia accompagnato da un’attestazione crittograficamente verificabile dei test condotti e degli esiti ottenuti, conservata in modo indipendente dal fornitore. Ciò consentirebbe di trasformare l’obiettivo di «ridurre il rischio di lock-in tecnologico» (§6.3, pag. 107) da aspirazione a proprietà dimostrabile, rendendo le clausole contrattuali di portabilità (§6.4) effettivamente esigibili.
La sezione rappresenta un punto di forza delle Linee Guida, ma la portabilità è attualmente limitata agli aspetti infrastrutturali e non include gli asset specifici dei sistemi di Generative AI. Ciò costituisce una criticità rilevante, in quanto il valore principale di questi sistemi risiede proprio nei prompt, nelle knowledge base e nei modelli personalizzati sviluppati nel tempo. Si propone quindi di estendere esplicitamente il concetto di portabilità a tali elementi, prevedendo obblighi contrattuali di esportazione in formati aperti e tempi certi. Tale integrazione è essenziale per evitare fenomeni di lock-in tecnologico e per garantire la possibilità di migrazione verso soluzioni alternative senza perdita di know-how.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.