آیا مرور ابری می‌تواند دشواری‌های اداری ایرلاین‌ها را برای مسافران حل کند؟

تصور کنید پرواز شما سه ساعت تأخیر دارد و طبق قانون اتحادیه اروپا یا بریتانیا مستحق دریافت غرامتی تا سقف ۵۲۰ پوند یا ۶۰۰ یورو هستید، اما به‌دلیل پیچیدگی فرم‌ها، نیاز به مدارک دقیق و قوانین خسته‌کننده، هرگز برای آن اقدام نمی‌کنید. Claimback دقیقاً برای حذف این اصطکاک طراحی شده است. این ابزار یک عامل (Agent) مبتنی بر هوش مصنوعی است که برای مدیریت تمام مراحل تحقیق، استدلال حقوقی و کاغذبازی‌های مورد نیاز برای این ادعاها ساخته شده است.

به نقل از گزارشی در dev.to که در ۱۴ سپتامبر ۲۰۲۶ منتشر شد، این عامل کل زنجیره عملیاتی، از ردیابی لحظه‌ای پرواز تا پر کردن فرم‌های نهایی را به‌طور خودکار مدیریت می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت عامل‌های هوش مصنوعی اشاره کردیم، چالش اصلی در این ابزارها، توازن میان خودکارسازی کامل و کنترل انسانی است تا از خطاهای حقوقی جلوگیری شود. در همین راستا، بحث بر سر مسئولیت قانونی عامل‌های خودمختار در سیستم‌های مالی نشان می‌دهد که تعریف حریم قانونی برای این ابزارها در سطح جهانی همچنان در حال تکامل است.

بسیاری از مسافران به‌دلیل نیاز به زمان دقیق رسیدن به گیت (Gate-arrival times) و درک عمیق از قوانین پیچیده هوانوردی از این کار می‌پرهیزند. برای مثال، پروازی که ۱۷۹.۵ دقیقه تأخیر دارد، به سقف بحرانی سه ساعت نمی‌رسد و مشمول غرامت نمی‌شود. همچنین قوانین بسته به اینکه شرکت هواپیمایی فعال (Operating Carrier) متعلق به اتحادیه اروپا باشد، بریتانیا یا منطقه‌ای دیگر، تغییر می‌کند. Claimback با ایفای نقش یک نماینده دیجیتال (Digital Proxy)، وب را به‌صورت زنده می‌خواند و متون حقوقی را تحلیل می‌کند تا این پیچیدگی‌ها را برطرف کند.

خط لوله بازیابی داده‌ها

این عامل ابتدا با رمزگشایی شناسه‌های پرواز شروع به کار می‌کند. از آنجا که سرویس FlightAware به‌جای شماره پروازهای استاندارد، به کدهای ICAO نیاز دارد، Claimback از ابزار Anakin Wire استفاده می‌کند تا شماره‌ای مانند "AI162" را به کد "AIC162" تبدیل کند. پس از این تبدیل، عامل صفحه FlightAware را اسکرپ کرده تا یک بلوک داده‌ای JSON را استخراج کند که شامل زمان‌های برنامه‌ریزی‌شده و زمان‌های واقعی رسیدن به گیت در ۱۴ روز گذشته است.

برای تضمین حداکثری دقت و جلوگیری از خطاهای احتمالی، عامل این داده‌ها را با منبع دیگری به نام AirHelp تطبیق می‌دهد. در یک مورد آزمایشی برای پرواز AI162 شرکت Air India از لندن هیترو به دهلی در تاریخ ۹ سپتامبر ۲۰۲۶، هر دو منبع تأخیر ۲۰۷ دقیقه‌ای را تأیید کردند. این اعتبارسنجی چندمنبعی (Multi-source verification) مانع از آن می‌شود که عامل تنها به یک نقطه داده تکیه کند که ممکن است اشتباه یا قدیمی باشد.

ظرافت‌های فنی در ردیابی پرواز

