Mercoledì 7 ottobre 2026 | ore 11:30 – 15:30
ARENA SAIE LAB – AI, BIM e DIGITAL | Pad. 26 - A27
Organizzato da SAIE in collaborazione con IBIMI
La digitalizzazione degli appalti pubblici non può limitarsi alla produzione di modelli BIM. Come garantire che le informazioni possano essere scambiate, interpretate e riutilizzate lungo tutto il ciclo di vita dell’opera, senza essere vincolate a uno specifico software?
L’interoperabilità sarà al centro del confronto organizzato da SAIE in collaborazione con IBIMI, con un focus sul passaggio dai modelli nativi ai dati aperti e sulla continuità informativa tra progettazione, costruzione e gestione.
Il tema riguarda non soltanto la tecnologia, ma anche la capacità delle stazioni appaltanti di definire correttamente requisiti informativi, standard e criteri di verifica. Formati aperti come IFC e BCF possono favorire lo scambio di geometrie, proprietà e informazioni tra ambienti software differenti, ma restano alcune criticità soprattutto nelle fasi di costruzione, Direzione Lavori e gestione dell’opera.
L’intervista approfondisce quindi una questione centrale: come preservare non solo i dati, ma anche il loro significato, le relazioni e la possibilità di utilizzarli nel tempo? E quali competenze servono a progettisti, imprese, produttori, pubbliche amministrazioni e gestori per costruire processi realmente interoperabili?
L’obiettivo è portare il tema dell’openBIM oltre il confronto tra specialisti e ragionare sulle condizioni necessarie per trasformare l’interoperabilità in un modo ordinario di lavorare per l’intera filiera delle costruzioni.
Interoperabilità e appalti pubblici: qual è oggi il vero problema?
Prof. Borin, quando parliamo di interoperabilità, quali sono oggi gli ostacoli principali? Il problema è prevalentemente tecnologico oppure riguarda soprattutto processi, requisiti informativi, standard e organizzazione di chi opera nel settore?
Grazie della domanda, che è un ottimo punto di partenza. Penso che anche i pur limitati problemi tecnologici siano, in buona parte, figli di una limitata competenza sull’interoperabilità del dato che il nostro settore ancora soffre.
Ci sono diversi motivi. Si parte dalla formazione universitaria, che in parte rappresento, per arrivare al carico burocratico cui professionisti, imprese e committenti sono sottoposti quotidianamente e che spesso non consente loro un approfondimento solido di un tema che può apparire specialistico o non direttamente pertinente alla propria attività, ma che in realtà incide profondamente sulla capacità di lavorare meglio.
Il punto, infatti, è che l’interoperabilità non coincide con la possibilità di aprire lo stesso file con software diversi. È prima di tutto la capacità di definire, produrre, scambiare, interpretare e riutilizzare informazioni in maniera coerente lungo un processo.
Da questo punto di vista, i problemi più rilevanti oggi riguardano la qualità con cui vengono definiti i requisiti informativi, la capacità di tradurli in strutture di dati verificabili e il grado di consapevolezza con cui vengono utilizzati standard, classificazioni, formati aperti e modelli informativi. Se manca questa base, anche una tecnologia perfettamente funzionante restituisce risultati modesti.
Negli appalti pubblici il problema diventa particolarmente evidente. La committenza dovrebbe essere in grado non soltanto di chiedere “un modello BIM”, ma di definire quali informazioni siano realmente necessarie, per quali usi, con quale struttura, in quale fase del processo e secondo quali criteri debbano essere verificate. Allo stesso modo, progettisti e imprese devono essere messi nella condizione di comprendere questi requisiti e trasformarli in dati affidabili.
Da questo punto di vista, gli strumenti openBIM necessari per costruire una pipeline informativa lineare tra pubblica amministrazione e operatori economici esistono già e sono operativi. Abbiamo standard per rappresentare i modelli, per formalizzare i requisiti informativi e per verificarne il contenuto. Quello che ancora manca, o almeno non è sufficientemente diffuso, è un numero adeguato di esempi concreti e replicabili che mostrino l’intero processo applicato in modo coerente, dalla definizione del requisito fino alla consegna e alla verifica del dato. Sappiamo però che queste esperienze stanno aumentando e credo che la loro diffusione sarà decisiva, perché consentirà di passare dalla discussione teorica sull’interoperabilità alla dimostrazione della sua effettiva applicabilità nei processi reali.
Dai modelli nativi ai dati aperti: cosa significa concretamente?
Il titolo dell’incontro parla di passaggio “dai modelli nativi ai dati aperti”. Cosa significa concretamente per chi progetta, costruisce e gestisce un’opera? E quali informazioni devono poter essere realmente trasferite da un ambiente software all’altro senza perdere contenuti, relazioni e affidabilità?
È un tema centrale. Come per un buon articolo giornalistico, l’obiettivo è portare l’informazione al lettore con la massima chiarezza e con la possibilità di approfondirla. Avere un formato aperto significa, in concreto, poter accedere al dato e utilizzarlo con il software che si preferisce, proprietario, open source o anche attraverso strumenti di Intelligenza Artificiale, senza essere vincolati all’ambiente in cui quel dato è stato originariamente prodotto.
La questione più interessante riguarda però i contenuti. Qui abbiamo un vantaggio rispetto all’esempio giornalistico: possiamo accordarci prima su quali informazioni debbano essere scambiate. La stazione appaltante, sulla base dei propri obiettivi e degli usi informativi previsti, deve quindi specificare con chiarezza cosa richiede: ad esempio quantità degli elementi ai progettisti, schede dei prodotti installati alle imprese, informazioni sugli stati di avanzamento alla direzione lavori.
La vera interoperabilità consiste quindi nel trasferire non solo geometrie, ma informazioni, proprietà e relazioni mantenendone significato e affidabilità. I formati aperti di buildingSMART supportano già questo approccio e, come comunità, stiamo lavorando proprio alla produzione di esempi concreti con gruppo di lavoro ad hoc, sui prodotti, sulla gestione economica delle opere, sui requisiti di progetto stradale e di ponti e viadotti che le stazioni appaltanti possano utilizzare, adattare e approfondire.
OpenBIM significa davvero indipendenza dal software?
Uno degli obiettivi dell’interoperabilità è evitare che un processo informativo pubblico sia vincolato a uno specifico applicativo. Ma fino a che punto oggi formati aperti e standard consentono una reale indipendenza dagli strumenti proprietari? Dove permangono ancora criticità?
Come già richiamato, l’analisi che stiamo portando avanti attraverso il Comitato Tecnico e Scientifico, le Commissioni e il confronto con gli associati mostra come oggi sia possibile scambiare in modo generalmente efficace geometrie, proprietà informative e criticità di progetto, anche attraverso formati aperti come IFC e BCF, pur con alcune differenze ancora presenti tra i diversi ambienti software.
Le maggiori criticità emergono quando si entra nelle fasi più complesse del processo edilizio: la costruzione, il rapporto con la Direzione Lavori, la programmazione delle attività e la gestione della componente economica lungo il ciclo di vita dell’opera. In questi ambiti, e in particolare nella gestione documentale degli ACDAT, permangono ancora forme di lock-in tecnologico che limitano una piena indipendenza dagli strumenti proprietari.
Il punto, quindi, non è soltanto disporre di formati aperti, ma costruire processi nei quali tali formati siano realmente utilizzati come infrastruttura dello scambio informativo. Questo richiede maggiore consapevolezza da parte di tutti gli attori, requisiti meglio strutturati e una progressiva estensione degli standard alle fasi oggi ancora meno mature dal punto di vista dell’interoperabilità.
Il problema non è solo scambiare i dati, ma conservarne il significato. Come si garantisce la continuità informativa?
Un dato che passa correttamente da un software a un altro non è necessariamente un dato ancora utilizzabile. Come possiamo garantire che, lungo progettazione, affidamento, costruzione e gestione, siano preservati non soltanto i dati ma anche struttura, significato, relazioni e possibilità di verifica?
È un’altra questione molto importante da porre sul tavolo e che discutiamo con continuità, sia nella componente strategica sia in quella tecnologica, a livello nazionale e internazionale. La UNI EN ISO 19650, oggi già in fase di aggiornamento, richiama esplicitamente l’attenzione del committente – nel nostro caso spesso una committenza pubblica – sul tema della continuità informativa, che considero una delle vere sfide del settore.
In questo senso l’openBIM può essere uno strumento decisivo, ma non è sufficiente da solo. La continuità delle decisioni si costruisce infatti anche attraverso documenti protocollati, atti amministrativi e silos informativi che spesso non hanno origine BIM. Penso, ad esempio, agli aspetti strategici ed economici. Anche il Codice dei contratti pubblici, collegando documenti come DOCFAP e DIP ai requisiti informativi, cerca di costruire una maggiore continuità tra decisioni, requisiti e sviluppo del progetto.
Un tema che riteniamo particolarmente importante è quindi l’interazione tra piattaforme digitali differenti, in modo che dati di natura diversa possano rimanere collegati e interrogabili nel tempo. È un ambito sul quale stiamo lavorando molto anche nella ricerca accademica.
Guardando più specificamente al BIM, credo sia necessario investire sempre più sull’integrazione del dato: classificazioni aperte e vocabolari condivisi, come quelli supportati dal bSDD, collegamento con i Digital Product Passport e verifica della continuità informativa tra oggetti digitali e prodotti effettivamente installati, anche rispetto a sostenibilità e criteri CAM.
Sul piano più strettamente tecnico, con il progetto IFCx buildingSMART sta inoltre investendo sul tema dell’autorialità e della provenienza del dato, aspetti che IFC ha sempre potuto rappresentare, ma che sono stati finora poco utilizzati nei processi reali.
Infine, per poter verificare davvero la continuità dell’informazione lungo l’intero ciclo di vita, occorre definire requisiti informativi sufficientemente stabili nel tempo. Senza questa base, il rischio è che ogni fase produca dati corretti localmente, ma difficilmente riutilizzabili nelle fasi successive.
Quali competenze servono alle stazioni appaltanti?
La digitalizzazione degli appalti richiede alle amministrazioni una capacità crescente di definire requisiti, controllare modelli e dati e governare ambienti informativi complessi. Quali competenze dovrebbero diventare prioritarie nelle stazioni appaltanti per evitare che la trasformazione digitale si riduca alla semplice richiesta di modelli BIM?
È un’altra questione molto importante da porre sul tavolo e che discutiamo con continuità, sia nella componente strategica sia in quella tecnologica, a livello nazionale e internazionale. La UNI EN ISO 19650, oggi già in fase di aggiornamento, richiama esplicitamente l’attenzione del committente – nel nostro caso spesso una committenza pubblica – sul tema della continuità informativa, che considero una delle vere sfide del settore.
In questo senso l’openBIM può essere uno strumento decisivo, ma non è sufficiente da solo. La continuità delle decisioni si costruisce infatti anche attraverso documenti protocollati, atti amministrativi e silos informativi che spesso non hanno origine BIM. Penso, ad esempio, agli aspetti strategici ed economici. Anche il Codice dei contratti pubblici, collegando documenti come DOCFAP e DIP ai requisiti informativi, cerca di costruire una maggiore continuità tra decisioni, requisiti e sviluppo del progetto. Un tema che riteniamo particolarmente importante è quindi l’interazione tra piattaforme digitali differenti, in modo che dati di natura diversa possano rimanere collegati e interrogabili nel tempo. È un ambito sul quale stiamo lavorando molto anche nella ricerca accademica.
Guardando più specificamente al BIM, credo sia necessario investire sempre più sull’integrazione del dato: classificazioni aperte e vocabolari condivisi, come quelli supportati dal bSDD, collegamento con i Digital Product Passport e verifica della continuità informativa tra oggetti digitali e prodotti effettivamente installati, anche rispetto a sostenibilità e criteri CAM. Sul piano ancora più strettamente tecnico, con il progetto IFCx buildingSMART sta inoltre investendo sul tema dell’autorialità e della provenienza del dato, aspetti che IFC ha sempre potuto rappresentare, ma che sono stati finora poco utilizzati nei processi reali. Infine, per poter verificare davvero la continuità dell’informazione lungo l’intero ciclo di vita, occorre definire requisiti informativi sufficientemente stabili nel tempo. Senza questa base, il rischio è che ogni fase produca dati corretti localmente, ma difficilmente riutilizzabili nelle fasi successive.
Perché è importante portare questa discussione al SAIE, davanti alla filiera delle costruzioni?
Al SAIE il tema sarà discusso mettendo a confronto competenze provenienti da ambiti diversi. Perché è importante che l’interoperabilità esca dal confronto tra soli specialisti BIM e venga affrontata insieme a progettisti, imprese, produttori, pubbliche amministrazioni e gestori? Quale messaggio vorrebbe emergesse dal dibattito di Bologna?
Portare questa discussione al SAIE è particolarmente importante perché come abbiamo visto sopra è lampante che l’interoperabilità non può rimanere un tema confinato agli specialisti BIM. Se vogliamo che abbia un impatto reale sul settore, deve entrare nel confronto quotidiano tra progettisti, imprese, produttori, pubbliche amministrazioni e gestori, soggetti che producono, utilizzano e trasformano informazioni diverse. Iil valore emerge solo quando questi dati possono essere collegati, interpretati e riutilizzati lungo l’intero processo. È quindi necessario superare una visione dell’openBIM come tema puramente tecnologico e riconoscerlo come una componente della gestione complessiva dell’opera.
Da questo punto di vista, il SAIE rappresenta un contesto particolarmente prezioso, perché mette intorno allo stesso tavolo attori che normalmente osservano il medesimo processo da prospettive differenti. Ed è esattamente ciò che vogliamo fare anche all’interno del Comitato Tecnico Scientifico di buildingSMART Italia: costruire un luogo di confronto capace di far emergere esigenze concrete della filiera e di trasformarle in indirizzi utili per l’associazione, per lo sviluppo degli standard, per l’attivazione di gruppi di lavoro e per l’approfondimento dei temi che richiedono ancora ricerca, sperimentazione e confronto.
Il messaggio che vorrei emergesse dal dibattito di Bologna è che gli strumenti e gli standard per migliorare questa continuità esistono già in larga parte. Ora serve una maggiore capacità di costruire processi condivisi, esempi applicativi e requisiti comprensibili a tutta la filiera. L’interoperabilità diventa realmente efficace quando smette di essere un tema per specialisti e diventa un modo ordinario di lavorare.
