Come usare l'AI per gestire il change log di un evento

Possiamo spostare il keynote alle 16? Arriva in chat alle 10:07.

Sembra una modifica di orario. Tocca speaker, regia, catering, transfer, sponsor, comunicazioni e forse il contratto della venue. Se qualcuno aggiorna solo l'agenda, il resto del progetto continua sulla versione vecchia.

Per gestire le modifiche di un evento con l'AI serve una change card: una scheda che collega la richiesta alla baseline, mostra gli impatti, porta la decisione all'autorità giusta e chiude soltanto quando tutti gli elementi coinvolti hanno una prova aggiornata. L'AI raccoglie e confronta. Non approva.

Il change log controlla la baseline

Il controllo delle versioni dei documenti evento dice quale file è corrente. Il controllo degli scostamenti di budget confronta costi reali, impegni e forecast. Il risk register di un evento segue eventi incerti e relative risposte.

Il change log decide se una richiesta può modificare ciò che era stato approvato.

GovS 002 definisce il change control come il modo per far entrare nella baseline soltanto cambiamenti necessari o utili. Chiede anche di stabilire cosa va controllato e chi ha l'autorità di autorizzare. Per un evento puoi usare lo stesso principio senza copiare la burocrazia di un grande progetto.

Congela ciò che vale prima della richiesta

Non puoi misurare un delta se la baseline è implicita.

Per ogni elemento controllato conserva ID, versione, stato, owner e riferimento alla prova approvata. Agenda, budget, planimetria, run of show, deliverable sponsor, contratti, liste tecniche e piano comunicazioni possono avere baseline diverse.

baseline_ref: event-plan:v18
approved_at: 2026-08-17T16:30:00+02:00
approved_by_role: event_director
linked_items:
  agenda: agenda:v12
  run_of_show: ros:v9
  budget: budget:v7
  sponsor_plan: sponsor:v5

Il riferimento non prova che il contenuto sia giusto. Prova quale versione era in vigore quando la richiesta è arrivata.

Se due persone indicano baseline diverse, il primo esito è baseline_conflict. Prima si chiarisce quale piano vale. Poi si valuta il cambio.

Raccogli la richiesta senza riscriverla

Una mail o una chat può essere ambigua. L'AI può estrarre una bozza strutturata, ma deve conservare il riferimento al messaggio originario e separare testo ricevuto da interpretazione.

Campi utili:

Campo	Contenuto
change_id	identificatore unico
requested_by_role	ruolo o parte richiedente
source_ref	messaggio, verbale o documento
requested_delta	cosa dovrebbe cambiare
reason_stated	motivo dichiarato, senza inferenze
needed_by	quando serve la decisione
confidence	qualità dell'estrazione

Se il messaggio dice spostiamo più tardi, l'AI non sceglie le 16. Crea TARGET_TIME_MISSING e chiede il dato. Il testo originale resta la fonte.

GovS 002 richiede che le change request siano registrate, identificate e definite. Qui definita significa abbastanza precisa da poter calcolare un impatto. Non significa già accettata.

Confronta richiesta e baseline

L'AI può produrre il delta riga per riga. Orario prima, orario proposto, documenti coinvolti, vincoli e riferimenti.

Evita il riassunto generico. Il keynote viene spostato nasconde ciò che cambia. Una diff operativa può dire:

change_id: CHG-042
element: keynote_session
before:
  start: 14:30
  room: plenaria
after:
  start: 16:00
  room: plenaria
unchanged:
  duration_minutes: 45
  speaker_ref: speaker-07

Conserva anche ciò che non cambia. Riduce il rischio che qualcuno ricostruisca l'intero elemento e introduca un secondo delta non richiesto.

Costruisci la mappa degli impatti

GovS 002 chiede di valutare la modifica su obiettivi, outcome, soluzione e piano. Per un evento traduci il controllo in domini concreti.

Dominio	Domanda
Programma	quali sessioni e buffer si spostano?
Persone	speaker, staff e fornitori sono disponibili?
Luogo	sala, accessi e allestimenti restano compatibili?
Tecnica	regia, prove e connessioni cambiano?
Commerciale	sponsor o cliente hanno impegni collegati?
Budget	nasce un costo o salta una condizione?
Sicurezza	il piano deve essere rivisto da un ruolo competente?
Comunicazioni	chi ha già ricevuto l'orario precedente?

L'AI trova relazioni note e segnala buchi. Non decide che l'impatto sicurezza sia nullo. Se manca la prova del ruolo competente, lo stato è unknown.

Una mappa utile distingue impatto confermato, ipotesi e domanda aperta. Il catering subirà un costo è un fatto solo con una fonte. Altrimenti scrivi costo da confermare con catering.

Porta la decisione all'autorità corretta

Definisci soglie e ruoli prima delle richieste urgenti.

Una modifica editoriale che non tocca costi, orari pubblici o impegni può rientrare nell'autorità del content owner. Un cambio che altera contratto, budget, sicurezza o promessa sponsor passa al ruolo autorizzato per quel dominio.