بر اساس مستندات توسعه‌دهنده، چندین جزئیات کوچک در فرآیند بازیابی داده‌ها برای دقت حقوقی حیاتی بودند:

• گیت در برابر نشست (Gate vs. Touchdown): قانون به‌طور مشخص تأخیر را در لحظه رسیدن به گیت می‌سنجد، نه در لحظه بلند شدن یا نشستن هواپیما روی باند. Claimback به‌دلیل ثبت دقیق زمان‌های گیت، به FlightAware متکی است.
• خطاهای گرد کردن: در نسخه‌های اولیه، عامل عدد ۱۷۹.۵ دقیقه را به ۱۸۰ گرد می‌کرد که باعث می‌شد به‌طور اشتباه ادعای غرامت ثبت شود. نسخه فعلی دقت سخت‌گیرانه‌ای را برای رعایت دقیق آستانه ۱۸۰ دقیقه اعمال می‌کند. این حساسیت به دقت در محاسبات یادآور اشتباهات کوچک در بازپرداخت‌های مالی است که می‌تواند منجر به چالش‌های جدی در مهندسی پرامپت و خروجی‌های مدل شود.
• منطق کدشیر (Codeshare Logic): در مواردی که مسافر بلیط را از طریق American Airlines رزرو کرده اما پرواز توسط British Airways اجرا می‌شود، قوانین مربوط به شرکت اجراکننده (Operating Carrier) ملاک است. عامل از FlightAware برای شناسایی اپراتور واقعی استفاده می‌کند تا حوزه قضایی (Jurisdiction) درست را اعمال کند.

استدلال حقوقی و حفاظ‌ها

پس از تأیید قطعی تأخیر، عامل تعیین می‌کند که کدام قوانین اعمال می‌شوند. برای پرواز AI162، قانون ۲۶۱/۲۰۰۴ بریتانیا شناسایی شد. عامل مستقیماً ماده ۷ را از وب‌سایت legislation.gov.uk می‌خواند تا مبلغ غرامت را بر اساس مسافت پرواز (که در این مورد ۶۷۳۲ کیلومتر بود) محاسبه کند. همچنین عامل اشاره می‌کند که اگرچه قوانین DGCA هند به‌دلیل ایرانی بودن شرکت Air India اعمال می‌شود، اما این قوانین پرداخت‌های نقدی برای تأخیرها را پیش‌بینی نمی‌کنند.

برای جلوگیری از توهم (Hallucination) — وضعیتی که مدل با اطمینان چیزی را می‌گوید که وجود ندارد — حفاظ‌های (Guardrails) سخت‌گیرانه‌ای تعریف شده است:

• تأیید نقل‌قول‌ها: هر نقل‌قول حقوقی که مدل ارائه می‌دهد، با صفحه منبع تطبیق داده می‌شود. در نسخه‌های اولیه، تنها ۱۲۰ کاراکتر اول مقایسه می‌شد و مدل می‌توانست جملات ساختگی را به جملات واقعی بچسباند. اکنون سیستم کل نقل‌قول را چک می‌کند و در صورت عدم تطابق دقیق، رابط کاربری آن را علامت‌گذاری می‌کند.
• جداول کدگذاری‌شده: عامل از یک جدول داخلی (Hard-coded) برای قوانین EU261، UK261، قوانین کانادا و هند استفاده می‌کند تا ارقام نهایی را تعیین کند. اگر محاسبه مدل با جدول متفاوت باشد، یک هشدار صادر می‌شود. برای پرواز AI162، هر دو منبع بر روی مبلغ ۵۲۰ پوند توافق کردند.
• پرداخت‌های جزئی: سیستم این قانون را می‌شناسد که در پروازهای بالای ۳۵۰۰ کیلومتر، اگر زمان رسیدن بین سه تا چهار ساعت تأخیر باشد، ایرلاین‌ها ممکن است تنها نیمی از غرامت را پرداخت کنند. در نتیجه، Claimback بازه صادقانه ۲۶۰ تا ۵۲۰ پوند را به کاربر ارائه می‌دهد.

