Impronta ambientale dell’intelligenza artificiale: cosa dice la ITU-T L.1801

Chi scrive «impronta ambientale dell’intelligenza artificiale» pensa al fornitore del modello: chip, addestramento, data center degli iperscaler. Il 6 febbraio 2026 lo Study Group 5 dell’ITU-T ha approvato una raccomandazione che sposta parte di quel conto altrove. La Raccomandazione ITU-T L.1801 (02/2026), Guidelines for assessing the environmental impact of artificial intelligence systems, stabilisce che raffreddamento e illuminazione del sito, durante l’uso di un sistema AI, si calcolano nella fase in cui quel sistema gira — dentro l’edificio. Non è un dettaglio d’appendice: è la riga che porta l’impianto nella dichiarazione ambientale di un sistema che il gestore della sala non ha progettato.

Da dove viene la L.1801, e cosa non fa

La raccomandazione nasce da un lavoro congiunto, lo dice l’Introduzione, testualmente: «This Recommendation was developed jointly by ETSI TC EE and ITU-T Study Group 5. It was published respectively by ITU as Recommendation ITU-T L.1801 and ETSI Standard [ETSI ES 204 135], which are equivalent in technical content» — sviluppata insieme da ETSI TC EE e dallo Study Group 5 dell’ITU-T, pubblicata come L.1801 e come standard ETSI ES 204 135: stesso testo, due sigle.

Poggia su due raccomandazioni precedenti — la metodologia LCA della ITU-T L.1410 (equivalente ETSI ES 203 199) e il metodo per gli effetti abilitanti della ITU-T L.1480 (equivalente ETSI ES 204 087) — e dichiara subito un limite: «Aggregation of AI impact on the international, national, or regional level is not part of this Recommendation» — l’aggregazione dell’impatto AI a livello internazionale, nazionale o regionale non fa parte di questa raccomandazione. Serve a valutare un sistema, non a produrre statistiche di settore.

Otto fasi del ciclo di vita, due processi trasversali

Il paragrafo 6.2 riprende da ISO/IEC 22989 le otto fasi del ciclo di vita AI: inception, design and development, verification and validation, deployment, operation and monitoring, continuous validation, re-evaluation, retirement — concepimento, progettazione e sviluppo, verifica e validazione, messa in esercizio, operatività, validazione continua, rivalutazione, dismissione. Segue la precisazione che conta: «Training and inference are not separate AI life cycle stages according to [ISO/IEC 5338], but they are central processes in AI systems» — addestramento e inferenza non sono fasi separate del ciclo di vita secondo ISO/IEC 5338, ma processi centrali nei sistemi AI: attraversano le fasi, e la L.1801 li colloca nel bilancio ambientale con una regola precisa, non con un’aggiunta a parte.

Dove finiscono addestramento e inferenza nel bilancio ambientale

Il cuore operativo, al paragrafo 8.1.1, mappa quelle fasi sulle quattro fasi LCA della L.1410: acquisizione delle materie prime, produzione, uso, fine vita. L’acquisizione contiene i materiali per l’hardware. La produzione include la fabbricazione dell’hardware più concepimento, progettazione, verifica e validazione — e, testualmente, «initial training shall be calculated as part of the LCA production stage»: l’addestramento iniziale si calcola nella produzione. L’uso include messa in esercizio, operatività, rivalutazione e validazione continua, e «inference and continuous learning (as part of re-training) shall be calculated as part of the LCA use stage»: inferenza e riaddestramento continuo si calcolano nell’uso. Il fine vita contiene il trattamento dell’hardware e la dismissione del sistema.

Sulla trasparenza: «It is required that the training impact is also reported separately for full transparency» — l’impatto dell’addestramento va sempre riportato anche a parte. Sull’affidabilità del dato: «Since initial training can be measured and an accurate figure provided but continuous learning will be based on estimated figures (using assumptions), these shall be reported separately» — l’addestramento iniziale si misura, il riaddestramento continuo si stima: le due cifre non si sommano in silenzio in un solo totale.

Le due righe che riguardano chi gestisce la sala

Qui la raccomandazione entra nell’edificio. La prima: «AI system installation and maintenance, as well as site specific support activities (e.g., cooling systems, lighting, etc.) during use shall be calculated for the LCA use stage» — installazione e manutenzione del sistema AI, e le attività di supporto specifiche del sito — raffreddamento, illuminazione — durante l’uso, si calcolano nella fase d’uso del ciclo di vita. Il raffreddamento non è un costo di gestione a parte dal bilancio ambientale dell’AI: è dentro il conto.

