openBIM: non più solo interoperabilità

Per molti anni abbiamo parlato di openBIM quasi sempre nello stesso modo: come risposta al problema dell’interoperabilità. Il racconto era semplice, a volte persino troppo semplice: usare formati aperti per non restare prigionieri di un solo software, scambiare modelli tra piattaforme diverse, garantire maggiore libertà agli attori della filiera.

Tutto vero. Ma oggi comincia a essere una lettura incompleta.

Le ultime attività di buildingSMART International, dall’Implementers Assembly di febbraio 2026 all’openBIM Hackathon di Porto 2026, mostrano che l’openBIM sta cambiando pelle. Non è più soltanto il tema del “file IFC che si apre correttamente”. Sta diventando un ecosistema tecnico più maturo, fatto di standard collegati tra loro, validazione automatica, requisiti informativi leggibili dalle macchine, dizionari condivisi, tracciamento delle issue e prototipi basati anche sull’intelligenza artificiale.

La notizia, secondo me, è proprio questa: l’openBIM sta uscendo dalla fase difensiva — quella del “non voglio dipendere da un software” — ed entra in una fase molto più interessante, quella dell’infrastruttura informativa aperta.

L’Implementers Assembly 2026: il segnale arriva dai produttori di software

L’Implementers Assembly di buildingSMART, ospitata da Bentley a Exton l’11 e 12 febbraio 2026, ha riunito la comunità dei soggetti che implementano gli standard buildingSMART nei propri strumenti software. Il tema centrale non era teorico: si è discusso di standard openBIM, implementazione reale, certificazione, validazione e direzioni future. In particolare, il workshop sulla nuova generazione di IFC, cioè IFC X, è stato indicato come uno dei fili conduttori principali delle due giornate.

Questo dettaglio conta molto.

Quando sono i produttori di software, gli sviluppatori e gli implementatori a confrontarsi su IFC X, IDS, BCF, bSDD e servizi di validazione, significa che il tema non resta confinato nei convegni o nei documenti metodologici. Entra nel livello più concreto: quello degli strumenti che i professionisti useranno davvero.

È qui che l’openBIM si gioca la sua credibilità.

Perché il settore AEC non ha bisogno di standard perfetti sulla carta e fragili nella pratica. Ha bisogno di standard implementabili, verificabili, integrabili nei flussi quotidiani di progettazione, controllo, consegna e gestione. La differenza tra una buona idea e una trasformazione reale passa quasi sempre da qui: dalla capacità di diventare software, processo, controllo automatico, scambio affidabile.

IFC X: non un semplice aggiornamento, ma un cambio di paradigma

Parlare di IFC X solo come “prossima versione dell’IFC” sarebbe riduttivo. Il punto non è soltanto migliorare un formato. Il punto è chiedersi se l’IFC possa diventare qualcosa di più dinamico, modulare e adatto a un ecosistema digitale in cui i dati non vivono più soltanto dentro un file esportato a fine fase.

Per anni l’IFC è stato vissuto come un contenitore. Esporto il modello, lo controllo, lo importo, lo confronto, lo archivio. Questo flusso resterà importante, ma il mercato sta andando verso scenari molto più complessi: piattaforme cloud, digital twin, controllo continuo dei dati, aggiornamento progressivo delle informazioni, collegamento con classificazioni, requisiti, issue, documenti, proprietà ambientali e dati di gestione.

In questa prospettiva, IFC X può rappresentare un passaggio decisivo: non più soltanto “un formato neutrale”, ma una base per servizi informativi più evoluti.

Naturalmente il rischio esiste. Ogni volta che uno standard diventa più ambizioso, aumenta anche la complessità. E il settore delle costruzioni, lo sappiamo bene, non sempre digerisce bene la complessità. Ma sarebbe un errore fermarsi alla paura. La vera domanda è un’altra: possiamo continuare a trattare lo scambio informativo come una semplice esportazione di file?

Secondo me no.