خودکارسازی فرم‌های ایرلاین

پیچیده‌ترین مرحله، پر کردن فرم واقعی ادعا است. Claimback از مرورگر ابری Anakin استفاده می‌کند که توسط playwright-core و از طریق پروتکل Chrome DevTools (CDP) هدایت می‌شود. این معماری به عامل اجازه می‌دهد در وب‌سایت‌های نامنظم ایرلاین‌ها که اغلب رویدادهای استاندارد بارگذاری صفحه (Page-load events) را صادر نمی‌کنند، به‌درستی پیمایش کند.

غلبه بر موانع وب

توسعه‌دهنده در هنگام خودکارسازی پورتال Air India با چالش‌های فنی متعددی روبرو شد:

• تایم‌اوت‌های بارگذاری: صفحه فرم Air India هرگز رویداد DOMContentLoaded را در مرورگر ابری صادر نمی‌کرد. توسعه‌دهنده مجبور شد به حالت waitUntil: 'commit' تغییر وضعیت دهد و به‌صورت دستی منتظر ظاهر شدن فیلدهای فرم بماند.
• مثبت‌های کاذب: استراتژی انتظار برای «هر ورودی در صفحه» شکست خورد، زیرا کادر جستجوی هدر سایت مدت‌ها پیش از ظاهر شدن فرم اصلی لود می‌شد.
• مسدودسازی منطقه‌ای: اتصال‌های پیش‌فرض گاهی منجر به صفحات خالی یا نمایش صرفاً گزینه «پذیرش همه کوکی‌ها» می‌شد. اتصال از طریق یک خروجی بریتانیا (country=GB) باعث شد صفحه درست بریتانیا به همراه دکمه «رد کردن همه» (Reject All) باز شود.
• لایه‌های UI: بنرهای کوکی اغلب با تأخیر لود می‌شدند و دکمه Submit را می‌پوشاندند. این امر باعث شد عامل مجبور شود قبل از هر گام، مجدداً وجود بنرها را بررسی کند.

مدل در این مرحله متن قابل مشاهده و لیستی شماره‌گذاری شده از کنترل‌های صفحه را دریافت کرده و سپس دستورات خاصی مانند "fill field 3 with 2100000000" صادر می‌کند.

قفل امنیتی «هرگز ارسال نکن»

به‌دلیل اینکه ارسال یک ادعای حقوقی پیامدهای واقعی دارد، توسعه‌دهنده یک قفل سخت (Hard lock) برای جلوگیری از کلیک AI روی دکمه "Submit" ایجاد کرد. مشخص شد که فیلترهای متنی ساده (Regex) ناکارآمد هستند. تست روی ۱۰ «صفحه تله» نشان داد که ۸ مورد از آن‌ها فیلترهای Regex را دور می‌زنند، از طریق:

• دکمه‌هایی که فقط آیکون دارند و متنی ندارند.
• ورودی‌های مبتنی بر تصویر.
• دکمه‌هایی با برچسب‌های "Claim now" یا "Next".
• منوهای کشویی (Dropdowns) که بلافاصله پس از انتخاب، فرم را ارسال می‌کردند.
• دکمه‌هایی که متنشان تنها پس از وارد کردن داده‌ها از "Next" به "Submit claim" تغییر می‌کرد.

به جای آن، Claimback یک قفل جاوااسکریپت را پیش از اجرای هرگونه اسکریپت ایرلاین در صفحه تزریق می‌کند. این قفل متدهای HTMLFormElement.prototype.submit و requestSubmit را بازنویسی (Override) کرده و با استفاده از event.preventDefault() و event.stopImmediatePropagation() تمام رویدادهای ارسال را متوقف می‌کند.

