Chi risponde se l'AI sbaglia un forecast di cantiere

C’è una domanda che in riunione di avanzamento sa creare un silenzio lungo: chi ha validato il dato che ha prodotto questo numero?

La scena è ormai ordinaria. Il report di forecast arriva in pochi minuti, prodotto da uno strumento AI collegato al sistema di controllo costi. Numeri puliti, grafici chiari, uno scostamento evidenziato in rosso su una lavorazione. Il cost controller ha caricato gli avanzamenti, il planner ha aggiornato il programma, qualcuno ha collegato i due flussi in una dashboard. Ognuno ha fatto la sua parte. Ma alla domanda su chi risponde se quel numero è sbagliato, spesso non corrisponde nessuno.

Il tema me l’ha riportato davanti un episodio del podcast Kosmos sulla formazione del data scientist nelle costruzioni, dove viene detto in modo molto diretto: siamo quantity surveyor, lavoriamo su costi e contratti, e la nostra formazione sfiora appena l’analisi dei dati. Abbiamo accelerato la parte analitica senza costruire quella di responsabilità. Su progetti dove un forecast si traduce in decisioni contrattuali, quel vuoto non resta teorico a lungo.

Il dato prima dell’algoritmo

Lo strumento AI, per quanto sofisticato, elabora quello che riceve. Su un progetto infrastrutturale il volume di dati è enorme: avanzamenti fisici, contabilità, programma, varianti, non conformità. Un CDE ben configurato aiuta a strutturare questo flusso, ma struttura non è sinonimo di qualità.

Chi alimenta quei flussi — il quantity surveyor che registra le quantità, il planner che aggiorna le date, il cost controller che riconcilia i due mondi — lavora spesso con convenzioni di naming, parametri e logiche di collegamento che non ha scelto e a volte non comprende fino in fondo. Il dato entra comunque. L’AI lo elabora comunque. E se la convenzione a monte è fragile, l’output a valle è solo un errore più veloce da produrre.

Ne ho scritto parlando di dati reali, non numeri a caso: un numero che sembra preciso non è automaticamente un numero vero. L’AI non risolve questo problema, lo amplifica, perché restituisce l’output con una sicurezza grafica che il dato grezzo non aveva.

Primo errore tipico: naming inconsistente tra sistemi. Il codice WBS usato in contabilità non coincide con quello usato nel programma. L’AI incrocia comunque i due dataset, ma l’incrocio è sbagliato alla radice.

Secondo errore: doppio conteggio negli avanzamenti. Succede quando la stessa lavorazione viene contabilizzata sia come fisica sia come economica senza un criterio di riconciliazione chiaro. Un algoritmo di forecasting non lo intercetta, perché non sa che è successo — vede solo numeri che quadrano.

Terzo errore: parametri non aggiornati. Produttività, costi unitari, curve di riferimento: se nessuno li rivede a cadenza regolare, l’AI proietta un futuro basato su un passato che non esiste più.

Quarto errore: clausole contrattuali che non stanno nel dataset. Se un subappalto ha una formula di revisione prezzi e il modello vede solo l’importo storico, l’estrapolazione è coerente con i dati che ha ricevuto e sbagliata rispetto al contratto. Non è un errore di calcolo, è un errore di perimetro — e si riconosce solo se qualcuno ha letto il contratto, non solo il dato.

Quinto errore: quantità geometriche usate come quantità contrattuali. Un modello restituisce volumi e superfici secondo la geometria. La contabilità li misura secondo le regole del contratto, con esclusioni, sovrapposizioni e criteri di misurazione propri. La differenza è spesso di pochi punti percentuali, costante e invisibile: esattamente il tipo di scostamento che nessuno nota finché non diventa una contestazione.

Sesto errore: CPI letto senza la curva dei costi. Nelle prime fasi i costi sono sbilanciati in avanti — mobilitazione, impianti di cantiere, approvvigionamenti. Un’estrapolazione lineare dell’indice di efficienza legge come sforamento quello che è un effetto di calendario. Il numero è corretto, la lettura no.

Un caso fuori dal cantiere che riguarda il cantiere

Il caso più istruttivo non viene dalle costruzioni, e proprio per questo è utile: nessuno può liquidarlo dicendo “da noi funziona diversamente”.

