La tua IA per i viaggi ti sta mentendo — e non lo scoprirai finché non resterai bloccato

L'anno scorso una donna ci ha scritto un'email con uno screenshot. Aveva usato un popolare pianificatore di viaggi basato sull'IA per prenotare una vacanza in famiglia in Costa Rica. L'IA le aveva consigliato un posto chiamato qualcosa come "Tabacon Springs Eco-Lodge" — descrizioni lussureggianti, un prezzo inferiore a 200 $ a notte, foto che sembravano corrispondere. Prenotò i voli per quattro persone. Noleggiò un'auto. Disse ai suoi figli che sarebbero andati a vedere le scimmie da una casa sull'albero.

Il lodge non esisteva.

Non "era chiuso" o "era in ristrutturazione". Semplicemente non esisteva. L'IA aveva fuso insieme i dettagli di due o tre veri resort costaricani — il nome di uno, i servizi di un altro, la fascia di prezzo di un ostello lungo la strada — e li aveva cuciti in un'unica proprietà splendidamente descritta che non era mai stata costruita. Il link di prenotazione portava a una generica pagina di pagamento che addebitò la sua carta e non consegnò nulla.

Quando lessi quell'email, non provai sorpresa. Provai riconoscimento. Perché il mio team di Veriprajna aveva passato mesi a fissare esattamente questa modalità di fallimento, a smontarla, a capire perché accade a livello architetturale. E la risposta è tanto semplice quanto profondamente scomoda per chiunque costruisca prodotti IA nel settore dei viaggi: i sistemi IA più popolari del settore sono ottimizzati per sembrare corretti, non per esserlo. Questa distinzione è sottile in un generatore di poesie. Nella logistica dei viaggi, è la differenza tra una vacanza e un disastro.

Perché la tua IA inventa hotel che non esistono?

Ecco ciò che la maggior parte delle persone non capisce sui grandi modelli linguistici — GPT-4, Claude, Gemini, tutti quanti. Non "conoscono" le cose nel modo in cui le conosce un database. Un sistema di prenotazione alberghiera sa che la Camera 412 al JW Marriott è prenotata dal 3 al 7 marzo. Questo è un fatto, memorizzato in una riga, interrogabile.

Un LLM non funziona così. Predice la parola successiva in una sequenza basandosi su schemi statistici presenti nei suoi dati di addestramento. Quando gli chiedi un "eco-lodge di lusso in Costa Rica sotto i 200 $", attiva insiemi di associazioni — "Costa Rica" richiama "lussureggiante", "foresta pluviale", "eco-lodge". Inizia a generare testo che è statisticamente probabile che segua quelle parole. E quando deve dare un nome alla proprietà? Fonde. Prende frammenti da migliaia di recensioni che ha visto e li assembla in qualcosa che suona plausibile.

Nella scrittura creativa, questa fusione si chiama immaginazione. Nei viaggi, si chiama allucinazione. E il modello non ha modo di distinguere la differenza.

Il modello sta ottimizzando per la coerenza, non per la correttezza. È progettato per produrre una risposta che sembra una risposta valida, non una che sia una risposta valida verificata rispetto all'inventario in tempo reale.

Ciò che peggiora la situazione è il modo in cui questi modelli vengono addestrati. Durante l'apprendimento per rinforzo da feedback umano (RLHF), i valutatori umani preferiscono costantemente risposte complete e sicure rispetto a risposte che dicono "non lo so". Così il modello impara, a un livello profondo, che tirare a indovinare con sicurezza viene premiato e ammettere l'ignoranza viene penalizzato. Un agente di viaggio umano che tira a indovinare sulla disponibilità viene licenziato. Un'IA che tira a indovinare sulla disponibilità viene lodata per la sua "fluidità" — finché il cliente non atterra in un paese straniero senza un posto dove dormire.

La notte in cui capii che la fluidità è il problema

C'è un momento a cui continuo a tornare. Stavamo testando un primo prototipo — non un prodotto che abbiamo lanciato, ma un esperimento interno per capire come gli LLM gestiscono le richieste di viaggio. Gli chiesi di trovarmi un hotel vicino a Central Park per meno di 250 $ a notte durante la Fashion Week a New York.

