La nostra AI ha prenotato un hotel che non esisteva — e la matematica diceva che sarebbe successo

La prima volta che ho visto il nostro assistente di viaggio confermare un hotel che non esisteva, la sala della demo è letteralmente scoppiata in un applauso.

Un tester aveva chiesto un eco-lodge di lusso in Costa Rica a meno di 200 $ a notte. Il modello ha restituito il "Tabacon Springs Eco-Lodge" — testi splendidi, una tariffa notturna plausibile, una schermata di conferma. Si legge magnificamente. Ma è anche il frutto di due strutture reali, Tabacon e Nayara Springs, fuse in un unico luogo immaginario. Il Tabacon Springs Eco-Lodge non esiste. Se all'altro capo di quello schermo ci fosse stata una famiglia, sarebbe volata in Costa Rica per arrivare a una reception che non aveva mai sentito parlare di lei.

Quel momento è l'intera ragione per cui la prenotazione di viaggi con AI agentica è più difficile di quanto sembri, ed è per questo che voglio ripercorrere gli errori che abbiamo commesso prima di azzeccarla. In breve: nei viaggi, una risposta fluente e una risposta vera sono oggetti diversi, e la distanza tra loro non è un bug che si elimina a forza di iterazioni. È una proprietà strutturale dell'usare un modello probabilistico per svolgere un lavoro deterministico.

Un agente di viaggio in carne e ossa che tira a indovinare sulla disponibilità viene licenziato. Un'AI che tira a indovinare viene lodata per il suo tono — finché un cliente non si ritrova bloccato in aeroporto.

Il consiglio di amministrazione ha chiesto "una strategia di AI". Il mercato ha dato loro un motivo per andare nel panico.

Lasciate che descriva la scena, perché se gestite il prodotto in una travel management company o in un'OTA, la state vivendo proprio ora.

Tra febbraio e aprile 2026, ogni principale livello di distribuzione nel settore dei viaggi ha rilasciato o annunciato la prenotazione agentica. Sabre, PayPal e Mindtrip hanno annunciato la prima esperienza agentica end-to-end del settore il 12 febbraio — voli generalmente disponibili nel Q2 2026, basati sulle API Mosaic di Sabre, con oltre 420 compagnie aeree e due milioni di hotel, e in cima la knowledge base da 6,5 milioni di punti di Mindtrip. Il giorno prima, il CEO di Marriott ha confermato che l'AI Mode di Google avrebbe prenotato Marriott direttamente, saltando del tutto il canale OTA. Amadeus ha inserito un assistente generativo chiamato Cytric Easy dentro Microsoft Teams, sviluppato con Accenture. Navan continua a riportare numeri che fanno sembrare lenta ogni TMC tradizionale.

Così il CFO entra nella stanza e chiede perché non state "facendo una cosa con l'AI come Navan". Ed ecco la trappola in cui ho visto cadere team in gamba: sentono quella domanda come lancia un chatbot in fretta, quando la vera domanda — l'unica che conta — è come lo facciamo senza scottarci come Air Canada.

Gli acquirenti con cui parlo non si chiedono se fare la prenotazione agentica. Quella discussione è chiusa. Si chiedono come farla senza scommettere l'azienda sull'inventario di un'unica piattaforma, e senza che una macchina sicura di sé ma in errore crei una responsabilità di cui dovranno rispondere in prima persona.

La responsabilità ha già un nome, e il vostro ufficio legale lo conosce

Se volete capire perché i legali del settore viaggi sono nervosi, vi basta un solo caso.

Il 14 febbraio 2024, il Civil Resolution Tribunal della Columbia Britannica ha ordinato ad Air Canada di pagare 812,02 $ a Jake Moffatt dopo che il suo chatbot aveva inventato una politica retroattiva di tariffe per lutto in contrasto con le regole tariffarie effettive della compagnia. La difesa di Air Canada sosteneva che il chatbot fosse, di fatto, un'entità giuridica separata responsabile delle proprie affermazioni. Il tribunale ha respinto la tesi in parole semplici: un'azienda è responsabile di tutto ciò che compare sulle sue superfici, che le parole provengano da una pagina web statica o da un modello.

Ottocentododici dollari sono un errore di arrotondamento. Il precedente no. Ogni memorandum legale nel travel-tech scritto da allora cita Moffatt, e una sentenza più recente è andata nella direzione opposta senza aiutare minimamente chi implementa questi sistemi — nel gennaio 2026 un tribunale di Hangzhou ha ristretto, per un LLM vendor, la responsabilità quando un utente ha provato a far valere la promessa di un chatbot. Lette insieme, le due sentenze puntano nella stessa scomoda direzione: il dovere di diligenza ricade sul brand di viaggio, non sul fornitore del modello. Non si può esternalizzare la colpa a OpenAI.

