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

Ripartiamo da qui:

Il capitolato informativo non è un modulo da compilare copiando un modello precedente, ma un documento contrattuale in cui la stazione appaltante traduce i propri obiettivi in requisiti informativi precisi e verificabili. Il Codice dei Contratti (Allegato I.9) impone quattro contenuti minimi: requisiti informativi strategici, requisiti di produzione e gestione dei dati, caratteristiche dell’ambiente di condivisione dati e specifiche di interoperabilità. Ogni requisito, per essere utile, deve seguire una catena precisa: scopo, oggetto, informazione richiesta, livello di fabbisogno informativo, criterio di accettazione e metodo di verifica. A redigerlo è il coordinatore dei flussi informativi, affiancato dal RUP, ma le esigenze informative restano proprie della stazione appaltante e non possono essere delegate o copiate da altri capitolati.

 

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

 

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

Il criterio di accettazione: decidere prima come dirai sì o no

Abbiamo stabilito perché chiediamo un’informazione. Abbiamo stabilito che cosa chiedere e quanto chiedere.

Manca però una decisione fondamentale: come stabiliremo che ciò che ci viene consegnato soddisfa davvero il requisito?

La UNI EN ISO 19650-2, al punto 5.2.1, lettera c), non si limita a suggerirlo: dice che il soggetto proponente “deve definire i criteri di accettazione per ogni requisito informativo”. Due parole reggono l’adempimento. Deve, perché siamo nella parte della norma che porta gli obblighi. E per ogni requisito: non uno per il capitolato, non uno per la fase. E la stessa norma definisce il criterio di accettazione come l'”evidenza richiesta per dimostrare che i requisiti sono stati soddisfatti”.

La parola decisiva è evidenza.

E nei capitolati veri? Abbiamo cercato la locuzione “criteri di accettazione” in quattro forme diverse dentro 132 documenti di gara reali, al 31 agosto 2026. In 130 non compare mai. Nei due in cui compare, uno dichiara il criterio della consegna nel suo insieme, l’altro non è nemmeno un capitolato informativo. Nessuno dei due lo fa per singolo requisito.

Il numero misura la presenza di quelle quattro locuzioni, non la conformità: un capitolato che scrivesse “il requisito si intende soddisfatto quando” sfuggirebbe alla ricerca. La frase esatta è che quelle quattro locuzioni non compaiono in centotrenta documenti su centotrentadue.

C’è un dato che sposta la spiegazione. Le Linee guida del Ministero delle Infrastrutture e dei Trasporti del 20 febbraio 2026 dedicano 62 pagine a come una stazione appaltante governa la gestione informativa. La parola “accettazione” non vi compare nemmeno una volta. Nello stesso documento “verifica” compare 66 volte. La guida ufficiale dice di verificare, in continuazione, e non dice mai rispetto a quale evidenza si accetta.

Perché sposta il problema dal momento del controllo al momento in cui il requisito viene scritto.

Non dovremmo aspettare la consegna per domandarci se un’informazione va bene. Dovremmo stabilire prima che cosa dovrà esserci davanti agli occhi, nostri o di una macchina, per poter affermare che quel requisito è stato soddisfatto.

Torniamo ancora una volta alla nostra porta.

La porta deve riportare la classe di resistenza al fuoco.

esprime una richiesta, ma non dice ancora quale evidenza ci permetterà di accettarla.

Se invece abbiamo stabilito che, per le porte alle quali il requisito si applica, deve essere presente Pset_DoorCommon.FireRating, che la proprietà deve assumere il valore richiesto e che il controllo sarà effettuato sul modello IFC consegnato, abbiamo fatto qualcosa di diverso.

Abbiamo deciso prima della consegna che cosa controlleremo.

E possiamo andare ancora oltre. Se il requisito è espresso in una forma interpretabile dalla macchina, la verifica può controllare la presenza dell’oggetto, dell’informazione richiesta e, quando previsto, anche la validità del valore. La norma sul livello di fabbisogno informativo utilizza proprio la resistenza al fuoco di una porta come esempio di informazione che può essere verificata e validata.

Ma non tutti i requisiti sono così.

Alcuni potranno essere verificati automaticamente. Altri richiederanno un controllo documentale. Altri ancora potranno essere soltanto parzialmente verificati da una macchina e richiederanno la validazione di una persona.

Per questo criterio di accettazione e metodo di verifica non sono la stessa cosa.