Tornò con tre opzioni. Descrizioni dettagliate. Prezzi. Servizi. Una di esse menzionava persino un bar sul tetto con vista sul parco. Il linguaggio era così raffinato, così specifico, che il mio primo istinto fu di cliccare "prenota".

Poi uno dei miei ingegneri — un tipo più tranquillo, molto metodico — eseguì la stessa query sull'API Amadeus Hotel Search. Due dei tre hotel esistevano ma non avevano disponibilità durante la Fashion Week. Il nome del terzo hotel era simile a quello di una proprietà reale ma non corrispondeva ad alcun ID hotel nel sistema. Il bar sul tetto? Apparteneva a un hotel completamente diverso a sei isolati di distanza.

Quella fu la notte in cui capii che il pericolo non è un'IA che fallisce in modo evidente. Un chatbot che dice "non capisco la tua domanda" è frustrante ma innocuo. Il pericolo è un'IA che comprende perfettamente la tua domanda e risponde con informazioni eloquenti, persuasive e fattualmente errate. Abbiamo iniziato a chiamare questa la "Uncanny Valley" dell'affidabilità — l'intelligenza verbale del sistema è così elevata che gli utenti abbassano la guardia sulla verifica dei fatti.

Il caso del chatbot di Air Canada ha reso tutto questo concreto in termini legali. Un chatbot ha allucinato una politica di rimborso. Il tribunale ha stabilito che la compagnia aerea era responsabile — non il fornitore dell'IA, non il chatbot come "strumento in beta". L'azienda che ha implementato l'agente era responsabile delle affermazioni dell'agente. Se la tua IA promette una suite vista mare a 200 $ e il GDS ha solo una camera standard a 400 $, potresti dover rispondere della differenza. O peggio, del viaggio rovinato.

Cosa succede quando tratti l'LLM come il cervello invece che come la bocca?

Dopo quella notte di test, il mio team ebbe una lunga discussione. Di quelle in cui le persone disegnano sulle lavagne e si parlano sopra a vicenda. La domanda era semplice: cerchiamo di rendere l'LLM più accurato, o cambiamo del tutto l'architettura?

Una fazione voleva prompt migliori, più guardrail, generazione aumentata dal recupero. Mettere a punto il modello sui dati di viaggio. L'altra fazione — quella in cui finii io — sosteneva che il problema non era la conoscenza del modello. Il problema era il ruolo del modello. Stavamo chiedendo a un generatore di testo di svolgere il lavoro di un gestore di inventario. È come chiedere a un romanziere di gestire una compagnia aerea. Può descrivere splendidamente l'esperienza del volo, ma non può dirti se c'è un posto sul volo delle 8 del mattino per Heathrow.

Così prendemmo una decisione che cambiò tutto ciò che costruimmo in seguito: l'LLM non sarebbe mai stato la fonte delle informazioni di viaggio. Sarebbe stato l'instradatore dell'intento.

L'utente dice "Trovami un hotel vicino a Central Park". Il compito dell'LLM è comprendere quell'intento, scomporlo in parametri strutturati — località, intervallo di date, budget, preferenze — e passare quei parametri a uno strumento che interroga l'inventario reale. Lo strumento restituisce dati effettivi. Il secondo compito dell'LLM è presentare quei dati in linguaggio naturale. Ma non genera mai i dati. Li traduce.

Abbiamo smesso di costruire un'IA che parla di viaggi. Abbiamo iniziato a costruire un'IA che fa i viaggi — interroga sistemi reali, interpreta codici di stato reali e conferma solo ciò che può verificare.

Questo è il passaggio da ciò che il settore chiama "LLM Wrapper" a un sistema di IA agentica. E la differenza non è incrementale. È un cambio di specie. Ho scritto in dettaglio di questa architettura nella versione interattiva della nostra ricerca.

Il pattern Orchestratore-Worker: perché un solo agente non basta

All'inizio provammo a far passare tutto attraverso un unico agente. Un solo prompt che gestiva voli, hotel, noleggi auto, restrizioni alimentari, politiche di viaggio aziendali. Crollò sotto il proprio peso. La finestra di contesto si riempiva. Le istruzioni entravano in conflitto. L'agente prenotava un hotel prima di confermare le date del volo, poi doveva disfare tutto.

