Foundation Models per l'Energia
L'applicazione dei Transformer alle serie temporali energetiche ha prodotto, tra il 2023 e il 2025, una nuova generazione di modelli pre-addestrati capaci di previsioni zero-shot su dati che non hanno mai visto durante il training. I tre riferimenti principali sono TimesFM (Google DeepMind, 2024), addestrato su 100 miliardi di punti temporali provenienti da Google Trends, Wikipedia e dataset di finance; Chronos (Amazon, 2024), basato su architettura T5 con tokenizzazione probabilistica dei valori numerici; e Moirai (Salesforce, 2024), che introduce il concetto di "any-variate" forecasting — un unico modello che gestisce sia serie univariate che multivariate senza riadattamento architetturale.
Il principio comune è il transfer learning temporale: così come un large language model addestrato su testi generalisti può rispondere a domande su argomenti specifici senza fine-tuning, questi modelli imparano pattern universali nelle serie temporali — stagionalità annuale, ciclicità settimanale, discontinuità da anomalie — e li trasferiscono su nuovi domini con pochi o zero campioni di addestramento specifici. Per un impianto fotovoltaico con soli tre anni di dati storici, questo è un vantaggio concreto: un foundation model gestisce correttamente pattern stagionali anche su finestre temporali corte, dove ARIMA o SARIMA classici produrrebbero parametri instabili.
Il limite principale dei foundation model energetici nel contesto del mercato elettrico italiano riguarda la latenza di inferenza vs il ciclo del MGP. Il Mercato del Giorno Prima si chiude a D-1 ore 12:00 — la previsione del fabbisogno per il giorno successivo deve essere disponibile entro quella finestra. Modelli di grandi dimensioni richiedono GPU dedicate per inferenza in tempi utili; soluzioni ibride (modello leggero per operatività, foundation model per calibrazione periodica) sono oggi la risposta più pragmatica.
AI Agent per il Demand Forecasting
L'architettura più diffusa nel demand forecasting operativo non è un singolo modello monolitico, ma un sistema multi-agent in cui agenti specializzati cooperano passando informazioni strutturate. Un'implementazione tipica prevede tre componenti principali.
Il forecasting agent è il cuore del sistema: riceve serie storiche di consumo orario, le preprocessa (imputazione valori mancanti, normalizzazione, rilevamento outlier) e genera la previsione a 24-72 ore tramite un foundation model o un'architettura LSTM+Attention custom addestrata sul dato proprietario. Il calendar agent inietta nel contesto del forecasting agent le informazioni sugli eventi che rompono i pattern storici: festività nazionali e regionali, chiusure produttive programmate, periodi particolari come Ferragosto o le settimane di Natale. Il weather agent interroga in autonomia API meteo esterne — Open-Meteo per previsioni a breve termine, ERA5 (Copernicus/ECMWF) per i reanalysis storici — e traduce le previsioni di irraggiamento globale (GHI) e temperatura in impatto atteso sulla produzione e sul consumo.
Il protocollo che governa la comunicazione tra questi agenti è sempre più spesso MCP (Model Context Protocol, introdotto da Anthropic a fine 2024): un'interfaccia standardizzata per cui un LLM può richiamare tool esterni — API meteo, database storici, portali regolatori — con uno schema di input/output dichiarato. Il pattern di ragionamento è ReAct (Reasoning + Acting): il modello ragiona esplicitamente sul passo successivo, esegue un'azione (es. chiamata API), osserva il risultato e itera. Questo rende il processo di forecasting ispezionabile — ogni output è accompagnato dalla catena di ragionamento che lo ha generato, un requisito di accountability sempre più richiesto nei contesti industriali.
La validazione quantitativa è l'unico criterio che conta. Su backtesting strutturato — hold-out set con dati storici reali, confronto su orizzonti di 24, 48 e 72 ore — sistemi multi-agent ben configurati mostrano una riduzione tipica del 25-40% del MAE (Mean Absolute Error) rispetto a baseline SARIMA, con miglioramenti più marcati nei periodi con discontinuità (festività, variazioni meteo improvvise) dove i modelli statistici classici soffrono di mancanza di contesto.
Digital Twin Impiantistico
La definizione tecnica precisa di digital twin è cruciale per evitare l'inflazione semantica del termine: un digital twin è un modello computazionale calibrato su misure fisiche reali che può simulare il comportamento dell'asset nel tempo e nello spazio, generare scenari controfattuali ("cosa succede se cambio l'orientamento del tracker?") e predire guasti prima che si manifestino. Un dashboard di monitoring in tempo reale non è un digital twin. Un gemello digitale deve avere la capacità di rispondere a domande su stati futuri e ipotetici — è questa la differenza.
Lo stack open-source di riferimento per digital twin di impianti energetici si articola su quattro livelli. FIWARE NGSI-LD (specifica ETSI CIM 009) funge da broker di contesto: aggrega dati eterogenei da SCADA, inverter e sensori ambientali in una rappresentazione semantica unificata, esportabile in JSON-LD con ontologie standard. InfluxDB è il time series database dove vengono storicizzati i dati di produzione oraria, le telemetrie di temperatura dei moduli e i log degli inverter. Grafana gestisce la visualization e il monitoring operativo. Eclipse Ditto è il livello di astrazione che realizza il "gemello": mantiene una rappresentazione dello stato corrente dell'asset (shadow state) e gestisce la sincronizzazione con il dispositivo fisico tramite protocolli MQTT o HTTP.
Le ontologie che governano la semantica del twin sono SAREF4ENER (ETSI TS 103 673, estensione di SAREF per il dominio energetico), BRICK Schema (ontologia per edifici e sistemi energetici, sviluppata da UC Berkeley e NIST) e IEC CIM 61968/61970 (Common Information Model, il modello dati standard per utility e trasmissione elettrica). L'adozione di queste ontologie non è esercizio accademico: permette interoperabilità tra sistemi di venditori diversi, requisito sempre più frequente nelle gare d'appalto di grandi impianti industriali.
Calibrazione su Dati Reali
Il vantaggio competitivo di chi gestisce un impianto con anni di dati storici di produzione reale risiede nella possibilità di calibrare modelli su misure effettive piuttosto che su stime statistiche. PVGIS (il tool europeo per la stima della produzione solare) utilizza dati satellitari medi su periodi di 15-20 anni — è lo standard per la fase di progettazione, ma un modello calibrato su telemetrie reali dell'inverter di quell'impianto specifico ha un'accuratezza misurabile e verificabile su hold-out set.
Il processo di calibrazione si articola in quattro fasi. La prima è l'ingestion dei dati storici: acquisizione sistematica delle telemetrie orarie degli inverter (potenza DC/AC, tensione stringa, temperatura moduli), pulizia dei dati (gestione gap, rimozione valori fisicamente impossibili) e arricchimento con dati meteo storici rianalizzati da ERA5. La seconda è il fitting del modello fisico: stima empirica dei parametri dell'impianto — temperature coefficient effettivo, Performance Ratio medio per stagione, system losses distribuite (soiling, shading parziale, mismatch). La terza è la validazione su hold-out set: calcolo di MAPE, RMSE e MBE (Mean Bias Error) su un periodo tenuto fuori dall'addestramento. La quarta è il monitoraggio del drift: rilevamento automatico di degradazione del modello nel tempo tramite test statistici (CUSUM, Page-Hinkley) e trigger per re-training periodico.
Per l'anomaly detection — identificazione di guasti o degradazioni prima che impattino sulla produzione — si usano due approcci complementari. Isolation Forest è un algoritmo non supervisionato che identifica punti anomali in spazi ad alta dimensionalità (potenza, temperatura, irraggiamento, ora del giorno) senza richiedere etichettatura manuale. PatchTST (Vision Transformer applicato a serie temporali segmentate in patch) è lo stato dell'arte per la previsione di degradazione a lungo termine, capace di rilevare trend di calo del PR su finestre di 6-18 mesi con anticipo sufficiente per pianificare interventi di manutenzione.
Limite e Responsabilità
L'entusiasmo per le capacità dei sistemi AI nel settore energetico deve essere bilanciato da una valutazione realistica dei limiti attuali. I sistemi di forecasting producono stime probabilistiche, non certezze: il confidence interval a 90% di un modello ben calibrato su 24 ore tipicamente oscilla tra ±8% e ±15% sulla produzione attesa, a seconda della variabilità meteorologica. Questi intervalli sono sufficienti per ottimizzare strategie di accumulo e offerte di mercato, ma richiedono che il sistema decisionale sia progettato per gestire l'incertezza, non per ignorarla.
Il principio di human-in-the-loop rimane obbligatorio per qualsiasi decisione che impatti su infrastruttura critica: l'AI produce una raccomandazione con confidence score esplicito, il tecnico o il trader validano o fanno override. Sistemi completamente autonomi su reti elettriche non sono né tecnicamente maturi né normativamente accettati nel contesto europeo attuale. Lo standard IEC 62443 definisce i requisiti di cybersecurity per i sistemi di automazione e controllo industriale — qualsiasi integrazione AI che acceda a sistemi SCADA deve essere valutata rispetto a questi requisiti, in particolare per quanto riguarda l'autenticazione delle connessioni e la segmentazione di rete.
La lezione successiva affronta un tema distinto ma complementare: come la blockchain può garantire l'autenticità e l'immuabilità del dato energetico che questi sistemi AI producono e consumano — partendo dalle Garanzie d'Origine fino agli oracle IoT che portano le misure fisiche on-chain.