Come usare l'AI per la verifica di prontezza di un evento
Mancano 26 ore all'apertura. La dashboard mostra 59 controlli verdi e tre celle vuote.
Qualcuno propone di calcolare il 95% e andare avanti. Solo che una cella riguarda il test radio, una l'accesso dei mezzi di emergenza e una il briefing degli steward.
La verifica di prontezza non fa la media delle spunte. Stabilisce quali condizioni devono essere provate prima del gate. L'AI può raccogliere documenti, confrontare versioni e trovare buchi. La decisione go, hold o no-go resta alla persona indicata. Lo strumento operativo è una readiness board.
La readiness review risponde a una domanda sola
L'agenda dell'evento definisce sessioni e vincoli. Il run of show coordina cue e tempi durante il live. Il risk register di un evento segue rischi, trigger e risposte.
La readiness review chiede: le condizioni necessarie per passare alla fase successiva sono dimostrate adesso?
Un rischio può essere accettato con una risposta pronta. Un criterio di prontezza può essere invece obbligatorio. Se manca la prova, il gate non diventa verde perché gli altri elementi sono a posto.
Definisci il gate prima della riunione
Scrivi nome, orario, autorità e decisioni ammesse. Controllo finale è troppo vago.
gate_id: event-readiness-24h
scheduled_at: 2026-08-21T09:00:00+02:00
decision_owner: event_director
allowed_decisions:
- go
- conditional_go
- hold
- no_go
evidence_cutoff: 2026-08-21T08:30:00+02:00
Definisci anche chi può validare i domini specialistici. Event director non sostituisce venue, responsabile tecnico o professionista della sicurezza. La board porta le loro evidenze alla decisione comune.
GovS 002 prevede assurance review prima di decisioni significative e chiede che le raccomandazioni siano documentate, concordate e seguite. Per un evento, il gate deve produrre una decisione e azioni assegnate. Non un verbale che arriva due giorni dopo.
Costruisci criteri dal contesto reale
HSE indica che scala, tipo, pubblico, luogo, durata, momento del giorno e periodo dell'anno guidano risorse e strutture necessarie. Quindi la checklist di un evento non va incollata su un altro.
Parti da perimetro, venue, pubblico, programma, fornitori e rischi. Poi organizza i criteri per dominio:
| Dominio | Esempio di criterio |
|---|---|
| Venue | accessi e spazi nella configurazione approvata |
| Persone | ruoli critici coperti e briefing completati |
| Tecnica | audio, video, rete e alimentazione provati |
| Fornitori | deliverable accettati con evidenza |
| Programma | sessioni, buffer e speaker confermati |
| Comunicazioni | messaggi e canali autorizzati |
| Accessibilità | percorso e supporti verificati |
| Safety | piano e controlli validati dal ruolo competente |
| Emergenze | ruoli, procedure e sistemi di comunicazione provati |
Questa tabella è un indice. Ogni criterio deve diventare una frase verificabile. Regia pronta non basta. Segnale video su output principale e backup verificato alle 18:10 dal technical lead si può provare.
Le fonti HSE citate sono britanniche. Offrono un riferimento operativo, non sostituiscono norme italiane, requisiti della venue o giudizio di professionisti competenti.
Assegna un evidence owner
Ogni riga ha un responsabile della prova. Non necessariamente la persona che esegue il lavoro.
criterion_id: TECH-07
statement: radio_control_room_and_stage_tested
evidence_owner: technical_lead
evidence_ref: test-radio:2026-08-20T18:10
observed_at: 2026-08-20T18:10:43+02:00
valid_until: event_close
status: green
verified_by: operations_lead
L'evidence owner consegna la prova. Il verificatore controlla che corrisponda al criterio. La decision authority guarda gli stati e decide il gate.
Se la stessa persona copre più ruoli in un evento piccolo, i cappelli restano distinti. Aiuta a capire se sta dichiarando il lavoro, verificandolo o autorizzando la partenza.
Una spunta senza prova resta unknown
Usa quattro stati, non due.
| Stato | Significato | Azione |
|---|---|---|
green | prova valida e criterio soddisfatto | nessuna |
amber | limite noto, trattamento e owner presenti | decisione esplicita |
red | criterio non soddisfatto | correzione o no-go |
unknown | prova assente, scaduta o incoerente | raccogliere o fermare |
Unknown indica informazione mancante, non una variante prudente del verde.
Evita anche la media. Un solo criterio bloccante rosso può fermare il gate. Definisci quali criteri sono must_pass, quali ammettono una condizione e quale autorità può accettare un amber.
La board può ordinare per gravità e scadenza. Non deve nascondere i tre vuoti sotto 59 righe verdi.
Fai lavorare l'AI sulla prova
L'AI è utile in quattro attività. Indicizza le fonti. Confronta la versione attesa con quella consegnata. Estrae date, owner e riferimenti. Segnala contraddizioni e campi mancanti.
Per ogni estrazione conserva il riferimento. Se legge un certificato, non scrive fornitore conforme senza indicare documento, versione, voce e limite. Se due file danno orari diversi, crea CONFLICTING_EVIDENCE.
L'AI non dichiara idoneità tecnica, conformità legale o sicurezza. Prepara la scheda per chi ha titolo e competenza. Sul safety plan, HSE parte dal risk assessment e da ruoli chiari. Il modello non sostituisce né il processo né la persona responsabile.
Prova anche le risposte, non solo i documenti
Un piano può essere completo e non funzionare.
HSE suggerisce table-top exercise per validare il piano di emergenza e chiede di testare sistemi come radio e public address prima dell'evento. Inserisci le prove nella board con data, scenario, partecipanti, esito e correzioni.
Esempio:
test_id: DRILL-03
scenario: loss_of_main_radio_channel
expected_response: switch_to_backup_channel
observed_result: failed_two_devices
corrective_action: replace_and_retest
status: red
La correzione non chiude il criterio. Serve il nuovo test. Quando riesce, aggiungi la seconda evidenza e conserva la prima.
Il briefing degli speaker segue la stessa logica. Inviare il documento non prova che call time, accessi e responsabilità siano stati capiti. Chiedi una conferma adatta al rischio del ruolo.
Prepara il gate meeting per eccezione
Non leggere tutte le righe. Porta al tavolo red, amber, unknown e criteri cambiati dall'ultima review.
La scheda di decisione contiene:
- gate e baseline esaminate
- criteri bloccanti
- prove mancanti o scadute
- condizioni proposte
- owner e scadenza
- autorità presenti
- decisione e motivo
Un conditional_go ha condizioni verificabili e un punto di controllo successivo. Andiamo e vediamo non è una condizione.
Se il gate resta hold, blocca le azioni dipendenti. Per esempio, non inviare una comunicazione finale che presuppone un orario ancora in discussione.
Collega la review alla transizione operativa
GovS 002 lega la transizione a verifica, validazione, continuità, trasferimento di ownership e tracciamento dei difetti. Per l'evento significa passare dal team di preparazione al team che opera il live senza perdere contesto.
La decisione verde consegna almeno baseline, lista ruoli, run of show, canali, escalation, difetti accettati e prossima review. Se un owner cambia al gate, registra l'accettazione.
Difetti minori possono restare aperti con owner e scadenza. Un difetto bloccante non sparisce nel verbale. Mantiene il gate in hold oppure porta a no-go secondo la governance definita.
Un esempio completo
Alle 09:00, 26 ore prima dell'apertura, la board conta 62 criteri. Cinquantanove sono verdi. TECH-07 non ha il test radio, SAFE-03 non ha verifica degli accessi e PEOPLE-12 non prova il briefing steward.
L'AI trova un report tecnico delle 18:10 e collega TECH-07, che diventa green dopo verifica del technical lead. Sugli accessi trova una planimetria vecchia e crea EVIDENCE_VERSION_MISMATCH. Il venue owner consegna la versione corrente alle 10:20. Il responsabile competente la valida.
Il briefing steward è previsto alle 14. Il gate decide conditional_go: preparazione consentita, apertura al pubblico bloccata finché PEOPLE-12 non riceve prova. Alle 14:37 arriva la lista firmata e il controllo a campione è verde.
La decisione finale non nasce dal 95%. Nasce dai tre criteri che mancavano.
Misura la qualità del gate
Conta criteri unknown al cutoff, prove scadute, riaperture, condizioni chiuse in ritardo e difetti scoperti dopo un green. Misura anche il tempo speso a cercare evidenze.
Una metrica utile è false_green_count: criteri dichiarati verdi che non avevano una prova valida. Deve restare a zero.
Il numero totale di criteri non è una misura di maturità. Una board corta e legata al rischio può essere migliore di 200 spunte copiate.
Il KPI di conversione della pagina resta l'invio form aggregato con source_page e source_form. La lettura SEO richiede almeno 28 giorni comparabili dopo un eventuale rilascio.
Gli errori che trasformano la review in teatro
Il primo è fare la media. I bloccanti scompaiono dentro una percentuale rassicurante.
Il secondo è accettare fatto come prova. Serve un riferimento verificabile e attuale.
Il terzo è lasciare all'AI la decisione su sicurezza o conformità. Il modello organizza evidenze. Le persone competenti decidono.
Il quarto è controllare soltanto documenti. Radio, PA, accessi e procedure vanno anche provati quando il criterio lo richiede.
Il quinto è fare la review una volta sola. Le evidenze possono scadere o cambiare dopo una modifica.
Think, Build, Enable applicato alla readiness review
Think: definisci gate, criteri bloccanti, autorità e fonti applicabili. Scrivi cosa l'AI non può validare.
Build: crea board, owner, stati e riferimenti. Inserisci un documento vecchio e una prova mancante per testare il fail-closed.
Enable: fai condurre il gate a chi guiderà l'evento. Il team deve saper spiegare ogni amber senza cercare l'autore del file.
La board serve a rendere visibile il dubbio quando c'è ancora tempo per chiuderlo.
Domande frequenti
Quanti criteri deve avere una readiness review?
Quelli necessari per scala, luogo, pubblico, programma, fornitori e rischi dell'evento. Parti dai bloccanti. Aggiungi solo criteri che cambiano una decisione o una consegna.
Un amber permette sempre di andare avanti?
No. Dipende dalla regola del gate, dal trattamento e dall'autorità. Alcuni domini non ammettono accettazione fuori dal ruolo competente.
Posso caricare tutti i documenti in un LLM?
Solo se dati, accessi, contratti e policy lo consentono. In molti casi basta lavorare su estratti autorizzati, metadati e riferimenti.
Readiness review e prova generale coincidono?
No. La prova generale produce alcune evidenze. La review integra quelle prove con persone, fornitori, venue, comunicazioni e altri criteri del gate.
Da dove parto?
Porta l'ultima checklist, il run of show e tre prove che oggi cerchi a mano. Il servizio automazioni e agent AI di MAIKER HUB costruisce la readiness board senza spostare la decisione fuori dalla tua governance.