Così costruimmo quello che chiamiamo il pattern Orchestratore-Worker. Immaginatelo come un consulente di viaggio senior che non tocca mai una tastiera, che gestisce un team di specialisti ciascuno dei quali fa una cosa sola in modo estremamente efficace.

L'Orchestratore è un modello ad alto ragionamento — GPT-4o o Claude 3.5 Sonnet — che parla con l'utente, mantiene la cronologia della conversazione e decide cosa deve accadere. Non tocca direttamente il GDS. Al di sotto di esso ci sono Worker specializzati: un Flight Worker che parla le API Amadeus Air e comprende i codici IATA, un Hotel Worker che parla i Content Services for Lodging di Sabre e conosce la differenza tra un deposito e una garanzia, un Policy Worker che verifica le regole di viaggio aziendali prima che qualsiasi cosa venga presentata.

Quando un utente dice "Prenota un volo per NYC martedì prossimo e un hotel vicino a Central Park", l'Orchestratore scompone la richiesta in due compiti, identifica che la ricerca dell'hotel dipende dall'orario di arrivo del volo, avvia prima il Flight Worker, poi l'Hotel Worker con le date corrette. Se l'Hotel Worker fallisce, l'Orchestratore presenta comunque le opzioni di volo e chiede se l'utente vuole riprovare con criteri di hotel diversi. Nulla va in crash. Nulla allucina.

L'intuizione chiave fu separare il pensare dal fare. L'Orchestratore pensa. I Worker fanno. E nessuno dei due finge di essere l'altro.

Perché "200 OK" ci ha quasi ingannati

Ecco una storia che mi fa ancora rabbrividire. Eravamo immersi nei test di integrazione con le API di prenotazione di Sabre. Il nostro Hotel Worker inviava una richiesta di prenotazione, riceveva in risposta un HTTP 200 — che nello sviluppo web significa "successo" — e lo passava all'Orchestratore. L'Orchestratore diceva all'utente: "Sei prenotato!"

Solo che non lo erano. Non sempre.

Ci mise un tempo imbarazzantemente lungo per accorgercene. La risposta HTTP era 200 perché il messaggio era stato consegnato con successo. Ma all'interno del corpo della risposta, il codice di stato del segmento GDS era UC — Unable to Confirm. L'hotel aveva rifiutato la richiesta, di solito perché la disponibilità in cache era obsoleta. La camera era stata venduta nei millisecondi tra la ricerca e il tentativo di prenotazione.

La disconnessione tra il livello di trasporto e il livello applicativo è una trappola classica, e ci finimmo dentro in pieno. Un 200 OK a livello HTTP diceva "il tuo messaggio è arrivato". Un UC a livello GDS diceva "la tua prenotazione è fallita". Il nostro sistema leggeva la busta e ignorava la lettera al suo interno.

Fu allora che implementammo quello che ora considero il pezzo più importante della nostra architettura: il Verification Loop. Ogni risposta di prenotazione passa attraverso un passaggio di verifica separato — o un controllo deterministico del codice o un prompt specializzato che funge da revisore della qualità — prima che qualsiasi conferma raggiunga l'utente. La regola è assoluta:

Un agente IA non è mai autorizzato a emettere un messaggio di conferma a meno che non abbia analizzato lo specifico codice di stato del segmento GDS e non lo abbia validato come HK — Holding Confirmed. Tutto il resto è un fallimento, indipendentemente da ciò che dice l'header HTTP.

HK significa che l'inventario è assicurato. UC significa che l'hotel ti ha rifiutato. NN significa che la richiesta è in sospeso — non promettere ancora nulla. NO significa nessuna azione intrapresa. Questi codici sono la differenza tra una camera prenotata e un viaggiatore bloccato, e la maggior parte dei sistemi IA di viaggio non li analizza nemmeno.

Per la ripartizione tecnica completa della nostra gestione dei codici di stato e dell'architettura di verifica, consulta il nostro documento di ricerca.

Come gestisce un agente IA la situazione "la camera è appena stata venduta"?

