Capitolato informativo in cerca d’autore: requisiti informativi, responsabilità e verificabilità dalla gara alla consegna – Parte 2

Ripartiamo da qui:

Il capitolato informativo non è un semplice allegato BIM da compilare, ma un documento contrattuale in cui la stazione appaltante traduce i propri obiettivi in requisiti informativi verificabili. Secondo l’Allegato I.9 del Codice degli Appalti, deve contenere quattro elementi: requisiti informativi strategici, requisiti per produzione/gestione/trasmissione dei dati, caratteristiche dell’ambiente di condivisione dati (ACDat) e specifiche di interoperabilità. Ogni requisito richiede origine, scopo, tempistica, livello di fabbisogno informativo e criteri di accettazione. La stesura spetta al coordinatore dei flussi informativi, nominato dalla stazione appaltante nell’ambito del supporto al RUP, ma le esigenze informative devono nascere dagli obiettivi specifici dell’ente, non da capitolati copiati o standard genericamente applicati.

Un esempio pratico: quanto può essere difficile chiedere un dato?

Fin qui abbiamo parlato di requisiti informativi. Ma proviamo a prenderne uno e seguirlo dall’inizio alla fine.
Immaginiamo una stazione appaltante che debba gestire un edificio e che, tra le proprie esigenze, abbia quella di conoscere e controllare le caratteristiche delle porte resistenti al fuoco.
Potremmo essere tentati di scrivere nel capitolato:

Le porte tagliafuoco devono riportare la classe di resistenza al fuoco.
La frase è comprensibile. Ma come requisito informativo è ancora incompleta.
La prima domanda, infatti, viene prima del requisito: perché mi serve questa informazione?
Lo scopo potrebbe essere, ad esempio, disporre delle informazioni necessarie alla verifica e alla successiva gestione degli elementi che concorrono alla compartimentazione antincendio. È da questo scopo che nasce l’esigenza informativa.
A quel punto dobbiamo tradurla in qualcosa di più preciso: quali oggetti mi interessano? Quale informazione devono possedere? Quando mi serve? Come deve essere rappresentata?

Cominciamo così a costruire la catena:
scopo → oggetto → informazione richiesta → modalità di rappresentazione → criterio di accettazione → verifica.
Ed è qui che una frase apparentemente banale comincia a diventare un vero requisito.
Se la consegna prevista è un modello IFC, per esempio, non basta più dire genericamente “porta” e “resistenza al fuoco”. Dobbiamo sapere dove quell’informazione dovrà trovarsi nel modello.
Nello schema IFC possiamo identificare la porta attraverso l’entità IfcDoor. La proprietà standard relativa alla resistenza al fuoco è FireRating, prevista nel Pset_DoorCommon.
Il requisito comincia quindi ad assumere una forma molto diversa:
Oggetto: IfcDoor  |  Proprietà: FireRating  |  Property set: Pset_DoorCommon  |  Cardinalità: obbligatoria per gli oggetti ai quali il requisito si applica  |  Valore atteso: quello stabilito per la specifica porta, ad esempio EI 60.

Ma non abbiamo ancora finito.
Dobbiamo stabilire a quali porte si applica. Tutte le IfcDoor? Soltanto quelle interessate dalla compartimentazione? Come vengono riconosciute? Attraverso una classificazione? Una proprietà? Un’altra regola? La risposta non è indifferente, ed è il punto in cui molte regole di verifica si rompono. Se selezioniamo tutte le porte, ogni porta interna ordinaria risulterà non conforme perché priva di una resistenza al fuoco che nessuno le ha mai chiesto. Se invece selezioniamo le porte che possiedono già la proprietà, quelle a cui il progettista si è dimenticato di attribuirla non entreranno nel controllo e passeranno inosservate. Il criterio che individua gli oggetti soggetti al requisito deve quindi essere indipendente dalla proprietà che stiamo controllando: una classificazione dichiarata nel capitolato, un tipo, un’altra proprietà obbligatoria.