Zillow, negli Stati Uniti, comprava case per rivenderle. Il prezzo di acquisto lo decideva un modello che stimava il valore di vendita futuro. Non un esperimento: era il cuore operativo della divisione Zillow Offers, costruita da un’azienda di dati con competenze e risorse che un’impresa di costruzioni non ha.

Il 2 novembre 2021 il consiglio di amministrazione ha deciso di chiudere quella divisione. Nel terzo trimestre 2021 la società ha registrato una svalutazione di magazzino di 304,4 milioni di dollari, che a fine anno è arrivata a 407,9 milioni, insieme al taglio di circa il 25% del personale. La motivazione scritta nei documenti depositati alla SEC è asciutta: avevano acquistato case a prezzi più alti delle proprie stime correnti del prezzo di vendita futuro, al netto dei costi di vendita. L’amministratore delegato Rich Barton l’ha detta così: l’imprevedibilità nel prevedere i prezzi delle case supera di molto quello che avevano ipotizzato.

Tradotto per chi fa stime e controllo costi: un’organizzazione il cui mestiere era il modello ha perso quella cifra perché la previsione di un valore futuro ha incontrato un mercato che si muoveva diversamente. La lezione non è “non usare i modelli”. È che la previsione di un modello è un’ipotesi, e qualcuno deve assumersi la decisione di agirci sopra — con un margine per il caso in cui l’ipotesi sia sbagliata.

Quello che si trasferisce al nostro lavoro è il meccanismo, non il contesto: una stima di valore futuro che alimenta decisioni operative su larga scala, con nessun punto del processo in cui qualcuno possa dire “questo numero non lo firmo”. Un EAC che decide se aprire una riserva o rinegoziare un subappalto ha la stessa struttura, su scala diversa.

Fonti: Zillow Group, Form 10-K FY2021 e Form 8-K del 2 novembre 2021 depositati alla SEC; analisi in Stanford Graduate School of Business.

Il vuoto di responsabilità

Nel mondo BIM esiste una codifica chiara: BIM Manager, BIM Coordinator, BIM Specialist. Ruoli, competenze, perimetro di responsabilità definiti, spesso richiamati contrattualmente. Se un modello è sbagliato, si risale a chi lo ha prodotto e a chi lo ha validato.

Sul dato che alimenta una decisione di costo o di programma, questa codifica non esiste. Non c’è uno scope of work che dica: “questa persona valida l’input prima che entri nell’algoritmo”. Non c’è una competenza minima richiesta per interpretare un output AI prima di portarlo in una decisione. Non c’è, soprattutto, una risposta chiara alla domanda “di cosa rispondo se questa analisi è sbagliata e genera una decisione contrattuale o una variante”.

È lo stesso tema che affronto parlando di cost control come lavoro da detective: il numero da solo non basta, serve qualcuno che lo interroghi prima che diventi un’informazione su cui si decide. Con l’AI nel mezzo, quell’interrogazione diventa più urgente, non meno, perché la velocità di produzione del numero aumenta ma la capacità di verificarlo resta umana.

Il rischio concreto è questo: un manager che decide sulla base di un output che nessuno ha formalmente validato sta prendendo una decisione contrattualmente esposta senza saperlo. Se quella decisione genera un claim o una contestazione, la prima domanda che arriva da un ufficio legale è: “su quale base è stata presa questa decisione, e chi l’ha autorizzata?” Se la risposta è “l’ha detto il sistema”, non è una risposta.

Cosa significa validare, in pratica

Validare un output AI prima che entri in una decisione non è un esercizio teorico. Significa costruire un processo con passaggi espliciti.

Definire chi inserisce cosa. Ogni fonte dati (contabilità, programma, avanzamenti fisici) deve avere un responsabile nominato, non implicito. Se il dato è sbagliato, si sa da dove è partito.

Stabilire una soglia di revisione umana. Non tutti gli output richiedono lo stesso livello di controllo. Uno scostamento minore su una voce secondaria è diverso da un forecast che impatta il budget complessivo. Serve una regola scritta su quando l’output richiede firma di un responsabile tecnico prima di circolare.