È qui che i sistemi agentici dimostrano il loro valore. La discrepanza "Look-to-Book" è endemica nei viaggi — cerchi, vedi la disponibilità, clicchi prenota, e la camera non c'è più. Accade di continuo durante l'alta stagione. Un'IA basata su wrapper non ha vocabolario per questa situazione. O dice "L'ho prenotata!" (sbagliato) o "È fallita" (inutile). Non può dire "C'era un secondo fa, ma qualcun altro l'ha presa — ecco la tua migliore alternativa".

I nostri agenti sì. Quando una prenotazione restituisce UC, il sistema attiva automaticamente una nuova ricerca di disponibilità per lo stesso hotel. Se è disponibile una camera o una tariffa diversa, presenta l'opzione: "La tariffa precedente è andata esaurita, ma ho trovato una camera simile per 10 $ in più". Se non c'è nulla di disponibile, estrae l'hotel migliore successivo dai risultati di ricerca originali e propone quello. Questo richiede che l'agente mantenga uno stato — una memoria di ciò che ha già cercato, di ciò che l'utente ha già rifiutato, di quali erano le alternative. I wrapper sono privi di stato. Non possono farlo. Ripartono da zero ogni volta, oppure allucinano la continuità.

Il problema della normalizzazione di cui nessuno parla

Una cosa che mi ha sorpreso — sinceramente sorpreso — è stata quanto siano diverse le strutture dati tra Amadeus e Sabre. Amadeus restituisce i prezzi suddivisi in base, totale e tasse in un JSON annidato rigoroso. Sabre a volte include le tasse, a volte no, a seconda del piano tariffario. I nomi dei campi differiscono. amount in un sistema è totalPrice in un altro.

Se dai in pasto entrambe le risposte grezze a un LLM e gli chiedi di confrontare gli hotel, si confonderà. Potrebbe citare il prezzo al netto delle tasse da Amadeus e il prezzo al lordo delle tasse da Sabre, facendo sembrare l'hotel di Amadeus 50 $ più economico quando in realtà è 20 $ più costoso. Lo abbiamo visto accadere durante i test, ed è il tipo di errore quasi impossibile da individuare per un utente.

Così costruimmo un Normalization Worker — un livello di codice deterministico che prende i JSON disparati di entrambi i sistemi e li converte in un unico schema standardizzato. L'Orchestratore non vede mai i dati GDS grezzi. Vede campi puliti e coerenti: nome, prezzo totale tasse incluse, classificazione a stelle, distanza dal punto di interesse dell'utente. L'LLM presenta questi dati normalizzati. Non interpreta risposte API grezze. Traduce fatti curati.

"Usa semplicemente GPT" — e altre cose che dicono gli investitori

Le persone mi chiedono di continuo perché non usiamo semplicemente la generazione aumentata dal recupero — portare i dati degli hotel in un database vettoriale, lasciare che l'LLM lo interroghi. Oppure mettere a punto un modello sui dati di viaggio. O semplicemente aggiungere un system prompt migliore.

Un investitore mi disse, senza mezzi termini: "Usa semplicemente GPT con un buon prompt. Il modello è abbastanza intelligente". Rispetto l'istinto — è la soluzione più semplice, e le soluzioni semplici di solito sono quelle giuste. Ma non qui. Non quando la modalità di fallimento è una famiglia che dorme in un aeroporto.

Il RAG aiuta con la conoscenza statica — "Qual è la politica sui visti per la Thailandia?" — ma non può dirti se il volo AA123 ha posti disponibili in questo momento. La messa a punto aiuta con il tono e il vocabolario di dominio, ma non collega il modello all'inventario in tempo reale. Un system prompt migliore aiuta con la formattazione, ma non impedisce al modello di generare il nome di un hotel che non esiste in nessun GDS.

L'unica cosa che previene l'allucinazione nei viaggi è ancorare l'output dell'IA a dati in tempo reale e verificati provenienti dal sistema di riferimento. Quel sistema è il GDS. Tutto il resto è decorazione.

La creatività senza vincoli è caos. Nei viaggi, il vincolo è la realtà — il posto sul volo che esiste o non esiste, la camera d'hotel che è disponibile o non lo è. Non c'è via di mezzo, e l'IA deve smettere di far finta che ci sia.

