Onze AI boekte een hotel dat niet bestond — en de wiskunde voorspelde het al

De eerste keer dat ik onze reisassistent een hotel zag bevestigen dat niet bestond, barstte de demozaal daadwerkelijk in applaus uit.

Een tester had gevraagd om een luxe eco-lodge in Costa Rica voor minder dan $200 per nacht. Het model gaf de "Tabacon Springs Eco-Lodge" terug — schitterende tekst, een plausibel nachttarief, een bevestigingsscherm. Het leest prachtig. Het zijn ook twee echte accommodaties, Tabacon en Nayara Springs, samengesmolten tot één fictieve plek. Er bestaat geen Tabacon Springs Eco-Lodge. Als er een gezin aan de andere kant van dat scherm had gezeten, waren ze naar Costa Rica gevlogen en aangekomen bij een receptie die nog nooit van hen had gehoord.

Dat moment is de hele reden waarom agentic AI-reisboekingen lastiger zijn dan ze lijken, en dat is waarom ik wil doornemen wat we verkeerd deden voordat we het goed kregen. De korte versie: in de reisbranche zijn een vloeiend antwoord en een waar antwoord verschillende dingen, en de kloof daartussen is geen bug die je wegitereert. Het is een structurele eigenschap van het gebruik van een probabilistisch model voor een deterministische taak.

Een menselijke reisagent die gokt naar beschikbaarheid wordt ontslagen. Een AI die gokt, wordt geprezen om zijn toon — totdat een klant op een luchthaven staat.

De raad van bestuur vroeg om "een AI-strategie." De markt gaf hun een reden om in paniek te raken.

Ik schets de situatie, want als je product leidt bij een travel management company of een OTA, beleef je dit op dit moment.

Tussen februari en april 2026 bracht elke grote distributielaag in de reisbranche agentic boeken uit of kondigde het aan. Sabre, PayPal en Mindtrip kondigden op 12 februari de eerste end-to-end agentic ervaring van de sector aan — vluchten algemeen beschikbaar in Q2 2026, draaiend op de Mosaic-API's van Sabre over meer dan 420 luchtvaartmaatschappijen en twee miljoen hotels, met daarbovenop de kennisbank van 6,5 miljoen punten van Mindtrip. De dag ervoor bevestigde de CEO van Marriott dat Google's AI Mode Marriott rechtstreeks zou boeken, waarbij het OTA-kanaal volledig wordt overgeslagen. Amadeus plaatste een generatieve assistent genaamd Cytric Easy in Microsoft Teams, gebouwd met Accenture. Navan blijft cijfers rapporteren die elke traditionele TMC traag doen lijken.

Dus de CFO komt binnen en vraagt waarom jij niet "iets met AI doet zoals Navan." En hier is de valkuil waar ik slimme teams in zag trappen: ze horen die vraag als snel een chatbot uitbrengen, terwijl de echte vraag — de enige die telt — is hoe doen we dit zonder onze vingers te branden zoals Air Canada.

De kopers met wie ik praat, vragen zich niet af óf ze agentic boeken moeten doen. Die discussie is voorbij. Ze vragen zich af hoe ze het moeten doen zonder het bedrijf in te zetten op de voorraad van één enkel platform, en zonder dat een zelfverzekerd foute machine een aansprakelijkheid creëert waarvoor zij persoonlijk verantwoording moeten afleggen.

De aansprakelijkheid heeft al een naam, en je juridische team kent hem

Als je wilt begrijpen waarom reisjuristen nerveus zijn, heb je maar één rechtszaak nodig.

Op 14 februari 2024 gelastte het British Columbia Civil Resolution Tribunal Air Canada om Jake Moffatt $812,02 te betalen nadat zijn chatbot een terugwerkend rouwtariefbeleid had verzonnen dat in strijd was met de daadwerkelijke tariefregels van de luchtvaartmaatschappij. Air Canada's verweer was dat de chatbot in feite een aparte juridische entiteit was die verantwoordelijk was voor zijn eigen uitspraken. Het tribunaal wees dat in duidelijke taal af: een bedrijf is verantwoordelijk voor alles op zijn kanalen, of de woorden nu van een statische webpagina komen of van een model.

Achthonderdtwaalf dollar is een afrondingsfout. Het precedent niet. Elk juridisch memo over reistechnologie dat sindsdien is geschreven, citeert Moffatt, en een recentere uitspraak viel de andere kant op zonder implementeerders ook maar iets te helpen — in januari 2026 beperkte een rechtbank in Hangzhou de aansprakelijkheid van een LLM-leverancier toen een gebruiker probeerde een belofte van een chatbot af te dwingen. Samen gelezen wijzen de twee zaken in dezelfde ongemakkelijke richting: de zorgplicht komt bij het reismerk te liggen, niet bij de modelaanbieder. Je kunt de schuld niet uitbesteden aan OpenAI.

