Come controllare con l'AI i deliverable dei fornitori evento

Giovedì, 15:26. Il file si chiama planimetria_finale.pdf. La legenda riporta 18 tavoli. La distinta del catering ne riporta 20. Entrambi i documenti risultano approvati.

Scenario fittizio. Il file è arrivato. L'accettazione, no.

Per controllare con l'AI i deliverable dei fornitori di un evento devi collegare ogni consegna a requisiti e criteri già concordati, scegliere una tecnica di prova, mostrare le evidenze e lasciare a una persona autorizzata l'esito. L'AI può estrarre, confrontare e segnalare. Non può accettare un obbligo, autorizzare un pagamento o correggere di nascosto il documento ricevuto.

Consegna e accettazione sono 2 stati

Delivered dice che un oggetto è arrivato. Accepted dice che ha superato i criteri previsti.

Tra i 2 stati può esserci una verifica documentale, un test, una dimostrazione, un campione oppure una validazione con chi userà davvero l'output. Saltare quel passaggio trasforma il nome del file in una prova.

The Teal Book distingue 2 domande. La verifica controlla se una soluzione o una sua parte rispetta la specifica. La validazione controlla se risponde al bisogno di utenti e stakeholder nel contesto previsto. Il capitolo riguarda la project delivery governativa, non prescrive il tuo processo evento. La distinzione resta utile.

Una planimetria può rispettare misure e simboli richiesti, quindi passare la verifica documentale. Può ancora fallire la validazione se il team operativo non riesce a usarla nel montaggio previsto.

Dai un ID a ogni deliverable

Il registro non parte dal nome del file. Parte da un identificatore stabile.

deliverable_id: VEN-PLAN-022
supplier_ref: SUP-07
work_package: venue-layout
required_version: 4
received_version: 4
received_at: 2026-09-18T15:26:00+02:00
requirements:
  - REQ-VEN-041
  - REQ-OPS-013
acceptance_owner: event_operations
status: received

I dati sono fittizi. supplier_ref evita di copiare il nome del fornitore in un dataset di lavoro che non ne ha bisogno. Il contratto e la documentazione ufficiale restano nelle sedi autorizzate.

Se lavori sul venue sourcing per eventi e DMC, conserva la continuità tra requisito usato nella selezione e requisito verificato dopo la consegna. Non riscriverlo a memoria quando arriva il file.

Trasforma il requisito in una prova

Planimetria completa non è verificabile. Contiene ID sala, scala, accessi tecnici, legenda e versione approvata lo è di più, ma ogni voce deve ancora avere una fonte e un owner.

Per ogni requisito scrivi:

La conseguenza non va inventata dal workflow. Può essere rework, chiarimento, escalation o blocco dell'handover. Pagamenti, penali e obblighi seguono i documenti e le persone competenti.

Scegli la tecnica giusta

The Teal Book elenca più tecniche di verifica e validazione. Non tutto richiede un test automatico.

La scelta dipende da rischio, costo, tempo e tipo di deliverable. L'AI può proporre la tecnica in base al registro. Il reviewer la conferma.

Qui tocca evitare il riflesso carichiamo tutto e chiediamo se va bene. Una chat senza criteri produce un parere, non un record di accettazione.

Fai lavorare l'AI sui riferimenti

Il workflow riceve il deliverable, la specifica approvata e la tabella dei requisiti. Estrae elementi con posizione o pagina, normalizza le unità ammesse e costruisce un confronto.

Un output utile può avere questa forma:

requirement_id: REQ-VEN-041
expected: 20-table-layout
observed: 18-table-layout
evidence:
  file_ref: VEN-PLAN-022@4
  page: 3
  region: legend
status: mismatch
confidence: source-explicit
next_action: reviewer_decision

Confidence non è la probabilità che il documento sia giusto. Dice quanto è esplicita l'evidenza trovata. Se la fonte è ambigua, lo stato corretto è needs_review.

Non lasciare che il workflow sistemi il numero direttamente nella planimetria. Segnala la differenza, mostra le 2 fonti e conserva la versione ricevuta.

Un workflow AI per agenzie eventi e DMC può raccogliere molti documenti. Questo controllo ha un confine più stretto: arriva dopo la consegna e prima dell'esito.

Separa difetto, causa ed esito

Un mismatch è un'evidenza. Non è ancora la causa.

