Come usare l'AI per creare il risk register di un evento

L'AI può aiutarti a raccogliere scenari, trovare campi vuoti e confrontare versioni del risk register. Non deve assegnare da sola probabilità, impatto o priorità. Quei valori dipendono dal contesto e da persone che conoscono evento, venue, contratti e responsabilità.

Il registro utile ha 10 campi: scenario, causa, conseguenza, segnale, probabilità, impatto, owner, prevenzione, piano B e prossima verifica.

Separa rischio, problema e cambio

Tre oggetti finiscono spesso nello stesso foglio.

• Un rischio è qualcosa che potrebbe succedere.
• Un problema è già successo oppure è già vero.
• Un cambio modifica scope, tempi, costi o responsabilità.

Il fornitore audio potrebbe consegnare tardi è un rischio. Il fornitore non ha confermato l'orario è un problema aperto. La plenaria inizia 30 minuti prima è un cambio.

L'AI può classificare una riga. L'owner approva la classe. Se il foglio mescola tutto, il piano B si attiva tardi e le modifiche restano senza impatto visibile.

Parti dalle fonti dell'evento

Non chiedere al modello di immaginare cosa può andare storto. Dagli documenti autorizzati e datati.

Il source pack può contenere:

• brief e scope approvato,
• contratto e allegati tecnici,
• planimetrie e schede della venue,
• run of show corrente,
• lista fornitori e dipendenze,
• piano trasporti,
• requisiti accessibilità,
• note di sopralluogo,
• incidenti e lesson learned di eventi comparabili.

Ogni fonte riceve un ID. Nel risk register, causa e controllo devono poter tornare a una fonte oppure essere marcati come ipotesi.

Togli PII, credenziali e dettagli che il tool non è autorizzato a trattare. Un registro può funzionare con ruoli e categorie. Non serve incollare nomi, telefoni e documenti interi dentro un prompt.

Costruisci una prima bozza senza punteggio

La prima passata serve a trovare scenari e campi mancanti. Non a ordinare i rischi.

Obiettivo: prepara una bozza di risk register per revisione umana.

Usa soltanto le fonti F01-F08.

Per ogni scenario restituisci:
- causa
- conseguenza
- segnale osservabile
- controllo già presente
- dato mancante
- fonte

Regole:
1. Non assegnare probabilità, impatto o priorità.
2. Non inventare obblighi, contatti o responsabilità.
3. Se un fatto è già vero, classificalo come PROBLEMA.
4. Se cambia lo scope, classificalo come CAMBIO.
5. Se manca una fonte, scrivi IPOTESI.

Il prompt obbliga il modello a restare nella fase di raccolta. Lo scoring viene dopo.

Usa categorie che seguono il lavoro

Un elenco generico di rischi aiuta poco. Le categorie devono parlare con gli owner.

Categoria	Esempi da verificare	Owner tipico
Venue	accessi, capienze, energia, piano B	venue manager
Produzione	audio, video, rete, cue, carichi	production lead
Persone	speaker, staff, flussi, accessibilità	event manager
Fornitori	consegne, dipendenze, sostituzioni	procurement o PM
Contenuti	claim, diritti, versioni, approvazioni	content owner
Dati	registrazioni, badge, app, trasferimenti	data owner
Trasporti	tempi, finestre, alternative	logistics lead
Reputazione	messaggi, escalation, tempi di risposta	communication lead

Gli owner sono esempi. Il progetto reale assegna nomi e responsabilità secondo la propria struttura.

Valuta probabilità e impatto con una persona competente

Il NIST AI RMF Core chiede di caratterizzare probabilità e magnitudine degli impatti usando il contesto e le evidenze disponibili. Il framework riguarda il rischio AI. Non prescrive la matrice di un evento.

Il principio però è trasferibile: un numero senza base non diventa vero perché è in una cella colorata.

Per ogni rischio registra:

• scala usata,
• motivo del punteggio,
• fonte o esperienza comparabile,
• data della valutazione,
• persona che l'ha approvata.

Una scala da 1 a 3 può bastare. 3 deve avere una definizione concreta. Per esempio, impatto 3 può significare interrompe una parte critica dell'evento e richiede una decisione dell'event director. La definizione va scritta prima di vedere i rischi.

Niente media automatica tra opinioni incompatibili. Se produzione assegna 3 e comunicazione assegna 1, registra il disaccordo e chiudi la decisione con l'owner previsto.

Scrivi trigger che si possono osservare

Se il fornitore è in ritardo non è un trigger. Manca l'ora, manca il segnale e manca chi lo controlla.