En het gaat niet alleen om geld. In 2025 trokken toeristen naar 4.000 meter in de Peruaanse Andes op zoek naar de "Sacred Canyon of Humantay," een plek die een AI-planner volledig had verzonnen. Een Maleisisch stel reed 400 kilometer om een "Kuak Skyride" te maken die niet bestaat. Een Tasmaans dorp van 33 inwoners kreeg opeens telefoontjes over thermale bronnen die het nooit heeft gehad. ISO 31030, de norm voor reisrisicobeheer, maakt de veiligheid van de reiziger tot de verplichting van de implementeerder — die incidenten zijn precies waarvoor die norm bestaat om ze te voorkomen. Nu ongeveer een kwart van de toeristen AI gebruikt om reizen te plannen, is de reikwijdte van de schade allang niet meer theoretisch.

Wat ik verkeerd had: ik dacht dat dit een promptprobleem was

Hier komt het deel waar ik niet trots op ben.

Onze eerste versie was, eerlijk gezegd, een goed uitziende wrapper. Een capabel model, een goed doordachte systeemprompt, retrieval over een hotelcatalogus, een strak chatoppervlak. Het demode goed — goed genoeg dat ik mezelf betrapte op de gedachte dat de hallucinaties een randgeval waren dat we met betere prompting en een grotere retrieval-index eruit zouden persen. Een investeerder vertelde me rond die tijd, min of meer, om gewoon GPT te gebruiken en er niet zo over door te denken. Ongeveer een maand lang geloofde ik hem half.

Het Tabacon Springs-moment is wat dat geloof brak, maar wat me daadwerkelijk van gedachten deed veranderen, was gaan zitten en het rekenwerk doen dat ik had vermeden.

Een realistische vluchtboeking bestaat uit ongeveer tien opeenvolgende stappen: intentie ontleden, zoeken, filteren, prijzen, vasthouden, beleid controleren, passagiersgegevens verzamelen, betaling overdragen, de PNR vastleggen, ticketten. Stel — royaal gerekend — dat elke stap een probabilistische modelaanroep is die 90% van de tijd klopt. Van begin tot eind is je slagingspercentage 0,9 tot de tiende macht. Ongeveer 34%.

Je kunt je niet uit een samengestelde stochastische fout prompten. De fout wordt niet kleiner naarmate je stappen toevoegt. Hij vermenigvuldigt zich.

Toen vond ik het getal dat het interne debat beëindigde. De TravelPlanner-benchmark van de OSU NLP Group mat dat GPT-4, met het populaire ReAct-patroon, realistische meerdaagse reisschema's voltooide met een percentage van 0,6%. Niet 60%. Nul komma zes. Zes geslaagde reizen op de duizend.

Mensen zwaaien met een cijfer van "97%" uit dezelfde benchmark, en ik wil hier precies zijn, want dat lenen zou ons of oneerlijk of naïef doen lijken: die 97% komt van een door code aangestuurde solver die draait tegen een statische, bevroren kennisbank — snapshots van OpenFlights en Yelp — niet een model dat boekt tegen live, veranderende voorraad. Het is geen productieboekingscijfer, en iedereen die het als zodanig citeert, heeft het paper niet gelezen. Het eerlijke getal voor een LLM die de hele flow aanstuurt, is het kleine.

Dat was het keerpunt. Het probleem was nooit de prompt. Het probleem was dat we überhaupt een probabilistisch model in de control flow hadden gezet.

Hoe voorkom je dat een AI een hotel boekt dat er niet is?

Toen ik ophield te proberen het model betrouwbaarder te maken en begon het te verwijderen uit de onderdelen die betrouwbaar moeten zijn, ontwierp de architectuur zichzelf bijna.

De regel waar we op uitkwamen: het taalmodel doet taal, en niets anders. Het haalt eruit wat een reiziger bedoelt en vat resultaten samen in gewone taal. Het roept de GDS niet aan. Het controleert geen beleid. Het raakt geen betaling aan. Elk van die zaken is hard-coded, deterministische logica. We draaien de orkestratie als een state machine — LangGraph is onze gebruikelijke control plane, hoewel we er niet dogmatisch over zijn; als een klant op AWS Bedrock AgentCore of Vertex AI Agent Builder staat, bouwen we daar in plaats daarvan.