I 18 tavoli possono dipendere da una planimetria vecchia, una modifica approvata non propagata, un errore di estrazione oppure una scelta del fornitore non registrata. Il reviewer controlla prima di assegnare il difetto.

Usa stati piccoli e chiari:

Quasi approvato non serve. Se mancano prove, resta needs_review. Se manca una correzione, resta rework.

Costruisci un pacchetto per la decisione

Il decision owner non dovrebbe cercare 11 allegati e ricostruire il requisito dalla mail iniziale.

Mostra in un'unica vista:

• deliverable ID e versione,

• requirement ID e testo approvato,

• evidenza con pagina o posizione,

• tecnica usata,

• esito del controllo,

• differenze aperte,

• impatto sul piano,

• decisione richiesta e scadenza.

Le fonti rimangono apribili. Un riassunto AI senza link non è sufficiente per un esito che può toccare tempi, costi o obblighi.

The Teal Book collega i record di verifica e validazione anche alla prova necessaria per decidere se un fornitore debba essere pagato. Quel passaggio non autorizza l'AI a interpretare il contratto. Significa che la prova deve essere abbastanza solida da sostenere la decisione delle persone autorizzate.

Collega difetti e rischi

Una differenza osservata può aprire un rischio o aggiornare un rischio esistente. Non duplicare il registro.

Il risk register di un evento conserva rischio, trigger, owner e risposta. Il registro di accettazione conserva requisito, prova, difetto ed esito. Collega gli ID.

Esempio: la planimetria incompleta è un difetto attuale. Il possibile ritardo nel via libera alla produzione è un rischio futuro. Stesso contesto, 2 oggetti diversi.

Un esempio completo

Scenario fittizio. Un fornitore tecnico consegna 4 oggetti: planimetria, power schedule, lista attrezzature e piano di carico. Il registro contiene 19 requisiti approvati.

Il workflow esegue ispezione documentale su versioni, ID e campi. Confronta poi 7 valori espliciti tra planimetria e lista attrezzature. Trova 2 differenze.

La prima riguarda 18 tavoli contro 20. Il reviewer scopre che la distinta catering usa una baseline precedente. La planimetria è corretta, la distinta diventa superseded. Nessun rework al fornitore.

La seconda riguarda un codice alimentazione presente nella lista ma assente dal power schedule. L'evidenza è esplicita. Il technical reviewer apre rework con requirement ID e pagina. Non propone un valore sostitutivo.

La versione 5 arriva alle 11:12 del giorno successivo. Il workflow ripete solo i controlli interessati e i 3 regression check definiti. Tutti passano. Il decision owner firma l'esito accepted e il record entra nel pacchetto di handover.

Misura il controllo

Conta deliverable ricevuti, tempo fino al primo controllo, mismatch per requisito, rework riaperti, difetti trovati dopo l'accettazione e decisioni senza evidenza.

Misura anche la provenienza. Quanti mismatch erano veri difetti del deliverable? Quanti dipendevano da una specifica vecchia o da un problema di versionamento interno? Se la seconda quota cresce, il fornitore non è l'unico punto da correggere.

Nessuna soglia universale. Un singolo difetto può essere bloccante, mentre 12 correzioni editoriali possono essere gestibili. Conta conseguenza e criterio.

Errori che trasformano il file in prova

• usare il nome finale come versione,

• controllare contro il brief sbagliato,

• cambiare il requisito dopo la consegna,

• accettare un riassunto senza aprire l'evidenza,

• confondere mismatch e causa,

• far correggere all'AI il file ricevuto,

• nascondere un rework dentro una nuova versione,

• applicare automaticamente conseguenze economiche o contrattuali,

• copiare dati fornitore in output non autorizzati.

I 2 numeri delle 15:26

Prendi un deliverable ricevuto questa settimana. Trova un requisito che contiene una quantità e un documento a valle che la ripete.

Se i 2 numeri divergono, non correggerli. Hai trovato il primo controllo da costruire.

Porta a MAIKER HUB 1 specifica e 2 deliverable. Nel percorso Think -> Build -> Enable costruiamo requirement ID, prove e decisioni senza lasciare che il nome del file faccia da collaudo.

Fonti e riferimenti

• NIST AI Risk Management Framework

• NIST AI 600-1: Generative AI Profile

• Commissione europea: quadro normativo sull'intelligenza artificiale