Il criterio dice quale evidenza dimostrerà che il requisito è soddisfatto. Il metodo stabilisce come otterremo o controlleremo quell’evidenza.

È una distinzione importante anche perché evita un equivoco: automatizzare un controllo non significa delegare alla macchina la decisione della stazione appaltante. La macchina può verificare che una proprietà esista, che un valore appartenga a un insieme ammesso o che una determinata regola sia rispettata. Ma la regola deve essere stata decisa prima da qualcuno.

Ed eccoci di nuovo all’autore.

È la stazione appaltante che deve decidere che cosa considera accettabile. Lo strumento di verifica può soltanto applicare quella decisione.

La UNI 11337-5 rafforza questa impostazione chiedendo che i requisiti informativi siano specifici e, ove possibile, misurabili, con l’indicazione dei limiti di accettazione e le tolleranze consentite.

A questo punto la nostra catena si allunga ancora: esigenza → scopo → requisito → oggetto → livello di fabbisogno informativo → criterio di accettazione → metodo di verifica → evidenza.

E qui compare una conseguenza forse più importante di tutte.

Se nel capitolato scriviamo un requisito senza sapere quale evidenza ci consentirà di verificarne il soddisfacimento, stiamo rinviando una decisione che avremmo dovuto assumere prima della gara.

Il problema emergerà dopo, quando l’affidatario avrà già prodotto l’informazione.

E allora la domanda non sarà più soltanto “mi hai consegnato quello che avevo chiesto?”.

Potrebbe diventare: “ma che cosa avevo chiesto, esattamente?”

È per questo che il criterio di accettazione non è l’ultimo controllo della catena.

È una parte del requisito stesso.

E una volta stabilito che cosa vogliamo controllare, dobbiamo affrontare un problema ancora più concreto: dove deve trovarsi esattamente quell’informazione perché noi, o una macchina, possiamo ritrovarla?

È qui che entrano in gioco nomi, proprietà, Pset, classificazioni e strutture dati.

Il dato deve avere un indirizzo

Abbiamo deciso perché chiedere un’informazione, quanto chiederne e quale evidenza ci permetterà di accettarla.

Adesso resta una questione apparentemente banale: dove deve trovarsi quel dato?

Torniamo alla nostra porta. Possiamo aver scritto che vogliamo conoscere la resistenza al fuoco, aver stabilito il valore richiesto e persino aver deciso di controllarlo sul modello IFC. Ma se l’informazione può essere scritta ogni volta in un posto diverso, con un nome diverso o secondo una convenzione diversa, la verifica torna a dipendere dall’interpretazione di chi apre il modello.

In un modello informativo, quindi, non basta che il dato ci sia. Dobbiamo sapere dove cercarlo.

È qui che la standardizzazione diventa molto concreta.

Nel nostro esempio abbiamo individuato IfcDoor, il property set Pset_DoorCommon e la proprietà FireRating. Non abbiamo inventato questi nomi per rendere più ordinato il capitolato: stiamo utilizzando una struttura dati condivisa. Ed è proprio questa condivisione che consente a soggetti e strumenti diversi di attribuire lo stesso significato alla stessa informazione.

La questione diventa ancora più evidente quando l’informazione che ci serve non è già prevista nello schema standard.

La stazione appaltante può avere esigenze proprie e quindi richiedere proprietà aggiuntive. Ma anche in questo caso quelle informazioni devono essere governate: occorre stabilire come si chiamano, dove vengono collocate e quale significato assumono. Il prefisso Pset_ è riservato ai property set standard IFC e non dovrebbe essere utilizzato per property set personalizzati.

Sembra un dettaglio da specialisti IFC.

In realtà è esattamente lo stesso problema che stiamo affrontando dall’inizio: rendere una richiesta non soltanto comprensibile, ma non ambigua e verificabile.

Immaginiamo di ricevere tre modelli nei quali la stessa informazione sia chiamata rispettivamente FireRating, ResistenzaFuoco e Classe_REI.

Una persona potrebbe probabilmente capire che i tre campi vogliono esprimere qualcosa di simile.

Una macchina, senza una regola che stabilisca quella corrispondenza, no.

E soprattutto la stazione appaltante non dovrebbe essere costretta, a ogni consegna, a ricostruire quale convenzione abbia utilizzato ciascun affidatario.

Per questo la struttura del dato non è un problema che nasce dopo, quando riceviamo il modello. È una decisione che appartiene al capitolato informativo.