Questa non è una questione secondaria. Una macchina non interpreta la frase “controlla le porte tagliafuoco” come farebbe una persona. Prima deve sapere quali oggetti selezionare, poi che cosa controllare su quegli oggetti.

È esattamente la logica di una specifica IDS: una parte definisce l’applicabilità, cioè quali oggetti devono essere controllati; l’altra definisce i requisiti che quegli oggetti devono soddisfare.
A quel punto possiamo arrivare fino al criterio di accettazione:
il requisito è soddisfatto se tutte le porte alle quali esso si applica possiedono la proprietà FireRating nel Pset_DoorCommon e il valore corrisponde a quello richiesto.
Adesso sì che abbiamo qualcosa che può essere verificato.

E, se il requisito è stato strutturato correttamente, quella verifica può anche essere tradotta in IDS ed eseguita sul modello IFC. Non chiediamo più a qualcuno di aprire il modello, selezionare una porta, cercare una proprietà e decidere a occhio se “sembra tutto a posto”. Possiamo ottenere un esito per gli oggetti ai quali la regola si applica: conforme oppure non conforme. A questi si affianca un terzo caso, che non è un esito della regola ma uno stato del controllo: quando il modello non è leggibile nella forma prevista, la verifica non è stata eseguita e non equivale a un esito negativo. E qui emerge il punto che ci interessa.
Siamo partiti da una frase di nove parole: “Le porte tagliafuoco devono riportare la classe di resistenza al fuoco”.
Per renderla realmente governabile abbiamo dovuto stabilire perché ci serve, a quali oggetti si applica, come riconosciamo quegli oggetti, quale informazione chiediamo, dove deve essere memorizzata, quale valore accettiamo e come la verificheremo. E questo era un solo requisito.

Immaginiamo ora di dover fare lo stesso lavoro per decine o centinaia di proprietà, geometrie, classificazioni, documenti e requisiti di processo.
È qui che il capitolato informativo smette definitivamente di essere un documento da compilare. Diventa un sistema di requisiti da progettare e governare.

E l’IDS? Arriva alla fine, non all’inizio.

Se il requisito riguarda informazioni strutturate contenute in un modello IFC, questa catena può fare un ulteriore passo. L’oggetto può diventare un’entità IFC, il dato una proprietà precisamente identificata, il valore atteso una condizione da soddisfare e il criterio di accettazione una regola verificabile.
Nel nostro esempio non chiediamo più genericamente che “la porta riporti la resistenza al fuoco”. Stabiliamo che, per le porte alle quali il requisito si applica, l’informazione debba essere presente nella proprietà FireRating del Pset_DoorCommon e debba assumere il valore richiesto.
A questo punto quella parte del requisito può essere tradotta in una specifica IDS: prima si individuano gli oggetti ai quali la regola si applica, poi si dichiarano le condizioni che quegli oggetti devono soddisfare.
Il controllo sul modello IFC potrà quindi produrre un’evidenza: quella porta è conforme, non è conforme oppure non è stato possibile verificarla nella forma prevista.
Ma attenzione al verso della catena: non siamo partiti dall’IDS per decidere che cosa chiedere. Siamo partiti da un’esigenza della stazione appaltante e siamo arrivati all’IDS perché avevamo definito abbastanza bene il requisito da poterlo rendere verificabile.
Ed è questa, probabilmente, la differenza tra chiedere un dato e progettare un requisito informativo.

Una riga del Codice, cinque obblighi della norma