برای جلوگیری از نشت داده‌ها از طریق متدهای غیر فرمی، این قفل توابع fetch ،XMLHttpRequest و sendBeacon را نیز در بر می‌گیرد. هر درخواستی که حاوی شماره تیکت مسافر، کد رزرو یا ایمیل باشد، مسدود می‌شود. هرگونه تلاش برای دور زدن این سیستم شمارش شده و عامل آن را به‌عنوان پایان فرآیند تلقی می‌کند.

عملکرد مدل و خروجی

تست‌ها شکاف قابل‌توجهی را بین سطوح مختلف مدل‌ها نشان داد. بک‌اند سیستم از Node و Express استفاده می‌کند و OpenAI موتور استدلال اصلی و Gemini به‌عنوان جایگزین (Fallback) است. در حالی که مدل gpt-4.1-nano به‌دلیل جداول کدگذاری‌شده توانست مبلغ را درست محاسبه کند، اما در دستورات پایه شکست خورد؛ مثلاً نام کامل را در کادر نام خانوادگی نوشت، پیشوند شماره تیکت را دو بار تکرار کرد و به‌طور توهم‌آمیز ادعا کرد که «هوای بد» علت تأخیر بوده است (بر اساس مقاله‌ای غیرمرتبط درباره مه در دهلی).

در مقابل، مدل gpt-5-mini فرم را به‌طور تمیز مدیریت کرد، منوهای کشویی غیرفعال را نادیده گرفت و پیشوندهای تیکت را به‌درستی تجزیه کرد. این موضوع تأیید می‌کند که اگرچه حفاظ‌ها برای داده‌های قابل بررسی (مانند مبالغ) کاربرد دارند، اما برای دنبال کردن دقیق دستورات (Instruction Following)، همچنان به مدل‌های سطح بالا نیاز است.

در نهایت، عامل یک نامه رسمی شامل جزئیات پرواز، زمان‌ها، قانون مربوطه و مبلغ غرامت تولید می‌کند. این نامه به‌عنوان پشتیبان برای فرم‌هایی که توسط CAPTCHA محافظت شده‌اند یا برای مسافرانی که ارتباط ایمیلی را ترجیح می‌دهند، عمل می‌کند. کل این فرآیند بین ۲ تا ۵ دقیقه زمان می‌برد و تقریباً ۱۴ اعتبار Anakin مصرف می‌کند.

این پروژه نشان‌دهنده تغییر رویکرد به سمت عامل‌های «با قابلیت اطمینان بالا» (High-reliability agents) است. با ترکیب انعطاف‌پذیری LLMها با جداول اعتبارسنجی سخت و قفل‌های امنیتی در سطح مرورگر، سیستمی ایجاد شده است که زحمت ادعا را می‌کشد بدون اینکه ریسک حقوقی ارسال نهایی را بپذیرد.

برای علاقه‌مندان به معماری این سیستم، کد منبع کامل در گیت‌هاب در دسترس است، از جمله مجموعه‌ای از ۵۸ تست آفلاین که فرم‌های ایرلاین و داده‌های پرواز را با نسخه‌های شبیه‌سازی شده Anakin و FlightAware بازسازی می‌کنند.

با تماشای اجرای ضبط‌شده این عامل، می‌توانید ببینید که چگونه پورتال Air India را گام‌به‌گام پیمایش می‌کند. لازم به ذکر است که Claimback توصیه حقوقی نیست؛ بلکه صرفاً تحقیق و کاغذبازی‌ها را خودکار می‌کند و کلیک نهایی را بر عهده کاربر می‌گذارد.

گام بعدی شما

• اگر مسافر هستید، قوانین EU261 و UK261 را بررسی کنید تا بدانید در چه شرایطی مستحق غرامت هستید.
• توسعه‌دهندگان می‌توانند برای پیاده‌سازی عامل‌های با قابلیت اطمینان بالا، از ترکیب جداول داده سخت (Hard-coded) و مدل‌های زبانی استفاده کنند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.