Tracciare la catena. Da quale dataset è partita l’analisi, quali parametri ha usato il modello, chi l’ha rivista. Non per burocrazia, ma perché in caso di dispute questa tracciabilità è l’unica cosa che protegge chi ha preso la decisione.

Formare chi alimenta i flussi. Un quantity surveyor o un planner che capisce come il proprio dato viene usato a valle produce dati migliori. È lo stesso principio che vale per l’Earned Value Management, dove un dato di avanzamento scollegato dalla logica di calcolo genera previsioni inutili prima ancora che inaffidabili — ne ho scritto parlando di PMBOK 8 e AI nel project control.

Questi quattro punti non eliminano il rischio, ma lo rendono gestibile. E soprattutto, rendono possibile rispondere alla domanda “chi ha validato questo numero” senza silenzio in sala riunioni.

Le cinque domande da fare a un output prima di portarlo in una decisione

Non serve un protocollo da certificare. Servono cinque domande, sempre le stesse, che si fanno in due minuti:

1. Quali dati sono entrati, e quale periodo coprono? Un forecast costruito su tre mesi di avanzamenti in fase di mobilitazione dice poco sul resto dell’opera.
2. Cosa è escluso dal dataset? Varianti non ancora approvate, riserve iscritte, ordini emessi e non contabilizzati: quello che manca pesa più di quello che c’è.
3. Quale ipotesi sta facendo il modello sul futuro? Produttività costante, prezzi fermi, nessuna interferenza. Scriverla è già metà della verifica.
4. Chi riesce a riprodurre il numero a mano, almeno su una voce? Se nessuno sa rifarlo su una singola lavorazione, nessuno è in condizione di difenderlo davanti a una contestazione.
5. Cosa dovrebbe cambiare perché la conclusione cambi? Se la risposta è “quasi niente”, quel numero non è una base per decidere: è un’indicazione da approfondire.

La quinta domanda è quella che separa un dato da un’opinione ben formattata.

La dimensione sicurezza, su opere pubbliche

Su infrastrutture di interesse pubblico — nodi di trasporto, metropolitane, grandi opere — il dato non è solo un problema di accuratezza. È anche un problema di custodia.

Chi ha accesso ai modelli e ai dataset, con quali livelli di autorizzazione, in base a quali obblighi contrattuali e normativi: sono domande che i committenti pubblici pongono già con precisione, spesso richiamando requisiti di sicurezza che vanno oltre il perimetro tecnico del progetto. La parte tecnica del settore, nella mia esperienza, non sempre ha una risposta altrettanto precisa.

Questo non è un dettaglio da ufficio legale. Se uno strumento AI elabora dati sensibili su un’infrastruttura critica, la domanda su chi può accedere a quei dati e con quali garanzie è parte dello stesso problema di responsabilità di cui parlavo sopra. Il potere analitico senza un criterio di accesso definito è un rischio che si accumula silenziosamente, esattamente come un dato non validato.

E anche qui il precedente esiste, dentro il nostro settore. Il 30 gennaio 2020 Bouygues Construction — uno dei maggiori gruppi di costruzioni europei — è stata colpita dal ransomware Maze e ha dovuto spegnere la propria rete informatica a livello mondiale. Gli attaccanti dichiararono di avere 200 GB di dati e chiesero un riscatto di 10 milioni di euro; parte dei dati del personale venne poi pubblicata online. Se la domanda “dove sono conservati questi dati e chi può raggiungerli” non ha un titolare in un’organizzazione di quelle dimensioni, difficilmente ce l’ha sul modello condiviso su una piattaforma di progetto molto più piccola.

Fonti: iTnews sull’interruzione dei sistemi; nota di Herbert Smith Freehills sulle implicazioni per gli appaltatori.

In sintesi

L’adozione di strumenti AI nel controllo di progetto non è una scelta, è già un fatto operativo su molte commesse infrastrutturali. Il problema non è lo strumento, è l’assenza di un processo che dica chiaramente chi valida il dato in ingresso e chi risponde dell’output. Finché questo vuoto resta, ogni decisione presa su un’analisi AI porta con sé un rischio che nessuno ha formalmente assunto.

Nel tuo progetto, c’è un processo definito per validare gli output AI prima che entrino in una decisione?