Come creare con l'AI un piano di contingenza per un evento

Ore 08:19. Lo speaker della plenaria scrive che il treno è fermo. Il suo intervento parte alle 09:40. Le slide sono sul laptop che viaggia con lui.

Scenario fittizio. Il rischio era noto. Il piano diceva soltanto prevedere alternativa.

Per creare con l'AI un piano di contingenza per un evento devi scegliere pochi scenari ad alto impatto, definire un trigger osservabile, assegnare la decisione, preparare fallback e risorse, scrivere le comunicazioni ammesse e provare la scheda prima dell'evento. L'AI confronta segnali e versioni. Non prende decisioni di safety, spesa o comunicazione pubblica.

Rischio, incidente e contingenza sono oggetti diversi

Il rischio descrive qualcosa che potrebbe accadere. L'incidente registra ciò che è accaduto. La contingenza prepara una risposta attivabile quando compare un segnale definito.

Oggetto	Domanda	Esempio fittizio
rischio	cosa può compromettere l'obiettivo?	speaker non disponibile in tempo
trigger	quale fatto apre la decisione?	assenza di conferma presenza entro 08:30
contingenza	quale alternativa è pronta?	inversione sessioni con materiali già disponibili
incidente	cosa è successo davvero?	treno fermo, arrivo stimato 10:22

Il risk register di un evento conserva probabilità, impatto, trigger e owner. La scheda di contingenza usa alcuni di quei trigger per preparare decisioni e azioni. Non copia tutto il registro.

Scegli pochi scenari

Un piano con 73 scenari non viene letto quando servono 4 minuti. Parti dagli eventi che possono bloccare un obiettivo, consumare il margine di tempo o rendere inutilizzabile un work package critico.

Per un evento puoi valutare, senza automatizzare decisioni:

• indisponibilità di uno speaker,
• file di playback non utilizzabile,
• ritardo di un deliverable essenziale,
• sala non disponibile nel momento previsto,
• collegamento remoto instabile,
• materiale informativo non aggiornato.

Safety, security, emergenze mediche, evacuazione e risposta di crisi seguono piani, ruoli e autorità competenti. Non si riducono a una scheda generata dall'AI.

L'Orange Book tratta il risk management come parte delle decisioni ordinarie e chiede come le contingenze per rischi ad alto impatto vengano progettate e testate. La guida è rivolta al settore pubblico britannico. Qui usiamo il principio, non il suo perimetro istituzionale.

Scrivi un trigger osservabile

Se lo speaker è in ritardo apre discussioni. Quanto in ritardo? Rispetto a quale fonte? Chi conferma?

Un trigger contiene fatto, fonte, momento e tolleranza:

scenario_id: CONT-PLENARY-004
trigger:
  fact: speaker-not-checked-in
  source: registration-desk-status
  check_at: 2026-10-21T08:30:00+02:00
  tolerance: 0m
decision_due: 2026-10-21T08:35:00+02:00
decision_owner: content-director

Date e ruoli sono fittizi. La tolleranza non dice quanto ritardo è accettabile in assoluto. Dice quando questa scheda apre la decisione.

Se la fonte non è disponibile, serve un secondo trigger. Esempio: conferma telefonica registrata dal referente autorizzato. Non lasciare che il workflow deduca la presenza da posizione, social o dati personali non previsti.

Assegna la decisione prima del trigger

Il decision owner deve avere autorità sul pezzo di piano che cambia. Chi controlla il segnale può essere un'altra persona.

Ruolo	Compito
signal owner	aggiorna il fatto e la fonte
decision owner	sceglie tra le opzioni autorizzate
action owner	esegue il cambio approvato
communication owner	prepara o invia il messaggio previsto
technical reviewer	conferma la fattibilità tecnica quando serve

Una persona può coprire più ruoli. La separazione resta scritta perché chiarisce quale decisione sta prendendo.