E non si tratta solo di soldi. Nel 2025, alcuni turisti hanno affrontato una camminata fino a 4.000 metri sulle Ande peruviane a caccia del "Sacro Canyon di Humantay", un luogo interamente inventato da un pianificatore AI. Una coppia malese ha guidato per 400 chilometri per provare una "Kuak Skyride" che non esiste. Un villaggio della Tasmania di 33 abitanti ha iniziato a ricevere telefonate su sorgenti termali che non aveva mai avuto. La ISO 31030, lo standard di gestione del rischio di viaggio, rende la sicurezza del viaggiatore un obbligo di chi implementa il sistema — quegli incidenti sono esattamente ciò che quello standard esiste per prevenire. Con circa un quarto dei turisti che ora usa l'AI per pianificare i viaggi, il raggio d'azione ha smesso di essere teorico già da un po'.

Dove ho sbagliato: pensavo fosse un problema di prompt

Ecco la parte di cui non vado fiero.

La nostra prima versione era, onestamente, un wrapper dall'aspetto curato. Un modello capace, un system prompt ben progettato, retrieval su un catalogo di hotel, un'interfaccia di chat pulita. Faceva una bella figura nelle demo — abbastanza da sorprendermi a credere che le allucinazioni fossero un caso limite che avremmo eliminato con un prompting migliore e un indice di retrieval più grande. Un investitore, in quel periodo, mi disse più o meno di usare semplicemente GPT e di smettere di complicarmi la vita. Per circa un mese gli ho creduto a metà.

È stato il momento del Tabacon Springs a incrinare quella convinzione, ma la cosa che mi ha davvero fatto cambiare idea è stata sedermi a fare i conti che avevo evitato.

Una prenotazione di volo realistica è composta da circa dieci passaggi sequenziali: interpretare l'intento, cercare, filtrare, quotare il prezzo, bloccare, verificare la policy, raccogliere i dati del passeggero, passare al pagamento, confermare il PNR, emettere il biglietto. Supponiamo — con generosità — che ogni passaggio sia una chiamata a un modello probabilistico corretta nel 90% dei casi. Dall'inizio alla fine, il tasso di successo è 0,9 elevato alla decima. Circa il 34%.

Non si può uscire a forza di prompt da un errore stocastico che si accumula. L'errore non diminuisce man mano che si aggiungono passaggi. Si moltiplica.

Poi ho trovato il numero che ha chiuso il dibattito interno. Il benchmark TravelPlanner dell'OSU NLP Group ha misurato GPT-4, usando il popolare pattern ReAct, mentre completava itinerari realistici di più giorni al 0,6%. Non il 60%. Zero virgola sei. Sei viaggi riusciti su mille.

C'è chi sventola una cifra del "97%" tratta dallo stesso benchmark, e voglio essere preciso qui perché prenderla in prestito ci farebbe apparire disonesti o ingenui: quel 97% deriva da un solver guidato dal codice eseguito contro una knowledge base statica e congelata — snapshot di OpenFlights e Yelp — non un modello che prenota su un inventario reale e in continuo cambiamento. Non è un dato di prenotazione in produzione, e chiunque lo citi come tale non ha letto il paper. Il numero onesto per un LLM che guida l'intero flusso è quello piccolo.

Questa è stata la svolta. Il problema non è mai stato il prompt. Il problema era che avevamo messo un modello probabilistico nel control flow, punto e basta.

Come si impedisce a un'AI di prenotare un hotel che non esiste?

Nel momento in cui ho smesso di provare a rendere il modello più affidabile e ho iniziato a rimuoverlo dalle parti che devono essere affidabili, l'architettura si è quasi progettata da sola.

La regola su cui ci siamo assestati: il modello linguistico si occupa di linguaggio, e nient'altro. Estrae ciò che un viaggiatore intende e riassume i risultati in un inglese semplice. Non chiama il GDS. Non verifica la policy. Non tocca il pagamento. Ognuna di queste è logica deterministica, scritta a mano nel codice. Gestiamo l'orchestrazione come una macchina a stati — LangGraph è il nostro control plane abituale, anche se non ne facciamo una religione; se un cliente si appoggia su AWS Bedrock AgentCore o Vertex AI Agent Builder, costruiamo lì invece.

