Unsere KI buchte ein Hotel, das nicht existierte — und die Mathematik sagte es voraus

Als ich zum ersten Mal beobachtete, wie unser Reiseassistent ein Hotel bestätigte, das gar nicht existierte, applaudierte der Demo-Raum tatsächlich.

Ein Tester hatte nach einer luxuriösen Öko-Lodge in Costa Rica für unter 200 $ pro Nacht gefragt. Das Modell lieferte die "Tabacon Springs Eco-Lodge" — großartiger Text, ein plausibler Übernachtungspreis, ein Bestätigungsbildschirm. Es liest sich wunderbar. Es sind allerdings zwei echte Objekte, Tabacon und Nayara Springs, verschmolzen zu einem fiktiven Ort. Es gibt keine Tabacon Springs Eco-Lodge. Wenn eine Familie am anderen Ende dieses Bildschirms gesessen hätte, wäre sie nach Costa Rica geflogen und an einer Rezeption angekommen, die noch nie von ihr gehört hatte.

Dieser Moment ist der ganze Grund, warum agentische KI-Reisebuchung schwieriger ist, als es aussieht, und deshalb möchte ich durchgehen, was wir falsch gemacht haben, bevor wir es richtig gemacht haben. Die Kurzfassung: Im Reisebereich sind eine flüssige Antwort und eine wahre Antwort verschiedene Objekte, und die Lücke zwischen ihnen ist kein Fehler, den man wegiteriert. Sie ist eine strukturelle Eigenschaft davon, ein probabilistisches Modell für eine deterministische Aufgabe einzusetzen.

Ein menschlicher Reiseberater, der bei der Verfügbarkeit rät, wird gefeuert. Eine KI, die rät, wird für ihren Ton gelobt — bis ein Kunde am Flughafen steht.

Der Vorstand bat um "eine KI-Strategie." Der Markt gab ihm einen Grund zur Panik.

Ich schildere die Situation, denn wenn Sie das Produkt bei einem Travel-Management-Unternehmen oder einem OTA verantworten, erleben Sie es gerade jetzt.

Zwischen Februar und April 2026 hat jede große Distributionsschicht im Reisebereich agentische Buchung ausgeliefert oder angekündigt. Sabre, PayPal und Mindtrip kündigten am 12. Februar das branchenweit erste durchgängige agentische Erlebnis an — Flüge allgemein verfügbar im 2. Quartal 2026, laufend auf Sabres Mosaic-APIs über mehr als 420 Fluggesellschaften und zwei Millionen Hotels, mit Mindtrips 6,5 Millionen Punkte umfassender Wissensbasis obendrauf. Am Tag zuvor bestätigte Marriotts CEO, dass Googles AI Mode Marriott direkt buchen würde und den OTA-Kanal komplett umgehen würde. Amadeus platzierte einen generativen Assistenten namens Cytric Easy in Microsoft Teams, gemeinsam mit Accenture entwickelt. Navan meldet weiterhin Zahlen, die jedes alteingesessene TMC langsam aussehen lassen.

Also kommt der CFO in den Raum und fragt, warum Sie nicht "eine KI-Sache wie Navan machen." Und hier ist die Falle, in die ich kluge Teams tappen sah: Sie hören diese Frage als schnell einen Chatbot ausliefern, während die eigentliche Frage — die einzige, die zählt — lautet: wie machen wir das, ohne uns wie Air Canada die Finger zu verbrennen.

Die Käufer, mit denen ich spreche, fragen nicht, ob sie agentische Buchung einführen sollen. Diese Debatte ist vorbei. Sie fragen, wie sie das tun, ohne das Unternehmen auf das Inventar einer einzigen Plattform zu verwetten, und ohne dass eine selbstbewusst falsche Maschine eine Haftung schafft, für die sie persönlich geradestehen müssen.

Die Haftung hat bereits einen Namen, und Ihr Rechtsteam kennt ihn

Wenn Sie verstehen wollen, warum Reiserechtsanwälte nervös sind, brauchen Sie nur einen einzigen Fall.

