در سپتامبر گذشته، قطعی‌های متوالی در سرویس‌های ChatGPT، Claude و Grok نشان داد که حتی پیشرفته‌ترین زیرساخت‌های هوش مصنوعی نیز در برابر خطا آسیب‌پذیر هستند. در حالی که اکثر تحلیل‌ها بر روی عدم دسترسی کاربران به ابزارهای کدنویسی و پژوهشی تمرکز کردند، مسئله حیاتی برای مدیران امنیت (CISO) و رهبران فنی، میزان وابستگی گردش‌کارهای سازمانی به این سرویس‌ها و نبود مسیرهای جایگزین در زمان قطعی است.
تضاد در شکست: توقف ناخواسته در برابر توقف ناممکن
دو روی سکه شکست در سیستم‌های AI وجود دارد: نخست، زمانی که سیستم در لحظه نیاز متوقف می‌شود و دوم، زمانی که سیستم در حالی که باید متوقف شود، به فعالیت ادامه می‌دهد. حادثه زیرساختی Hugging Face نمونه بارز مورد دوم بود؛ جایی که عامل‌های ارزیابی (Evaluation Agents) به دلیل نقص در سیستم هشدار و قابلیت بازسازی خودکار (Self-respawning)، حدود دو روز و نیم فعال ماندند و حذف Podها به تنهایی نتوانست آن‌ها را متوقف کند.
پاسخ رایج صنعت به این چالش، ایجاد یک «کلید قطع» (Kill Switch) یا ترمز اضطراری است تا انسان بتواند در هر لحظه اجرای مدل را متوقف کند. اما این رویکرد تنها نیمی از راه است؛ زیرا بحث‌ها معمولاً در لحظه فشار دادن کلید متوقف می‌شوند و به این پرسش پاسخ نمی‌دهند که: «پس از قطع سیستم، چه چیزی جایگزین آن می‌شود؟»
هزینه بالای توقف: چرا کلید قطع زده نمی‌شود؟
در محیط‌های سازمانی، توقف یک Agent که در یک فرآیند حیاتی (مانند تایید فاکتورها در سیستم ERP) قرار دارد، هزینه‌بر است. اگر یک تیم امنیتی متوجه رفتار غیرعادی AI شود، اما هیچ طرح جایگزینی برای مدیریت هزاران درخواست در صف نباشد، مدیریت کسب‌وکار احتمالاً از قطع سیستم جلوگیری می‌کند تا عملیات متوقف نشود. در این حالت، تردید در تصمیم‌گیری، فرصتی را برای Agentهایی که با سرعت ماشین عمل می‌کنند فراهم می‌کند تا خسارات بیشتری وارد کنند.
اصول طراحی سیستم‌های جایگزین (Fallback Systems)
برای اینکه فشار دادن کلید قطع «ارزان» و بدون ریسک باشد، باید پیش از طراحی مسیر AI، مسیر غیر-AI (Fallback Path) طراحی شود. این سیستم جایگزین باید چهار اصل اساسی را رعایت کند:
- یادگیری از سیستم اصلی: طرح جایگزین نباید استاتیک باشد. دستورالعمل‌های عملیاتی (Runbooks) باید به‌طور مداوم بر اساس تصمیمات فعلی Agent به‌روزرسانی شوند تا فاصله بین حالت عادی و حالت جایگزین از بین برود.
- استفاده از قرارداد یکسان: سیستم جایگزین باید از همان API سیستم اصلی پاسخ دهد تا سیستم‌های بالادستی نیازی به تغییر نحوه فراخوانی سرویس نداشته باشند.
- عملکرد در حالت کاهش‌یافته (Degraded Mode): در حالت جایگزین، لایه‌های سیاست‌گذاری (Policy Layer) باید سخت‌گیرانه‌تر شوند. برای مثال، سقف تاییدات مالی کاهش یابد و نیاز به تایید انسانی افزایش یابد.
- اثبات کارایی پیش از بهره‌برداری: هیچ سیستم جایگزینی که تست نشده باشد، قابل اعتماد نیست. دقت سیستم Fallback باید پیش از عملیاتی شدن، با معیارهای پذیرفته‌شده تطبیق داده شود.
چک‌لیست استقرار امن Agentها
پیش از عملیاتی کردن هر Agent در محیط کسب‌وکار، بررسی موارد زیر ضروری است:
- تعریف وضعیت خاموش (Off-state): مشخص شود که کارهای در جریان و صف‌های انتظار هنگام توقف Agent چگونه مدیریت می‌شوند و چه کسی مسئول تایید نهایی است.
- کلید قطع مبتنی بر هویت: به جای تلاش برای کشتن Processها، باید دسترسی‌های Agent (مانند Tokens و Credentials) ابطال شود تا امکان بازسازی خودکار (Respawn) از بین برود.
- نقاط بازرسی (Checkpoints): اقدامات Agent باید به گونه‌ای طراحی شوند که قابل ردیابی باشند و برای هر اقدام، یک عملیات جبرانی (Compensating Action) جهت بازگرداندن وضعیت (Rollback) تعریف شود.
- سیاست‌های سخت‌گیرانه در حالت بحران: محدودیت‌های عملیاتی در زمان اجرای Fallback باید از پیش تعریف و منتشر شده باشند.
- تمرینات انتقال (Handoff Drills): به‌طور برنامه‌ریزی شده و در ساعات کاری، کلید قطع زده شود تا زمان رسیدن به وضعیت امن و میزان انباشت کارهای عقب‌مانده اندازه‌گیری شود.
تاب‌آوری در عصر هوش مصنوعی با دانستن این موضوع آغاز می‌شود که وقتی AI حذف شود، چه اتفاقی می‌افتد. سازمان‌هایی سریع‌تر بازیابی می‌شوند که نه تنها بهترین کلید قطع را دارند، بلکه «وضعیت خاموش» را پیش از هر چیز طراحی کرده‌اند.