Se vogliamo che un requisito possa essere verificato attraverso una specifica IDS, la necessità diventa ancora più evidente. L’IDS formalizza requisiti applicati a oggetti IFC attraverso entità, proprietà, classificazioni e altri elementi precisamente identificabili: prima definisce a quali oggetti si applica la regola, poi quali condizioni quegli oggetti devono soddisfare.

La macchina, insomma, non deve indovinare.

Deve poter leggere una regola.

E qui possiamo aggiungere un altro anello alla nostra catena: esigenza → scopo → requisito → oggetto → livello di fabbisogno → struttura del dato → criterio di accettazione → metodo di verifica → evidenza.

Più questa catena è definita, meno spazio lasciamo all’interpretazione nel momento peggiore possibile: quando la consegna è già arrivata.

Ma attenzione: questo non significa trasformare ogni requisito del capitolato in una proprietà IFC.

Alcuni requisiti riguarderanno la geometria, altri informazioni alfanumeriche, altri ancora documentazione. E altri saranno requisiti di processo, organizzativi o tecnologici che non possono essere ridotti a un campo all’interno di un modello.

Il principio rimane però lo stesso: ogni informazione deve avere un posto, una forma e una regola sufficientemente chiari da consentirci di ritrovarla e verificarla.

A questo punto potremmo pensare di aver finito.

Abbiamo definito il requisito, stabilito quanto chiedere, deciso dove deve stare il dato e come controllarlo.

Ma il capitolato informativo viene scritto prima della gara.

Quel requisito deve ancora attraversare l’offerta dell’operatore economico, entrare nel piano di gestione informativa, arrivare nelle consegne e infine essere verificato.

Ed è proprio durante questo viaggio che rischiamo di perderlo.

Dal capitolato alla consegna: il requisito deve sopravvivere

A questo punto il requisito sembra completo.

Sappiamo perché lo chiediamo, che cosa chiediamo, quanto chiediamo, dove deve trovarsi l’informazione e come intendiamo verificarla.

Potremmo pensare che il lavoro del capitolato informativo sia finito.

In realtà, è appena cominciato.

Il capitolato viene posto a base della procedura. Da quel momento il requisito che abbiamo costruito deve attraversare una serie di passaggi: viene letto dall’operatore economico, trova una risposta nell’offerta di gestione informativa, viene consolidato nel piano di gestione informativa e, infine, deve arrivare nelle consegne prodotte durante l’esecuzione. Una precisazione che conviene avere presente: l’offerta di gestione informativa non è dovuta sempre. L’Allegato I.9, all’articolo 1 comma 10 lettera b), la prescrive nelle procedure con il criterio dell’offerta economicamente più vantaggiosa. Negli altri casi la catena passa direttamente dal capitolato al piano di gestione informativa.

La vera catena, quindi, non termina nel capitolato: CI → offerta → PGI → consegna → verifica → esito.

Ed è qui che compare un problema diverso da quelli affrontati finora: la tracciabilità.

Torniamo ancora alla nostra porta. Nel capitolato abbiamo chiesto una determinata informazione, con una struttura e un criterio di accettazione precisi. Quando riceviamo l’offerta, dovremmo poter capire come l’operatore economico intende soddisfare proprio quel requisito.

Quando viene predisposto il piano di gestione informativa, dovremmo poter verificare che quella risposta sia stata mantenuta, sviluppata e resa coerente con quanto richiesto e con quanto offerto.

E quando arriva il modello IFC, dovremmo poter tornare ancora una volta allo stesso requisito e verificare ciò che è stato effettivamente consegnato.

Sembra scontato.

Ma significa che lo stesso requisito deve restare riconoscibile mentre cambia il documento che lo contiene e il soggetto che lo gestisce.

Se nel capitolato è una riga, nell’offerta diventa un impegno, nel PGI una modalità operativa e nella consegna un’informazione concreta. Alla fine, però, dobbiamo essere ancora in grado di ricostruire il percorso:

questo era ciò che avevo chiesto → questa è stata la risposta → questo è ciò che è stato pianificato → questo è ciò che è stato consegnato → questo è l’esito del controllo.

È questa continuità che trasforma il capitolato da documento iniziale a strumento di governo della commessa.

E introduce anche un tema contrattuale che non va sottovalutato.

L’Allegato I.9 disciplina la prevalenza contrattuale dei contenuti informativi e le Linee guida MIT precisano come questa debba essere letta anche in relazione alle scelte di modellazione e a quanto dichiarato nel piano di gestione informativa.