Am 14. Februar 2024 verurteilte das British Columbia Civil Resolution Tribunal Air Canada, Jake Moffatt 812,02 $ zu zahlen, nachdem ihr Chatbot eine rückwirkende Trauerfall-Tarifregelung erfunden hatte, die den tatsächlichen Tarifbestimmungen der Fluggesellschaft widersprach. Air Canadas Verteidigung lautete, der Chatbot sei praktisch eine eigenständige juristische Person, die für ihre eigenen Aussagen verantwortlich sei. Das Tribunal wies dies in klarer Sprache zurück: Ein Unternehmen ist für alles auf seinen Oberflächen verantwortlich, ob die Worte von einer statischen Webseite oder einem Modell stammen.

Achthundertzwölf Dollar sind ein Rundungsfehler. Der Präzedenzfall nicht. Jedes seither verfasste juristische Memo im Bereich Travel-Tech zitiert Moffatt, und ein jüngeres Urteil ging in die andere Richtung, ohne den Betreibern überhaupt zu helfen — im Januar 2026 schränkte ein Gericht in Hangzhou die Haftung eines LLM-Anbieters ein, als ein Nutzer versuchte, das Versprechen eines Chatbots durchzusetzen. Zusammen gelesen weisen die beiden Fälle in dieselbe unbequeme Richtung: Die Sorgfaltspflicht landet bei der Reisemarke, nicht beim Modellanbieter. Sie können die Schuld nicht an OpenAI auslagern.

Und es geht nicht nur ums Geld. Im Jahr 2025 wanderten Touristen auf 4.000 Meter in die peruanischen Anden, auf der Suche nach dem "Sacred Canyon of Humantay," einem Ort, den ein KI-Planer komplett erfunden hatte. Ein malaysisches Paar fuhr 400 Kilometer, um eine "Kuak Skyride" zu fahren, die nicht existiert. Ein tasmanisches Dorf mit 33 Einwohnern begann, Anrufe über Thermalquellen entgegenzunehmen, die es nie hatte. Die ISO 31030, die Norm für Reise-Risikomanagement, macht die Sicherheit der Reisenden zur Pflicht des Betreibers — genau solche Vorfälle soll sie verhindern. Da mittlerweile etwa ein Viertel der Touristen KI zur Reiseplanung nutzt, hat der Wirkungsradius vor einer Weile aufgehört, theoretisch zu sein.

Was ich falsch verstanden habe: Ich hielt das für ein Prompt-Problem

Hier ist der Teil, auf den ich nicht stolz bin.

Unser erster Build war, ehrlich gesagt, ein gut aussehender Wrapper. Ein leistungsfähiges Modell, ein gut ausgearbeiteter System-Prompt, Retrieval über einen Hotelkatalog, eine saubere Chat-Oberfläche. Es machte sich gut in der Demo — gut genug, dass ich mich dabei ertappte zu glauben, die Halluzinationen seien ein Randfall, den wir mit besserem Prompting und einem größeren Retrieval-Index herausquetschen würden. Ein Investor riet mir um diese Zeit mehr oder weniger, einfach GPT zu nutzen und aufzuhören, es zu überdenken. Etwa einen Monat lang glaubte ich ihm halb.

Der Tabacon-Springs-Moment ist das, was diesen Glauben zerbrach, aber was tatsächlich meine Meinung änderte, war, mich hinzusetzen und die Rechnung zu machen, der ich ausgewichen war.

Eine realistische Flugbuchung umfasst etwa zehn aufeinanderfolgende Schritte: Absicht erfassen, suchen, filtern, bepreisen, halten, Richtlinie prüfen, Passagierdaten erheben, Zahlung übergeben, das PNR festschreiben, ticketieren. Nehmen wir — großzügig — an, jeder Schritt sei ein probabilistischer Modellaufruf, der in 90 % der Fälle richtig liegt. Durchgängig beträgt Ihre Erfolgsquote 0,9 hoch zehn. Etwa 34 %.

Sie können sich nicht aus einem sich aufmultiplizierenden stochastischen Versagen herausprompten. Der Fehler wird nicht kleiner, wenn Sie Schritte hinzufügen. Er multipliziert sich.

Dann fand ich die Zahl, die die interne Debatte beendete. Der TravelPlanner-Benchmark der OSU NLP Group maß, dass GPT-4 mit dem populären ReAct-Muster realistische mehrtägige Reiserouten mit 0,6 % abschloss. Nicht 60 %. Null Komma sechs. Sechs erfolgreiche Reisen von tausend.