La seconda riguarda chi ospita più clienti sotto lo stesso tetto: «In shared infrastructure use, full life cycle impact of the infrastructure shall be allocated to the users according to their usage» — nell’uso di un’infrastruttura condivisa, l’intero impatto di ciclo di vita dell’infrastruttura va allocato agli utenti secondo il loro utilizzo. In ogni colocation, l’impatto dell’edificio — non solo dell’hardware AI ospitato — va diviso fra gli inquilini per utilizzo, non a stima forfettaria.

Come lo verifichiamo noi

Quando scriviamo un capitolato per una sala che ospiterà carichi AI di terzi, la prima domanda non è quale server entra, ma quale contatore misura cosa, e con quale criterio l’infrastruttura condivisa viene ripartita fra i clienti. Nei capitolati che scriviamo e verifichiamo quel criterio diventa una clausola scritta prima, non negoziata dopo: punto di misura, perimetro dell’impianto attribuito, distinzione fra dato misurato e dato stimato. In accettazione controlliamo che il contatore dichiarato esista nel punto dichiarato, e che la traccia — as-built, posizione, quota — sia quella che un cliente può portare nella propria dichiarazione, non una promessa verbale.

Vedi il servizio · Parlane con un tecnico

Cosa cambia per chi gestisce una sala macchine

Un’ultima avvertenza del testo, verbatim: «Multiple AI systems in the assessment may become very complex with agentic AI, especially if multiple agents are involved» — valutare più sistemi AI insieme può diventare molto complesso con l’AI agentica, specie con più agenti coinvolti: per una sala multi-cliente è, prima del calcolo, un problema di perimetro.

La conseguenza pratica è che il cliente deve dichiarare l’impronta del proprio sistema AI con dati che non ha: raffreddamento e illuminazione li misura chi gestisce la sala, non chi vi porta dentro il proprio carico — è la stessa sala di cui abbiamo scritto parlando delle classi di disponibilità. Servono contatori nel punto giusto, non un totalizzatore diviso a posteriori; un criterio di allocazione scritto prima del primo cliente, non rinegoziato a ogni gara; e una traccia di quale quota è attribuita a chi. Un data center che non sa rispondere non è fuori norma: la L.1801 è una raccomandazione tecnica internazionale, non una legge — ed è una dichiarazione diversa da quella energetica di cui abbiamo già scritto. Ma è un data center che il cliente non può mettere nel proprio conto, e in gara si vede.

Cosa scrivere in capitolato, cosa verificare in accettazione

In capitolato: il contratto di ospitalità dichiara quale criterio di allocazione dell’infrastruttura condivisa si applica, su quale grandezza misurata — non a stima forfettaria. Va specificato il punto di misura: cosa è contato a monte e a valle, quali impianti di sito rientrano nella quota attribuita. Raffreddamento e illuminazione vanno richiesti come misurati e attribuibili, non ricavati da un rapporto medio annuo. Il dato consegnato distingue ciò che è misurato da ciò che è stimato: la raccomandazione impone di riportarli separatamente.

In accettazione: si verifica che i contatori dichiarati esistano nei punti dichiarati, che il criterio di allocazione sia quello scritto — non uno più comodo introdotto in corsa — e che l’as-built registri posizione e perimetro di ogni contatore, nella stessa logica della mappa unica dell’infrastruttura di cui abbiamo scritto altrove. Senza quel registro, la stessa dichiarazione l’anno dopo non è ripetibile.

Due assi, applicati a questo conto

Primo asse: il criterio di allocazione e i requisiti di misura diventano righe verificabili del capitolato e punti di collaudo in accettazione, con la traccia che un committente esibisce per costruire la propria dichiarazione.

Secondo asse: contatori, criterio di allocazione e as-built non restano fogli sparsi per ogni cliente. Diventano, insieme a CSIDIA, l’altra società del gruppo, una mappa unica dell’infrastruttura: quale contatore copre quale impianto, quale quota è attribuita a quale cliente — lo stesso dato che serve quando qualcuno chiede conto di un consumo anomalo, e su cui un’AI fa la diagnosi mentre la squadra interviene. Nel perimetro del cliente: on-premise su macchine autonome senza integrazione profonda nella rete esistente, oppure cloud dedicato con data center in Italia, sempre con gestione condivisa.

Ospitate carichi AI di terzi e dovete costruire un criterio di allocazione difendibile, o verificare se i contatori che avete oggi bastano a sostenerlo? Parlatene con un tecnico: il sopralluogo è senza costi, e il punto di misura si progetta prima del prossimo cliente, non dopo.