IDS: il vero salto è rendere i requisiti leggibili dalle macchine

Tra gli standard che più meritano attenzione c’è l’IDS, Information Delivery Specification. buildingSMART lo definisce come uno standard per specificare requisiti informativi in forma interpretabile da un computer, consentendo il controllo automatico della conformità dei modelli IFC.

Qui siamo davanti a un passaggio fondamentale.

Perché uno dei grandi problemi del BIM, soprattutto nelle gare e nei contratti, è sempre stato questo: i requisiti informativi vengono spesso scritti in documenti lunghi, testuali, ambigui, difficili da verificare in modo oggettivo. Il risultato è che si produce documentazione, ma non sempre si produce chiarezza.

L’IDS cambia prospettiva. Non si limita a dire “serve questa informazione”. Prova a rendere quel requisito controllabile. E quando un requisito diventa controllabile, cambia il rapporto tra committenza, progettista, impresa e controllore.

In termini molto pratici, l’IDS può aiutare a rispondere a domande che oggi spesso generano conflitti:

• quali proprietà devono essere presenti?
• in quali oggetti?
• con quale formato?
• con quali valori ammessi?
• rispetto a quale fase?
• il modello consegnato rispetta davvero quanto richiesto?

Questa è una delle evoluzioni più importanti dell’openBIM: passare dalla fiducia dichiarata alla verifica automatica.

E, personalmente, credo che nei prossimi anni questa sarà una delle competenze più richieste. Non solo saper modellare, non solo saper coordinare, ma saper tradurre un fabbisogno informativo in requisiti controllabili.

BCF: le issue diventano memoria del processo

Il BCF, BIM Collaboration Format, è spesso percepito come uno strumento tecnico per gestire segnalazioni, clash, osservazioni o problemi di coordinamento. Ma anche qui il tema è più profondo.

Una issue non è soltanto un promemoria. È una traccia decisionale.

Quando segnaliamo un problema, lo assegniamo, lo commentiamo, lo risolviamo e lo chiudiamo, stiamo costruendo una memoria del processo. Stiamo dicendo chi ha rilevato cosa, quando, con quale responsabilità, con quale soluzione e con quale impatto sul modello.

Nel contesto dell’openBIM, il BCF diventa quindi molto più di un formato di comunicazione. Diventa un pezzo della governance del progetto.

Ed è interessante che, durante l’Hackathon di Porto, uno dei prototipi abbia lavorato proprio sul concetto di “BCF Time Machine”, cioè sulla possibilità di tracciare la storia e l’evoluzione delle issue nel tempo.

Questa direzione è molto significativa. Perché il coordinamento digitale non può limitarsi a dire “abbiamo risolto i clash”. Deve poter ricostruire la qualità delle decisioni. Deve rendere visibile il percorso, non solo il risultato finale.

bSDD: senza vocabolari condivisi, i dati restano fragili

Un altro tassello fondamentale è il bSDD, buildingSMART Data Dictionary. Troppo spesso si parla di dati come se bastasse inserirli in un modello per renderli utili. Ma i dati, senza significato condiviso, rischiano di diventare rumore.

Una proprietà può chiamarsi in modi diversi. Una classificazione può essere interpretata in modo diverso. Un attributo può essere scritto con unità, formati o convenzioni non coerenti. Il risultato è che i dati ci sono, ma non sono davvero interoperabili.

Il bSDD lavora proprio su questo piano: dare ai dati un riferimento semantico condiviso. Non solo scambiare informazioni, ma capirle nello stesso modo.

Questo aspetto è meno appariscente rispetto a un modello 3D, ma è probabilmente più importante per il futuro. Perché digital twin, sostenibilità, product passport, computi, facility management e intelligenza artificiale hanno tutti bisogno di una cosa: dati leggibili, coerenti, collegabili e semanticamente robusti.

Senza vocabolari condivisi, l’openBIM rischia di fermarsi alla geometria. Con vocabolari condivisi, può diventare una vera infrastruttura di conoscenza.

