Come usare l'AI per creare il run of show di un evento

Un'agenda dice cosa vede il pubblico. Il run of show dice chi fa cosa, a quale minuto, con quale cue, asset, dipendenza e piano B. L'AI può preparare la prima struttura e trovare collisioni. La versione live resta della regia.

Il metodo più sicuro usa 2 livelli: un file strutturato come fonte di verità e viste diverse per programma, regia, palco, speaker, A/V e venue.

Agenda e run of show fanno lavori diversi

Una riga dell'agenda può dire 10:00 apertura. Nel run of show quella riga si apre in più azioni: doors close, standby speaker, microfono live, video off, luci palco, cue musica, ingresso, timer e conferma della regia.

Se usi l'agenda come run sheet, le dipendenze restano nelle chat e nella testa delle persone. Se usi il run sheet come programma pubblico, mostri dettagli che il partecipante non deve leggere.

Mantieni una relazione tra i 2 file. Non duplicare manualmente gli orari in 6 documenti.

Definisci lo schema prima del prompt

Ogni riga deve avere campi stabili. Questo permette al modello di completare bozze e ai controlli di trovare errori.

Campo	Funzione
cue_id	identificatore che non cambia tra versioni
start_planned	ora prevista
duration_min	durata approvata
area	palco, foyer, regia, backstage o altra zona
owner	persona o ruolo responsabile
action	azione osservabile
trigger	evento che fa partire l'azione
asset_id	video, slide, audio, luce o documento
dependency	cue o condizione precedente
comms	canale e destinatario dell'aggiornamento
fallback	piano B già approvato
status	draft, checked, locked, changed, done

Partenza video è vaga. Regia manda V07 dopo conferma stage manager è verificabile. L'azione deve poter essere vista o confermata.

Prepara il source pack

Il modello non riceve note sparse. Riceve un pacchetto con versioni e owner.

Servono, quando pertinenti:

• brief e obiettivi dell'evento,
• programma approvato,
• planimetria e accessi,
• lista speaker e contatti operativi autorizzati,
• script e presentazioni,
• cue sheet A/V,
• schede degli asset,
• tempi di setup e teardown,
• call sheet del personale,
• piano safety e procedure della venue,
• decisioni e domande aperte.

Assegna un ID a ogni asset. finale_v7_nuovo_ok.mp4 non è un ID. V07 sì, se la scheda collega V07 al file corretto, alla durata e all'owner.

Il brief per un video AI aziendale aiuta sul sottoprogetto creativo. Il run of show deve comunque ricevere la versione approvata e la durata esatta dell'asset.

Genera una prima bozza vincolata

PCMA ha raccontato nel febbraio 2026 un hackathon in cui 3 professionisti hanno usato Spark e altri tool AI per produrre, tra gli altri output, un esempio di run of show. Il caso dimostra che l'output si può generare. Mostra anche il pezzo che il modello non porta da solo: esperienza, prompt dettagliato e giudizio sulle transizioni.

Usa un prompt stretto.

Obiettivo: prepara la bozza del run of show nel formato richiesto.

Usa soltanto il source pack fornito.

Regole:
1. Non inventare orari, owner, asset o procedure.
2. Mantieni i cue_id già assegnati.
3. Se manca un dato, scrivi [DA ASSEGNARE].
4. Calcola end_planned da start_planned e duration_min.
5. Segnala sovrapposizioni, dipendenze impossibili e buffer assenti.
6. Non cambiare il programma pubblico.
7. Non inviare messaggi e non prendere decisioni live.

<schema>
{{campi_run_of_show}}
</schema>

<source_pack>
{{fonti_approvate}}
</source_pack>

La bozza deve produrre anche un elenco dei campi mancanti. Se li nasconde in una prosa fluida, il formato è sbagliato.

Fai i controlli con regole, non con eloquenza

I controlli di tempo e integrità sono deterministici. Non serve chiedere al modello se sembra tutto coerente.

Verifica almeno:

1. end_planned = start_planned + duration_min,
2. nessun owner in 2 luoghi nello stesso intervallo,
3. nessun asset usato prima del check,
4. ogni speaker ha call time precedente al cue,
5. ogni cambio palco ha tempo di transizione,
6. ogni dipendenza punta a un cue esistente,
7. ogni cue critico ha un fallback,
8. programma pubblico e run sheet condividono gli stessi blocchi,
9. timezone e formato orario sono unici,
10. la somma dei ritardi non viene nascosta.

