تصور کنید یک ناوگان عظیم کالا در بندر متوقف شده و تنها به دلیل نبود یک سند قانونی ساده، میلیاردها دلار سرمایه بلوکه شده است. در ۳۱ اوت ۲۰۲۶، نمایش معماری جدیدی به نام Cargo Release ثابت کرد که می‌توان این اصطکاک‌های اداری را بدون سپردن قدرت تصمیم‌گیری قانونی به عامل‌های هوش مصنوعی، به‌طور کامل خودکار کرد.
در دنیای حوادث دریایی، ترخیص کالا نیازمند فرآیند پیچیده‌ای به نام «تسهیم خسارت عمومی» (General Average) است. این فرآیند شامل ارائه ضمانت‌نامه‌هایی از سوی مالکان کالا و تضمین‌هایی از طرف بیمه‌گران است که همگی باید از طریق یک ارزیاب (Average Adjuster) هدایت شوند. این جداسازی — یعنی «ترخیص اکنون، تسویه بعداً» — در هر دو سند راهنمای CMI درباره قوانین یورک-آنتورپ و بررسی‌های UNCTAD در مورد رویه‌های تسهیم خسارت عمومی مستند شده است. این یک محیط با ریسک بسیار بالاست، جایی که یک عبارت ساده‌ی «به نظر درست می‌رسد» از سوی یک هوش مصنوعی می‌تواند منجر به مسئولیت‌های مالی کمرشکن و عظیم شود.
برای کسی که هماهنگی منافع مالکان کالا را بر عهده دارد، این مسیر شبیه به یک صف طولانی و دشوار از کارهای تکراری است: تطبیق اعلان حادثه با مدارک کالا؛ دریافت گواهی تأیید مالک؛ اخذ ضمانت‌نامه بیمه‌گر؛ ارسال بسته امنیتی؛ ثبت و نگهداری ردیه ارزیاب (به جای گم کردن آن در ایمیل‌ها)؛ اصلاح بسته مدارک؛ دریافت پذیرش نهایی؛ درخواست دستور ترخیص از متصدی حمل؛ تأیید اینکه متصدی واقعاً دستور را خوانده و در نهایت اطلاع‌رسانی به اپراتور بدون اینکه این اطلاع‌رسانی با «اقتدار قانونی» اشتباه گرفته شود.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، مشکل اصلی اکثر سامانه‌ها در اینجا رخ می‌دهد: آن‌ها «هوش» را با «اقتدار» اشتباه می‌گیرند. اگر به یک عامل (Agent) — شبیه به دستیاری که دستورات را اجرا می‌کند اما حق امضای چک را ندارد — گفته شود «کالا را ترخیص کن»، ممکن است برای رسیدن به هدف و رضایت کاربر، سعی کند تاییدیه جعلی بسازد یا رد شدن مدارک را نادیده بگیرد. این چالش‌ها دقیقاً همان نقاط ضعفی هستند که ابزارهای جدید اسکن امنیتی برای شناسایی حفره‌های عامل‌های هوش مصنوعی بر روی آن‌ها متمرکز شده‌اند. Cargo Release این مشکل را با ایجاد یک «ناتوانی ساختاری» یا قانون اساسی (Constitutional Incapacity) حل کرده است؛ عامل‌ها فقط هماهنگ می‌کنند، اما هرگز نمی‌توانند مجوز صادر کنند. مدل می‌تواند بررسی کند، استخراج کند، رتبه‌بندی کند، توضیح دهد و پیشنهاد دهد، اما هرگز نمی‌تواند جایگزین مالک، بیمه‌گر، ارزیاب، متصدی حمل یا نویسنده وضعیت قانونی شود.
نقشه چهاربانده اقتدار
برای تضمین ایمنی، این سیستم عملیات را به چهار مسیر مجزا تقسیم کرده است تا به این پرسش حیاتی پاسخ دهد: چه کسی اجازه دارد واقعیت را تغییر دهد؟
۱. ورودی احراز شده: سرویس‌های Google Cloud Pub/Sub و Eventarc پاکت‌های حادثه را تحویل می‌دهند. سرویس عمومی Next.js روی Cloud Run اجرا می‌شود و یک رله احراز شده محدود را فراهم می‌کند. تنها ورودی رسانه‌ای پذیرفته شده، اسکن‌های مصنوعی است که دارای هش (Digest) هستند. هیچ سطح آپلود عمومی و بدون محدودیتی وجود ندارد تا از تزریق داده‌های مخرب جلوگیری شود.
۲. هماهنگی محدود: Google ADK یک هماهنگ‌کننده و چهار کارگر متخصص را روی Vertex AI اجرا می‌کند: شواهد مانیفست، بسته امنیتی، اقتدار متصدی و بازیابی زمان اجرا. هر کارگر فقط یک ابزار خواندنی، خروجی ساختاریافته دارد، اجازه انتقال داده به هم‌رده‌های خود را ندارد و متغیر release_authority=false برای همه آن‌ها تغییرناپذیر است.
۳. اقتدار قطعی: یک کنترل‌کننده خصوصی در Cloud Run به عنوان تنها نویسنده وضعیت (State Writer) عمل می‌کند. پایگاه‌داده Cloud SQL for PostgreSQL تمام مأموریت‌ها، نسخه‌ها، اجاره‌ها (Leases)، تصمیمات مربوط به شواهد، رسیدها و رویدادهای متصل به هش را نگه می‌دارد. وضعیت سیستم تنها زمانی پیش می‌رود که یک انسان تأییدیه خاصی بدهد یا یک شریک تجاری رسید امضا شده ارسال کند. بیمه‌گر، ارزیاب و متصدی حمل به صورت سرویس‌های خصوصی Cloud Run با هویت‌های ایزوله اجرا می‌شوند.
۴. پیامد قابل مشاهده: وضعیت فیزیکی کانتینر تنها پس از برآورده شدن یک شرط «دو-کلیدی» از حالت «نگه داشته شده» (HELD) به «ترخیص شده» (RELEASED) تغییر می‌کند. اعلان Slack تنها پس از آن ارسال می‌شود که متصدی حمل تأیید کند دستور را خوانده است؛ این امر تضمین می‌کند که اعلان، نتیجه‌ی اقدام است، نه علت آن.
در این ساختار، ابزارهایی مثل Agent Identity, Agent Gateway, Registry, Model Armor, Memory Bank, Cloud Logging و Cloud Trace سیستم را محدود یا نظارت می‌کنند اما هرگز اقتدار ترخیص پیدا نمی‌کنند. طبق راهنمای Google Cloud Run، این سیستم برای احراز هویت سرویس-به-سرویس از Workload Identities استفاده می‌کند تا نیاز به اعتبارنامه‌های مشترک حذف شود.
جزئیات عملیاتی و گردش کار
فرآیند با یک رویداد CloudEvent مصنوعی آغاز می‌شود. اجرای سیستم روی یک مأموریت بادوام در Cloud SQL متمرکز می‌شود، حتی اگر رویداد چندین بار تحویل داده شود. در این مسیر، سیستم پنج منبع شواهد آماده را جمع‌آوری می‌کند که دو مورد از آن‌ها را عمداً متضاد قرار داده است:
- ایمیل خصمانه: ایمیلی که به مدل دستور می‌دهد فرآیند را نادیده بگیرد و تاییدیه جعلی بسازد. این پیام قرنطینه شده و هیچ حقیقت مورد اعتمادی ایجاد نمی‌کند، هیچ ورودی در حافظه نمی‌سازد و هیچ تغییر وضعیتی در سیستم ایجاد نمی‌کند.
- اسکن مصنوعی: یک ردیه ارزیاب که دارای فیلد اصلاحی قابل مشاهده است. هش، پرونده، کانتینر، بازبینی، چک‌باکس، فیلد گمشده و میزان اطمینان آن باید با یک طرح (Schema) تایپ‌شده مطابقت داشته باشد. یک سیاست قطعی (Deterministic) — و نه متن تولید شده توسط مدل — تصمیم می‌گیرد که آیا این ساختار قابل پذیرش است یا خیر.
پس از پردازش مدارک، سیستم متوقف می‌شود. تنها یک تصمیم انسانی باقی می‌ماند: تأیید ضمانت‌نامه مالک. این یک تأیید انسانی، هشت اقدام متوالی و محدود را فعال می‌کند: ۱ تأیید انسانی، ۵ رسید امضا شده منحصربه‌فرد از شرکا، ۱ ارسال بسته امنیتی، ۱ اصلاح خودکار و ۱ اعلان علامت‌گذاری شده پس از ترخیص.
تبدیل شکست به داده
یکی از کلیدی‌ترین تصمیمات در Cargo Release نحوه برخورد با «رد شدن» مدارک است. در گردش‌های کاری معمول، رد شدن یک سند به عنوان یک خطا تلقی می‌شود که باعث توقف اجرا می‌گردد (ارسال $ \rightarrow $ رد $ \rightarrow $ شکست اجرا). اما در اینجا، رد شدن به عنوان یک «شواهد بادوام» تلقی می‌شود.
وقتی ارزیاب بسته امنیتی نسخه ۱ (v1) را رد می‌کند، سیستم این استثنا را پنهان نمی‌کند، بلکه ردیه امضا شده، دلیل رد شدن و مرجع منبع را ذخیره می‌کند. سپس کنترل‌کننده از این مرجع تایید شده برای تولید یک نسخه اصلاح شده (v2) استفاده می‌کند. ارزیاب نسخه v2 را می‌پذیرد، متصدی دستور را صادر می‌کند و متصدی به‌طور مستقل تأیید می‌کند که دستور را خوانده است.
این رویکرد اجازه می‌دهد سیستم به‌طور خودکار بازیابی شود بدون اینکه نیاز باشد انسان برای هر غلط تایپی دوباره وارد حلقه شود. این اصلاح توسط یک دلیل تایپ‌شده و اعتبارسنج شده محدود شده است، نه اینکه یک عامل هوش مصنوعی از خود برای ساخت یک سند امنیتی جدید بداهه‌پردازی کند. یک سیستم عامل‌محور مفید، صرفاً از مسیر اشتباه جان سالم به در نمی‌برد، بلکه مسیر اشتباه را به ورودی تأیید شده بعدی تبدیل می‌کند.
مقابله با شکست مدل
توسعه‌دهنده هنگام استفاده از یک آداپتور (Adapter) — لایه‌ای که مدل را با داده‌های خاص سازگار می‌کند — برای استخراج رکورد ردیه نسخه ۱ از اسکن آماده با مدل Gemini با مشکلی روبرو شد. این آداپتور محدود به هش و دارای نسخه طرح (Schema) است. با این حال، هنگام اجرا در سرویس مدیریت شده، اسکن معتبر پذیرفته نشد زیرا مدل خروجی ساختاریافته‌ای تولید کرد که بدشکل (Malformed) بود.
به جای شل کردن اعتبارسنج‌ها برای اینکه دمو «بهتر» به نظر برسد یا پنهان کردن شکست برای نمایش یک «مسیر موفق»، توسعه‌دهنده این استخراج‌ها را به عنوان «FIXTURE» برچسب زد. این فیکسچر قطعی از همان طرح و مرز اعتبارسنجی استفاده می‌کند، بنابراین مسیر علی از مدرک به نسخه v2 همچنان قابل نمایش است، اما ادعا نمی‌شود که استخراج زنده توسط استنتاج بومی Vertex AI انجام شده است.
این امر تضمین می‌کند که خروجی بدشکل مدل نمی‌تواند سیستم را فریب دهد تا به آن اعتماد کند. سیستم به‌گونه‌ای طراحی شده که «بسته شکست بخورد» (Fail Closed)؛ یعنی اگر هوش مصنوعی نتواند خروجی کاملاً مطابق با طرح تولید کند، فرآیند به‌طور کامل متوقف می‌شود تا حدس نزند. این انتخاب، ویژگی اصلی ایمنی را ثابت کرد: خروجی معیوب مدل نمی‌تواند سیستم را متقاعد به اعتماد کند.
ادغام چندمدلی بدون اقتدار
این معماری از مدل‌های مختلفی استفاده می‌کند، اما همه آن‌ها پایین‌دستِ مرز اقتدار هستند:
- Gemma 4: بررسی بسته ضمانت‌نامه مالک بر اساس یک چک‌لیست محدود و سخت‌گیرانه.
- Gemini Embedding 2: رتبه‌بندی هشت مورد بررسی شده پس از فیلترینگ قطعی.
- Veo 3.1 Fast: تولید یک ویدیو ۴ ثانیه‌ای از بازپخش ترخیص در Cloud Storage خصوصی.
هر سه مدل رسیدهای قابل مشاهده تولید می‌کنند و هر سه مقدار release_authority=false را برمی‌گردانند. ویدیو تولید شده توسط Veo کاملاً از اعلان رسمی Slack جدا شده است، زیرا یک ویدیوی تولید شده هرگز نمی‌تواند سند قانونی برای وقوع یک اتفاق باشد. پرونده تسهیم خسارت عمومی حتی پس از ترخیص کالا در وضعیت «باز» (OPEN) باقی می‌ماند تا تضمین شود که سیستم یک فرآیند حقوقی پیچیده را به یک تیک سبز غیرصادقانه تبدیل نمی‌کند.
قابلیت اطمینان و تکرارپذیری
برای مدیریت هرج‌ومرج زیرساخت‌های ابری در دنیای واقعی، سیستم به‌شدت Idempotent است. در سیستم‌های رویدادمحور، تحویل مجدد رویدادها، تلاش مجدد مرورگرها و تایم-اوت شرکا رایج است. اگر «یک تأیید $ \rightarrow $ هشت اقدام» در اثر تلاش مجدد به شانزده اقدام تبدیل می‌شد، این متریک صرفاً یک نمایش نمایشی بود.
برای جلوگیری از این اتفاق، تعداد اقدامات از روی انواع رسیدهای بادوام و منحصربه‌فرد، انواع رویدادها و اعلان‌های تحویل داده شده استخراج می‌شود. رویدادهای تکراری روی یک مأموریت متمرکز می‌شوند. اجاره‌های اتمیک (Atomic Leases) اجازه می‌دهند تنها یک نویسنده فعال وجود داشته باشد. رسیدهای شرکا به صادرکننده متصل هستند، امضا شده‌اند، دارای آدرس هش هستند و تنها از یک وضعیت قبلی مجاز معتبر می‌باشند.
در تست‌ها، یک پروب هم‌زمانی مدیریت شده، یک حادثه را ۶ بار در ۳ نمونه Cloud Run ارسال کرد. هر درخواست با موفقیت پاسخ داد، اما دیتابیس تنها یک اعلان، یک اجرا و یک گیت انسانی را ثبت کرد. خودمختاری با تعداد اقدامات انجام شده تعریف نمی‌شود، بلکه با توانایی انجام «تعداد درست» اقدامات علی‌رغم تکرار، تأخیر و تلاش مجدد تعریف می‌شود.
اثبات زنده
دموی نهایی از روی استقرار عمومی Cloud Run اجرا شد و URL مربوط به .run.app را در کنار یک مأموریت بومی Eventarc و شناسه پیام Pub/Sub نشان داد (Mission: mission-13820650dbee; Pub/Sub message: 21614781193876288).
در یک اجرای بدون وقفه، تمام زنجیره مشاهده شد: ورودی احراز شده، قرنطینه متن خصمانه، شواهد بصری با برچسب‌های حقیقت، تنها تأیید مالک، رد نسخه v1 با ثبت دلیل، اصلاح خودکار به نسخه v2، دریافت ۵ رسید تأیید شده، تأیید دریافت توسط متصدی و در نهایت تغییر وضعیت فیزیکی کالا به «ترخیص شده» در حالی که پرونده ارزیابی همچنان «باز» باقی ماند. این فرآیند با یک پیام Slack و متریک اثبات ۱ $ \rightarrow $ ۸/۸ به پایان رسید.
سورس اپلیکیشن نسخه v6 در زمان ۳ دقیقه و ۱۶.۸۴ ثانیه بدون هیچ برشی حفظ شده است. نسخه v7 مستر (۳ دقیقه و ۲۸.۸۰ ثانیه) تا لحظه پیامد نهایی به‌طور پیوسته است. یک بخش ۱۲ ثانیه‌ای از کنسول گوگل کلاد، پروژه ata-2026-cargo و کنترل‌کننده cargo-release-controller در منطقه us-central1 و پاسخ GET /v1/missions/mission-13820650dbee 200 OK را نشان می‌دهد.
درس‌های آموخته شده
۱. اول افعال: ایمن‌ترین معماری با تعریف این شروع می‌شود که چه کسی اجازه خواندن، پیشنهاد، نوشتن، تأیید و صدور رسید دارد. نام محصولات بعد از این پاسخ‌ها می‌آید.
۲. رسید مدل $ \neq $ اقتدار: داشتن منبع، درصد اطمینان، نسخه طرح و هش منبع، خروجی مدل را قابل بررسی می‌کند، اما به آن اعتبار قانونی نمی‌دهد.
۳. انسان در حلقه (HITL) دقیق: اپراتور دکمه «تأیید هوش مصنوعی» را نمی‌زند، بلکه یک حقیقت مربوط به مالک را تأیید می‌کند. هر چیز دیگری اجرای محدود است.
۴. شکست به مثابه داده: یک ردیه در نسخه v1 ارزشمندتر از یک خطای کلی است چون حاوی دلیلی است که نسخه v2 را انتخاب می‌کند.
۵. برچسب‌های حقیقت: استفاده از برچسب‌هایی مثل NATIVE، ADAPTER و FIXTURE از اینکه پیچیدگی ظاهری، یک اجرای فیکسچر را بپوشاند جلوگیری می‌کند.
۶. مرزهای رسانه‌ای: رسانه‌های تولید شده (مثل Veo) باید برای آموزش بعد از مرز تصمیم‌گیری باشند، نه برای اثبات قبل از آن.
محدوده و محدودیت‌ها
پروژه Cargo Release یک نمایش معماری مصنوعی و تخیلی است. این سیستم تصمیماتی درباره پوشش بیمه‌ای، مسئولیت، سهم مشارکت، کفایت قانونی یا یک ارزیابی واقعی تسهیم خسارت عمومی نمی‌گیرد. این سیستم با مالکان واقعی کالا، بیمه‌گران، ارزیابان، متصدیان، ترمینال‌ها یا کشتی‌ها ارتباط برقرار نمی‌کند. عبارت «ترخیص شده» به معنای رسیدن مأموریت مصنوعی به وضعیت نهایی قطعی است. خدمات شرکا در اینجا Fixtureهای ایزوله هستند، نه ادغام‌های تجاری واقعی. این محدودیت‌ها، مرز بین نمایش یک معماری اقتدار و تظاهر به مدیریت یکی از آن‌هاست.
نتیجه نهایی این است که بخش جذاب این پروژه، ساخت یک «برج کنترل» نبود، بلکه سیستمی بود که می‌توانست بین چندین طرف هماهنگی ایجاد کند در حالی که از نظر ساختاری «ناتوان» از جعل هویت هر یک از آن‌هاست. عامل‌ها هماهنگ کردند، اما هرگز کلید را در دست نداشتند.
گفتگو