Un agente testato in condizioni controllate non è un agente pronto per il campo. Il Pilot è la fase in cui si scopre cosa funziona davvero — non su input costruiti ad hoc, ma su situazioni reali, clienti reali, pressioni operative reali. Questo modulo ti insegna a pianificare il lancio controllato, a gestire le prime settimane in esercizio e a usare i dati raccolti per decidere con metodo se e come andare avanti. Il contesto di riferimento è l'agenzia viaggi, dove il volume di richieste è alto, i tempi di risposta sono critici e l'errore ha un costo diretto sulla relazione con il cliente.
La distinzione tra test e Pilot è più importante di quanto sembri. Un test si fa in condizioni controllate, su input preparati, con l'obiettivo di verificare che il sistema funzioni come previsto. Un Pilot si fa in produzione — o in un sottoinsieme di produzione — con input reali, su casistiche che nessuno ha previsto, in condizioni operative che cambiano di giorno in giorno.
Per un'agenzia viaggi, questa differenza è concreta. In fase di test, l'agente di classificazione delle richieste viene alimentato con email tipo: "Vorrei informazioni per un viaggio a Lisbona per due persone a luglio". In Pilot, arriva l'email di un cliente che scrive alle 23:00 da un aeroporto di scalo, in italiano mescolato con qualche parola in inglese, con un tono ansioso, chiedendo di cambiare la tratta del giorno dopo. L'agente che ha funzionato perfettamente in condizioni controllate potrebbe classificare questo come una richiesta informativa generica invece di un'emergenza operativa.
Il Pilot serve a scoprire questi gap — non a confermarne l'assenza. Chi entra nel Pilot aspettandosi che tutto funzioni come in test si trova impreparato alla prima anomalia. Chi entra sapendo che troverà gap, con un sistema per raccoglierli e analizzarli, trasforma ogni anomalia in un'informazione utile.
Il primo errore nel lancio di un Pilot è non definirne il perimetro. "Proviamo con un po' di richieste" non è un Pilot: è un esperimento informale che non produce dati analizzabili. Un Pilot ha un perimetro preciso su tre dimensioni: volume, tipo di richiesta e durata.
Prima di attivare l'agente su richieste reali dei clienti, è necessario eseguire una mock session: una simulazione su email costruite appositamente, tratte dalla casistica reale dell'agenzia e anonimizzate con Presidio (nomi, riferimenti personali, dati di contatto). La mock session copre almeno una email per ogni categoria di richiesta prevista nel perimetro del Pilot, più i casi che il team considera storicamente difficili da gestire. Solo quando la mock session produce risultati soddisfacenti su tutti i casi previsti, il Pilot può partire. La mock session non sostituisce il Pilot — serve a evitare di dover gestire errori e scuse con i clienti reali nelle prime settimane.
Un'agenzia viaggi con picchi stagionali ha un vincolo aggiuntivo: i dati raccolti in bassa stagione non predicono il comportamento in alta stagione. Se il Pilot cade a gennaio, le conclusioni non si trasferiscono automaticamente ad agosto. Pianifica un secondo ciclo di verifica nei periodi di picco, anche se il Pilot formale è già concluso.
Un Pilot che il team non capisce è un Pilot che fallisce per ragioni non tecniche. In un'agenzia viaggi, chi risponde alle email dei clienti deve sapere tre cose prima che il Pilot inizi: cosa fa l'agente esattamente, cosa deve fare il consulente quando l'agente produce un output che sembra strano, e come segnalare un problema in modo che sia utile — non solo "l'agente ha sbagliato".
Il piano di comunicazione interno non è un documento tecnico: è un briefing operativo che risponde alle domande pratiche del team. Quanto ci vorrà prima che cambi qualcosa nel mio lavoro quotidiano? Devo controllare tutto quello che produce l'agente? Se un cliente si lamenta, di chi è la responsabilità? Queste domande devono trovare risposta prima del lancio, non mentre il Pilot è in corso.
Per le agenzie viaggi, un elemento spesso trascurato è la formazione del team sull'uso dello strumento di segnalazione. Se il team usa WhatsApp per segnalare i problemi dell'agente, le segnalazioni arriveranno in formato non strutturato e non saranno analizzabili. Anche cinque minuti di formazione su come compilare una scheda segnalazione possono fare la differenza tra informazioni analizzabili e feedback non strutturato.
Prima di lanciare il Pilot, devi definire le condizioni in cui lo interrompi. Questo non è pessimismo: è la garanzia che il Pilot rimanga uno strumento di apprendimento e non diventi una fonte di danni operativi o reputazionali.
Per un'agenzia viaggi, i criteri di interruzione più rilevanti sono tre. Primo: se più del 15% degli output dell'agente richiede correzione sostanziale prima di essere inviato al cliente, il sistema non è abbastanza affidabile per operare anche in modalità "bozza con revisione". Secondo: se un output scorretto raggiunge un cliente senza essere intercettato dal team — anche una sola volta — il Pilot deve fermarsi per analizzare come è successo e cosa va modificato. Terzo: se il team smette di segnalare problemi non perché non ce ne siano, ma perché si è stancato del processo di segnalazione, il dato raccolto non è più affidabile e il Pilot ha perso la sua funzione.
La definizione di criteri di interruzione prima del lancio è una pratica di gestione del rischio raccomandata dall'AI Act per i sistemi che operano in contesti con impatto diretto sul cliente. Per le agenzie viaggi, l'output dell'agente raggiunge clienti reali — la mancata definizione di soglie di interruzione espone l'azienda a rischi reputazionali e, in alcuni contesti, a responsabilità contrattuali.
Le prime 48 ore del Pilot sono le più critiche e le più informative. In questo intervallo emergono i problemi di configurazione che i test non hanno intercettato, i comportamenti dell'agente su input reali che differiscono dagli input sintetici, e le prime reazioni del team al cambiamento operativo.
Per un'agenzia viaggi, le prime 48 ore devono essere presidiate in modo attivo: il consulente o chi gestisce il sistema deve essere disponibile per rispondere rapidamente alle segnalazioni del team e, se necessario, modificare il perimetro del Pilot — ridurre il volume, escludere temporaneamente alcune categorie di richiesta, o sospendere e correggere prima di riprendere.
L'errore più frequente nelle prime 48 ore è non intervenire per non ammettere che qualcosa non funziona come previsto. Il Pilot è progettato esattamente per trovare questi problemi — trovarne uno nelle prime ore non è un fallimento, è il sistema che funziona correttamente.
Dopo le prime 48 ore, il Pilot entra in un ritmo settimanale. La struttura che funziona meglio per le agenzie viaggi prevede tre momenti fissi: una revisione rapida dei log a metà settimana (20-30 minuti), una sessione di analisi delle segnalazioni a fine settimana (45-60 minuti), e un riepilogo inviato al referente interno entro il lunedì mattina.
La revisione a metà settimana serve a intercettare anomalie prima che si accumulino. Se l'agente ha sviluppato un pattern di errore su un tipo specifico di richiesta, è molto meglio identificarlo dopo 3 giorni che dopo 7 — la correzione è più facile e i dati da analizzare sono meno. La sessione di fine settimana è invece il momento in cui si decide se il Pilot prosegue invariato, se il perimetro va modificato, o se è necessario sospendere per un ciclo di ottimizzazione (Optimize).
| Momento | Durata | Cosa si fa | Output |
|---|---|---|---|
| Mercoledì — revisione log | 20-30 min | Controlla frequenza per categoria, segnala anomalie emergenti | Lista breve di anomalie da approfondire venerdì |
| Venerdì — analisi segnalazioni | 45-60 min | Classifica le segnalazioni del team, identifica pattern, decide azioni | Decisione: continua / modifica perimetro / sospendi per Optimize |
| Lunedì — riepilogo | 15-20 min | Invia riepilogo settimanale al referente interno dello studio | Documento: segnalazioni per categoria, azioni intraprese, prossimi passi |
Durante il Pilot, alcune situazioni richiedono una risposta immediata — non il venerdì in sessione di analisi, ma nell'arco di minuti o ore. Per un'agenzia viaggi, queste situazioni sono prevedibili: un output dell'agente che raggiunge un cliente con un errore di contenuto significativo, una risposta automatica che viene inviata invece di rimanere in bozza, un'anomalia tecnica che blocca il workflow per un sottoinsieme di richieste.
Il protocollo di risposta alle eccezioni deve essere definito prima del lancio e deve essere semplice abbastanza da essere eseguito anche sotto pressione. Il modello che funziona prevede tre livelli: il team segnala nell'arco di 15 minuti dalla scoperta dell'anomalia, il consulente valuta entro un'ora se sospendere o ridurre il perimetro del Pilot, e la comunicazione al cliente — se necessaria — viene gestita dal team con un messaggio standard di scusa predisposto in anticipo.
La mock session serve esattamente a questo: evitare di dover gestire scuse con i clienti reali. Simulare le casistiche difficili prima del Pilot — incluse le richieste ambigue, le emergenze fuori orario, le email in lingua mista — riduce drasticamente la probabilità che un errore raggiunga un cliente durante le prime settimane. Il messaggio di scusa è la rete di sicurezza per i casi che la mock session non ha intercettato, perché nessuna simulazione copre tutto. Va predisposto prima del lancio, ma l'obiettivo del metodo è non doverlo mai usare.
La gestione delle eccezioni in tempo reale durante il Pilot è uno degli ambiti in cui la supervisione umana prevista dall'AI Act si traduce in pratica operativa concreta. Per i sistemi che producono output verso i clienti, l'AI Act richiede che siano predisposti meccanismi di intervento rapido in caso di comportamenti anomali — non come opzione, ma come requisito del sistema di gestione del rischio.
Sospendere il Pilot non è un fallimento — è una decisione operativa che richiede lo stesso metodo di qualsiasi altra decisione nel processo. Il momento giusto per sospendere è quando continuare produce più danni di quanti dati utili stia raccogliendo. Per un'agenzia viaggi, questo momento arriva tipicamente quando uno dei criteri di interruzione definiti prima del lancio viene raggiunto, o quando emergono nel log pattern di errore sistematico che richiedono un ciclo di ottimizzazione (Optimize) prima di poter raccogliere dati affidabili.
La sospensione deve essere comunicata al team in modo chiaro e senza creare ansia: "abbiamo identificato un aspetto da migliorare prima di continuare, torniamo operativi entro X giorni". Questa comunicazione è importante tanto quanto quella di lancio — un team che non capisce perché il Pilot si è fermato tende a sviluppare sfiducia nello strumento, che poi è difficile recuperare al rilancio.
Al termine del Pilot, o al termine di ogni settimana di Pilot, i dati raccolti devono permettere di prendere tre tipi di decisione: se il sistema è pronto per estendere il volume, se il system prompt richiede un ciclo di ottimizzazione (Optimize) prima di procedere, e se il perimetro del Pilot va modificato — ampliato ad altre categorie di richiesta, ristretto a un sottoinsieme più controllato, o mantenuto invariato.
Queste tre decisioni richiedono dati diversi. La decisione sull'estensione del volume richiede il tasso di accuratezza per categoria e il confronto con la soglia operativa definita prima del lancio. La decisione sull'Optimize richiede l'analisi dei pattern di errore — se gli errori sono casuali o sistematici. La decisione sul perimetro richiede l'analisi della distribuzione delle segnalazioni: se il 70% delle segnalazioni riguarda un'unica categoria di richiesta, quella categoria è il problema da affrontare, non il sistema nel suo insieme.
Uno dei rischi più frequenti nell'analisi dei dati del Pilot è l'interpretazione eccessiva di campioni piccoli. Quattro settimane di Pilot su 20-25 richieste settimanali producono 80-100 casi totali — abbastanza per identificare pattern evidenti, non abbastanza per calcolare statistiche con margini di errore piccoli.
Per un'agenzia viaggi, questo significa che una settimana con il 20% di errori non indica necessariamente un peggioramento del sistema: potrebbe essere una settimana con più richieste atipiche, un evento esterno che ha modificato i comportamenti dei clienti, o semplicemente la varianza naturale di un campione piccolo. Prima di trarre conclusioni da un'anomalia settimanale, confrontala con le altre settimane del Pilot e con la distribuzione attesa.
Il principio operativo è semplice: una settimana anomala merita attenzione, non azione. Due settimane consecutive anomale nella stessa direzione meritano un'analisi approfondita. Tre settimane consecutive anomale meritano un'azione.
Chi ha costruito l'agente tende a interpretare i dati del Pilot in modo favorevole — a enfatizzare i casi gestiti correttamente e a minimizzare gli errori come "casi limite". Chi è scettico sull'agente tende all'opposto. Entrambe le distorsioni producono decisioni sbagliate. Il metodo corretto è partire dalla soglia operativa definita prima del lancio — non dalla propria impressione soggettiva — e confrontare i dati con quella soglia.
Al termine del Pilot, la decisione finale deve essere documentata in forma scritta — non comunicata solo verbalmente in una riunione. Per un'agenzia viaggi, questo documento è il punto di transizione tra il Pilot e la fase successiva: o il Transform, se il sistema è pronto, o un nuovo ciclo di ottimizzazione (Optimize) + Pilot se non lo è.
Il documento di chiusura del Pilot contiene quattro elementi: il riepilogo dei dati raccolti nelle settimane del Pilot, il confronto tra i dati e le soglie operative definite prima del lancio, la decisione presa e la motivazione, e i passi successivi con responsabile e scadenza. Non è un documento lungo: due pagine sono sufficienti. Ma deve esistere come riferimento per chiunque voglia capire perché è stata presa quella decisione in quel momento.
Oltre alla funzione tecnica di raccolta dati, il Pilot ha una funzione organizzativa spesso sottovalutata: costruisce la fiducia del team nel sistema. Un team che ha partecipato al Pilot — che ha segnalato problemi, che ha visto le segnalazioni produrre modifiche reali, che ha vissuto il ritmo settimanale di revisione — è un team che ha sviluppato un rapporto di lavoro con l'agente. Non è un rapporto di fiducia cieca, ma di fiducia basata sull'esperienza.
Per un'agenzia viaggi, questa fiducia è critica. Il team che risponde ai clienti deve sentirsi sicuro nell'usare le bozze dell'agente — deve sapere che se qualcosa non va, c'è un sistema per gestirlo e che la sua segnalazione produce un effetto. Se il Pilot è stato gestito in modo trasparente e reattivo, questo senso di sicurezza emerge naturalmente. Se il Pilot è stato gestito in modo opaco — dati raccolti ma non condivisi, segnalazioni ricevute ma mai riscontrate — il team entra nella fase di produzione con riserve che non spariscono facilmente.
La gestione trasparente del Pilot è una forma concreta di applicazione del principio di trasparenza richiesto dall'AI Act per i sistemi AI che operano in contesti lavorativi. I lavoratori che interagiscono con sistemi AI hanno diritto a essere informati del loro funzionamento e dei loro limiti — il Pilot, se gestito correttamente, è il momento in cui questa informazione viene trasmessa attraverso l'esperienza diretta invece che attraverso un documento.
Genera un file Markdown con tutti i prompt pronti all'uso di questo modulo, la tua riflessione e il piano del Pilot che hai costruito.
Cos'è un file .md? È un file di testo con una formattazione semplice. Puoi aprirlo con Blocco note o TextEdit — vedrai il testo con qualche simbolo di formattazione. Per visualizzarlo con titoli e sezioni già formattati, importalo in Notion trascinando il file nella barra laterale.
© 2025 AI ADOPT™ — Tutti i diritti riservati.