Nessun chi è online decide. Se l'owner non risponde entro il tempo previsto, la scheda usa sostituto, escalation o fallback sicuro. Non promuove automaticamente il signal owner.

Prepara opzioni già ammesse

Ogni scenario ha poche opzioni. Per lo speaker in ritardo potrebbero essere inversione di 2 sessioni, collegamento remoto già provato oppure contenuto sostitutivo approvato.

Scrivi prerequisiti e limite:

Opzione	Prerequisiti	Costo sul piano	Stop
invertire sessioni	secondo speaker presente, regia aggiornata	cambia 2 cue	uno speaker non conferma
collegamento remoto	linea testata, consenso, slide disponibili	usa 8 minuti di buffer	test audio fallisce
contenuto sostitutivo	master approvato e caricato	riduce Q&A	file non verificato

Numeri e condizioni sono esempi. Il piano reale deve usare buffer, consensi e risorse osservati.

The Teal Book raccomanda piani di backout e contingenza con tempi e decision point nella schedule di transizione quando necessari. Per un evento, il decision point deve stare prima del momento in cui la modifica diventa impraticabile.

Collega risorse e dipendenze

Un fallback senza risorse è un desiderio.

Per ogni opzione registra file, persone, spazi, accessi, attrezzatura, canali e tempo. Usa riferimenti, non copie sparse.

option_id: OPT-REMOTE-02
requires:
  - remote-link-test:green
  - slides-master:approved
  - speaker-consent:recorded
  - playback-channel:available
depends_on:
  - RUN-CUE-118
  - COMMS-ROOM-03
backout: restore-session-order-v9

Il run of show dell'evento resta la fonte per sequenza e cue. La scheda di contingenza collega le righe da cambiare e la baseline da ripristinare.

Qui tocca aprire davvero i file. Slides disponibili non basta se esistono master, master2 e master_finale. La scheda usa ID e versione approvata.

Prepara le comunicazioni

Una modifica può coinvolgere team, speaker, venue e partecipanti. Non tutti ricevono lo stesso messaggio.

La communication matrix definisce destinatario, canale, owner, template, momento e approvazione:

Destinatario	Quando	Contenuto minimo	Owner
regia	dopo la decisione	cue e versione aggiornata	show caller
speaker coinvolti	prima della modifica pubblica	nuovo ordine e check-in	speaker manager
staff sala	prima dell'apertura porte	orario e istruzione operativa	floor manager
partecipanti	solo se cambia ciò che devono fare	informazione approvata	communication owner

Ruoli ed esempi sono fittizi. Per safety, crisi e comunicazioni sensibili valgono i protocolli competenti.

L'articolo sulle comunicazioni ai partecipanti di un evento mostra come lavorare con fonti, owner e canali. La contingenza aggiunge il trigger. Non autorizza l'invio.

Usa l'AI come confronto

Il workflow può leggere trigger, stato del run of show, versioni dei file e disponibilità registrate. Poi prepara una scheda per il decision owner.

Output utile:

scenario_id: CONT-PLENARY-004
trigger_status: met
evidence:
  source: registration-desk-status
  observed_at: 2026-10-21T08:31:14+02:00
eligible_options:
  - OPT-SWAP-01
blocked_options:
  - id: OPT-REMOTE-02
    reason: remote-link-test-missing
decision_required_by: 2026-10-21T08:35:00+02:00

La parola chiave è eligible, non recommended. Il workflow mostra quali prerequisiti risultano verdi. Il decision owner valuta il contesto che il sistema potrebbe non vedere.

Vieta 4 azioni automatiche: cambiare il run of show, contattare persone, impegnare spesa e pubblicare messaggi. Possono esistere in altri processi autorizzati, non in questo default.

Prova la scheda

Un tabletop test mette il team davanti allo scenario senza toccare l'evento reale. Il facilitatore legge gli aggiornamenti. Owner e action owner usano la scheda, aprono le prove e dichiarano cosa farebbero.

Testa almeno:

• trigger vero con opzione disponibile,
• trigger vero con prerequisito mancante,
• segnale ambiguo,
• owner indisponibile,
• 2 scenari che competono per la stessa risorsa,
• ritorno al piano dopo il fallback.

The Teal Book prevede una readiness review prima del go/no-go e richiede record aggiornati per adattare il piano. Il test produce proprio quei record: tempo, decisione, gap, cambio richiesto e nuova versione.

Non usare test superato come unica evidenza. Scrivi chi ha visto cosa, quale decisione ha preso e dove il piano ha perso tempo.

Definisci il ritorno

La contingenza ha un criterio di chiusura. Può essere rientro nel piano originale, passaggio a una nuova baseline oppure chiusura definitiva dello scenario.

Per l'inversione delle sessioni, il ritorno può avvenire dopo la pausa. Per un collegamento remoto, l'ordine potrebbe restare modificato fino a fine giornata. Nessun default.

Registra:

Campo	Esempio fittizio
active_plan	run-of-show-v10-contingency
return_condition	speaker-on-site-and-room-ready
return_decision_owner	content-director
earliest_return	11:15 CEST
communication_required	regia, speaker, floor manager
closure_evidence	cue log e conferma owner

Se il ritorno non è praticabile, la baseline cambia. Conserva il collegamento tra vecchio e nuovo piano.

Un esempio completo

Scenario fittizio. Alle 08:19 lo speaker segnala un blocco ferroviario. Il trigger ufficiale controlla il check-in alle 08:30. Nessun check-in. La scheda si apre.

Il workflow legge 3 opzioni. Il collegamento remoto è bloccato perché il test audio non è stato registrato. Il contenuto sostitutivo è disponibile ma riduce la sessione di 18 minuti. L'inversione con il panel successivo è disponibile: tutti i partecipanti sono presenti e i cue hanno dipendenze note.

Alle 08:34 il content director sceglie l'inversione. Lo show caller aggiorna una copia del run of show e il communication owner prepara 3 messaggi interni già previsti. Nessun messaggio ai partecipanti, perché sala e orario di apertura restano uguali.

Alle 10:08 lo speaker arriva. Il ritorno prima della pausa richiederebbe 4 cambi e consumerebbe il buffer. Il decision owner mantiene la baseline di contingenza fino alle 11:15. Il cue log registra esito e tempi.

Il test del piano, fatto 6 giorni prima, aveva trovato il prerequisito mancante del collegamento remoto. Il team non lo improvvisa alle 08:31.

Misura la prontezza

Conta scenari con trigger verificabile, opzioni con prerequisiti completi, test eseguiti, tempo tra trigger e decisione, escalation, comunicazioni fuori piano e ritorni non definiti.

Misura i falsi trigger. Se la scheda si apre 9 volte senza bisogno, la fonte o la tolleranza sono sbagliate. Se non si apre quando il team interviene, il segnale arriva tardi.

Non misurare il successo con nessun incidente. Un evento tranquillo non prova il piano. Il test e la qualità delle evidenze dicono se la contingenza era utilizzabile.

Errori che fanno crollare il piano

• scrivere prevedere alternativa senza opzioni,
• usare trigger soggettivi,
• assegnare la decisione a un reparto,
• preparare fallback senza file, persone o tempo,
• dimenticare il criterio di ritorno,
• far cambiare all'AI il run of show,
• lasciare messaggi esterni senza approvazione,
• trattare safety o crisi come scenari generici,
• non provare il caso con owner assente,
• sovrascrivere la baseline originale.

Il messaggio delle 08:19

Prendi 1 rischio che oggi contiene la frase serve un piano B. Scrivi il fatto che apre la decisione, la fonte e l'ora limite.

Poi prova il caso in cui l'opzione preferita non è disponibile.

Porta a MAIKER HUB 3 scenari, risk register e run of show. Nel percorso Think -> Build -> Enable costruiamo trigger, opzioni e prove senza affidare all'AI una decisione che non le appartiene.