Het detail dat er meer toe doet dan het framework is de getypeerde state. De meeste productie-agentimplementaties die ik heb gezien, sterven dezelfde stille dood: de state drift onopgemerkt tussen stappen, niemand merkt het, en de agent handelt vol vertrouwen op een corrupt beeld van de wereld. Een strikt Pydantic-getypeerd state-schema — elk veld gedeclareerd, gevalideerd bij elke overgang — is het roemloze ding dat het voorkomt. Wanneer een boeking meerdere commits moet omvatten, verzorgt een saga-patroon de rollback: als het hotel mislukt nadat de vlucht al is geticket, weet de graph hoe hij moet annuleren en terugdraaien in plaats van een reiziger half geboekt achter te laten.

We hebben het gebouwd als drie capaciteiten, niet één product, omdat niet elke koper het hele geheel nodig heeft. Er is de deterministische boekingsagent — de kern. Er is verification-as-a-service, een op zichzelf staande API die elk bestaand reis-AI-team kan aanroepen om te vragen "bestaat dit hotel echt, is deze prijs actueel, is deze PNR daadwerkelijk bevestigd?" — een guardrail die vóór een wrapper zit die je al hebt uitgebracht, wat een veel goedkoper antwoord is wanneer juridische zaken Moffatt aankaart in je stuurgroep dan alles eruit te rukken. En er is een beleids- en compliancelaag die een zakelijk reisbeleid of de tariefregels van een OTA compileert tot afgedwongen beperkingen, de zorgplichtverplichtingen van ISO 31030 instrumenteert en de transparantievereisten van de EU AI Act meedraagt. We hebben opgeschreven hoe de drie samenkomen op de oplossingspagina voor dit werk.

Beleidshandhaving moet code zijn, geen prompt. Prompts driften tussen modelversies. Bedrijfsregels mogen dat niet.

Het getal dat niemand op de pitch-slide zet

Als ik elk reisteam één ding zou kunnen laten internaliseren voordat ze live gaan, zou het geen hallucinatie zijn. Het zou de economie van zoeken zijn.

GDS-aanbieders factureren niet per boeking. Ze factureren per segmentzoekopdracht, doorgaans $3 tot $3,50 plus ongeveer 10% commissie, en ze handhaven look-to-book-verhoudingen die je bestraffen voor speculatief zoeken. Lufthansa Group verhoogde zijn GDS-boekingskosten opnieuw, met ingang van 1 januari 2026, bij Amadeus, Sabre en Travelport. Stel je nu een agent voor die "behulpzaam" vier verkennende zoekopdrachten per gespreksbeurt uitvoert omdat het model besloot grondig te zijn. Op de merchant-marge van 3 tot 5% van een OTA zal die agent de winst van het kwartaal opbranden aan een chatbot die nooit daadwerkelijk iets boekt.

Dit is de meest over het hoofd geziene regel in elke agentic-travel-demo die ik heb bijgewoond, en het is precies waarom die demo's het contact met productie niet overleven. Een deterministische agent begrenst en cachet zoekopdrachten omdat de orkestratielaag — niet de bui van het model — beslist wanneer een zoekopdracht zijn kosten waard is.

En voor een TMC hangt die economie rechtstreeks samen met het getal dat de CFO daadwerkelijk najaagt. De metric die deze build verplaatst, is het percentage touchless boekingen en de afhandeltijd van de offlinewachtrij die erachter zit. Elke gehallucineerde of onbruikbare boeking is een ticket dat terugvalt op een menselijke agent — en dat zijn de kosten waarnaar wordt verwezen wanneer iemand in de kamer zegt "doe iets met AI zoals Navan."

Waarom kun je het niet gewoon op de Amadeus-API bouwen?

Een paar realiteiten die ik op de dure manier moest leren, en die ik nu ter sprake breng in het eerste discovery-gesprek zodat niemand in maand drie voor verrassingen komt te staan.

Als je een TMC bent die van plan is om "gewoon op de Amadeus-API te bouwen," controleer dan welke sleutel je hebt. De Self-Service Production-tier van Amadeus sluit het Flight Create Orders-endpoint specifiek uit — het is, in hun eigen bewoordingen, ontworpen voor bedrijven zonder reisbureaucertificering. Om daadwerkelijk orders uit te geven heb je Enterprise nodig. Ik heb gezien hoe dat ene item een roadmap een kwartaal terugzette.

Dan is er de naad die iedereen als opgelost beschouwt en dat niet is: NDC versus GDS. New Distribution Capability is geweldig voor de eerste offer en order, maar servicing na de boeking — omboekingen, terugbetalingen, herboekingen bij verstoorde operaties — draait nog steeds op GDS-infrastructuur, zelfs wanneer de oorspronkelijke verkoop via NDC ging. Een productieagent heeft beide pijpen nodig, geen binaire keuze tussen de twee. En NDC zelf is niet één ding: Level 4-ordermanagement via een aggregator als Verteil of Duffel is een andere integratie dan de Level 3-shopping waar de meeste wrappers stoppen. IROPS is waar de kloof echt wordt — één enkele weersgebeurtenis kan reizigers bij vliegtuigladingen tegelijk stranden, en elk daarvan kost $500 tot $2.000 om om te boeken. Een agent die kan zoeken maar niet kan servicen, is speelgoed.

