Dal LOD al LOIN — la normativa BIM sta cambiando linguaggio

Il livello di dettaglio giusto non è un numero. È una domanda.

Un capitolato ti chiede una modellazione a LOD 300. Tu lo sai fare, lo hai fatto decine di volte. Il problema è che dall'altra parte del tavolo — il collaboratore strutturista, il BIM manager del committente, il collega che deve estrarre gli Schedule — quello stesso LOD 300 se lo immagina in modo leggermente diverso dal tuo.

Non è un problema di competenza. Nessuno dei due sbaglia, tecnicamente. Il punto è che "LOD 300" da solo non dice cosa deve contenere il modello — dice solo un numero su una scala che, a seconda di chi la legge, si interpreta con margini diversi. E in un progetto BIM, un margine di interpretazione su un dato condiviso è il punto esatto in cui iniziano le rilavorazioni.

È lo stesso problema che affrontiamo a livello di singola famiglia — te ne ho parlato parlando di geometria, parametri e informazione come tre livelli distinti di qualità di una Revit Family. Ecco: quello che vale per una famiglia vale, su scala più larga, per un intero modello. E la normativa se n'è accorta prima di noi — tanto che il concetto stesso di LOD si sta riscrivendo da dentro.

LOD, LOG e LOI: la lettura italiana

Partiamo dalla base, perché è quella su cui è costruita ancora oggi la maggior parte della contrattualistica BIM in Italia: la UNI 11337-4.

Prima di andare avanti, un chiarimento terminologico: quando la normativa parla di LOD, LOG, LOI, parla di "oggetti digitali" — un linguaggio volutamente neutro, che non conosce Revit, Archicad o Tekla. "Famiglia" è il nome che diamo noi a quell'oggetto quando lavoriamo dentro Revit. Stessa sostanza, vocabolario diverso.

La norma italiana definisce il LOD come il "livello di sviluppo degli oggetti digitali" — non a caso l'acronimo, nella versione nostrana, non traduce pedissequamente l'inglese Level of Development. È una scala che va da A a G, e che descrive quanto un oggetto è approfondito e stabile man mano che il progetto avanza: da un concept ancora indicativo fino a un modello cantierabile, aggiornato as-built.

Fin qui, niente di diverso da quello che probabilmente già conosci per esperienza diretta sui capitolati. La parte interessante — quella che spesso resta sullo sfondo — è che la UNI 11337-4 non si ferma a un'unica lettera. Scompone il LOD in due componenti distinte:

• LOG — Level of Geometry: quanto è definita, dimensionalmente e formalmente, la geometria dell'oggetto. È la domanda "che forma ha, e quanto è precisa quella forma?"
• LOI — Level of Information: quanti e quali dati alfanumerici porta con sé l'oggetto. È la domanda "cosa so di questo oggetto, oltre a come è fatto?"

Ti suona familiare? Dovrebbe: è esattamente la stessa distinzione tra geometria e informazione di cui ti ho parlato parlando delle Revit Family come asset BIM — solo che lì la applicavamo a una singola famiglia nel Family Editor, qui la norma la applica a livello di intero modello, con una scala standardizzata e contrattualmente vincolante.

Ed è qui che nasce il primo problema pratico: LOG e LOI non crescono sempre alla stessa velocità. Un oggetto può avere una geometria dettagliatissima e zero parametri utili allo Schedule. Oppure il contrario — geometria semplificata, ma un LOI ricchissimo perché è quello che serve realmente in quella fase. La lettera unica del "LOD 300" nasconde questa asimmetria. Ed è proprio questa la crepa da cui, a livello europeo, è nato qualcosa di diverso.

Non è un dettaglio da poco: un LOG che cresce senza controllo — geometria importata pari pari da un software esterno, dettagli scultorei che nessuno vedrà mai in pianta — è esattamente il tipo di scelta che uccide le performance di un modello. Più dettaglio non è mai un obiettivo di per sé: lo diventa solo se risponde a un fabbisogno informativo reale.

Perché si inizia a parlare di LOIN

Il limite del sistema LOD/LOG/LOI, in fondo, è lo stesso limite di ogni scala a lettere: comprime informazioni complesse in un simbolo semplice. Comodo per il capitolato, meno comodo quando la realtà del progetto non entra ordinatamente in sette caselle.

A livello europeo questo limite è stato affrontato di petto. Dal 2016 un tavolo di lavoro internazionale — guidato, tra l'altro, da un'esperta italiana — ha messo a punto un framework nuovo: il LOIN, Level of Information Need. Il testo è stato prima formalizzato nella norma europea EN 17412-1 (adottata in Italia come UNI EN 17412-1:2021) e successivamente elevato a standard internazionale: oggi il riferimento ufficiale è la UNI EN ISO 7817-1:2024.

L'idea di fondo resta un cambio di prospettiva netto: non più "quanto dettaglio ha questo oggetto secondo una scala standard", ma "quanto dettaglio serve davvero, a chi, per fare cosa, in quale fase". Non è un caso che a livello europeo si sia deciso di non condensare il concetto in un acronimo a effetto — il rischio, dichiarato apertamente da chi ha scritto la norma, era che tutti sostituissero semplicemente "LOD" con "LOIN" senza cambiare davvero approccio.