Questo rende ancora meno convincente l’idea di un capitolato informativo che venga scritto, allegato alla gara e poi sostanzialmente dimenticato.

Il requisito deve sopravvivere.

Deve sopravvivere ai chiarimenti, all’offerta, alla contrattualizzazione, al PGI, alle revisioni e alle consegne.

E soprattutto deve sopravvivere senza perdere il legame con la ragione per cui era stato formulato e con il criterio con cui avevamo deciso di verificarlo.

Perché se quel legame si spezza, alla fine potremmo avere davanti un modello ricchissimo di informazioni e non essere più in grado di rispondere alla domanda più semplice: “È quello che avevamo chiesto?”

A questo punto la catena completa comincia a diventare evidente.

Da una parte abbiamo la costruzione del requisito: esigenza → scopo → requisito → oggetto → livello di fabbisogno → struttura del dato → criterio di accettazione → metodo di verifica.

Dall’altra abbiamo la sua vita nella commessa: capitolato → offerta → PGI → consegna → verifica → evidenza → esito.

Le due catene non sono separate.

Sono la stessa catena.

Ed è probabilmente qui che si vede il limite più grande del pensare al capitolato informativo soltanto come a un documento da scrivere.

Perché quando i requisiti diventano cento o trecento, il problema non è più soltanto redigere un buon capitolato.

È riuscire a non perderne nessuno lungo la strada.

E quando i requisiti diventano cento?

Finora abbiamo seguito un requisito alla volta.

Lo abbiamo fatto nascere da un’esigenza, lo abbiamo collegato a uno scopo, abbiamo stabilito quali informazioni chiedere, quanto chiederne, dove trovarle, come verificarle e quale evidenza ci permetterà di accettarle. Poi abbiamo seguito quello stesso requisito dal capitolato fino alla consegna.

Con un requisito, il percorso è comprensibile.

Con dieci, probabilmente anche.

Ma proviamo a immaginarne cento!

Cento requisiti significa cento richieste che possono riferirsi a oggetti diversi, discipline diverse, fasi diverse e scopi diversi. Alcuni riguarderanno informazioni geometriche, altri dati alfanumerici, altri documentazione. Alcuni potranno essere verificati attraverso IDS, altri richiederanno controlli documentali o valutazioni che restano necessariamente umane.

E per ciascuno dovremmo riuscire a ricostruire la stessa storia: perché lo abbiamo chiesto → che cosa abbiamo chiesto → a chi e a che cosa si applica → quanto abbiamo chiesto → come deve essere rappresentato → quando deve essere consegnato → come lo controlleremo → quale evidenza dimostrerà che è soddisfatto.

A questo punto il problema cambia natura.

Non è più soltanto: “So scrivere un buon capitolato informativo?”

Diventa: “Come faccio a mantenere coerenti tutte queste decisioni?”

Un documento di testo è molto efficace per rappresentare il capitolato informativo. È ciò che verrà letto, approvato, allegato agli atti di gara e utilizzato dalle parti.

Ma il documento non necessariamente coincide con il modo migliore per costruire e governare le informazioni che contiene.

Se modifichiamo lo scopo di uno di essi, dovremmo verificare se è ancora corretto il livello di fabbisogno informativo. Se cambiamo il modo in cui chiediamo una proprietà, dobbiamo verificare che sia ancora coerente il criterio di accettazione. Se cambia il criterio, dobbiamo controllare che il metodo di verifica sia ancora applicabile. E quando riceviamo l’offerta o il PGI, dobbiamo riuscire a collegare la risposta dell’affidatario esattamente al requisito da cui eravamo partiti.

Non stiamo più gestendo soltanto delle righe.

Stiamo gestendo relazioni.

Ed è probabilmente questa la distinzione più utile da fare: il capitolato informativo può essere un documento come forma finale, ma ciò che contiene è sempre più simile a un sistema strutturato di requisiti.

Del resto, lo stesso Allegato I.9 apre esplicitamente alla possibilità di rendere i requisiti informativi in maniera analitica, secondo modelli di dati, anche per consentire un più efficiente accertamento della conformità.

Significa però che strutturare l’informazione può aiutarci a governarla.

Ed è qui che gli strumenti assumono un significato diverso.

Non servono a decidere al posto della stazione appaltante quali informazioni chiedere. Non possono conoscere al posto del RUP gli obiettivi dell’intervento. E non dovrebbero trasformare la redazione del capitolato in una sequenza automatica di caselle compilate da una macchina.