Qui tocca fare i conti. Un modello può indicare la riga sospetta, ma la formula deve chiudere il conflitto.

Usa buffer espliciti

Il buffer non è spazio bianco. Ha una funzione e un owner.

Può servire per cambio palco, ingresso pubblico, reset sala, sound check, trasferimento speaker o recupero ritardo. Scrivi il motivo. Un buffer senza motivo viene tagliato alla prima pressione sul programma.

Non aggiungere minuti a caso. Usa tempi di venue, produzione e prove. Se non esiste una misura, registra l'assunzione e verifica durante la prova generale.

Versiona senza perdere i cue

Il cue_id resta stabile. Gli orari possono cambiare.

Una versione contiene:

• numero e timestamp,
• owner che l'ha bloccata,
• righe cambiate,
• motivo,
• persone che devono ricevere l'aggiornamento,
• versione sostituita,
• punto di ripristino.

Evita allegati rinominati in chat. Pubblica una vista read-only con numero visibile e conserva un unico file modificabile. Se la connessione salta, prepara una copia offline datata.

Il cambio dopo il lock richiede un protocollo breve: richiesta, impatto, decisione, aggiornamento, conferma. Il modello può preparare il diff. Non approva la modifica.

Distribuisci viste per ruolo

La regia vede tutto. Uno speaker non ha bisogno del foglio completo con contatti, note tecniche e piani riservati.

Genera viste filtrate:

Vista	Campi principali
Regia	tutti i cue, asset, trigger, dipendenze
Stage manager	palco, speaker, ingressi, fallback
A/V	asset, durata, cue, conferma tecnica
Speaker	call time, slot, durata, contatto operativo
Venue	accessi, sale, catering, sicurezza, logistica
Cliente	milestone, approvazioni, decisioni aperte

Ogni vista deriva dal file strutturato. Non diventa una seconda fonte da modificare a mano.

Gestisci il live con eventi reali

Durante l'evento annota actual_start, actual_end, stato e decisione. Il piano non va sovrascritto, perché il confronto tra previsto e reale serve al report.

Quando un blocco ritarda, il sistema può calcolare l'impatto sui cue dipendenti. La regia sceglie se assorbire, accorciare, spostare o attivare il fallback.

Nessun agent invia messaggi a speaker o partecipanti senza un'autorizzazione specifica. Una notifica sbagliata durante un cambio sala crea un problema più grande del ritardo che voleva risolvere.

Un esempio ipotetico

Cue	Ora	Durata	Owner	Azione	Trigger	Fallback
C010	08:30	30	venue	apertura accrediti	check front desk	lista offline
C020	09:55	5	stage	standby apertura	sala pronta	hold pubblico
C030	10:00	4	regia	sigla V01	conferma stage	immagine fissa
C040	10:04	16	host	apertura	fine V01	ingresso senza video
C050	10:20	5	stage	cambio speaker	fine apertura	Q&A host
C060	10:25	25	speaker	sessione 1	microfono live	intervista host

Le righe mostrano il formato. Orari, ruoli e asset sono inventati.

Il controllo trova che C050 dipende dalla fine reale di C040, non soltanto dalle 10:20. Se l'apertura dura 19 minuti, la regia vede subito l'impatto su C050 e C060.

Misura il processo

Misura ciò che il run of show evita o rende visibile:

• campi mancanti trovati prima della prova generale,
• collisioni di owner,
• asset senza conferma,
• cue cambiati dopo il lock,
• ritardo previsto e reale per blocco,
• fallback attivati,
• messaggi correttivi inviati,
• problemi scoperti dal pubblico,
• tempo umano per aggiornare una versione.

Confronta eventi simili. Una conferenza su 2 sale e una cena su 1 sala non hanno la stessa complessità.

Gli errori che fanno saltare il foglio

• generare il run sheet da un'agenda non approvata,
• usare descrizioni senza owner o trigger,
• rinominare i cue a ogni versione,
• tenere asset e orari in file separati senza ID,
• chiedere al modello di stimare tempi tecnici,
• distribuire copie modificabili,
• aggiornare il live cancellando il piano,
• lasciare che un automation invii cambi non approvati.

Il primo passo

Prendi 20 righe di un run sheet chiuso. Assegna cue ID, owner, trigger, asset e dipendenza. Fai generare soltanto i campi mancanti e chiedi al team di bocciare la bozza.

Il pillar su AI per agenzie eventi e DMC raccoglie gli altri workflow. MAIKER HUB può trasformare il test in un workshop AI aziendale sul processo operativo del team.