C’è un momento preciso in cui un project manager smette di trattare gli assistenti AI come gadget e inizia a metterli in catena. Un agent legge i ticket e stima lo sforzo. Un secondo agent prende quelle stime e costruisce la timeline. Un terzo prepara lo stato avanzamento per lo sponsor. Sulla carta è una piccola squadra digitale che lavora mentre tu fai altro. Nella pratica, è anche il modo più rapido per spedire un errore fino in cima alla gerarchia senza che nessun essere umano lo abbia mai letto.
Il problema non sono le allucinazioni in sé. Quelle le conosciamo già: un modello linguistico produce con sicurezza un’informazione falsa. Il problema, nei workflow agentici, è che l’output di un agent diventa l’input del successivo. E quando un dato sbagliato entra in uno step, lo step dopo non lo mette in discussione: lo usa come fatto. L’allucinazione non resta isolata, si compone. Si moltiplica lungo la catena come un errore di battitura che nessuno corregge prima di andare in stampa.
Cosa significa “allucinazione che si compone”
Immagina una catena di tre agent su un progetto di migrazione software. Il primo agent stima il modulo di autenticazione in 40 ore. È una stima inventata: il modello non aveva dati storici, ma ha prodotto un numero plausibile perché glielo abbiamo chiesto. Il secondo agent costruisce il Gantt assumendo che quelle 40 ore siano affidabili, le incastra tra altre attività e calcola una data di consegna. Il terzo agent redige la mail allo sponsor: “il modulo di autenticazione sarà pronto il 12 settembre”.
Nessuno dei tre agent ha mentito di proposito. Ognuno ha fatto il suo lavoro sull’input ricevuto. Ma il dato falso del primo step è arrivato allo sponsor travestito da impegno preciso, con tanto di data sul calendario. La fiducia che lo sponsor ripone in quella mail è inversamente proporzionale a quanto sa di come è stata generata. Questo è il cuore del rischio: la catena nasconde l’origine dell’errore e gli dà credibilità a ogni passaggio.
La cosa scomoda è che catene più lunghe sembrano più sofisticate, e più sofisticate sembrano più affidabili. È esattamente il contrario. Ogni step aggiuntivo è un punto in cui un’allucinazione può nascere e un punto in cui un’allucinazione esistente può essere amplificata. Più anelli ha la catena, più superfici di errore stai sommando.
Perché succede proprio nel project management
Il PM lavora con materiale particolarmente esposto a questo meccanismo. Le stime sono opinioni mascherate da numeri. Le dipendenze tra attività sono concatenazioni logiche, lo stesso tipo di concatenazione su cui un modello costruisce le sue allucinazioni. I report sono sintesi di sintesi. Tutto ciò che facciamo passa attraverso traduzioni successive di un’informazione, ed è proprio lì che l’AI si infila bene e sbaglia peggio.
Aggiungi che i nostri dati di partenza sono spesso incompleti. Un ticket scritto male, una nota di riunione ambigua, un requisito che esiste solo nella testa dello sponsor. Quando dai a un agent un input lacunoso, non ti chiede chiarimenti: riempie il vuoto. E quel riempimento, plausibile e sicuro, è il primo anello difettoso della catena.
Una mappa degli errori e delle contromisure
Vale la pena distinguere i tipi di allucinazione che incontri in un workflow di PM, perché ognuno ha un impatto diverso e una difesa diversa. Una contromisura generica non funziona: devi sapere contro cosa ti stai difendendo.
| Tipo di allucinazione | Impatto sul progetto | Contromisura |
|---|---|---|
| Stima inventata (numero di ore o costo senza base reale) | Timeline e budget costruiti sul vuoto, scivolamenti a cascata | Grounding sui dati storici: l’agent cita la fonte della stima o dichiara “nessun dato disponibile” |
| Dipendenza fittizia (attività collegate che in realtà non lo sono) | Sequenze di lavoro sbagliate, risorse bloccate per nulla | Validazione del PM sul grafo delle dipendenze prima della pianificazione |
| Fatto fabbricato (uno stato, un nome, una decisione mai presa) | Comunicazioni false allo sponsor o al team, perdita di fiducia | Tracciabilità: ogni affermazione deve poter essere ricondotta a un documento sorgente |
| Sintesi distorta (report che enfatizza o omette) | Decisioni di steering prese su un quadro alterato | Checkpoint umano sul report prima dell’invio, confronto con i dati grezzi |
| Sicurezza ingiustificata (l’agent presenta un’ipotesi come certezza) | L’errore non viene segnalato come dubbio e passa indisturbato | Richiedere all’agent un livello di confidenza esplicito per ogni output |
Dove inserire i checkpoint umani
Il riflesso sbagliato è mettere un controllo umano alla fine, sul report finale. Troppo tardi: a quel punto l’errore ha già attraversato tutta la catena e si è mescolato con dati buoni, rendendolo difficile da isolare. I checkpoint vanno messi dove l’informazione è ancora separabile, vicino alla sorgente.
Ecco una mappa pratica di dove fermarsi e cosa guardare:
- Dopo l’ingestione dei dati grezzi. Prima che qualunque agent elabori, verifica che l’input sia completo. Un ticket vago va chiarito da un umano, non riempito da un modello.
- Dopo la stima, prima della pianificazione. È il checkpoint più importante. Qui le stime sono ancora numeri isolati e leggibili. Una volta dentro il Gantt si confondono e perdono visibilità.
- Tra pianificazione e comunicazione. Prima che un dato diventi una promessa allo sponsor, qualcuno con il contesto deve dargli l’ok. È l’ultima barriera prima dell’esterno.
- Su ogni output destinato a chi sta fuori dal team. Cliente, sponsor, direzione: tutto ciò che esce dal perimetro del team passa da un occhio umano, sempre.
Non serve presidiare ogni singolo passaggio. Serve presidiare i passaggi giusti: quelli dove l’informazione cambia di stato (da grezza a stimata, da stimata a pianificata, da interna a esterna). Sono le giunture della catena, ed è lì che gli errori entrano e si nascondono.
Cinque modi concreti per spezzare la catena
Validazione tra uno step e l’altro
Non lasciare che un agent passi il testimone al successivo senza un controllo intermedio. La validazione può essere umana sui passaggi critici, o automatica su quelli a basso rischio: un secondo agent indipendente che verifica la coerenza dell’output del primo, regole esplicite che bloccano valori impossibili. L’idea è semplice: prima di propagare, verifica.
Grounding sui dati sorgente
Un agent non dovrebbe mai produrre un fatto che non riesce a ricondurre a una fonte. Se stima 40 ore, deve poter dire da dove arriva quel numero: progetti analoghi, dati storici, un benchmark. Se non ha fonti, deve dichiararlo invece di inventare. Il grounding trasforma “il modello ha detto X” in “il modello ha derivato X da questo documento”, e la differenza è tutta lì.
Limitare la lunghezza delle catene
Ogni anello in più è rischio in più. Quando puoi, spezza un workflow lungo in segmenti corti con un controllo umano in mezzo, invece di costruire una catena di sei agent che gira da sola. Tre step supervisionati battono sei step autonomi quasi sempre. La lunghezza non è un segno di maturità del sistema, è una misura della tua esposizione.
Log e tracciabilità
Devi poter ricostruire come è nato ogni output. Quale agent lo ha prodotto, su quale input, con quali assunzioni. Senza log, quando lo sponsor ti chiede da dove esce quella data del 12 settembre, non hai una risposta. Con i log, risali la catena fino all’anello difettoso e capisci dove si è generato l’errore. La tracciabilità è ciò che rende un workflow agentico verificabile invece che misterioso.
Confidenza esplicita
Chiedi a ogni agent di dichiarare quanto è sicuro di ciò che produce. Un output marcato come “ipotesi a bassa confidenza” viaggia lungo la catena con un’etichetta di avvertimento, e lo step successivo può trattarlo con la cautela giusta. È un modo economico per impedire che un’incertezza si trasformi in una certezza solo perché ha cambiato di mano.
Checklist anti-propagazione
Prima di mettere in produzione un workflow con più agent in sequenza, passa questa lista. Se una riga resta senza spunta, hai un anello debole.
- Ogni agent dichiara la fonte dei dati che produce, oppure ammette di non averne.
- C’è un checkpoint umano tra stima e pianificazione.
- Nessun output raggiunge lo sponsor senza una verifica umana.
- La catena è la più corta possibile per ottenere il risultato.
- Ogni step registra un log con input, output e assunzioni.
- Gli output portano un livello di confidenza esplicito.
- Esiste un agent o una regola che valida la coerenza tra uno step e il successivo.
- Sai ricostruire, per qualunque dato finale, da dove è partito.
I workflow agentici non si supervisionano da soli
Vale la pena essere chiari su un punto, senza entusiasmi facili. I workflow agentici sono potenti: comprimono ore di lavoro ripetitivo, gestiscono volumi che un PM da solo non reggerebbe, lavorano mentre dormi. Ma sono fragili nello stesso identico modo in cui sono potenti. La velocità con cui propagano lavoro buono è la stessa con cui propagano errori. Non puoi avere l’una senza l’altra.
Questo non è un argomento per non usarli. È un argomento per usarli da adulti. La supervisione umana non è un residuo da eliminare appena il sistema “funziona abbastanza bene”. È la componente che rende l’automazione affidabile. Il PM che mette agent in catena senza checkpoint non sta risparmiando tempo: lo sta prendendo in prestito, e lo restituirà con gli interessi il giorno in cui un dato falso arriverà allo sponsor con la sua firma sopra.
Il mestiere del project manager, in questo scenario, non scompare. Cambia. Smetti di produrre tu ogni stima e ogni report, e inizi a progettare la catena, scegliere dove fidarti e dove controllare, leggere i log quando qualcosa non torna. È un mestiere più di architettura e meno di esecuzione. Ma richiede di capire come questi sistemi sbagliano, non solo come funzionano quando vanno bene.
Costruire le competenze per governare l’AI nei progetti
Gestire workflow agentici nel project management significa padroneggiare due mondi insieme: la disciplina della gestione progetti e il pensiero critico su come l’AI produce e propaga informazioni. Le fondamenta restano quelle di sempre: stimare bene, pianificare in waterfall e in agile, comunicare allo sponsor con dati verificabili, governare un prodotto digitale e misurare con gli OKR. Su quelle fondamenta si innesta la capacità di mettere l’automazione al servizio del controllo, non al suo posto.
Il Corso DPM Executive di Management Academy è il percorso più completo per la gestione di progetti digitali: 118 ore di contenuti on demand che coprono la gestione progetti sia in modalità waterfall sia agile, la creazione e la gestione di un prodotto digitale e l’uso degli OKR. È un percorso executive e richiede il diploma come titolo di accesso.
Sul piano delle certificazioni, il corso prepara a quattro traguardi riconosciuti: CAPM di PMI, Scrum di Scrum Alliance, Product Management di ACS e include moduli dedicati agli OKR. Una precisazione onesta: il corso prepara agli esami ma non rilascia le certificazioni. Gli esami si sostengono presso gli enti esterni, sono in italiano e non sono inclusi nel costo del corso.