Possono però fare qualcosa di molto utile: impedire che una decisione venga persa.

Possono ricordarci che un requisito non ha ancora uno scopo associato; che manca il criterio di accettazione; che abbiamo previsto una verifica senza indicare l’informazione necessaria a eseguirla; che una risposta presente nel PGI non trova corrispondenza nel capitolato; oppure che una consegna è arrivata senza che un determinato requisito sia mai stato controllato.

La decisione resta umana.

La memoria della decisione può essere strutturata.

E forse è proprio questo il passaggio culturale più importante.

Digitalizzare il capitolato informativo non significa trasformare un file Word in un PDF, né compilare lo stesso documento attraverso una maschera.

Significa riuscire a mantenere viva la relazione: esigenza → requisito → risposta → consegna → verifica → evidenza.

Prima viene la struttura che permette a quelle informazioni di non perdersi.

Perché con cento requisiti il rischio maggiore non è dimenticare una riga.

È dimenticare perché quella riga esiste, che cosa doveva produrre e come avevamo deciso di controllarla.

Da portare in gara: la prova dei tre requisiti

Siamo partiti da un capitolato informativo in cerca d’autore.

Abbiamo scoperto che l’autore esiste, che il Codice gli assegna un ruolo preciso e che la stazione appaltante deve essere in grado di esplicitare le proprie esigenze informative.

Ma arrivati fin qui dovrebbe essere chiaro che trovare l’autore non basta.

Perché il vero lavoro non consiste nel riempire un documento. Consiste nel trasformare le esigenze della stazione appaltante in requisiti che abbiano uno scopo, un contenuto adeguato, una struttura riconoscibile, un criterio di accettazione e un metodo con cui possano essere verificati.

E poi bisogna fare in modo che tutto questo non si perda durante la commessa.

Prima di chiudere un capitolato informativo, allora, possiamo fare una prova molto semplice.

Prendiamo tre requisiti a caso.

Non quelli scritti meglio. Non quelli più importanti. Tre qualsiasi.

Per ciascuno proviamo a rispondere:

• perché lo stiamo chiedendo e a quale esigenza risponde;
• che cosa deve essere effettivamente prodotto;
• a quali oggetti o contenuti si applica;
• quanto è necessario chiedere per soddisfare quello scopo;
• dove e come deve essere rappresentata l’informazione;
• quale evidenza ci permetterà di affermare che il requisito è soddisfatto;
• come intendiamo effettuare quella verifica;
• quando quell’informazione dovrà essere disponibile.

E aggiungiamo un’ultima domanda: riusciremo a riconoscere lo stesso requisito nell’offerta, nel PGI e nella consegna finale?

Se riusciamo a rispondere a tutte queste domande, probabilmente non abbiamo soltanto scritto una prescrizione. Abbiamo progettato un requisito informativo.

Se invece a un certo punto la catena si interrompe, abbiamo individuato qualcosa che conviene risolvere prima della gara, non quando arriverà la consegna.

Ed è forse questo il modo più semplice per capire se un capitolato informativo sta davvero funzionando.

Non chiediamoci soltanto se contiene tutti i capitoli previsti.

Chiediamoci se ogni requisito riesce ad arrivare fino alla verifica senza perdere per strada il proprio significato.

Perché alla fine la questione è tutta qui.

Il capitolato informativo non è un elenco di dati da chiedere all’affidatario. È il punto nel quale la stazione appaltante decide che cosa ha bisogno di sapere, perché ha bisogno di saperlo e come farà a riconoscere che ciò che riceverà corrisponde davvero a ciò che aveva chiesto.

Gli strumenti possono aiutarci a mantenere queste relazioni, a segnalare ciò che manca e a conservare la tracciabilità delle decisioni.

Ma non possono sostituirsi all’autore.

Perché siamo tornati esattamente al punto da cui eravamo partiti.

I personaggi sono i requisiti informativi.

La norma può indicarci le regole della rappresentazione. Gli strumenti possono aiutarci a non perdere le battute. Ma qualcuno deve ancora decidere quale storia vuole raccontare.

E quella storia appartiene alla stazione appaltante.

Il capitolato informativo cerca un autore. Adesso sappiamo anche che cosa deve saper scrivere.

Due questioni operative da tenere presenti

Prima dei riferimenti, restano due aspetti che incidono direttamente sulla possibilità di governare e verificare i requisiti: la neutralità tecnologica dei formati e la continuità contrattuale dei contenuti informativi.

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.