Abbiamo impiegato un intero paragrafo per costruire un solo requisito. Siamo partiti da un’esigenza, abbiamo individuato lo scopo, l’oggetto, il dato da chiedere, il valore atteso, il criterio di accettazione e il metodo con cui verificarlo. Adesso torniamo al capitolato.
Il comma 7 dell’Allegato I.9 stabilisce che, ai fini della gestione informativa digitale, rilevano le norme internazionali della serie UNI EN ISO 19650, mentre le norme della serie UNI 11337 costituiscono un utile riferimento.
Ed è proprio entrando nelle norme tecniche che le quattro grandi voci indicate dal Codice cominciano ad aprirsi.
Prendiamo ancora una volta la prima: i requisiti informativi.
La UNI EN ISO 19650-2, al punto 5.2.1, non si limita a dire che devi definirli. Dietro quella richiesta trovi una serie di decisioni: devi tenere conto dei requisiti dell’organizzazione, del cespite e della commessa; definire il livello di fabbisogno informativo necessario per soddisfare ciascun requisito; stabilire i criteri di accettazione; individuare le eventuali informazioni di supporto; definire scadenze di consegna e punti decisionali.

Cinque obblighi per una sola delle quattro voci del Codice. E ciascuno di essi è una decisione da prendere, non una casella da spuntare. Il punto è un altro: ogni voce si apre.

“Definire un requisito” significa prendere una decisione. “Definire il livello di fabbisogno informativo” significa prenderne un’altra. Stabilire un criterio di accettazione significa decidere prima della consegna quale evidenza ti permetterà di dire sì, questo requisito è soddisfatto. Stabilire quando quell’informazione deve essere disponibile significa collegarla a una fase, a una consegna o a un punto decisionale.

E soprattutto queste decisioni non sono indipendenti. Il livello di fabbisogno informativo deve essere adeguato allo scopo per il quale chiedi l’informazione. Il criterio di accettazione deve essere coerente con il requisito. Il metodo di verifica deve essere compatibile con il modo in cui hai chiesto di rappresentare il dato. La scadenza deve essere collocata prima del momento in cui quel dato servirà per assumere una decisione.
È la stessa catena che abbiamo appena visto con la porta tagliafuoco, soltanto moltiplicata per tutti i requisiti della commessa. Ed è qui che comincia a emergere un problema molto concreto.

Come fai a sapere che non hai perso un anello?

Puoi avere scritto correttamente il requisito e aver dimenticato il criterio di accettazione. Puoi aver definito una proprietà e non aver chiarito a quali oggetti si applica. Puoi aver chiesto un’informazione senza riuscire più a ricostruire a quale esigenza della stazione appaltante rispondesse. Oppure puoi aver stabilito un controllo che, al momento della consegna, scopri di non poter realmente eseguire. Il rischio, quindi, non è soltanto dimenticare una voce del capitolato. Il rischio è perdere la relazione tra le decisioni. E più aumentano i requisiti, più questa relazione diventa difficile da governare attraverso un documento costruito esclusivamente come una sequenza di paragrafi e tabelle.

A questo punto il capitolato informativo comincia ad assomigliare meno a un testo e molto di più a una struttura di dati e relazioni che, alla fine, viene anche rappresentata in un documento.
Questa distinzione sarà importante più avanti.
Per ora ci basta una domanda molto semplice: se per un solo requisito abbiamo dovuto costruire tutta la catena che abbiamo appena visto, che cosa dobbiamo fare quando i requisiti diventano cinquanta, cento o trecento?

È da qui che conviene iniziare a smontarli, uno alla volta.

Generali e specifici: ma soprattutto, perché li stai chiedendo?

