ה-AI שלנו הזמין מלון שלא היה קיים — והחשבון אמר שכך יקרה
בפעם הראשונה שבה ראיתי את עוזר הנסיעות שלנו מאשר מלון שלא היה קיים, החדר בהדגמה ממש פרץ בתשואות.
בודק ביקש אכסניה אקולוגית יוקרתית בקוסטה ריקה בפחות מ-$200 ללילה. המודל החזיר את "Tabacon Springs Eco-Lodge" — טקסט מרהיב, תעריף לילי סביר, מסך אישור. זה נקרא נהדר. זה גם שני נכסים אמיתיים, Tabacon ו-Nayara Springs, שהותכו למקום בדיוני אחד. אין דבר כזה Tabacon Springs Eco-Lodge. אילו משפחה הייתה בצד השני של המסך הזה, היא הייתה טסה לקוסטה ריקה ומגיעה לדלפק קבלה שמעולם לא שמע עליה.
אותו הרגע הוא כל הסיבה לכך שהזמנת נסיעות מבוססת agentic AI קשה יותר משנראה, וזו הסיבה שאני רוצה לעבור על מה שטעינו בו לפני שהצלחנו. הגרסה הקצרה: בנסיעות, תשובה שוטפת ותשובה נכונה הן שני עצמים שונים, והפער ביניהם אינו באג שאפשר לפתור בעזרת איטרציות. זוהי תכונה מבנית של שימוש במודל הסתברותי לביצוע עבודה דטרמיניסטית.
סוכן נסיעות אנושי שמנחש לגבי זמינות מפוטר. בינה מלאכותית שמנחשת זוכה לשבחים על הטון שלה — עד שלקוח עומד בשדה תעופה.
הדירקטוריון ביקש "אסטרטגיית AI". השוק נתן להם סיבה להיכנס לפאניקה.
אתאר את התמונה, כי אם אתם מנהלים מוצר בחברת ניהול נסיעות או ב-OTA, אתם חיים את זה עכשיו.
בין פברואר לאפריל 2026, כל שכבת הפצה מרכזית בעולם הנסיעות השיקה או הכריזה על הזמנה מבוססת סוכנים. Sabre, PayPal ו-Mindtrip הכריזו על חוויית ה-agentic מקצה לקצה הראשונה בתעשייה ב-12 בפברואר — טיסות שיהיו זמינות באופן כללי ברבעון השני של 2026, הרצות על ממשקי ה-Mosaic של Sabre ביותר מ-420 חברות תעופה ושני מיליון מלונות, עם בסיס הידע של Mindtrip בן 6.5 מיליון הנקודות מעליהם. יום קודם לכן, המנכ"ל של Marriott אישר שמצב ה-AI של Google יזמין ישירות ב-Marriott, תוך עקיפה מוחלטת של ערוץ ה-OTA. Amadeus הכניסה עוזר גנרטיבי בשם Cytric Easy לתוך Microsoft Teams, שנבנה עם Accenture. Navan ממשיכה לדווח על מספרים שגורמים לכל TMC מהדור הישן להיראות איטית.
אז ה-CFO נכנס לחדר ושואל למה אתם לא "עושים משהו עם AI כמו Navan". והנה המלכודת שראיתי צוותים חכמים נופלים לתוכה: הם שומעים את השאלה הזו כהשקה מהירה של צ'אטבוט, בעוד שהשאלה האמיתית — היחידה שחשובה — היא איך אנחנו עושים את זה בלי להיכוות כמו Air Canada.
הקונים שאני מדבר איתם לא שואלים אם לעשות הזמנה מבוססת סוכנים. הוויכוח הזה הסתיים. הם שואלים איך לעשות זאת בלי להמר על החברה כולה על המלאי של פלטפורמה אחת, ובלי מכונה שטועה בביטחון עצמי ויוצרת חבות שהם עצמם יצטרכו לתת עליה את הדין.
לחבות כבר יש שם, והצוות המשפטי שלכם מכיר אותו
אם אתם רוצים להבין למה יועצים משפטיים בתחום הנסיעות עצבניים, אתם צריכים רק תיק אחד.
ב-14 בפברואר 2024, בית הדין לפתרון סכסוכים אזרחיים של קולומביה הבריטית הורה ל-Air Canada לשלם ל-Jake Moffatt סכום של $812.02 לאחר שהצ'אטבוט שלה המציא מדיניות תעריף אבל רטרואקטיבית שסתרה את כללי התעריפים האמיתיים של חברת התעופה. הגנתה של Air Canada הייתה שהצ'אטבוט הוא, למעשה, ישות משפטית נפרדת האחראית להצהרותיה שלה. בית הדין דחה זאת במילים ברורות: חברה אחראית לכל מה שמופיע על המשטחים שלה, בין אם המילים מגיעות מדף אינטרנט סטטי ובין אם ממודל.
שמונה מאות ושתים עשרה דולר הם טעות עיגול. התקדים אינו כך. כל מזכר משפטי בתחום טכנולוגיית הנסיעות שנכתב מאז מצטט את Moffatt, ופסיקה עדכנית יותר נטתה דווקא לכיוון ההפוך מבלי לעזור כלל למטמיעים — בינואר 2026 בית משפט בהאנגז'ואו צמצם, כשמדובר ב-LLM, את חבותו של ספק כאשר משתמש ניסה לאכוף הבטחה של צ'אטבוט. בקריאה משותפת, שני התיקים מצביעים לאותו כיוון לא נוח: חובת הזהירות נופלת על מותג הנסיעות, ולא על ספק המודל. אי אפשר להעביר את האשמה במיקור חוץ ל-OpenAI.
וזה לא רק כסף. ב-2025, תיירים צעדו לגובה 4,000 מטרים בהרי האנדים של פרו בחיפוש אחר "הקניון הקדוש של Humantay", מקום שמתכנן AI המציא מהיסוד. זוג מלזי נסע 400 קילומטרים כדי לרכוב על "Kuak Skyride" שאינו קיים. כפר טסמני בן 33 תושבים החל לקבל שיחות טלפון על מעיינות חמים שמעולם לא היו לו. ISO 31030, תקן ניהול סיכוני הנסיעות, מטיל את בטיחות הנוסע כחובתו של המטמיע — התקריות הללו הן בדיוק מה שהוא נועד למנוע. כאשר כרבע מהתיירים משתמשים כעת ב-AI כדי לתכנן טיולים, רדיוס הפגיעה חדל מלהיות תיאורטי כבר לפני זמן מה.
במה טעיתי: חשבתי שזו בעיה של פרומפט
הנה החלק שאני לא גאה בו.
הבנייה הראשונה שלנו הייתה, בכנות, מעטפת נאה למראה. מודל מוכשר, פרומפט מערכת מהונדס היטב, אחזור על פני קטלוג מלונות, ממשק צ'אט נקי. הוא הודגם היטב — טוב מספיק כדי שתפסתי את עצמי מאמין שההזיות הן מקרה קצה שנסחט החוצה עם פרומפטים טובים יותר ואינדקס אחזור גדול יותר. משקיע באותה תקופה אמר לי, פחות או יותר, פשוט להשתמש ב-GPT ולהפסיק לחשוב על זה יותר מדי. במשך כחודש חצי האמנתי לו.
רגע Tabacon Springs הוא מה ששבר את האמונה הזו, אבל הדבר שבאמת שינה את דעתי היה לשבת ולעשות את החשבון שממנו נמנעתי.
הזמנת טיסה ריאלית כוללת כעשרה שלבים עוקבים: פענוח כוונה, חיפוש, סינון, תמחור, שמירה זמנית, בדיקת מדיניות, איסוף פרטי הנוסע, העברה לתשלום, ביצוע ה-PNR, הנפקת כרטיס. נניח — בנדיבות — שכל שלב הוא קריאה למודל הסתברותי שנכונה ב-90% מהזמן. מקצה לקצה, שיעור ההצלחה שלכם הוא 0.9 בחזקת עשר. בערך 34%.
אי אפשר לפתור באמצעות פרומפטים כשל סטוכסטי מצטבר. השגיאה לא קטנה ככל שמוסיפים שלבים. היא מוכפלת.
ואז מצאתי את המספר שסיים את הוויכוח הפנימי. מבחן ה-TravelPlanner של קבוצת OSU NLP מדד את GPT-4, בעזרת דפוס ה-ReAct הפופולרי, כשהוא משלים מסלולים רב-יומיים ריאליים בשיעור של 0.6%. לא 60%. אפס נקודה שש. שישה טיולים מוצלחים מתוך אלף.
אנשים מנפנפים במספר של "97%" מאותו מבחן, ואני רוצה לדייק כאן כי לשאול אותו היה גורם לנו להיראות או לא כנים או תמימים: אותם 97% מגיעים מפותר מבוסס-קוד שרץ מול בסיס ידע סטטי וקפוא — תמונות מצב של OpenFlights ו-Yelp — לא מודל שמזמין מול מלאי חי ומשתנה. זה אינו מספר הזמנות בסביבת ייצור, וכל מי שמצטט אותו ככזה לא קרא את המאמר. המספר הכן עבור LLM שמניע את כל התהליך הוא המספר הקטן.
זו הייתה נקודת המפנה. הבעיה מעולם לא הייתה הפרומפט. הבעיה הייתה שהכנסנו מודל הסתברותי לזרימת הבקרה בכלל.
איך עוצרים AI מלהזמין מלון שאינו קיים?
ברגע שהפסקתי לנסות להפוך את המודל לאמין יותר והתחלתי לנסות להסיר אותו מהחלקים שחייבים להיות אמינים, הארכיטקטורה כמעט עיצבה את עצמה.
הכלל שהתייצבנו עליו: מודל השפה עושה שפה, ותו לא. הוא מחלץ את מה שנוסע מתכוון אליו ומסכם את התוצאות בחזרה באנגלית פשוטה. הוא אינו קורא ל-GDS. הוא אינו בודק מדיניות. הוא אינו נוגע בתשלום. כל אחד מאלה הוא לוגיקה דטרמיניסטית מקודדת קשיח. אנחנו מריצים את התזמור כמכונת מצבים — LangGraph היא מישור הבקרה הרגיל שלנו, אף שאיננו דוגמטיים בנוגע לכך; אם לקוח נשען על AWS Bedrock AgentCore או Vertex AI Agent Builder, אנחנו בונים שם במקום זאת.
הפרט שחשוב יותר מהמסגרת הוא המצב המוקלד (typed state). רוב פריסות סוכני הייצור שראיתי מתות באותו מוות שקט: המצב נסחף בשקט בין שלבים, אף אחד לא שם לב, והסוכן פועל בביטחון על בסיס תמונת עולם משובשת. סכימת מצב מוקלדת קפדנית מסוג Pydantic — כל שדה מוצהר, מאומת בכל מעבר — היא הדבר הלא זוהר שמונע זאת. כאשר הזמנה חייבת להשתרע על פני מספר commits, דפוס saga מטפל בביטול (rollback): אם המלון נכשל לאחר שהטיסה כבר הונפקה, הגרף יודע כיצד לבטל ולפרק במקום להשאיר נוסע מוזמן למחצה.
בנינו זאת כשלוש יכולות, לא כמוצר אחד, כי לא כל קונה זקוק לכל הדבר. יש את סוכן ההזמנות הדטרמיניסטי — הליבה. יש את האימות-כשירות (verification-as-a-service), API עצמאי שכל צוות travel-AI קיים יכול לקרוא לו כדי לשאול "האם המלון הזה אמיתי, האם המחיר הזה עדכני, האם ה-PNR הזה באמת מאושר?" — מעקה בטיחות שיושב לפני מעטפת שכבר השקתם, שהיא תשובה זולה בהרבה כשהמשפטנים מנפנפים ב-Moffatt בוועדת ההיגוי שלכם מאשר לעקור הכול. ויש שכבת מדיניות-ותאימות שמהדרת מדיניות נסיעות ארגונית או את כללי התעריפים של OTA לאילוצים אכיפים, ממכשירת את חובות הזהירות של ISO 31030, ונושאת את דרישות השקיפות של חוק ה-AI של האיחוד האירופי. כתבנו כיצד שלושתם משתלבים יחד בעמוד הפתרון של העבודה הזו.
אכיפת מדיניות חייבת להיות קוד, לא פרומפט. פרומפטים נסחפים בין גרסאות מודל. לכללים עסקיים אסור להיסחף.
המספר שאף אחד לא שם על שקופית המכירה
אם יכולתי לגרום לכל צוות נסיעות להפנים דבר אחד לפני שהם משיקים, זו לא הייתה ההזיה. זו הייתה הכלכלה של החיפוש.
ספקי GDS לא מחייבים לפי הזמנה. הם מחייבים לפי חיפוש מקטע, בדרך כלל $3 עד $3.50 בתוספת עמלה של כ-10%, והם אוכפים יחסי look-to-book שמענישים אתכם על חיפושים ספקולטיביים. קבוצת Lufthansa העלתה שוב את דמי ההזמנה שלה ב-GDS, החל מ-1 בינואר 2026, ברחבי Amadeus, Sabre ו-Travelport. עכשיו דמיינו סוכן ש"בעזרה" מריץ ארבעה חיפושים חקרניים בכל תור שיחה כי המודל החליט להיות יסודי. על מרווח סוחר של 3 עד 5% של OTA, אותו סוכן ישרוף את רווח הרבעון על צ'אטבוט שמעולם לא מזמין דבר בפועל.
זו השורה הכי מוזנחת בכל הדגמת agentic-travel שישבתי בה, וזו בדיוק הסיבה שההדגמות הללו לא שורדות מגע עם הייצור. סוכן דטרמיניסטי מגביל ומאחסן במטמון חיפושים כי שכבת התזמור — לא מצב הרוח של המודל — מחליטה מתי חיפוש שווה את העמלה שלו.
ולגבי TMC, הכלכלה הזו קשורה ישירות למספר שה-CFO באמת רודף אחריו. המדד שהבנייה הזו מזיזה הוא אחוז ההזמנות ללא מגע וזמן הטיפול בתור הלא-מקוון שעומד מאחוריו. כל הזמנה מהוזה או בלתי ניתנת לשירות היא כרטיס שנופל בחזרה לסוכן אנושי — וזו העלות שמצביעים עליה כשמישהו בחדר אומר "עשו משהו עם AI כמו Navan".
למה אי אפשר פשוט לבנות את זה על ה-API של Amadeus?
כמה מציאויות שנאלצתי ללמוד בדרך היקרה, ושאני מעלה כעת כבר בשיחת הגילוי הראשונה כדי שאף אחד לא יופתע בחודש השלישי.
אם אתם TMC שמתכנן "פשוט לבנות על ה-API של Amadeus", בדקו איזה מפתח יש לכם. שכבת ה-Self-Service Production של Amadeus, באופן ספציפי, מחריגה את נקודת הקצה Flight Create Orders — היא, בניסוח שלהם עצמם, מיועדת לעסקים ללא הסמכת סוכנות נסיעות. כדי להנפיק הזמנות בפועל אתם צריכים Enterprise. ראיתי את סעיף היחיד הזה מאפס מפת דרכים ברבעון שלם.
ואז יש את התפר שכולם מתייחסים אליו כפתור והוא לא: NDC מול GDS. New Distribution Capability מצוינת עבור ההצעה וההזמנה הראשונית, אבל שירות שלאחר-הזמנה — החלפות, החזרים, הזמנה מחדש בתפעול חריג — עדיין רץ על תשתית GDS גם כשהמכירה המקורית הייתה NDC. סוכן ייצור זקוק לשני הצינורות, לא בחירה בינארית ביניהם. וגם NDC עצמו אינו דבר אחד: ניהול הזמנות ברמה 4 דרך אגרגטור כמו Verteil או Duffel הוא אינטגרציה שונה מהקנייה ברמה 3 שבה רוב המעטפות עוצרות. IROPS הוא המקום שבו הפער הופך ממשי — אירוע מזג אוויר יחיד יכול להתקיע נוסעים במטוסים שלמים, כשכל אחד עולה $500 עד $2,000 להזמנה מחדש. סוכן שיכול לחפש אבל לא לתת שירות הוא צעצוע.
ואם העיצוב שלכם כולל סוכן שמנפיק כרטיסים ישירות במקום לנתב למערכת מארחת, אתם כעת בטריטוריית הסמכה — ARC בארה"ב, שאורך כ-25 יום ברגע שהתנאים המקדימים מתקיימים, או הסמכת IATA מלאה, שיכולה לקחת שישה עד שנים עשר חודשים. יש גם מלכודת תשלום: ברגע שממשק צ'אט אוסף נתוני כרטיס, משכתם את כל הערימה שלכם לתחולת PCI. מסחר מבוסס-סוכנים כיום עדיין מוסר את האישור בפועל לשלב תשלום אנושי, כשטוקניזציה דרך ספק כמו VGS או Checkout.com שומרת את נתוני הכרטיס מחוץ לסביבה שלכם.
שום דבר מזה אינו בנאום המרכזי. כל זה נמצא בדוח תקריות הייצור.
"למה שלא פשוט לקנות את של Sabre, או Cytric, או Navan?"
אנשים שואלים אותי את זה כל הזמן, והתשובה הכנה שלי מפתיעה אותם: לפעמים כדאי לכם.
אם אתם OTA לפנאי ששמח להפיץ את המלאי של Sabre על המסילות של Sabre, ערימת Sabre–PayPal–Mindtrip היא קנייה סבירה — כל עוד קיבלתם את ההיצע הנעול ל-Sabre ואת היעדר שכבת מדיניות ארגונית או מכשור ISO 31030. אם אתם ארגון Microsoft-native שכבר על Cytric ו-Concur, Cytric Easy בתוך Teams כנראה נכון עבורכם, ואני אגיד לכם את זה ישירות. אם אתם רוצים לעקור את ה-TMC שלכם לגמרי ולהריץ פלטפורמה AI-native, Navan באמת הרוויחה את המספרים שלה — 73% הוצאות ללא מגע, הפרות מדיניות ירדו מ-35% לפחות מ-5% — ואני לא הולך להעמיד פנים שאנחנו מנצחים אותם במשחק להיות Navan.
אנחנו מתאימים למקרה צר וספציפי יותר: אתם רוצים לשמור על חוזי ה-GDS הקיימים שלכם ועל הקשר שלכם עם ה-TMC ולהוסיף אינטליגנציה מעל הכול, ניטרלית לספק, בלי להפוך למפיץ של מי שממנו קניתם את הסוכן שלכם. זו הבנייה. ואת החלקים שאני לא יכול לעשות, אני אומר בקול — איננו סוכן הנפקה מוסמך IATA/ARC, ולכן ההנפקה עוברת דרך המארח שלכם; איננו הבעלים של הסכמי ה-GDS המסחריים שלכם; ואיננו יכולים לתקן מדיניות נסיעות ארגונית עמומה, אף שנעזור לכם להדק אותה בשלב הגילוי, כי מדיניות עמומה יוצרת סוכן עמום לא משנה כמה הקוד טוב.
המועד האחרון שסוגר את החלון
עוד דבר אחד על השעון. חובות השקיפות של חוק ה-AI של האיחוד האירופי עבור מטמיעים נכנסות לתוקף ב-2 באוגוסט 2026, וההנחיה לסיווג בסיכון גבוה נחתה כבר ב-2 בפברואר 2026. אם הסוכן שלכם מדבר עם צרכנים באיחוד האירופי, הגילוי אינו אופציונלי ו"נוסיף את זה אחר כך" הוא ממצא תאימות שממתין לקרות. אנחנו בונים את משטח הגילוי של סעיף 50 ושובל ביקורת של תיעוד-והסבר מההתחלה, כי התאמה בדיעבד של שקיפות למעטפת קופסה שחורה כואבת הרבה יותר מאשר לתכנן עבורה.
אז לכאן הגעתי אחרי הכול. השטף כעת חינמי — כל מעטפת בשוק נשמעת בטוחה בעצמה, ונוסע לא יכול להבחין בין אישור אמיתי לבין מהוזה על ידי קריאתו. מה שנוסע כן יכול להבחין בו, בסופו של דבר, הוא האם החדר קיים בדלפק הקבלה כשהוא מגיע. הפער הזה — בין משפט שנקרא כאמיתי לבין PNR שהוא אמיתי — לא נסגר כי המודל נהיה גדול יותר. הוא נסגר כי מישהו החליט, לפני ההשקה, שהמודל לעולם לא יהיה הדבר שעונה על "האם זה אמיתי?" השכבה הדטרמיניסטית שעונה על כך אינה זוהרת, היא לא מודגמת טוב כל כך, והיא כל העבודה.
ה-Tabacon Springs Eco-Lodge עדיין אינו מקום אמיתי. השאלה היחידה שחשובה היא האם המערכת שלכם יודעת זאת לפני שהלקוח שלכם עומד בלובי. אם אתם רוצים לראות איך בנינו את שלנו כדי שידע, הפירוט המלא נמצא כאן.