Il dettaglio che conta più del framework è lo stato tipizzato. La maggior parte dei deployment di agenti in produzione che ho visto muore della stessa morte silenziosa: lo stato deriva in modo impercettibile tra un passaggio e l'altro, nessuno se ne accorge, e l'agente agisce con sicurezza su un'immagine corrotta del mondo. Uno schema di stato rigorosamente tipizzato con Pydantic — ogni campo dichiarato, validato a ogni transizione — è la cosa poco appariscente che lo previene. Quando una prenotazione deve estendersi su più commit, un pattern saga gestisce il rollback: se l'hotel fallisce dopo che il volo è già stato emesso, il grafo sa come annullare e tornare indietro invece di lasciare il viaggiatore a metà prenotazione.

L'abbiamo costruito come tre capacità, non un unico prodotto, perché non ogni acquirente ha bisogno dell'intero pacchetto. C'è l'agente di prenotazione deterministico — il cuore. C'è la verification-as-a-service, un'API a sé stante che qualsiasi team di travel-AI esistente può chiamare per chiedere "questo hotel è reale, questo prezzo è attuale, questo PNR è davvero confermato?" — un guardrail che si mette davanti a un wrapper che avete già rilasciato, una risposta molto più economica, quando i legali sollevano il caso Moffatt nel vostro comitato direttivo, che smontare tutto. E c'è un livello di policy-e-compliance che compila una policy di viaggio aziendale o le regole tariffarie di un'OTA in vincoli applicati, strumenta gli obblighi di dovere di diligenza della ISO 31030 e integra i requisiti di trasparenza dell'EU AI Act. Abbiamo spiegato come i tre elementi si combinano nella pagina della soluzione dedicata a questo lavoro.

L'applicazione delle policy dev'essere codice, non un prompt. I prompt derivano tra una versione del modello e l'altra. Le regole di business non possono permetterselo.

Il numero che nessuno mette nella slide di presentazione

Se potessi far interiorizzare una sola cosa a ogni team del settore viaggi prima del rilascio, non sarebbe l'allucinazione. Sarebbe l'economia della ricerca.

I provider GDS non fatturano a prenotazione. Fatturano a ricerca di segmento, tipicamente da 3 a 3,50 $ più una commissione di circa il 10%, e impongono rapporti look-to-book che vi penalizzano per la ricerca speculativa. Il Gruppo Lufthansa ha aumentato di nuovo le sue commissioni di prenotazione GDS, con effetto dal 1° gennaio 2026, su Amadeus, Sabre e Travelport. Ora immaginate un agente che, "con zelo", esegue quattro ricerche esplorative per ogni turno di conversazione perché il modello ha deciso di essere scrupoloso. Con il margine commerciale del 3-5% di un'OTA, quell'agente brucerà il profitto del trimestre su un chatbot che in realtà non prenota mai nulla.

Questa è la voce più trascurata in ogni demo di viaggi agentici a cui ho assistito, ed è esattamente il motivo per cui quelle demo non sopravvivono all'impatto con la produzione. Un agente deterministico limita e mette in cache le ricerche perché è il livello di orchestrazione — non l'umore del modello — a decidere quando una ricerca vale la sua tariffa.

E per una TMC, quell'economia si lega direttamente al numero che il CFO sta davvero inseguendo. La metrica che questa soluzione muove è la percentuale di prenotazioni touchless e il tempo di gestione della coda offline che ci sta dietro. Ogni prenotazione allucinata o non gestibile è un ticket che ricade su un agente umano — ed è proprio il costo a cui si punta quando qualcuno nella stanza dice "facciamo una cosa con l'AI come Navan".

Perché non puoi semplicemente costruirlo sull'API di Amadeus?

Alcune realtà che ho dovuto imparare a caro prezzo, e che ora tiro fuori nella prima discovery call così che nessuno si sorprenda al terzo mese.

Se siete una TMC che ha in programma di "costruire e basta sull'API di Amadeus", controllate quale chiave avete. Il tier Self-Service Production di Amadeus in particolare esclude l'endpoint Flight Create Orders — è, nella loro stessa formulazione, pensato per aziende prive di certificazione da agenzia di viaggi. Per emettere davvero gli ordini serve il tier Enterprise. Ho visto quella singola voce far slittare una roadmap di un trimestre.

Poi c'è la giuntura che tutti trattano come risolta e che non lo è: NDC contro GDS. La New Distribution Capability è ottima per l'offerta e l'ordine iniziali, ma la gestione post-prenotazione — cambi, rimborsi, riprotezioni per operazioni irregolari — gira ancora sull'infrastruttura GDS anche quando la vendita originale era in NDC. Un agente in produzione ha bisogno di entrambe le pipeline, non di una scelta binaria tra le due. E l'NDC in sé non è una cosa sola: la gestione degli ordini di Livello 4 tramite un aggregatore come Verteil o Duffel è un'integrazione diversa dallo shopping di Livello 3 a cui la maggior parte dei wrapper si ferma. È nell'IROPS che il divario si fa reale — un singolo evento meteo può lasciare a terra interi aerei di viaggiatori, ognuno con un costo di riprotezione da 500 a 2.000 $. Un agente che sa cercare ma non sa gestire è un giocattolo.