Abbiamo visto quanto lavoro può esserci dietro una richiesta apparentemente semplice. Ma c’è una domanda che viene ancora prima di IfcDoor, di FireRating, del livello di fabbisogno informativo e persino dell’IDS:
perché stai chiedendo quell’informazione?
Il Codice parla espressamente di requisiti informativi strategici generali e specifici e chiede che siano definiti tenendo conto della natura dell’opera, del livello progettuale e del tipo di appalto.
Il rischio è leggere questa prescrizione come un’altra classificazione da riportare nel capitolato: requisiti generali da una parte, requisiti specifici dall’altra.
Ma il punto più interessante è un altro.
Un requisito non dovrebbe comparire nel capitolato semplicemente perché “nel BIM si fa così”, perché era presente nel capitolato precedente o perché qualcuno dispone di una libreria di proprietà molto dettagliata. Dovrebbe esserci perché serve a soddisfare un’esigenza concreta della stazione appaltante. Torniamo alla nostra porta.
Non abbiamo chiesto FireRating perché IFC mette a disposizione quella proprietà. Siamo arrivati a FireRating perché avevamo prima individuato un’esigenza: disporre delle informazioni necessarie a conoscere e verificare le prestazioni delle porte interessate dalla compartimentazione antincendio. Il verso è questo:
non parto dal dato per cercargli uno scopo; parto dallo scopo per capire quali dati mi servono. Sembra una differenza sottile. In realtà cambia completamente il modo di costruire un capitolato informativo.
Se parti dai dati, il rischio è produrre lunghi elenchi di proprietà da compilare: materiale, produttore, codice, trasmittanza, resistenza al fuoco, manutenzione, classificazione, vita utile e così via. Più informazioni chiedi, più il capitolato sembra completo. Ma completezza e utilità non sono la stessa cosa.
Ogni informazione richiesta ha un costo: qualcuno dovrà produrla, aggiornarla, consegnarla e qualcun altro, almeno in teoria, dovrà controllarla. Un dato che non serve a nessun obiettivo è quindi non soltanto inutile: genera lavoro senza produrre valore informativo.
E allora la domanda da fare davanti a ogni requisito diventa quasi brutale nella sua semplicità:
“Che cosa farò con questa informazione?”

Se non sappiamo rispondere, forse non abbiamo ancora un requisito. Abbiamo soltanto un dato che abbiamo deciso di chiedere.
Ed è qui che la distinzione tra requisiti generali e specifici acquista un significato operativo. Alcune esigenze appartengono all’organizzazione e possono ripetersi in molte commesse; altre nascono invece dallo specifico intervento, dal cespite, dalla fase o dalla decisione che dovrà essere assunta.
La UNI EN ISO 19650-2, quando tratta la definizione dei requisiti informativi, richiama infatti i requisiti dell’organizzazione, del cespite e della commessa.
Questo significa che il capitolato non dovrebbe essere una raccolta piatta di prescrizioni. Dietro ogni requisito dovrebbe essere possibile risalire alla ragione per cui esiste.
E qui compare un’altra difficoltà pratica. Con cinque requisiti puoi ricordartelo. Con cinquanta forse puoi ricostruirlo. Con trecento, distribuiti tra discipline, oggetti e fasi diverse, diventa molto più difficile.
Per questo la vera domanda non è soltanto: “Ho scritto tutti i requisiti?”
È piuttosto: “Per ciascun requisito, riesco ancora a dimostrare da quale esigenza nasce e quale obiettivo deve soddisfare?”
Perché se perdi questo collegamento, puoi avere un capitolato molto dettagliato, tecnicamente sofisticato e perfino verificabile automaticamente. Ma potresti non sapere più perché stai verificando quelle informazioni. E un requisito senza uno scopo è soltanto un dato in cerca di una ragione.

Quanto chiedere: il livello di fabbisogno informativo

Abbiamo stabilito che ogni requisito dovrebbe nascere da uno scopo. Ma sapere che cosa chiedere non basta. C’è una seconda domanda, altrettanto importante: quanto devo chiedere?
La UNI EN ISO 19650-1, al punto 11.2, dà un’indicazione molto forte: il livello di fabbisogno informativo dovrebbe essere determinato sulla base della quantità minima di informazioni necessarie per rispondere a ciascun requisito. Ciò che eccede questo minimo viene considerato spreco. Spreco. La parola è importante, perché mette in discussione un’abitudine abbastanza diffusa: pensare che un modello sia tanto migliore quanto più è ricco di informazioni. Non necessariamente.
Se per raggiungere il mio scopo ho bisogno di conoscere la resistenza al fuoco di una porta, chiedere altre venti proprietà che non utilizzerò per nessuna decisione non rende migliore il requisito. Rende semplicemente più oneroso produrlo, aggiornarlo e controllarlo.
Ed è proprio qui che torna utile la catena che abbiamo costruito nel paragrafo precedente.
Non posso stabilire il livello di fabbisogno informativo se prima non so a quale scopo deve rispondere l’informazione.
Torniamo ancora per un momento alla nostra porta.
Se mi serve soltanto verificare che una determinata porta possieda la prestazione di resistenza al fuoco prevista, potrebbero essere sufficienti l’identificazione corretta dell’oggetto e le informazioni alfanumeriche necessarie a effettuare quella verifica.

