Come usare l'AI nella comunicazione di crisi di un evento

Alle 16:42 arrivano tre messaggi. La venue segnala un problema tecnico, una chat dice che la sala verrà evacuata, un fornitore scrive che è tutto sotto controllo. Nessuna delle tre frasi ha la stessa autorità.

Un LLM può trasformarle in una comunicazione fluida in pochi secondi. Ed è proprio il rischio: rendere credibile un'informazione che non è stata verificata.

Nella comunicazione di crisi di un evento l'AI lavora dopo la fonte e prima dell'approvazione. Prepara bozze, confronta versioni, adatta un messaggio già autorizzato ai canali e segnala campi mancanti. Non decide lo show stop, non interpreta il piano di emergenza e non invia al pubblico.

Le fonti citate qui sono HSE e Government Communication Service del Regno Unito, più una guida WHO per emergenze sanitarie. Offrono criteri operativi. Non sostituiscono legge italiana, piano della venue, servizi di emergenza o professionisti competenti.

Separa piano di emergenza e processo di comunicazione

Il piano di emergenza stabilisce scenari, ruoli, procedure, autorità, coordinamento e azioni di safety. Il processo di comunicazione traduce una decisione autorizzata in messaggi coerenti per staff, partecipanti e stakeholder.

L'AI nel piano di contingenza di un evento può aiutare a strutturare trigger e dipendenze. Qui il perimetro è più stretto: cosa può essere detto, da chi, su quale fonte e attraverso quale canale.

HSE indica che i messaggi ufficiali al pubblico vanno pianificati insieme ai servizi di emergenza. Per lo show stop chiede persone chiave, metodo di attivazione e wording pre-concordato per gli annunci. Il modello non crea questa autorità. Usa soltanto ciò che il piano approvato gli consegna.

Crea una source card per ogni aggiornamento

Prima della bozza serve una scheda breve e verificabile.

incident_id: EVT-INC-017
observed_at: 2026-09-18T16:42:10+02:00
authoritative_source: venue-control
source_ref: radio-log-884
known:
  - hall-b-power-unavailable
unknown:
  - estimated-restoration-time
approved_action:
  - hold-entry-to-hall-b
public_instruction:
  - follow-staff-to-assigned-waiting-area
message_authority: event-director
channel_owner: communication-lead
next_update_at: 2026-09-18T16:55:00+02:00

Known contiene fatti confermati. Unknown evita che il modello riempia il vuoto. Approved action e public instruction arrivano dai ruoli competenti. Next update dà una promessa concreta senza inventare il tempo di soluzione.

Se due fonti sono in conflitto, la scheda resta bloccata. L'AI può mostrare il confronto, non scegliere quale radio o chat abbia ragione.

Definisci chi può approvare ogni messaggio

La guida STOP include ruoli, alternative in caso di assenza e requisiti di sign-off. Per un evento serve una matrice corta, accessibile anche fuori orario.

I nomi reali, i sostituti e i contatti restano nel piano protetto, non in un prompt aperto. Il sistema usa identificatori di ruolo e recupera solo ciò che serve.

Un'approvazione deve legare testo, versione, fonte e canali. Se cambia una frase dopo il sign-off, nasce una nuova versione. Non considerare approvata una variante perché mantiene lo stesso senso secondo il modello.

Prepara holding line e moduli riutilizzabili

Una holding line permette di comunicare presto senza fingere di avere già tutte le risposte. La guida STOP suggerisce di preparare e, quando possibile, pre-approvare messaggi chiave per le prime ore.

Un modulo può contenere:

Cosa sappiamo: {{known_fact}}
Cosa stiamo facendo: {{approved_action}}
Cosa devi fare ora: {{public_instruction}}
Cosa non sappiamo ancora: {{unknown_fact}}
Prossimo aggiornamento: {{time_or_condition}}
Fonte del messaggio: {{authoritative_role}}

Ogni campo deve arrivare dalla source card. Se public_instruction manca, il modello non la inventa. Produce BLOCKED_MISSING_INSTRUCTION.

WHO raccomanda, nel contesto delle emergenze sanitarie, informazioni accurate fornite presto, spesso e in lingue e canali che le persone comprendono e usano. Il criterio è utile anche qui: il messaggio deve dire cosa si sa, cosa fare e quando arriva il prossimo aggiornamento. La sua applicazione concreta dipende dal piano evento e dalle autorità competenti.

Limita il prompt alla trasformazione

Il prompt deve vietare interpretazioni operative.

Prepara una bozza usando soltanto la source card e il modulo approvato.

Regole:
1. Non aggiungere cause, tempi, rischi o istruzioni.
2. Mantieni separati known e unknown.
3. Non cambiare il significato dell'approved_action.
4. Se manca un campo richiesto, restituisci BLOCKED con il nome del campo.
5. Non inviare, pubblicare o scegliere il canale.
6. Mantieni incident_id e message_version.

La guida STOP cita l'uso di LLM per prime bozze, ricerca, bisogni delle audience e varianti. È un esempio governativo britannico, non un'autorizzazione per il tuo evento. Il valore trasferibile è il confine: draft dentro un piano, con persone formate e processo di approvazione.