En als je ontwerp de agent tickets rechtstreeks laat uitgeven in plaats van door te sturen naar een hostsysteem, zit je nu in accreditatieterrein — ARC in de VS, dat ongeveer 25 dagen duurt zodra aan de voorwaarden is voldaan, of volledige IATA-accreditatie, die zes tot twaalf maanden kan duren. Er is ook een betalingsval: op het moment dat een chatoppervlak kaartgegevens verzamelt, heb je je hele stack binnen de PCI-scope getrokken. Agentic commerce overhandigt vandaag de dag de daadwerkelijke autorisatie nog steeds aan een menselijke betaalstap, waarbij tokenisatie via een aanbieder als VGS of Checkout.com de kaartgegevens buiten je omgeving houdt.

Niets hiervan staat in de keynote. Alles ervan staat in het productie-incidentrapport.

"Waarom niet gewoon dat van Sabre, of Cytric, of Navan kopen?"

Mensen vragen me dit voortdurend, en mijn eerlijke antwoord verrast hen: soms moet je dat doen.

Als je een leisure-OTA bent die graag Sabres voorraad over Sabres rails distribueert, is de Sabre–PayPal–Mindtrip-stack een redelijke aankoop — zolang je Sabre-gebonden aanbod en de afwezigheid van een bedrijfsbeleidslaag of ISO 31030-instrumentatie hebt geaccepteerd. Als je een Microsoft-native onderneming bent die al op Cytric en Concur draait, is Cytric Easy in Teams waarschijnlijk de juiste keuze voor jou, en dat zeg ik je rechtstreeks. Als je je TMC volledig wilt vervangen en een AI-native platform wilt draaien, heeft Navan zijn cijfers oprecht verdiend — 73% touchless declaraties, beleidsovertredingen gedaald van 35% naar onder de 5% — en ik ga niet doen alsof wij hen verslaan in het zijn van Navan.

Wij passen bij een smaller, specifiek geval: je wilt je bestaande GDS-contracten en je TMC-relatie behouden en toevoegen, intelligentie erbovenop, leverancierneutraal, zonder een distributeur te worden voor degene bij wie je je agent hebt gekocht. Dat is de build. En de delen die ik niet kan doen, zeg ik hardop — we zijn geen IATA/ARC-geaccrediteerde ticketagent, dus uitgifte verloopt via jouw host; we bezitten je commerciële GDS-overeenkomsten niet; en we kunnen een dubbelzinnig zakelijk reisbeleid niet repareren, hoewel we je zullen helpen het aan te scherpen in de discovery, omdat een dubbelzinnig beleid een dubbelzinnige agent maakt, hoe goed de code ook is.

De deadline die het venster sluit

Nog één ding met de klok. De transparantieverplichtingen van de EU AI Act voor implementeerders gaan op 2 augustus 2026 in, en de richtlijnen voor de classificatie met een hoog risico kwamen al op 2 februari 2026. Als je agent met EU-consumenten praat, is openheid niet optioneel en is "dat voegen we later toe" een compliancebevinding die staat te wachten om te gebeuren. We bouwen het Artikel 50-openbaarmakingsoppervlak en een log-en-verklaar-audittrail er vanaf het begin in, omdat het achteraf inbouwen van transparantie in een black-box-wrapper veel pijnlijker is dan er meteen voor te ontwerpen.

Dus dit is waar ik na dit alles ben uitgekomen. Vloeiendheid is nu gratis — elke wrapper op de markt klinkt zelfverzekerd, en een reiziger kan een echte bevestiging niet onderscheiden van een gehallucineerde door haar te lezen. Wat een reiziger uiteindelijk wél kan zien, is of de kamer bij de receptie klaarligt als hij aankomt. Die kloof — tussen een zin die waar leest en een PNR die waar is — sluit niet omdat het model groter werd. Hij sluit omdat iemand vóór de lancering besloot dat het model nooit datgene zou zijn dat "is dit echt?" beantwoordt. De deterministische laag die het beantwoordt, is roemloos, demode minder goed, en het is de hele klus.

De Tabacon Springs Eco-Lodge is nog steeds geen echte plek. De enige vraag die telt, is of jouw systeem dat weet voordat je klant in de lobby staat. Als je wilt zien hoe wij de onze hebben gebouwd om het te weten, de volledige uitwerking staat hier.