Il RAID log è uno di quei documenti che tutti sanno di dover tenere e che quasi nessuno aggiorna con costanza. Risks, Assumptions, Issues, Dependencies: quattro registri che dovrebbero raccontare in tempo reale dove il progetto rischia di inciampare. Nella pratica diventano un foglio che apri a inizio progetto, popoli a fatica per mezza giornata e poi lasci morire fino al primo audit. Il risk register, in particolare, è il pezzo che paghi più caro quando lo trascuri: i rischi non scompaiono perché non li hai scritti.
Qui l’AI generativa cambia davvero le carte, ma non nel modo in cui te la vendono. Non ti serve un agente magico che “gestisce il rischio”. Ti serve un assistente paziente che trasforma il materiale grezzo del progetto in righe di registro ben formate, che ti propone mitigazioni a cui non avevi pensato e che ti aiuta a mantenere lo stato aggiornato senza riscrivere tutto a mano. Il giudizio resta tuo. Questo articolo è una piccola libreria di prompt pronti per fare esattamente questo sul tuo RAID log.
Cosa dare in pasto all’AI prima di chiedere rischi
La qualità dei rischi che ottieni dipende quasi interamente da cosa metti nel prompt. Un modello a cui chiedi “elenca i rischi di un progetto di migrazione cloud” ti risponderà con generalità da manuale: scope creep, budget, resistenza al cambiamento. Roba vera ma inutile, perché non parla del tuo progetto.
Prima di aprire la chat, raccogli il materiale che descrive il progetto come è davvero. Bastano estratti, non documenti interi:
- Il project brief o lo statement of work, con obiettivi e criteri di successo.
- Il milestone plan o la timeline, con le date che non puoi sforare.
- Gli appunti delle ultime riunioni, dove emergono i dubbi reali del team.
- I vincoli contrattuali: penali, SLA, scadenze legate a fatturazione.
- Le assunzioni già scritte, anche quelle che dai per scontate (“il cliente fornirà i dati entro la settimana 2”).
- Le decisioni ancora aperte e le preoccupazioni degli stakeholder, anche quelle sussurrate a fine call.
Più contesto specifico dai, più i rischi proposti somigliano al tuo progetto e meno alla checklist di un libro. È qui che l’AI smette di essere un generatore di banalità e inizia a essere utile.
La regola che non puoi dimenticare: l’AI non conosce la politica
Vale la pena fissarlo prima di passare ai prompt, perché è la cosa che fa la differenza tra un risk register affidabile e uno pericoloso. Il modello non sa che lo sponsor è in uscita dall’azienda, che il fornitore ha già saltato due deadline su un altro progetto, che il team backend è esausto dopo l’ultimo rilascio. Non conosce il contesto organizzativo, le tensioni tra reparti, le promesse fatte a voce.
Questo significa due cose. Primo: l’AI sarà fortissima sui rischi tecnici e di processo, più debole su quelli politici e relazionali, che spesso sono i più letali. Secondo: ogni rischio che propone è una bozza, non una verità. Il PM legge, taglia quello che non c’entra, riformula, aggiunge l’impatto reale e soprattutto inserisce i rischi politici che il modello non poteva vedere. L’AI accelera la stesura, non sostituisce il tuo fiuto.
La prompt library per il RAID log
Questi prompt sono pensati per essere copiati, riempiti con il tuo contesto e incollati in una chat. Funzionano meglio se incolli il materiale del progetto prima della richiesta, nello stesso messaggio. Adattali al tuo settore: più li personalizzi, meglio rispondono.
1. Identificare i rischi dal materiale di progetto
Agisci come un project manager senior esperto di risk management. Ti incollo qui sotto il brief, la timeline e gli appunti delle ultime riunioni di un progetto [tipo di progetto, es. migrazione di un e-commerce su nuova piattaforma].
Identifica da 8 a 12 rischi concreti e specifici per QUESTO progetto, non rischi generici. Per ognuno indica: titolo breve, descrizione in una frase, e la categoria (tecnico, risorse, fornitore, scope, tempi, budget, qualità). Concentrati sui rischi che emergono dai dubbi e dalle assunzioni nel materiale, non da una checklist standard. Segnala anche le aree dove ti mancano informazioni per valutare un rischio.
[INCOLLA QUI BRIEF + TIMELINE + APPUNTI]
2. Trasformare assunzioni e dipendenze in rischi
Qui sotto trovi la lista delle assunzioni e delle dipendenze del progetto. Per ciascuna, dimmi cosa succede se l’assunzione si rivela falsa o se la dipendenza salta o ritarda. Trasforma ogni caso problematico in un rischio del risk register con titolo, evento scatenante e conseguenza sul progetto. Ignora le assunzioni a basso impatto e dimmi quali sono.
[INCOLLA QUI ASSUNZIONI + DIPENDENZE]
3. Valutare impatto e probabilità
Ti do una lista di rischi del mio risk register. Per ognuno proponi una valutazione di probabilità (Bassa / Media / Alta) e di impatto (Basso / Medio / Alto), con una riga di motivazione per ciascuna. Calcola un punteggio di priorità combinando i due. IMPORTANTE: dichiara esplicitamente le assunzioni che fai su contesto, budget e team, perché non li conosci. Se per valutare correttamente un rischio ti serve un’informazione che non ho dato, chiedimela invece di inventare.
[INCOLLA QUI LISTA RISCHI]
4. Proporre mitigazioni e piani di risposta
Per ciascuno dei rischi qui sotto, proponi: una strategia di risposta (evitare, ridurre, trasferire, accettare), 2 azioni di mitigazione concrete e attuabili, un possibile owner per ruolo (non per nome), e un indicatore di allerta precoce che mi dica che il rischio si sta materializzando. Le mitigazioni devono essere realistiche per un team piccolo con budget limitato. Niente soluzioni generiche tipo “comunicare di più”.
[INCOLLA QUI RISCHI VALUTATI]
5. Aggiornare lo stato dopo una riunione
Qui sotto c’è il mio risk register attuale e gli appunti dell’ultima riunione di stato. Confrontali e dimmi: quali rischi sono cambiati di probabilità o impatto e perché, quali si sono trasformati in issue effettive, quali nuovi rischi emergono dagli appunti, e quali si possono chiudere. Restituisci solo le righe da modificare con il nuovo stato proposto, non riscrivere l’intero registro.
[INCOLLA QUI RISK REGISTER + APPUNTI RIUNIONE]
6. Distinguere rischi, issue e dipendenze
Ti incollo un elenco disordinato di preoccupazioni emerse dal team. Classifica ogni voce come Rischio (potrebbe accadere), Issue (sta già accadendo), Assunzione (diamo per vero ma non è confermato) o Dipendenza (dipendiamo da qualcuno di esterno). Per le voci ambigue spiega perché hai scelto quella categoria. Segnala i duplicati.
[INCOLLA QUI ELENCO PREOCCUPAZIONI]
Mappa rapida: cosa chiedere e cosa verificare per ogni componente RAID
Ogni lettera del RAID si presta a un uso diverso dell’AI, e ognuna ha un punto cieco da controllare a mano. Tieni questa tabella accanto mentre lavori sul registro.
| Componente | Cosa chiedere all’AI | Cosa verificare tu |
|---|---|---|
| Risks (rischi) | Generare rischi specifici dal brief, valutare probabilità/impatto, proporre mitigazioni e indicatori di allerta. | Che i rischi politici e relazionali ci siano (l’AI li perde). Che impatto e probabilità riflettano il tuo contesto reale, non assunzioni del modello. |
| Assumptions (assunzioni) | Trasformare ogni assunzione in un “cosa succede se è falsa”, far emergere assunzioni implicite nel brief. | Che non vengano spacciate per certezze. Le assunzioni più rischiose sono quelle che nessuno ha mai scritto. |
| Issues (problemi attivi) | Distinguere issue reali dai rischi, riassumere lo storico di un problema, proporre azioni di rientro. | La priorità reale e chi è impattato davvero. L’AI non sa quale issue ti sta facendo perdere lo sponsor. |
| Dependencies (dipendenze) | Mappare dipendenze esterne dalla timeline, evidenziare quelle sul percorso critico, generare il rischio collegato a ogni ritardo. | L’affidabilità reale del fornitore o del reparto da cui dipendi. Quella la conosci solo tu. |
Un flusso di lavoro che regge nel tempo
Il valore vero non sta nel popolamento iniziale, che fai una volta sola, ma nel mantenimento. Un RAID log utile è quello che resta vivo. Ecco un giro che richiede pochi minuti a settimana.
A inizio progetto usa i prompt 1, 2 e 6 per riempire i quattro registri partendo dal materiale che hai. Poi passa al prompt 3 per dare a ogni rischio una priorità e al prompt 4 per associargli una risposta. Dedica più tempo a tagliare e correggere che a generare: il primo giro dell’AI è sempre troppo lungo e troppo generico, il tuo lavoro è renderlo tuo.
Da lì in poi, dopo ogni riunione di stato incolli gli appunti nel prompt 5 e lasci che l’assistente ti segnali cosa è cambiato. In pochi minuti hai un registro aggiornato invece di uno fossile. Questo è il punto in cui la maggior parte dei team molla, ed è esattamente dove l’AI toglie l’attrito che faceva mollare.
Una nota sui dati: se il progetto contiene informazioni sensibili o coperte da contratto, verifica le policy aziendali sull’uso di strumenti AI prima di incollare brief e appunti. Spesso basta anonimizzare nomi e numeri per lavorare in sicurezza senza perdere la sostanza del contesto.
Il giudizio resta il tuo mestiere
Un risk register popolato dall’AI in dieci minuti non è un risk register finito. È una bozza ricca, ben strutturata, con idee a cui non avevi pensato e mitigazioni pronte da valutare. Il salto di qualità lo fai tu quando aggiungi il rischio che il modello non poteva vedere, quando declassi un rischio tecnico perché sai che quel team lo gestisce a occhi chiusi, quando alzi la priorità di un’issue perché conosci la persona che la sta vivendo. L’AI scrive le righe, tu decidi quali contano. È così che il RAID log torna a essere uno strumento di governo del progetto e non un documento da spolverare prima dell’audit.
Vuoi padroneggiare il digital project management?
Saper usare l’AI sul RAID log è un pezzo di un mestiere più ampio. Se vuoi costruire basi solide nella gestione di progetti in contesti digitali, il Corso DPM Foundation di Management Academy offre 27 ore di contenuti video on demand e una certificazione Digital Project Management di livello Foundation, pensata per chi guida progetti digitali. Il corso ti prepara alla certificazione: l’esame è a parte e non è incluso nel percorso.