Man wirft mit einer "97-%"-Zahl aus demselben Benchmark um sich, und ich möchte hier präzise sein, denn sie zu übernehmen würde uns entweder unehrlich oder naiv aussehen lassen: Diese 97 % stammen von einem code-gesteuerten Solver, der gegen eine statische, eingefrorene Wissensbasis läuft — OpenFlights- und Yelp-Snapshots — nicht von einem Modell, das gegen lebendes, sich änderndes Inventar bucht. Es ist keine produktive Buchungszahl, und wer sie als solche zitiert, hat das Paper nicht gelesen. Die ehrliche Zahl für ein LLM, das den gesamten Ablauf steuert, ist die kleine.

Das war die Wende. Das Problem war nie der Prompt. Das Problem war, dass wir überhaupt ein probabilistisches Modell in den Kontrollfluss gesetzt hatten.

Wie hält man eine KI davon ab, ein Hotel zu buchen, das es nicht gibt?

Sobald ich aufhörte, das Modell zuverlässiger machen zu wollen, und begann, es aus den Teilen zu entfernen, die zuverlässig sein müssen, gestaltete sich die Architektur fast von selbst.

Die Regel, auf die wir uns festlegten: Das Sprachmodell macht Sprache, und sonst nichts. Es extrahiert, was ein Reisender meint, und fasst die Ergebnisse in klarer, verständlicher Sprache zusammen. Es ruft nicht das GDS auf. Es prüft keine Richtlinie. Es rührt keine Zahlung an. Jedes davon ist fest verdrahtete, deterministische Logik. Wir betreiben die Orchestrierung als Zustandsautomaten — LangGraph ist unsere übliche Steuerungsebene, obwohl wir da nicht dogmatisch sind; wenn ein Kunde auf AWS Bedrock AgentCore oder Vertex AI Agent Builder steht, bauen wir stattdessen dort.

Das Detail, das mehr zählt als das Framework, ist der typisierte Zustand. Die meisten produktiven Agenten-Deployments, die ich gesehen habe, sterben denselben stillen Tod: Der Zustand driftet unbemerkt zwischen den Schritten, niemand merkt es, und der Agent handelt selbstbewusst auf Basis eines korrumpierten Weltbilds. Ein striktes, Pydantic-typisiertes Zustandsschema — jedes Feld deklariert, bei jedem Übergang validiert — ist das unglamouröse Ding, das genau das verhindert. Wenn eine Buchung mehrere Commits umfassen muss, übernimmt ein Saga-Muster das Rollback: Wenn das Hotel scheitert, nachdem der Flug bereits ticketiert ist, weiß der Graph, wie er storniert und rückabwickelt, anstatt einen Reisenden halb gebucht zurückzulassen.

Wir haben es als drei Fähigkeiten gebaut, nicht als ein Produkt, denn nicht jeder Käufer braucht das Ganze. Da ist der deterministische Buchungsagent — der Kern. Da ist Verification-as-a-Service, eine eigenständige API, die jedes bestehende Reise-KI-Team aufrufen kann, um zu fragen: "Ist dieses Hotel echt, ist dieser Preis aktuell, ist dieses PNR wirklich bestätigt?" — ein Schutzmechanismus, der vor einem Wrapper sitzt, den Sie bereits ausgeliefert haben, was eine weitaus günstigere Antwort ist, wenn das Rechtsteam in Ihrem Lenkungsausschuss Moffatt markiert, als alles herauszureißen. Und da ist eine Richtlinien- und Compliance-Schicht, die eine Firmenreiserichtlinie oder die Tarifbestimmungen eines OTA in erzwungene Beschränkungen kompiliert, die Sorgfaltspflichten nach ISO 31030 instrumentiert und die Transparenzanforderungen des EU AI Act trägt. Wir haben aufgeschrieben, wie die drei zusammenpassen, auf der Lösungsseite zu dieser Arbeit.

Die Durchsetzung von Richtlinien muss Code sein, kein Prompt. Prompts driften zwischen Modellversionen. Geschäftsregeln dürfen das nicht.

Die Zahl, die niemand auf die Pitch-Folie setzt

Wenn ich jedem Reiseteam eine einzige Sache vor dem Launch verinnerlichen könnte, wären es nicht die Halluzinationen. Es wäre die Ökonomie der Suche.