Il framework LOIN lavora insieme alla serie UNI EN ISO 19650, quella che in Italia regola la gestione informativa dei progetti BIM (Piano di Gestione Informativa, requisiti del committente, e così via) — la 19650 dice che serve un fabbisogno informativo, la 17412-1 dice come specificarlo in modo coerente: scopo dell'informazione, attori coinvolti, milestone di consegna, requisiti geometrici e alfanumerici.

E qui arriva la parte più onesta da raccontare: in Italia siamo in una fase di transizione, non di sostituzione. La UNI EN ISO 7817-1:2024 è già norma italiana a tutti gli effetti. Ma la UNI 11337-4 — quella che abbiamo visto nel blocco precedente, con LOD/LOG/LOI — è ancora al lavoro per allinearsi a questo nuovo framework. Il risultato pratico è che oggi, nella contrattualistica reale, i due linguaggi convivono: capitolati che chiedono ancora "LOD 300", accanto a committenze più avanzate — spesso quelle abituate a lavorare con la ISO 19650 — che iniziano a specificare requisiti informativi in termini di LOIN.

Non è un difetto della normativa. È semplicemente il tempo che ci mette un intero settore a cambiare vocabolario senza rompere tutto quello che c'è già in piedi.

Un esempio concreto: il Kitchen Utensil Cabinet

Prendiamo lo stesso mobile portautensili da cucina di cui ti ho già parlato nell'articolo sugli asset BIM, e proviamo a leggerlo con le lenti di LOG e LOI invece che con quelle generiche di "geometria, parametri, informazione".

In una fase concettuale (LOD basso), quel mobile potrebbe esistere nel modello come un semplice parallelepipedo con ingombro corretto — il LOG è minimo, giusto lo spazio che occuperà in pianta. Il LOI, in questa fase, potrebbe comunque non essere zero: basta un parametro di classificazione o di destinazione d'uso per iniziare a farlo dialogare con lo Schedule dei costi preliminari. Geometria bassa, informazione già presente. Questo è esattamente il tipo di asimmetria che la scala LOD unica tende a nascondere.

Avanzando nel progetto, il LOG cresce: compaiono le due configurazioni — quattro contenitori o due, gestite dal parametro di visibilità — la struttura in legno prende forma reale, i contenitori in vimini diventano geometria vera e non più un blocco generico. In parallelo, ma non necessariamente allo stesso ritmo, cresce anche il LOI: materiali di top e intelaiatura come parametri di istanza, dimensioni editabili — spessore del top, spessore dell'intelaiatura, scorrimento dei contenitori — tutti dati che alimentano gli Schedule e permettono al mobile di rispondere a un coordinamento reale con altri professionisti.

Qui il ragionamento in ottica LOIN diventa concreto. Chi userà quel modello, e per fare cosa? Se il modello serve a un render di presentazione, serve LOG alto e LOI basso — la forma deve essere convincente, i dati contano poco. Se il modello serve a un computo metrico o a una gestione futura della manutenzione, vale l'opposto: serve LOI alto, con dati su materiali e componenti, mentre il LOG può restare più semplificato senza danneggiare l'uso finale. Chiedersi "che LOD serve" a questo mobile è una domanda incompleta. Chiedersi "chi userà questo dato, e per quale scopo" è la domanda che il framework LOIN prova a mettere al centro — non un dettaglio più alto per definizione, ma il dettaglio giusto per lo scopo.

Il livello di dettaglio giusto non è un numero. È una domanda.

Quando ho iniziato a guardare la Kitchen Utensil Cabinet con le lenti di LOG e LOI, mi sono reso conto di una cosa: la domanda che mi ero fatto per anni — "che LOD serve a questa famiglia?" — non era mai stata la domanda giusta. Era solo la più comoda. Una lettera da mettere in un capitolato, facile da scrivere, facile da controllare, difficile da interpretare allo stesso modo da entrambe le parti del tavolo.

Il LOIN non aggiunge complessità alla normativa BIM. La toglie, spostandola dove deve stare — non più "quanto dettaglio, genericamente", ma "quale dettaglio, per chi, per fare cosa, in quale fase". È un cambio di prospettiva che assomiglia a quello che ogni modellatore fa già istintivamente ogni volta che decide se un parametro deve essere di istanza o di tipo: non si tratta di aggiungere controllo per principio, si tratta di darne il giusto, dove serve.

Vale per una singola famiglia nel Family Editor. Vale per un intero modello in un capitolato. La domanda non cambia — cambia solo la scala a cui te la poni.

Una cosa va detta con onestà, ed è bene chiuderci su questo: la normativa italiana su questo fronte è ancora in movimento. La UNI 11337-4 non ha ancora recepito in modo definitivo il framework LOIN, e finché quel lavoro non sarà concluso (al momento della scrittura di questo articolo, Ottobre 2026, non risulta ancora pubblicata la revisione definitiva), LOD e LOIN continueranno a convivere nei capitolati che leggiamo ogni giorno. Non è un limite da ignorare — è semplicemente lo stato delle cose, ed è probabile che ci torneremo sopra in un prossimo articolo, quando la norma avrà preso la sua forma definitiva.

Se ti interessa risalire ancora più indietro, a chi per primo ha immaginato un oggetto edilizio come contenitore di informazioni e non solo di forma, il punto di partenza è Il Profeta del BIM — Charles M. Eastman. Buona lettura.