L’Hackathon di Porto: la notizia non sono i prototipi, ma il metodo

Dal 22 al 24 marzo 2026, a Porto, buildingSMART ha organizzato il primo openBIM Hackathon. In circa 50 ore, 47 partecipanti divisi in 9 team hanno sviluppato prototipi funzionanti basati sugli standard openBIM. Non presentazioni, non concept astratti, ma strumenti reali: AI per arricchire modelli, app in realtà aumentata per visualizzare e modificare dati IFC, dashboard per la gestione IDS su larga scala.

Questo è un segnale molto sano.

Il settore AEC è pieno di parole: innovazione, interoperabilità, digital twin, AI, sostenibilità, automazione. Il problema è che spesso queste parole viaggiano più velocemente delle pratiche. Un hackathon, invece, costringe a sporcare le mani. Obbliga a dimostrare se uno standard funziona, dove si rompe, cosa manca, cosa va chiarito, quali casi d’uso sono realistici.

Tra i progetti citati da buildingSMART c’è anche Autofix, uno strumento che usa AI per arricchire e migliorare i dati di un modello IFC, suggerendo proprietà mancanti, classificazioni o correzioni in base al contesto; può usare IDS e generare BCF per informare gli utenti dei problemi del modello.

Qui si vede molto bene il punto di contatto tra openBIM e intelligenza artificiale.

L’AI, da sola, rischia di produrre risultati suggestivi ma poco controllabili. Inserita dentro un ecosistema di standard aperti, requisiti verificabili e dati semanticamente strutturati, può invece diventare uno strumento di supporto alla qualità informativa.

Il vero tema: l’AI ha bisogno dell’openBIM più di quanto sembri

Oggi tutti parlano di AI applicata all’architettura, all’ingegneria e alle costruzioni. Generazione automatica di concept, analisi predittiva, controllo dei modelli, automazione di task ripetitivi, estrazione di informazioni, assistenti digitali per il coordinamento.

Ma c’è una verità che spesso viene sottovalutata: l’intelligenza artificiale, senza dati strutturati, diventa fragile.

Può sembrare intelligente, ma se lavora su informazioni incoerenti, incomplete, ambigue o chiuse dentro formati proprietari difficili da interpretare, la sua utilità reale diminuisce. L’AI non elimina il problema della qualità dei dati. Lo amplifica.

Per questo l’openBIM diventa ancora più importante nell’epoca dell’intelligenza artificiale. Non perché sia più “etico” o più “aperto” in senso astratto, ma perché offre una base tecnica per rendere i dati più accessibili, verificabili e collegabili.

In altre parole: senza openBIM, molta AI per l’AEC rischia di restare una bella interfaccia sopra dati disordinati.

Dall’interoperabilità alla responsabilità informativa

A mio avviso, il passaggio più interessante è questo: l’openBIM non dovrebbe essere più raccontato solo come una questione di interoperabilità software. Dovrebbe essere raccontato come una questione di responsabilità informativa.

Interoperabilità significa riuscire a scambiare dati.

Responsabilità informativa significa sapere se quei dati sono corretti, completi, verificabili, aggiornabili, tracciabili e utili per una decisione.

La differenza è enorme.

Un file IFC può essere formalmente esportato e comunque essere povero, confuso, incompleto o poco utile. Un flusso openBIM maturo, invece, collega geometrie, proprietà, requisiti, classificazioni, issue e controlli. Non si limita a far “passare” informazioni da un software all’altro: costruisce fiducia nel dato.

Ed è proprio questa fiducia che serve al settore delle costruzioni.

Cosa cambia per professionisti, imprese e committenze

Per i professionisti, la conseguenza è chiara: conoscere l’openBIM non può più voler dire soltanto “saper esportare un IFC”. Bisogna capire come è strutturato, come viene verificato, quali informazioni contiene, quali perde, quali standard si collegano ad esso e come si costruisce un flusso di controllo.