Se invece quella stessa porta dovrà essere utilizzata successivamente per attività di gestione e manutenzione, potranno servirmi altre informazioni: identificazione del prodotto installato, documentazione, dati utili alla manutenzione o altre caratteristiche necessarie allo specifico uso.

L’oggetto è sempre lo stesso. Lo scopo è cambiato. E quindi cambia anche ciò che è necessario sapere dell’oggetto.
È questo il senso più interessante del livello di fabbisogno informativo: non descrivere genericamente quanto deve essere dettagliato il modello, ma stabilire quali informazioni sono necessarie per soddisfare uno specifico scopo.
E quelle informazioni non sono soltanto geometriche.
Il livello di fabbisogno informativo può riguardare informazioni geometriche, informazioni alfanumeriche e documentazione. Lo dice la UNI EN ISO 7817-1:2024, che al punto 7 elenca proprio questi contenuti e li esemplifica con la presenza di un oggetto come una porta, la sua resistenza al fuoco, la sua posizione e un documento associato come una garanzia. La stessa norma distingue la verifica, che accerta se la caratteristica c’è, dalla validazione, che accerta se il valore è ammissibile secondo le legislazioni nazionali.
Questo cambia parecchio il modo di ragionare.
Non dovremmo più domandarci genericamente: “A che livello di dettaglio voglio il modello?”
Dovremmo piuttosto domandarci: “Per questo requisito e per questo specifico scopo, qual è l’informazione minima che mi serve?”
Solo dopo possiamo decidere quale informazione geometrica occorre, quali dati alfanumerici devono essere presenti e quale documentazione deve accompagnarli.
La conseguenza è importante anche nella redazione del capitolato.
Un unico livello di fabbisogno informativo assegnato indistintamente a un intero progetto rischia di perdere proprio questa relazione. Il fabbisogno nasce dal requisito e dallo scopo che quel requisito deve soddisfare, non dalla volontà di attribuire un’etichetta generale al modello.
E qui si vede ancora una volta perché costruire il capitolato come un semplice elenco può diventare problematico.
Per ogni requisito dobbiamo riuscire a mantenere il collegamento: scopo → requisito → oggetto → livello di fabbisogno informativo.
E dobbiamo chiedere abbastanza per poter assumere la decisione che ci interessa, ma non più di quanto realmente necessario.
Perché chiedere troppo non è prudenza.
È chiedere informazioni che qualcuno dovrà produrre e che la stazione appaltante dovrà poi essere in grado di governare.
E una volta stabilito quanto chiedere, resta la domanda forse più scomoda di tutte: come farò a sapere che quello che mi hanno consegnato è davvero ciò che avevo chiesto?
È qui che entra in gioco il criterio di accettazione.

Riferimenti essenziali

• D.lgs. 36/2023, art. 43; Allegato I.9; Allegato I.7, art. 13, comma 2, lettera h);
• Linee guida per la gestione informativa digitale per le stazioni appaltanti e gli enti concedenti, Ministero delle Infrastrutture e dei Trasporti, 20 febbraio 2026;
• UNI EN ISO 19650-1:2019, punti 5.1 e 11.2;
• UNI EN ISO 19650-2:2019, punti 3.1.1.1 e 5.2.1;
• UNI 11337-5:2017, punto 4.2;
• UNI EN ISO 16739-1, schema IFC;
• buildingSMART, IFC4 Reference View V1.2, per la riserva sui prefissi Pset_ e Qto_.

A cura dell’ ing. Nicola Furcolo: BIM Manager, docente e autore.