Un trigger utile suona così: alle 14:00 il materiale non è registrato al loading bay. Puoi osservarlo. Puoi assegnare un owner. Puoi collegarlo a un piano B.

Rischio	Trigger	Owner del controllo	Azione
consegna tecnica tardiva	nessun check-in alle 14:00	logistics lead	chiama canale approvato e attiva slot alternativo
speaker assente	mancata conferma al check delle 16:30	speaker manager	attiva format sostitutivo approvato
rete instabile	2 test sotto la soglia definita	production lead	passa alla linea di backup

La tabella è ipotetica. Orari, soglie e azioni vanno decisi sul caso reale.

Qui tocca essere precisi: tenere monitorato non è un'azione.

Collega ogni rischio a prevenzione e piano B

La prevenzione riduce la possibilità o l'impatto. Il piano B entra quando il trigger scatta.

Per un problema di connettività, la prevenzione può essere un test tecnico con criteri approvati. Il piano B può essere un collegamento alternativo già provato. Chiedere all'AI cosa fare non è nessuno dei 2.

Il NIST AI RMF Core include processi di contingenza per guasti o incidenti di sistemi e dati di terzi considerati ad alto rischio. Nel contesto evento, usiamo lo stesso rigore documentale anche per dipendenze non AI: trigger, owner e alternativa devono esistere prima del giorno live.

Safety, security, salute, accessibilità, assicurazioni e obblighi locali richiedono professionisti competenti. Il registro editoriale non li sostituisce.

Mantieni il registro vivo senza riscriverlo da zero

Ogni riga ha una data di review. L'AI può confrontare 2 versioni e segnalare:

• nuovi rischi,
• campi cambiati,
• fonti scadute,
• owner mancanti,
• trigger senza piano B,
• controlli superati dalla nuova versione del progetto.

Non farle consolidare il foglio senza diff. Se una riga sparisce, devi sapere chi l'ha rimossa e perché.

Usa stati semplici: aperto, ridotto, accettato, attivato, chiuso. Chiuso richiede evidenza. Accettato richiede l'owner che può accettare quel rischio.

Un esempio ipotetico

Un evento corporate ha 1 plenaria, 2 sale parallele e 4 fornitori. Il source pack contiene 9 documenti ripuliti. La prima bozza AI produce 22 righe.

Il team ne elimina 5 perché duplicano lo stesso scenario. Sposta 3 righe nei problemi aperti. Per 4 rischi manca un owner. Nessun punteggio viene accettato dal modello.

Dopo la review restano 14 rischi. Solo 6 hanno un trigger osservabile. Il lavoro utile del giorno non è aggiungerne altri. È chiudere gli 8 trigger mancanti.

I numeri spiegano il flusso. Non sono un benchmark MAIKER HUB.

Misura il registro

Conta la qualità delle decisioni:

• rischi con fonte,
• rischi con owner,
• rischi con trigger osservabile,
• piani B testati,
• fonti scadute,
• problemi emersi senza essere nel registro,
• rischi attivati con escalation nei tempi,
• righe chiuse senza evidenza.

Nel PULSE Cvent pubblicato il 04/02/2026, il 65% del campione dichiara di usare GenAI, mentre il 16% segnala miglioramenti significativi nella pianificazione e nell'esecuzione. Il campione aggrega più di 1.000 professionisti nelle edizioni citate. Questi numeri non misurano il tuo evento. Dicono soltanto che adozione e risultato non sono la stessa cosa.

Gli errori che rompono il registro

• chiedere al modello una lista senza fonti,
• lasciare che assegni punteggi e priorità,
• mescolare rischi, problemi e cambi,
• scrivere owner generici come team,
• usare trigger non osservabili,
• avere un piano B mai provato,
• cancellare righe senza diff,
• trattare la matrice come un documento di safety approvato,
• caricare contratti o dati personali in tool non autorizzati.

Un registro da 80 righe senza trigger è un inventario. Non è un piano.

Il primo registro da testare

Prendi un evento chiuso. Ricostruisci 10 rischi partendo dai documenti. Poi confrontali con i problemi che sono successi davvero. Le differenze mostrano quali fonti o categorie mancavano.

Il pillar AI per agenzie eventi e DMC raccoglie i workflow del ciclo. Il workshop AI aziendale permette di testare il registro su un processo reale. Gli eventi MAIKER HUB mostrano il contesto pubblico del brand.

Se il nodo è assegnare ruoli e gate, la consulenza su roadmap e governance AI è il passaggio coerente.