E se il vostro design prevede che l'agente emetta i biglietti direttamente invece di instradarli a un sistema host, siete ora in territorio di accreditamento — ARC negli Stati Uniti, che richiede circa 25 giorni una volta soddisfatti i prerequisiti, oppure il pieno accreditamento IATA, che può richiedere dai sei ai dodici mesi. C'è anche una trappola nei pagamenti: nel momento in cui un'interfaccia di chat raccoglie i dati della carta, avete trascinato l'intero stack nel perimetro PCI. Il commercio agentico oggi affida ancora l'autorizzazione effettiva a un passaggio di pagamento umano, con la tokenizzazione tramite un provider come VGS o Checkout.com che tiene i dati della carta fuori dal vostro ambiente.

Niente di tutto questo è nel keynote. Tutto quanto è nel report degli incidenti di produzione.

"Perché non comprare semplicemente quello di Sabre, o Cytric, o Navan?"

Me lo chiedono di continuo, e la mia risposta onesta li sorprende: a volte dovreste.

Se siete un'OTA nel leisure contenta di distribuire l'inventario di Sabre sui binari di Sabre, lo stack Sabre–PayPal–Mindtrip è un acquisto ragionevole — a patto che abbiate accettato una fornitura vincolata a Sabre e l'assenza di un livello di policy aziendale o di strumentazione ISO 31030. Se siete un'azienda Microsoft-native già su Cytric e Concur, Cytric Easy dentro Teams è probabilmente la scelta giusta per voi, e ve lo dirò senza giri di parole. Se volete rimuovere del tutto la vostra TMC e far girare una piattaforma AI-native, Navan si è guadagnata davvero i suoi numeri — 73% di spese touchless, violazioni delle policy scese dal 35% a meno del 5% — e non fingerò che li battiamo nel fare i Navan.

Noi ci adattiamo a un caso più ristretto e specifico: volete mantenere i vostri contratti GDS esistenti e il rapporto con la vostra TMC e aggiungere intelligenza al di sopra, in modo neutrale rispetto ai vendor, senza diventare un distributore per chiunque vi abbia venduto il vostro agente. Questo è ciò che costruiamo. E le parti che non posso fare, le dico ad alta voce — non siamo un agente di ticketing accreditato IATA/ARC, quindi l'emissione passa attraverso il vostro host; non deteniamo i vostri accordi commerciali GDS; e non possiamo sistemare una policy di viaggio aziendale ambigua, anche se vi aiuteremo a renderla più stringente in fase di discovery, perché una policy ambigua produce un agente ambiguo per quanto buono sia il codice.

La scadenza che chiude la finestra

Un'ultima cosa sul cronometro. Gli obblighi di trasparenza dell'EU AI Act per chi implementa i sistemi entrano in vigore il 2 agosto 2026, e le linee guida sulla classificazione ad alto rischio sono arrivate già il 2 febbraio 2026. Se il vostro agente parla con consumatori dell'UE, la disclosure non è facoltativa e "lo aggiungiamo dopo" è un rilievo di conformità pronto a scattare. Costruiamo fin dall'inizio la superficie di disclosure prevista dall'Articolo 50 e un audit trail di tipo log-and-explain, perché applicare a posteriori la trasparenza a un wrapper black-box è molto più doloroso che progettarla fin da subito.

Ecco dunque il punto a cui sono arrivato dopo tutto questo. La fluenza ora è gratis — ogni wrapper sul mercato suona sicuro di sé, e un viaggiatore non può distinguere una conferma reale da una allucinata semplicemente leggendola. Ciò che un viaggiatore può capire, alla fine, è se la camera c'è davvero alla reception quando arriva. Quel divario — tra una frase che si legge come vera e un PNR che è vero — non si chiude perché il modello è diventato più grande. Si chiude perché qualcuno ha deciso, prima del lancio, che il modello non sarebbe mai stato ciò che risponde alla domanda "è reale?". Il livello deterministico che risponde è poco appariscente, non fa altrettanto bella figura nelle demo, ed è l'intero lavoro.

Il Tabacon Springs Eco-Lodge continua a non essere un luogo reale. L'unica domanda che conta è se il vostro sistema lo sa prima che il vostro cliente si trovi nella hall. Se volete vedere come abbiamo costruito il nostro perché lo sappia, l'analisi completa è qui.