La change card mostra:

• autorità richiesta
• pareri necessari
• opzioni disponibili
• impatti confermati
• incognite residue
• scadenza della decisione

La persona può accettare, rifiutare, chiedere dati oppure approvare con condizioni. Il silenzio non equivale ad approvazione.

Il documento firmato e la governance del progetto restano la fonte dell'autorità. L'AI applica una matrice già approvata. Non interpreta una clausola per allargare il proprio potere.

Prepara il piano prima di eseguire

GovS 002 prevede un piano di implementazione prima dell'autorizzazione. Sembra un dettaglio, ma evita una decisione presa senza sapere cosa andrà aggiornato.

Il piano elenca ogni elemento, owner, ordine, verifica e fallback. Non modifica ancora nulla.

implementation_plan:
  - item: agenda:v12
    proposed_version: v13
    owner: programme_owner
    verify: keynote_start_is_16_00
  - item: ros:v9
    proposed_version: v10
    owner: show_caller
    verify: cues_and_buffers_recalculated

Se l'approvazione arriva, il workflow esegue soltanto le azioni consentite. Se viene negata, archivia piano e motivo. Nessuna versione intermedia diventa baseline.

Propaga il cambio con tracciabilità

La stessa fonte GovS 002 lega change control e traceability. Ogni elemento dovrebbe avere stato e versione, con relazioni verificabili tra livelli.

Per l'evento significa sapere che agenda:v13 alimenta run-of-show:v10, speaker-brief:v6 e participant-message:v4. Una modifica chiusa deve aggiornare o confermare ciascun nodo coinvolto.

Lo stato della card può avanzare così:

received → impact_ready → awaiting_decision → approved
→ implementing → verifying → closed

Un rifiuto chiude rejected. Un dato mancante resta blocked. Una modifica parziale resta implementing o verification_failed, non closed per comodità.

Chiudi con prove, non con una spunta

Dopo l'aggiornamento, raccogli versioni nuove, hash o riferimenti, esiti dei controlli e comunicazioni completate. GovS 002 indica che la decisione va comunicata e che la request si chiude dopo l'aggiornamento della baseline e delle informazioni interessate.

La prova può essere leggera:

Elemento	Versione	Controllo	Esito
agenda	v13	keynote 16:00	green
run of show	v10	cue e buffer	green
brief speaker	v6	call time aggiornato	green
messaggio partecipanti	v4	invio autorizzato	pending

Con un elemento pending, la card non è chiusa. Può essere approved_partial solo se la governance ammette quel percorso e la parte non eseguita ha un owner.

Un esempio completo

Alle 10:07 il cliente chiede di spostare il keynote dalle 14:30 alle 16. L'AI crea CHG-042, collega il messaggio e confronta agenda:v12.

La mappa trova sette elementi collegati. Regia e speaker sono disponibili. Il catering deve confermare il nuovo intervallo. Uno slot sponsor perderebbe 10 minuti. Il cambio supera quindi l'autorità del programme owner e passa a event director e partnership owner.

La decisione arriva alle 11:02: accettato a condizione di mantenere lo slot sponsor e ricevere conferma catering entro le 12. Il piano aggiorna agenda, run of show e brief. Il catering conferma alle 11:41. Le prove sono verdi alle 12:06.

La card chiude. La chat resta il punto di partenza, non il sistema di controllo.

Misura il lavoro assorbito dai cambi

Conta richieste per origine, tempo fino alla decisione, card riaperte, modifiche senza baseline, impatti trovati dopo l'approvazione e elementi rimasti su versione vecchia.

La metrica più scomoda è orphan_change_count: cambi applicati senza request, decisione o prova. Deve restare a zero.

Non usare il numero di change request per giudicare il progetto. Un evento complesso può averne molte e gestirle bene. Guarda quante arrivano definite, quante restano bloccate e quante producono rework evitabile.

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 rompono il change log

Il primo è aggiornare un file prima della decisione. La bozza inizia a circolare come versione approvata.

Il secondo è usare l'AI per interpretare il contratto. Estrazione e confronto aiutano. L'autorità competente decide il significato.

Il terzo è calcolare solo l'impatto sull'agenda. Gli effetti più costosi spesso sono fuori dal documento che ha ricevuto la modifica.

Il quarto è chiudere quando il piano è stato eseguito, senza verificare le prove.

Il quinto è correggere la request originaria. Aggiungi chiarimenti e decisioni. Non riscrivere ciò che era stato chiesto.

Think, Build, Enable applicato al change log

Think: scegli le baseline controllate, le soglie e le autorità. Disegna cosa resta fuori dall'AI.

Build: crea intake, diff, impact map, piano e ricevute. Prova una richiesta ambigua e una che tocca più domini.

Enable: consegna la vista a producer e owner. Fagli seguire una modifica dalla chat fino alla baseline aggiornata.

Una modifica è chiusa quando tutto il progetto sa qual è la nuova verità.