Evita prompt generici come scrivi un messaggio rassicurante. Rassicurare senza un fatto può produrre una promessa falsa. Chiedi invece chiarezza, fedeltà alla fonte e istruzione esatta.

Adatta il messaggio senza cambiare l'azione

PA, radio staff, SMS, app, sito e social hanno limiti diversi. La versione per canale può cambiare lunghezza e ordine, non il fatto o l'istruzione.

Il processo per le comunicazioni ai partecipanti copre segmenti, versioni e invii ordinari. Durante una crisi, autorità, velocità e coerenza diventano gate.

Una variante breve non deve cancellare il limite. Sala B chiusa è diversa da Non entrare in Sala B e segui lo staff verso l'area indicata. Usa soltanto l'istruzione già approvata.

Prova canali e fallback prima dell'evento

HSE indica di testare radio e public announcement equipment prima dell'evento. Suggerisce anche table-top exercise per validare il piano.

Per la comunicazione, prova:

• source card incompleta

• approvatore principale assente

• rete dati indisponibile

• PA non udibile in una zona

• radio principale occupata

• due versioni del messaggio in circolazione

• traduzione non pronta

• partecipanti con bisogni di accessibilità diversi

• falso messaggio su un canale non ufficiale

Ogni prova deve avere esito, difetto, owner, correzione e retest. Una radio sostituita non chiude il controllo finché il secondo test non passa.

Collega queste prove alla verifica di prontezza dell'evento. Template pronto è una dichiarazione. Messaggio v4 approvato, letto su PA e confermato in zona C alle 18:12 è una prova.

Progetta accessibilità e lingue prima dell'urgenza

La crisi riduce il tempo disponibile. Se alternative e canali non sono stati preparati, l'accessibilità arriva dopo il primo messaggio.

Definisci in anticipo:

• lingue prioritarie in base al pubblico

• formato breve autorizzato

• messaggio visuale e audio coerenti

• canali per persone che non sentono il PA

• istruzioni compatibili con mobilità e supporti previsti

• owner di traduzione e verifica

• tempo dichiarato per i formati successivi

Il contenuto su accessibilità dei materiali evento con l'AI aiuta a preparare alternative e QA. In emergenza, il modello non certifica che l'istruzione sia sicura o accessibile. Adatta il testo entro opzioni già validate.

Una traduzione rapida può introdurre ambiguità proprio sul verbo d'azione. Mantieni un glossario approvato per luoghi, ruoli e istruzioni ricorrenti. Le frasi critiche richiedono verifica umana competente.

Registra ogni versione e ogni invio

Il registro del messaggio può essere corto:

message_id
incident_id
source_card_hash
draft_version
approved_version
approved_by
approved_at
channels
sent_at
delivery_receipts
supersedes
next_update_at

Conserva anche i messaggi rifiutati e il motivo. Evita che una bozza scartata torni da una chat privata e venga usata come se fosse approvata.

Durante l'incidente, il sistema può mostrare quale versione è corrente e quali canali devono ancora riceverla. Non corregge in silenzio il testo già inviato. Crea un aggiornamento e collega ciò che sostituisce.

La disinformazione si gestisce con la stessa disciplina: fonte ufficiale, messaggio corrente, canale verificato, monitoraggio e correzione autorizzata. Il modello può trovare discrepanze. Non risponde da solo a ogni voce.

Esempio fittizio

Durante un evento, la control room riceve dalla venue la conferma che una sala è senza alimentazione. La causa e il tempo di ripristino non sono noti. L'event director approva il blocco degli ingressi e l'attesa nell'area già prevista dal piano.

La source card contiene il fatto, l'istruzione e il prossimo aggiornamento alle 16:55. L'AI prepara tre versioni: PA, radio staff e app. Il communication lead confronta ogni frase con la card e approva la versione 3.

Il test di consegna mostra che l'app è lenta. La control room usa PA e staff secondo il fallback. Alle 16:52 la venue comunica il ripristino, ma il piano richiede una verifica tecnica prima della riapertura. L'AI non scrive problema risolto. Prepara alimentazione ripristinata, verifica in corso, Sala B resta chiusa fino al prossimo aggiornamento usando la nuova source card approvata.

La sala riapre soltanto dopo la decisione del ruolo competente. Il registro collega fonte, due messaggi, canali e ricevute.

Think, Build, Enable applicato alla comunicazione di crisi

Think: definisci scenari, fonti autorevoli, autorità, wording, audience, canali e limiti dell'AI.

Build: crea source card, moduli, prompt vincolato, versioni, sign-off, fallback e registro invii.

Enable: prova assenze, canali rotti e messaggi incompleti. Fai condurre l'esercizio a chi userà davvero il processo.

Porta piano, ruoli, canali e template alla consulenza roadmap e governance AI di MAIKER HUB. L'AI può togliere minuti alla bozza. La verità del messaggio e l'autorità restano fuori dal modello.