Il project management AI ha bisogno di una lezione che arriva, paradossalmente, da un incendio. A giugno un fuoco è divampato in un edificio ancora in costruzione del data center Lake Mariner, a Somerset, New York. I vigili del fuoco locali sono entrati, come ha raccontato il capo dei pompieri Steve Matisz, “praticamente alla cieca”: nessun allarme funzionante, nessun sistema antincendio operativo, tre idranti fuori uso. I documenti di sicurezza che avrebbero dovuto consultare sono bruciati insieme all’edificio. Dietro quel progetto da 3,2 miliardi di dollari c’era una rete di aziende diverse, ciascuna responsabile di un pezzo. Nessuna, evidentemente, dell’insieme.
Perché la responsabilità diffusa è il rischio nascosto nei progetti complessi
Chi fa project management sa che i progetti falliscono raramente per un singolo errore tecnico. Falliscono quando la responsabilità si frammenta tra troppi attori e nessuno ha una visione d’insieme aggiornata. Nei progetti AI questo rischio si moltiplica, perché coinvolgono fornitori di infrastruttura, sviluppatori di modelli, integratori di sistemi e, sempre più spesso, agenti autonomi che eseguono compiti senza supervisione costante.
Pensiamo a un caso più vicino alle PMI italiane: un’azienda manifatturiera che affida a tre fornitori diversi lo sviluppo di un sistema di manutenzione predittiva basato su AI. Il primo fornisce i sensori, il secondo l’infrastruttura cloud, il terzo il modello predittivo. Se il sistema sbaglia una previsione e ferma una linea produttiva, chi risponde? Senza una matrice di responsabilità chiara, la risposta arriva sempre troppo tardi, spesso dopo il danno.
Come strutturare il project management AI per evitare zone grigie
La lezione di Lake Mariner per chi gestisce progetti AI è pratica, non teorica. Prima regola: mappare esplicitamente chi controlla cosa, prima che il progetto parta, non dopo un incidente. Ogni componente del sistema, dai dati di addestramento all’infrastruttura di calcolo, deve avere un responsabile identificabile e raggiungibile.
Seconda regola: i documenti di sicurezza e di governance non possono esistere solo in digitale su un server che potrebbe non essere accessibile proprio quando serve. Serve ridondanza, anche fisica, delle informazioni critiche.
Terza regola, forse la più trascurata: prevedere audit periodici che coinvolgano tutti gli attori della filiera insieme, non ciascuno per conto suo. È quello che raccomanda anche Ars Technica nella sua analisi sul boom dei data center AI: quando più aziende collaborano su un progetto, la responsabilità va progettata quanto l’infrastruttura stessa.
- Definire owner unici per ogni sottosistema critico, anche quando i fornitori sono esterni
- Documentare protocolli di emergenza accessibili offline e condivisi con tutte le parti coinvolte
- Programmare revisioni congiunte trimestrali tra i diversi fornitori di un progetto AI
- Includere clausole contrattuali che chiariscano la responsabilità in caso di incidente
Un’occasione per ripensare la governance dei progetti
Un altro segnale in questa direzione arriva dal glossario AI di TechCrunch, che elenca termini come “opaque recurrence”: sistemi la cui logica interna diventa difficile da ricostruire proprio quando la responsabilità è distribuita tra più organizzazioni. Non è un dettaglio tecnico per addetti ai lavori, è una questione di governance operativa.
Per un project manager italiano, spesso alla guida di team piccoli con budget limitati, la tentazione è delegare tutto ai fornitori tecnologici e concentrarsi solo sulle scadenze. Ma un progetto AI ben gestito richiede la stessa attenzione che si darebbe a un cantiere: sapere sempre chi tiene in mano quale chiave, prima che qualcuno debba cercarla nel fumo.
Project Management AI: la lezione dei data center sui rischi