GDS-Anbieter berechnen nicht pro Buchung. Sie berechnen pro Segmentsuche, typischerweise 3 bis 3,50 $ plus etwa 10 % Provision, und sie erzwingen Look-to-Book-Verhältnisse, die Sie für spekulatives Suchen bestrafen. Die Lufthansa Group hat ihre GDS-Buchungsgebühren erneut angehoben, mit Wirkung zum 1. Januar 2026, bei Amadeus, Sabre und Travelport. Stellen Sie sich nun einen Agenten vor, der "hilfsbereit" vier erkundende Suchen pro Gesprächsrunde durchführt, weil das Modell beschloss, gründlich zu sein. Bei der 3- bis 5-%-Händlermarge eines OTA verbrennt dieser Agent den Quartalsgewinn mit einem Chatbot, der nie tatsächlich etwas bucht.

Das ist die am meisten übersehene Zeile in jeder agentischen Reise-Demo, in der ich gesessen habe, und genau deshalb überstehen diese Demos den Kontakt mit der Produktion nicht. Ein deterministischer Agent begrenzt und cacht Suchen, weil die Orchestrierungsschicht — nicht die Laune des Modells — entscheidet, wann eine Suche ihre Gebühr wert ist.

Und für ein TMC hängt diese Ökonomie direkt mit der Zahl zusammen, die der CFO tatsächlich jagt. Die Kennzahl, die dieser Build bewegt, ist der prozentuale Anteil berührungsloser Buchungen und die dahinterliegende Bearbeitungszeit der Offline-Warteschlange. Jede halluzinierte oder nicht bedienbare Buchung ist ein Vorgang, der auf einen menschlichen Agenten zurückfällt — und das ist der Kostenfaktor, auf den gezeigt wird, wenn jemand im Raum sagt: "Macht eine KI-Sache wie Navan."

Warum kann man es nicht einfach auf der Amadeus-API bauen?

Ein paar Realitäten, die ich auf die teure Tour lernen musste und die ich jetzt schon im ersten Discovery-Gespräch anspreche, damit im dritten Monat niemand überrascht ist.

Wenn Sie ein TMC sind, das plant, "einfach auf der Amadeus-API zu bauen," prüfen Sie, welchen Schlüssel Sie haben. Die Self-Service-Production-Stufe von Amadeus schließt den Flight-Create-Orders-Endpunkt ausdrücklich aus — sie ist, in ihrer eigenen Formulierung, für Unternehmen ohne Reisebüro-Zertifizierung ausgelegt. Um tatsächlich Aufträge zu erteilen, brauchen Sie Enterprise. Ich habe zugesehen, wie diese einzige Position eine Roadmap um ein Quartal zurücksetzte.

Dann ist da die Nahtstelle, die jeder als gelöst behandelt und die es nicht ist: NDC gegen GDS. New Distribution Capability ist großartig für das anfängliche Angebot und die Bestellung, aber die Nachbuchungsbetreuung — Umtausch, Erstattungen, Umbuchungen bei Betriebsunregelmäßigkeiten — läuft weiterhin auf GDS-Infrastruktur, selbst wenn der ursprüngliche Verkauf NDC war. Ein produktiver Agent braucht beide Leitungen, keine binäre Wahl zwischen ihnen. Und NDC selbst ist nicht eine Sache: Level-4-Auftragsverwaltung über einen Aggregator wie Verteil oder Duffel ist eine andere Integration als das Level-3-Shopping, bei dem die meisten Wrapper aufhören. IROPS ist der Punkt, an dem die Lücke real wird — ein einziges Wetterereignis kann Reisende flugzeugweise stranden lassen, wobei jeder 500 bis 2.000 $ Umbuchungskosten verursacht. Ein Agent, der suchen, aber nicht betreuen kann, ist ein Spielzeug.

Und wenn Ihr Design vorsieht, dass der Agent Tickets direkt ausstellt, anstatt sie an ein Host-System weiterzuleiten, befinden Sie sich nun im Akkreditierungsgebiet — ARC in den USA, das etwa 25 Tage dauert, sobald die Voraussetzungen erfüllt sind, oder die vollständige IATA-Akkreditierung, die sechs bis zwölf Monate dauern kann. Es gibt außerdem eine Zahlungsfalle: In dem Moment, in dem eine Chat-Oberfläche Kartendaten erhebt, haben Sie Ihren gesamten Stack in den PCI-Geltungsbereich gezogen. Agentischer Handel übergibt heute die eigentliche Autorisierung noch an einen menschlichen Zahlungsschritt, wobei die Tokenisierung über einen Anbieter wie VGS oder Checkout.com die Kartendaten aus Ihrer Umgebung heraushält.