Per le imprese, l’openBIM può diventare uno strumento molto concreto per ridurre ambiguità e rilavorazioni. Ma solo se viene usato dentro processi chiari. Non basta ricevere modelli aperti: bisogna saperli controllare, collegare al computo, al cronoprogramma, alla produzione, alla qualità e alla gestione delle varianti.

Per le committenze, soprattutto pubbliche, la sfida è ancora più grande. Chiedere openBIM non significa scrivere “formato IFC obbligatorio” in un capitolato. Significa definire requisiti informativi chiari, controllabili, legati agli usi del modello e alla gestione futura dell’asset.

Qui IDS, bSDD e BCF diventano strumenti strategici. Non accessori tecnici.

La formazione dovrà uscire dal mito del “salva con nome IFC”

Anche sul piano formativo il messaggio è forte.

Per troppo tempo l’openBIM è stato trattato come una lezione sull’esportazione IFC: impostazioni, mapping, proprietà, classificazioni, qualche controllo in un viewer e poco altro. Oggi questo approccio non basta più.

La formazione deve iniziare a raccontare l’openBIM come un ecosistema:

• IFC per rappresentare e scambiare dati;
• IDS per definire e verificare requisiti;
• bSDD per dare significato condiviso alle informazioni;
• BCF per gestire comunicazione, issue e tracciabilità;
• servizi di validazione per controllare qualità e conformità;
• AI e automazioni come strumenti che devono poggiare su dati affidabili.

Questo è un passaggio culturale importante. Perché sposta l’attenzione dal comando software al processo informativo.

E, a mio avviso, è proprio qui che si misura la maturità di un professionista BIM oggi: non nel sapere quale pulsante premere, ma nel sapere perché quell’informazione deve esistere, come deve essere strutturata e come potrà essere usata da altri.

Il rischio italiano: usare l’openBIM come etichetta

Nel contesto italiano vedo un rischio abbastanza evidente: trasformare l’openBIM in una formula da capitolato.

Chiedere IFC, citare openBIM, allegare qualche requisito, pretendere un CDE e considerare risolto il problema. È un errore che abbiamo già visto con il BIM in generale: parole corrette, processi deboli.

L’openBIM, se interpretato male, può diventare l’ennesima etichetta. Se interpretato bene, invece, può cambiare davvero il modo in cui vengono gestite le informazioni di progetto.

La differenza sta nella competenza della committenza e nella qualità della domanda.

Una committenza matura non chiede semplicemente “un modello IFC”. Chiede dati coerenti con usi precisi, requisiti controllabili, tracciabilità delle issue, vocabolari condivisi e processi di validazione.

E soprattutto chiede informazioni che servano dopo la consegna, non solo durante la gara.

Conclusione: l’openBIM non è più una posizione ideologica

Per anni l’openBIM è stato raccontato anche come una battaglia culturale: aperto contro chiuso, standard contro proprietario, libertà contro dipendenza da software. Questa dimensione resta importante, ma oggi non è più sufficiente.

La vera forza dell’openBIM non sta solo nell’apertura. Sta nella possibilità di costruire un ambiente digitale in cui i dati siano più controllabili, più leggibili, più collegabili e più utili.

IFC X, IDS, BCF e bSDD indicano una direzione precisa: il futuro del BIM aperto non sarà fatto da un unico standard miracoloso, ma da una rete di standard che lavorano insieme.

Ed è qui che l’openBIM diventa adulto.

Non quando riusciamo semplicemente ad aprire un file in un altro software, ma quando riusciamo a costruire un processo informativo affidabile, verificabile e capace di accompagnare l’opera nel tempo.

La domanda, allora, non è più: “il tuo software esporta IFC?”

La domanda vera diventa: il tuo processo produce informazioni aperte, comprensibili e verificabili?

E questa è una domanda molto più scomoda. Ma anche molto più utile.