Metodologia

Perché i dati di progetto FV hanno bisogno di un formato standard

di Michele PravadelliPubblicato il Aggiornato il 3 min di lettura

Nella nostra esperienza, chi partecipa a una transazione infrastrutturale ha quasi sempre la stessa lamentela sui dati.

Gli sviluppatori dicono che ogni controparte chiede le stesse informazioni in un formato diverso. Gli investitori dicono che le data room che ricevono non sono comparabili tra deal. I lender dicono che quello che ha superato la bancabilità in un portafoglio riappare, organizzato diversamente, nel successivo.

Stanno descrivendo lo stesso problema: i dati ci sono, ma non hanno forma.

Il costo di non avere uno standard

Qualche dato ha già un riferimento unico: in Italia l'anagrafica tecnica degli impianti di produzione sta in GAUDÌ, il sistema di Terna. Il dossier di due diligence no: autorizzazioni, contratti, controparti e dati finanziari arrivano in data room con la logica di chi li ha preparati.

Non è un problema cosmetico. Secondo noi è una fonte di attrito concreta per l'ingresso del capitale istituzionale nel FV italiano. Allunga le DD. Costringe ogni acquirente a ricostruire l'apparato analitico per ogni deal. Rende quasi impossibile confrontare i deal tra loro per regione, vintage e tecnologia: le statistiche del GSE descrivono il parco installato, non le transazioni.

Lo vediamo ogni volta: stessi documenti, riorganizzati a mano, dentro ogni DD.

Come sarebbe uno standard

Uno standard utilizzabile non è un template rigido. È:

  • Uno schema definito per gli oggetti che contano: impianti, autorizzazioni, contratti, controparti, dati finanziari, registri operativi.
  • Valori source-linked: ogni dato estratto punta al documento originale e alla pagina.
  • Confidence per campo: quanto è affidabile ogni valore e perché.
  • Strutturato e leggibile da una macchina: esportabile in JSON o equivalente, leggibile dai sistemi a valle (credit model, portfolio tracker, reporting normativo) senza intervento manuale.

Nessuna di queste proprietà è esotica. Sono i requisiti minimi perché i dati diventino un asset.

AIP Engine

AIP Engine, oggi in early access, è il nostro primo passo. Acquisisce pacchetti non strutturati (PDF, Excel, scansioni, foto) e produce un Dossier Digitale Strutturato (DDS) conforme allo schema che sviluppiamo sui deal reali.

Il prodotto è volutamente stretto. È pensato per i tre profili che conosciamo meglio: investitori che fanno DD acquisition-side su asset FV italiani, asset manager che prendono in carico nuovi mandati, lender che rivedono la bancabilità.

Lo schema evolverà. La copertura degli input si estenderà. La convinzione di fondo non cambia: i dati infrastrutturali hanno bisogno di un formato standard, e il punto più credibile da cui costruirlo è il lato che riceve la transazione, non quello che la emette.

Se il tema vi riguarda, come utenti o come collaboratori sullo schema, scriveteci.

Fonti

Anagrafica degli impianti di produzione: Terna, GAUDI, Gestione delle Anagrafiche Uniche Degli Impianti di produzione (pagina consultata il 2 ottobre 2026), e GAUDÌ, descrizione delle funzionalità principali della piattaforma (maggio 2012). Statistiche sul parco: GSE, Solare fotovoltaico, Rapporto statistico 2024 (settembre 2025), capitoli 4, 8, 9, 12 e 21 (evoluzione per anno, regioni, province, tipologia dei moduli, ore di utilizzazione equivalenti). Le osservazioni su data room e due diligence sono esperienza e opinione di Altheon, non dati tratti da queste fonti. Fonti verificate al 2 ottobre 2026. Aggiornamento del 2 ottobre 2026: le valutazioni sul mercato sono presentate come esperienza e opinione di Altheon, è stato tolto il superlativo sulla «principale fonte di attrito», sono stati aggiunti il riferimento all'anagrafica GAUDÌ e la distinzione fra statistiche sul parco installato e dati di transazione.

Parliamone

Vuoi parlarne sul tuo progetto?

Mezz'ora di chiamata è di solito il modo più veloce per capire come applicare quanto sopra a un caso reale. Rispondiamo entro due giorni lavorativi.