Nichts davon steht in der Keynote. Alles davon steht im Bericht zum Produktionsvorfall.

"Warum nicht einfach Sabres, oder Cytric, oder Navan kaufen?"

Man fragt mich das ständig, und meine ehrliche Antwort überrascht die Leute: Manchmal sollten Sie das.

Wenn Sie ein Freizeit-OTA sind, das gerne Sabres Inventar auf Sabres Schienen vertreibt, ist der Stack aus Sabre, PayPal und Mindtrip ein vernünftiger Kauf — solange Sie sich mit Sabre-gebundenem Angebot und dem Fehlen einer Firmenreiserichtlinien-Schicht oder einer ISO-31030-Instrumentierung abgefunden haben. Wenn Sie ein Microsoft-natives Unternehmen sind, das bereits auf Cytric und Concur läuft, ist Cytric Easy in Teams wahrscheinlich das Richtige für Sie, und das sage ich Ihnen direkt. Wenn Sie Ihr TMC komplett herausreißen und eine KI-native Plattform betreiben wollen, hat Navan seine Zahlen wirklich verdient — 73 % berührungslose Ausgaben, Richtlinienverstöße von 35 % auf unter 5 % gesenkt — und ich werde nicht so tun, als würden wir sie darin schlagen, Navan zu sein.

Wir passen zu einem engeren, spezifischen Fall: Sie wollen Ihre bestehenden GDS-Verträge und Ihre TMC-Beziehung behalten und Intelligenz obendrauf setzen, anbieterneutral, ohne zum Distributor für denjenigen zu werden, von dem Sie Ihren Agenten gekauft haben. Das ist der Build. Und die Teile, die ich nicht leisten kann, spreche ich laut aus — wir sind kein IATA/ARC-akkreditierter Ticketing-Agent, also läuft die Ausstellung über Ihren Host; uns gehören Ihre kommerziellen GDS-Vereinbarungen nicht; und wir können keine mehrdeutige Firmenreiserichtlinie reparieren, obwohl wir Ihnen helfen, sie im Discovery-Prozess zu straffen, denn eine mehrdeutige Richtlinie macht einen mehrdeutigen Agenten, egal wie gut der Code ist.

Die Frist, die das Fenster schließt

Noch eine Sache zur Uhr. Die Transparenzpflichten des EU AI Act für Betreiber treten am 2. August 2026 in Kraft, und die Leitlinien zur Hochrisiko-Einstufung kamen bereits am 2. Februar 2026. Wenn Ihr Agent mit EU-Verbrauchern spricht, ist die Offenlegung nicht optional, und "wir fügen es später hinzu" ist ein Compliance-Verstoß, der nur darauf wartet zu passieren. Wir bauen die Offenlegungsoberfläche nach Artikel 50 und einen Log-and-Explain-Prüfpfad von Anfang an ein, weil das nachträgliche Aufsetzen von Transparenz auf einen Blackbox-Wrapper weitaus schmerzhafter ist, als von vornherein dafür zu entwerfen.

Also, hier bin ich nach all dem gelandet. Eloquenz ist jetzt gratis — jeder Wrapper auf dem Markt klingt selbstbewusst, und ein Reisender kann eine echte Bestätigung nicht von einer halluzinierten unterscheiden, indem er sie liest. Was ein Reisender letztlich erkennen kann, ist, ob das Zimmer an der Rezeption bereit ist, wenn er ankommt. Diese Lücke — zwischen einem Satz, der sich wahr liest, und einem PNR, das wahr ist — schließt sich nicht, weil das Modell größer wurde. Sie schließt sich, weil jemand vor dem Launch entschied, dass das Modell niemals das sein würde, was die Frage "ist das echt?" beantwortet. Die deterministische Schicht, die sie beantwortet, ist unglamourös, sie macht sich in der Demo nicht so gut, und sie ist die ganze Aufgabe.

Die Tabacon Springs Eco-Lodge ist noch immer kein echter Ort. Die einzige Frage, die zählt, ist, ob Ihr System das weiß, bevor Ihr Kunde in der Lobby steht. Wenn Sie sehen wollen, wie wir unseres gebaut haben, damit es das weiß, hier ist die vollständige Aufschlüsselung.