E la parte lenta?

Non fingerò che i sistemi agentici siano veloci. Una singola richiesta dell'utente potrebbe attivare quattro chiamate agli strumenti — ricerca, controllo del prezzo, controllo della policy, sintesi della risposta. Questo può richiedere 10-15 secondi. Nell'e-commerce, è un'eternità.

Gestiamo la cosa in tre modi. Primo, trasmettiamo in streaming il ragionamento dell'agente all'utente: "Ricerca di voli su Amadeus…" "Controllo della politica di viaggio aziendale…" Mostrare il lavoro riduce drasticamente la latenza percepita. Secondo, eseguiamo i Worker in parallelo — il Flight Worker e l'Hotel Worker cercano simultaneamente anziché in sequenza, dimezzando all'incirca il tempo di attesa totale. Terzo, mettiamo in cache i risultati di disponibilità per 15 minuti in Redis. Se l'utente dice "Mostrami di nuovo quel secondo hotel", non interroghiamo di nuovo il GDS. Preleviamo dalla cache.

È veloce quanto un wrapper che inventa una risposta in due secondi? No. È veloce quanto serve per un utente che vuole una risposta vera? Sì.

La parte in cui ammetto ciò che non sappiamo ancora fare

Nessun sistema IA gestisce ogni caso. Itinerari complessi a più tratte con dipendenze dai visti, alleanze aeree oscure, prenotazioni di gruppo che richiedono tariffe negoziate — queste cose fanno ancora inceppare le cose. Lo sappiamo perché abbiamo costruito un sistema di rilevamento apposta. Quando l'agente entra in loop senza risolvere, o quando l'analisi del sentiment segnala la frustrazione dell'utente, il sistema declassa a quella che chiamiamo "modalità Copilot". Avvisa un agente di viaggio umano, gli passa l'intero contesto strutturato della conversazione, e l'umano completa la prenotazione usando gli strumenti che l'agente ha preparato.

Le persone mi chiedono se questo sia un fallimento. Io penso il contrario. L'IA più pericolosa è quella che non sa quando fermarsi. Conoscere i propri limiti e passare il testimone con eleganza è una funzionalità, non un difetto. L'agente che dice "Lascia che ti metta in contatto con uno specialista" è più affidabile di quello che continua a tirare a indovinare con sicurezza.

Dove si va da qui

Ciò che stiamo costruendo oggi è le fondamenta, non il tetto. Siamo a quello che definirei un'autonomia di Livello 3 — l'agente esegue compiti specifici, ma l'utente conferma prima che il denaro si muova. Il percorso in avanti include agenti di negoziazione che non si limitano a prenotare i prezzi elencati ma interrogano le API degli hotel per ottenere sconti sui volumi, motori di packaging dinamico che raggruppano voli e hotel in prodotti personalizzati con margini gestiti, e una gestione proattiva delle interruzioni — agenti che monitorano lo stato dei voli 24 ore su 24 e, quando avviene una cancellazione, hanno già bloccato un posto sulla migliore alternativa prima ancora che il viaggiatore sappia che qualcosa è andato storto.

Nulla di tutto ciò è possibile su un wrapper. Nulla di ciò funziona se il sistema allucina. Ognuna di queste capacità richiede l'architettura stateful, verificata e ancorata agli strumenti che abbiamo costruito.

Il settore dei viaggi si trova a un punto di svolta. La prima ondata di adozione dell'IA — i wrapper, i chatbot, gli esperimenti del tipo "aggiungi semplicemente GPT" — ha creato qualcosa di seducente e pericoloso: sistemi che suonano come il miglior agente di viaggio che tu abbia mai incontrato ma che non riescono davvero a prenotare una camera. La prossima ondata sarà definita da una domanda più difficile e meno affascinante: non "L'IA sa scrivere un bell'itinerario?" ma "L'IA sa confermare che ogni voce di quell'itinerario esista davvero, in questo momento, al prezzo che ha indicato?"

Quella famiglia in Costa Rica meritava di meglio di una finzione scritta magnificamente. Ogni viaggiatore lo merita. L'era dell'IA che tira a indovinare è finita. Ciò che viene dopo è l'IA che verifica — e parla solo quando sa.