Quando si parla di ACDat — ovvero dell'Ambiente di Condivisione dei Dati previsto dalla normativa italiana in attuazione della UNI EN ISO 19650, della UNI 11337 e del D.Lgs. 36/2023 — il dibattito si concentra spesso sulle funzionalità operative: come si struttura la gerarchia dei contenitori informativi, come si gestiscono i flussi di approvazione o quali plugin integrino meglio i software di BIM Authoring. Meno frequentemente, invece, si affrontano con la dovuta profondità tre aspetti che sono centrali nella gestione matura di un ACDat:
Eppure, sono proprio questi tre elementi a determinare la solidità giuridica, la resilienza operativa e la tracciabilità di tutto il processo informativo.
Chi lavora quotidianamente con queste piattaforme sa bene che configurare un ACDat in modo tecnicamente funzionante è relativamente semplice. Configurarlo in modo conforme, sicuro e difendibile davanti a un committente o a un giudice è tutt'altra cosa. Questo articolo affronta i tre temi nell'ordine in cui, nella mia esperienza, andrebbero affrontati: prima la sicurezza strutturale del sistema, poi la conformità al quadro normativo sulla privacy e, infine, la gestione delle versioni come presidio di qualità e tracciabilità.
La sicurezza di un ACDat non è una questione puramente tecnica da delegare al reparto IT. Al contrario, si tratta di una responsabilità organizzativa che inizia con una valutazione della sensibilità aziendale: l'identificazione sistematica dei rischi derivanti dalla creazione, dallo scambio e dall'integrazione delle informazioni all'interno dell'ambiente digitale condiviso.
Un progetto o un bene costruito deve essere considerato sensibile quando, tra le altre condizioni, comprende un'infrastruttura nazionale critica, svolge funzioni di difesa o di ordine pubblico, oppure tratta informazioni di terzi già classificate come riservate. In questi casi, il CDE Manager è chiamato a sviluppare e mantenere una strategia di sicurezza strutturata, che includa la valutazione dei rischi specifici legati alla maggiore disponibilità di informazioni digitali, all'integrazione di servizi e sistemi e alla crescente dipendenza da tecnologie basate su cloud.
Tale strategia deve tradursi in un piano di gestione della sicurezza: un documento operativo che stabilisce le politiche e i processi per la creazione, la distribuzione, l'uso, la conservazione e la distruzione delle informazioni sensibili. In modo particolare, il piano deve disciplinare cosa accade nel momento in cui un modello informativo — nuovo, modificato o esistente — viene condiviso o pubblicato all'interno dell'ACDat: chi può accedervi, in quale stato e con quali restrizioni. Non si tratta di burocrazia aggiuntiva, ma di concreta prevenzione operativa.
Il documento deve comprendere anche un piano di gestione delle violazioni e degli incidenti. Non è sufficiente sapere come proteggere i dati; occorre sapere cosa fare quando la protezione fallisce. Questo include la definizione delle misure da adottare in caso di violazione, le modalità di notifica e le responsabilità di ciascun attore coinvolto nel processo informativo, in stretta analogia con quanto previsto dal GDPR 2016/679 in tema di data breach.
Figura 1 - Livelli di maturità BIM secondo la UNI EN ISO 19650
Un aspetto spesso sottovalutato è che l'ACDat non gestisce soltanto dati tecnici di progetto, ma tratta anche dati personali: quelli degli operatori che accedono alla piattaforma, dei responsabili delle revisioni e dei soggetti coinvolti nelle comunicazioni formali. Il Regolamento europeo 2016/679 (GDPR) si applica quindi integralmente, trovando completamento in Italia nel D.Lgs. 196/2003 (Codice Privacy), così come modificato e aggiornato dal D.Lgs. 101/2018.
Ogni trattamento di dati personali deve fondarsi su un'idonea base giuridica tra quelle previste dall'articolo 6 del GDPR: dal consenso dell'interessato all'adempimento di obblighi contrattuali, fino alla necessità di salvaguardare interessi vitali o adempiere a obblighi di legge. In un contesto di appalto pubblico, il trattamento troverà spesso la propria base giuridica nell'adempimento di un obbligo legale o nell'esecuzione di un contratto, mentre in un contesto privato potrà essere necessario raccogliere un consenso specifico.
Distinguere questi casi è una responsabilità del CDE Manager, che deve saper formalizzare l'informativa e, dove necessario, il modulo di consenso.
Il principio di data protection by design and by default, sancito dall'articolo 25 del GDPR, richiede che le misure di protezione siano integrate nella progettazione stessa dell'ACDat, anziché essere applicate a posteriori. In termini pratici, ciò significa che l'architettura dei permessi, la struttura di accesso ai contenitori informativi e le modalità di esportazione dei dati devono essere configurate sin dall'inizio, così da garantire la minimizzazione dei dati e limitare l'accesso alle sole informazioni necessarie per ciascun ruolo. L'efficacia di tali misure va poi documentata e monitorata nel tempo attraverso indicatori di performance (KPI) adeguati, aggiornandoli in funzione dei progressi tecnologici e dei nuovi rischi emergenti.
Un tema particolarmente delicato riguarda il trasferimento di dati personali al di fuori dell'Unione Europea. In un mercato in cui molte piattaforme ACDat sono fornite da vendor internazionali con server situati oltre i confini UE, questa non è affatto una casistica teorica. Occorre infatti verificare le garanzie offerte dal fornitore: clausole contrattuali standard, decisioni di adeguatezza della Commissione europea o altri meccanismi formalmente riconosciuti dal GDPR. Ignorare questo aspetto in fase di selezione della piattaforma espone l'organizzazione a rischi significativi.
Figura 2 - Paradigmi fondanti del GDPR
Il versioning, ovvero la gestione sistematica delle versioni successive di un contenitore informativo, è uno dei requisiti minimi che un ACDat conforme alla normativa italiana deve soddisfare. Il D.Lgs. 36/2023 e il quadro regolatorio attuativo richiedono infatti che l'ACDat garantisca la tracciabilità e la successione storica delle revisioni apportate ai dati contenuti, oltre alla loro conservazione nel tempo e al costante aggiornamento. Non si tratta di una funzionalità opzionale, ma di una vera e propria condizione di conformità.
In un progetto che può durare mesi o anni, con documenti rielaborati da più professionisti appartenenti a team diversi, è indispensabile denominare in modo univoco ogni file digitale presente nell'ACDat, così da rendere evidente sia la sequenza temporale sia la responsabilità delle lavorazioni. Un sistema di versioning correttamente impostato permette di conservare, oltre alla versione corrente, tutte le versioni precedenti, ciascuna identificata in modo univoco. Questo non serve solo a ricostruire la storia del progetto, ma tutela i singoli professionisti in caso di contestazioni.
La UNI EN ISO 19650 e la UNI 11337-5 definiscono tre stati fondamentali attraverso cui un contenitore informativo transita nel ciclo di vita del progetto:
A questi tre stati si aggiunge lo stato Archived (Archivio), fondamentale al termine del progetto. I contenitori informativi non più attivi, compresi quelli superati, devono essere conservati in modalità di sola lettura per far fronte a eventuali controversie e per capitalizzare l'esperienza in progetti futuri.
I tempi di conservazione devono essere definiti nel Capitolato Informativo. A livello di revisione, è prassi consolidata adottare codici granulari che identifichino lo stato di ogni singola versione: dalle bozze preliminari fino alle versioni "superate", ovvero sostituite da una revisione successiva. Questi codici, integrati nei metadati obbligatori dell'ACDat, rendono leggibile a colpo d'occhio lo stato di avanzamento di ciascun contenitore.
Il tema della tracciabilità nell'ACDat assume una dimensione non solo organizzativa, ma anche prettamente giuridica. Sebbene un ACDat consenta la tracciabilità degli accessi e delle operazioni, i classici strumenti di gestione documentale non rispondono a protocolli formalmente riconosciuti dall'ordinamento. In pratica, i dati di tracciabilità delle operazioni, per quanto affidabili sul piano tecnico, non trovano un automatico riconoscimento in sede giudiziale. Il CDE è infatti un sistema di proprietà di una delle parti, il che offre scarse garanzie in termini di incorruttibilità delle transazioni e di opponibilità verso terzi.
In questo contesto si inserisce l'interesse crescente per l'applicazione della tecnologia blockchain ai sistemi ACDat. I database centralizzati tradizionali sono vulnerabili soprattutto ad attacchi interni: la manipolazione dei dati da parte di utenti autorizzati, per negligenza o con intenti malevoli, rappresenta una minaccia concreta e difficile da rilevare a posteriori. Registrare le operazioni su blockchain significa rendere ogni singola azione degli utenti immutabile nel tempo, creando così un deterrente efficace e una base solida per la responsabilizzazione di tutte le parti.
È importante essere precisi su cosa la blockchain garantisca e cosa no. Registrare informazioni su una blockchain non equivale a certificarne la veridicità: la tecnologia attesta l'immutabilità e l'immodificabilità nel tempo di un documento informatico in un preciso momento storico. Questo è sufficiente per garantire il non ripudio delle azioni e per rafforzare il valore probatorio delle informazioni contenute nell'ACDat, senza però sostituire una verifica del contenuto.
Sul fronte dell'interoperabilità, le openCDE API rappresentano lo strumento tecnico per connettere piattaforme ACDat diverse, consentendo lo scambio strutturato di informazioni senza perdere la tracciabilità. Per commesse complesse che coinvolgono più organizzazioni e più piattaforme, saper valutare e implementare queste soluzioni, anche in combinazione con tecnologie di registrazione su blockchain, è una competenza che un CDE Manager di livello avanzato non può assolutamente ignorare.
Figura 3 - Estratto dal webinar buildingSMART Italia: POC di registrazione in blockchain di un documento informatico da un CDE
La normativa italiana, in linea con la UNI EN ISO 19650 e in attuazione del D.Lgs. 36/2023, stabilisce i requisiti minimi che ogni soluzione ACDat deve soddisfare. Tra questi rientrano:
Su questi requisiti si innesta la figura del CDE Manager, che non è un semplice amministratore di sistema, bensì il responsabile dell'approccio orientato alla sicurezza dell'intera organizzazione rispetto al processo informativo. Le sue responsabilità comprendono:
Questo implica una competenza che va ben oltre la selezione del software. Richiede la capacità di leggere i rischi organizzativi, di tradurli in politiche operative documentate, di verificarne l'efficacia e di aggiornarle al variare del contesto tecnologico o normativo. In un settore come quello delle costruzioni, attualmente impegnato in una trasformazione digitale strutturale, questa figura rappresenta un presidio indispensabile tra la tecnologia e il processo.
Figura 4 - Soluzione dTwin del gruppo Nemetschek
Privacy, cybersecurity e versioning non sono accessori tecnici dell'ACDat: sono i tre caposaldi su cui si costruisce la fiducia tra i soggetti che partecipano al processo informativo. Un Ambiente di Condivisione Dati privo di una gestione strutturata di questi tre aspetti è magari tecnicamente funzionante, ma si rivela giuridicamente fragile e organizzativamente rischioso.
Chi sta progettando o rivedendo la propria infrastruttura ACDat farebbe bene a partire da qui, prima ancora di confrontare le feature dei software disponibili sul mercato: definire la strategia di sicurezza, mappare i trattamenti dei dati personali e strutturare il versioning secondo gli stati previsti. Sono passaggi che richiedono tempo e competenza, ma che evitano problemi ben più costosi a progetto avviato.
Se vuoi approfondire la tematica, scrivimi a mario@napolitano.consulting oppure fai un salto sul mio profilo IG o sito web.