وقتی مدل اصلی از دسترس خارج می‌شود، سامانه هنوز حق چه کاری دارد؟

دستیار پشتیبانی سیاست بازپرداخت را پیدا می‌کند، اما مدل اصلی دیر پاسخ می‌دهد. مسیریاب، بی‌سروصدا درخواست را به مدل کوچک‌تر می‌فرستد. مدل دوم پاسخی روان می‌نویسد و ابزار بازپرداخت را فرا می‌خواند. داشبورد سبز می‌ماند؛ ولی سامانه‌ای تأییدنشده تصمیم گرفته است.

دسترسی‌پذیری حفظ شده، اما قرارداد عملیاتی شکسته است.

پرسش درست هنگام اختلال این نیست که «آیا مدل پشتیبان داریم؟» باید از پیش معلوم باشد که با کند، کهنه، نامطمئن یا قطع شدن هر وابستگی، کدام کار ادامه پیدا می‌کند، کدام کار کوچک می‌شود، چه چیزی در صف می‌ماند یا به انسان می‌رسد و چه عملی باید کاملاً متوقف شود. پاسخ این پرسش همان قرارداد حالت کم‌توان سامانه است.

پاسخ گرفتن به معنای سالم بودن خدمت نیست

بسیاری از پایش‌ها فقط می‌پرسند فرایند زنده است، نشانی شبکه پاسخ می‌دهد یا زمان پاسخ از آستانه پایین‌تر مانده است. این نشانه‌ها لازم‌اند، اما برای یک قابلیت هوش مصنوعی کافی نیستند. نمایه بازیابی ممکن است ساعت‌ها عقب باشد. پاسخ می‌تواند بدون استناد برسد. موتور سیاست شاید قطع شده باشد. مخزن رویدادهای حسابرسی ممکن است نوشته‌ها را از دست بدهد. حتی مدلی که پاسخ می‌دهد شاید آزمون محافظت‌شده همان روز را رد کرده باشد.

قطع تولید متن لزوماً نباید کل مسیر مشتری را بخواباند. شاید سامانه هنوز هویت را بررسی کند، منبع معتبر را نشان دهد، درخواست را نگه دارد یا مدرک را به کارشناس برساند. هدف، بزرگ‌ترین خدمت مفید و ازپیش‌مجاز است که شواهد، اختیار و پیامدهایش پذیرفته‌اند.

این مسئله با بازیابی پس از حادثه یکی نیست. راهنمای ژرف درباره نقطه سازگار بازیابی می‌پرسد چگونه اجزای سامانه پس از اختلال به یک وضعیت هماهنگ برگردند. این نوشته درباره همان ساعتی است که اختلال ادامه دارد: سامانه در آن ساعت هنوز اجازه انجام چه کاری را دارد؟

منابع معتبر چه چیزی را قطعی می‌کنند؟

هیچ‌یک از منابع رسمی، معماری یگانه‌ای برای جایگزینی مدل تجویز نمی‌کند؛ اما مرزهای تصمیم را روشن می‌کنند.

هسته چارچوب مدیریت ریسک هوش مصنوعی NIST برای خرابی سامانه پرخطر شخص ثالث، برنامه جایگزین، سنجش «خرابی ایمن»، راه غیرهوش‌مصنوعی و سازوکاری با مسئول مشخص برای خاموش‌کردن سامانه منحرف از کاربرد مصوب می‌خواهد. این چارچوب پایش را به توقف، حادثه، بازیابی و تغییر پیوند می‌دهد. نسخه ۱٫۰ در حال بازنگری است؛ استناد ما به متن منتشرشده در تاریخ بازبینی است.

NIST SP 800-34 Rev. 1 که در سال ۲۰۱۰ منتشر شد، مبنای عمومی مفیدی برای برنامه تداوم است: با تحلیل اثر کسب‌وکار، اولویت‌ها و نیازهای بازیابی را تعیین کنید، رویه‌ها را بنویسید و آن‌ها را تمرین کنید. این سند درباره مدل زبانی نیست و هم‌ارزی دو مدل را ثابت نمی‌کند.

راهنمای زیرساخت بعد اجرایی را اضافه می‌کند. اصل کاهش تدریجی خدمت در Google Cloud، با آخرین بازبینی ۳۰ دسامبر ۲۰۲۴، محدودکردن بار، رد زودهنگام درخواست، رسیدگی به خطای جزئی، پایش و آزمون فشار را توصیه می‌کند. راهنمای جاری AWS برای کاهش کنترل‌شده خدمت حفظ کار حیاتی، سادگی مسیر خرابی و آزمون آن را لازم می‌داند. سازگاری تراکنش گاهی از ظاهر همیشه‌در‌دسترس مهم‌تر است.

این‌ها یافته‌های مستندند. طراحی زیر، تحلیل ژرف برای سامانه‌های هوش مصنوعی است؛ جایی که مدل «پشتیبان» ممکن است رفتار، انتخاب ابزار، کیفیت فارسی، طول زمینه، مسیر پردازش داده و سطح خطر را عوض کند.

ابتدا کوچک‌ترین خدمت مفید را نام‌گذاری کنید

از کار کاربر شروع کنید، نه از نام قطعه. «مدل بالا است» تعریف خدمت نیست. «مشتری احراز‌شده می‌تواند قانون جاری بازپرداخت را همراه منبع ببیند» تعریف قابل آزمون است.

هر مسیر مهم را به چهار بخش بشکنید:

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

این جداسازی وابستگی سخت را آشکار می‌کند. گفت‌وگو به مدل نیاز دارد، اما دریافت درخواست نه. نمایش مقدار احراز‌شده شاید بدون مدل ادامه یابد. در مقابل، بدون سیاست جاری، هویت مستأجر یا دفتر اثر بیرونی، اقدام مالی ممکن است هیچ شکل کم‌توان امنی نداشته باشد.

شرط‌های سلامت را روی نقشه بیاورید

فهرست فروشنده‌ها و نشانی‌های شبکه کافی نیست. برای هر قابلیت بنویسید چه شرط‌هایی آن را مجاز می‌کنند:

• هویت، مستأجر و اختیار واگذارشده؛
• داده جاری، نمایه بازیابی و منشأ هر مدرک؛
• نسخه مدل، دستور، تعریف ابزار و سیاست؛
• اعتبارسنجی خروجی، کنترل محتوا و الزام استناد؛
• ظرفیت تأیید و صلاحیت مسئول انسانی؛
• مخازن حسابرسی، جلوگیری از تکرار، تراکنش و تطبیق؛
• منطقه ارائه‌دهنده، مسیر داده، سهمیه و بودجه زمانی؛
• سامانه مرجع و کانالی که اثر بیرونی را اجرا می‌کند.

برای هر پیوند حالت خطا را مشخص کنید: قطع، کند، کهنه، ناقص، ناسازگار، پربار، مخدوش، لغوشده یا بیرون از محدوده آزموده‌شده. «سالم یا ناسالم» کافی نیست؛ نمایه می‌تواند در دسترس اما ۱۸ ساعت عقب باشد و مدل می‌تواند بدون استناد اجباری پاسخ دهد.

سن و کامل‌بودن داده را شرط کنید. نشانی دفتر شاید با زمان ثبت نمایش داده شود؛ دستور توقف پرداخت به تأیید جاری یا بستن مسیر نیاز دارد.

یک چراغ سبز را به بردار قابلیت تبدیل کنید

پروب زیرساخت فقط پرسشی محدود را جواب می‌دهد. مستندات جاری Kubernetes درباره پروب‌ها که ۳۰ ژوئن ۲۰۲۶ اصلاح شده، میان شروع، زنده‌بودن و آمادگی تفکیک می‌کند: فرایند ممکن است زنده باشد اما نباید ترافیک بگیرد. همین تفکیک را یک لایه بالاتر ببرید.

وضعیت هر قابلیت را جدا ثبت کنید:

identity=ready
source_freshness=ready
retrieval=ready
generation=impaired
policy=ready
approval_capacity=constrained
audit_sink=ready
effect_executor=halted

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

برای هر خرابی یک سرنوشت روشن تعیین کنید

پاسخ عملیاتی را به چند گزینه محدود و قابل ثبت تبدیل کنید.

«نسخه ذخیره‌شده را نشان بده»، «مدل کوچک‌تر را صدا بزن» یا «فعلاً این بررسی را رد کن» هنوز تصمیم نیستند؛ فقط سازوکار پیشنهادی‌اند. برای هرکدام باید کار مجاز، کد دلیل، مدرک، پیام کاربر، زمان انقضا و شرط خروج نوشته شود.

راهنمای امتناع سنجیده سامانه در سطح یک ادعا یا اقدام، میان پاسخ، جست‌وجوی مدرک، تحویل و رد انتخاب می‌کند. قرارداد حالت کم‌توان همین منطق را در مقیاس کل خدمت اجرا می‌کند؛ جایی که از دست‌رفتن یک شرط، چندین ادعا و ابزار را هم‌زمان محدود می‌سازد.

مدل جایگزین، نامزد انتشار تازه است

یکسان‌بودن رابط برنامه‌نویسی، هم‌ارزی رفتاری نمی‌آورد. دو مدل در پیروی از دستور، فراخوانی ابزار، زبان، امتناع، زمینه، زمان پاسخ، سیاست ایمنی و محل داده تفاوت دارند. حتی نسخه تازه همان فروشنده می‌تواند بدون تغییر کد رفتار محصول را عوض کند.

پس مسیریابی خودکار فقط برای کاری امن است که همان مدل دوم، با همان دستور، بازیابی، ابزار، اعتبارسنج و سیاست، آزمون مربوط را گذرانده باشد. مجوز را به نام کار بدهید، نه به «کل ترافیک». مدلی که برای خلاصه‌کردن یک سیاست مستند تأیید شده، لزوماً صلاحیت تشخیص شرایط بازپرداخت یا ساخت آرگومان ابزار را ندارد.

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

مسیر کم‌توان باید از مسیر اصلی ساده‌تر باشد

طرحی با فروشنده دوم، اعتبارنامه تازه، شبکه میان‌ابری، مبدل، پالایش و کش جدید، مسیر پیچیده‌ای می‌سازد که فقط هنگام بحران اجرا می‌شود. این اجزا وضعیت ناشناخته را بیشتر می‌کنند.

بهتر است مسیر کاهش‌یافته واقعاً کار کمتری انجام دهد:

• رکورد معتبر یا بند منبع را بدون نتیجه‌گیری نشان دهد؛
• شخصی‌سازی، زمینه بلند، ابزار اختیاری و نوشتن را خاموش کند؛
• درخواست را با رسید بپذیرد، بی‌آنکه تکمیل کار را ادعا کند؛
• برای پیام وضعیت محدود از الگوی قطعی استفاده کند؛
• بسته مدرک را به کارشناس واجد شرایط برساند؛
• ترافیک کم‌اهمیت را پیش از مصرف ظرفیت مدل یا بازبین کنار بگذارد.

راهنمای Google و AWS می‌گوید در فشار و خرابی، کار حیاتی را نگه دارید و کار غیرحیاتی را حذف کنید. در سامانه هوش مصنوعی یک شرط دیگر هم هست: خروجی کم‌توان نباید خود را شبیه خدمت کامل و دارای همه شواهد جا بزند. هم انسان و هم سامانه پایین‌دست باید کد حالت و توضیح صریح دریافت کنند.

نمونه بازپرداخت را تا مرز اثر دنبال کنید

دستیار فرضی سه کار دارد: پاسخ به پرسش سیاست، پیشنهاد واجدشرایط‌بودن و اجرای بازپرداخت تأییدشده.

در حالت عادی، هویت مشتری و سفارش بررسی می‌شود، سیاست جاری منطقه بازیابی می‌گردد، مدل اصلی توضیح مستند می‌سازد، فیلدهای لازم اعتبارسنجی می‌شوند و پرونده واجد شرایط به خدمت مستقل تأیید و اجرا می‌رسد.

حالا نرخ پایان‌مهلت مدل از آستانه مصوب می‌گذرد. هویت، سفارش، سیاست و ثبت حسابرسی سالم‌اند. کنترل‌کننده، مدار تولید را باز می‌کند و حالت آزموده‌شده فقط مدرک را فعال می‌سازد. صفحه، بندهای جاری سیاست و داده سفارش را با زمان ثبت نشان می‌دهد. درخواست بازبینی پذیرفته می‌شود، اما سامانه درباره واجدشرایط‌بودن حکم نمی‌دهد، توضیح اقناعی نمی‌نویسد و دکمه بازپرداخت را نمایش نمی‌دهد.

مدل کوچک‌تر، خلاصه کوتاه انگلیسی را خوب انجام می‌دهد، اما در استثنای فارسی و آرگومان ابزار زیر کف پذیرش است. فقط خلاصه اختیاری انگلیسیِ متصل به مدرک مجاز می‌شود. کاربر فارسی منبع و بررسی انسانی می‌بیند؛ هیچ گروهی پنهانی تصمیم ضعیف‌تر نمی‌گیرد.

اگر سپس مخزن حسابرسی قطع شود، سامانه پذیرش درخواست بازبینی را هم متوقف می‌کند، چون دیگر نمی‌تواند دریافت و مالکیت را ثابت کند. نمایش فقط‌خواندنی، اگر سیاست اجازه دهد، ادامه می‌یابد. اگر سیاست بازیابی‌شده نیز از حد تازگی عبور کند، پاسخ مستند بسته می‌شود و تنها پیام وضعیت و راه ثبت پرونده باقی می‌ماند.

هیچ‌کدام از این تصمیم‌ها به تشخیص مدل وابسته نیست. سیاست قطعی، شرط اندازه‌گیری‌شده را به کار مجاز نگاشت می‌کند.

تحویل انسانی را با ظرفیت واقعی پشتیبانی کنید

«به انسان ارجاع شود» با صف بی‌مالک، مدرک ناقص یا ظرفیت ناکافی شکست می‌خورد. قرارداد تحویل باید پذیرش، اولویت، بیشترین انتظار، رسید، مسئول، ساعت خدمت و رفتار صف پر را مشخص کند. متن ناقص هوش مصنوعی هم نباید نقطه شروع بی‌چون‌وچرای کارشناس شود.

قانون هوش مصنوعی اتحادیه اروپا، مقرره 2024/1689 در ۱۳ ژوئن ۲۰۲۴ تصویب و ۱۲ ژوئیه منتشر شد. ماده ۱۴ برای سامانه‌های پرخطر در دامنه این قانون، نظارت انسانی متناسب می‌خواهد؛ از جمله توان نادیده‌گرفتن، جایگزینی یا برگرداندن خروجی و، در جای مناسب، توقف سامانه در وضعیت امن. این الزام حقوقی فقط در محدوده تعریف‌شده قانون اعمال می‌شود. درس فنی آن عمومی‌تر است: مسئول انسانی به اختیار، اطلاعات، زمان و توقف واقعی نیاز دارد؛ برچسب «صف انسانی» کافی نیست.

ورود، ماندن و خروج از حالت کم‌توان را کنترل کنید

یک ماشین حالت روشن بسازید؛ برای نمونه: عادی ← مختل ← کم‌توان ← متوقف ← در حال بازگشت ← عادی. هر گذار باید این موارد را داشته باشد:

• ماشه اندازه‌گیری‌شده و پنجره مشاهده؛
• فهرست دقیق قابلیت‌های روشن و خاموش؛
• نسخه سیاست و مالک تصمیم؛
• کد قابل‌خواندن برای ماشین و پیام روشن برای کاربر؛
• سقف صف، زمان، هزینه و دامنه اثر؛
• شواهد پیش و هنگام تغییر؛
• آزمون خروج، نه فقط خبر «فروشنده برگشت».

بازگشت به حالت عادی خودش منبع خطر است. مدارها را مرحله‌ای ببندید، کارهای صف‌مانده را اجرا یا منقضی کنید، خروجی ذخیره‌شده ناامن را کنار بگذارید، اثرهای بیرونی را تطبیق دهید و یکپارچگی بسته انتشار را بسنجید. چند پاسخ موفق فقط دسترسی شبکه را ثابت می‌کند. آزمون‌های محافظت‌شده و سهم کوچکی از ترافیک باید پیش از بازگشت کامل موفق شوند.

راهنمای عملیات امن هوش مصنوعی NCSC بریتانیا، منتشرشده در ۲۷ نوامبر ۲۰۲۳، پایش ورودی، خروجی، کارایی و تغییر ناگهانی یا تدریجی رفتار را توصیه می‌کند و می‌گوید تغییر مهم مدل، داده یا دستور باید مانند نسخه‌ای تازه ارزیابی شود. همین شواهد باید هم ورود به حالت کم‌توان و هم اجازه خروج از آن را تغذیه کنند.

فقط قطع کامل را تمرین نکنید

خطای ساده ۵۰۰ نمونه‌های خطرناک را نمی‌بیند. پاسخ دیررس، جریان نیمه‌کاره، استناد حذف‌شده، بازیابی کهنه، پایان سهمیه، اختلال یک زبان، قطع حسابرسی، صف پر، اعتبارنامه لو‌رفته و مدل پاسخ‌گو اما کم‌کیفیت را بیازمایید.

در هر سناریو ثابت کنید:

۱. حالت درست در مهلت مقرر فعال می‌شود؛ ۲. ابزار و خروجی ممنوع از نظر فنی دست‌نیافتنی می‌گردد؛ ۳. کار در حال اجرا بدون اثر تکراری به وضعیتی معلوم می‌رسد؛ ۴. کاربر محدودیت درست و اقدام بعدی مفید را می‌بیند؛ ۵. صف، کش، تلاش دوباره و بار انسان از مرز نمی‌گذرند؛ ۶. بازگشت، کار کهنه یا نسخه‌های آمیخته را دوباره وارد نمی‌کند.

تمرین را با هویت، سیاست، زبان، سن داده، بار و خرابی پایین‌دست واقعی اجرا کنید. مسیر پشتیبانی روی کاغذ، سامانه‌ای آزموده‌شده نیست.

ارزش حفظ‌شده و آسیبی را که رخ نداد اندازه بگیرید

زمان‌کار معمول ممکن است ادامه ناامن را تشویق کند. این ابعاد را جدا بسنجید:

• انتخاب درست حالت: زمان کشف، گذار نادرست و نوسان میان حالت‌ها؛
• خدمت حفظ‌شده: سهم مسیرهای حیاتی که در قرارداد کوچک‌تر کامل شدند؛
• سلامت مرز: تلاش برای اقدام ممنوع، رسید گمشده و دورزدن سیاست؛
• صداقت خروجی: ادعای کهنه یا بی‌استناد، برچسب حالت غلط و سوءبرداشت کاربر؛
• پایداری نیروی انسانی: پذیرش تحویل، سن صف، رهاکردن و بار بازبین؛
• کیفیت بازگشت: اختلاف تطبیق، اثر تکراری، پاک‌سازی کش و زمان رسیدن به خدمت عادیِ اعتبارسنجی‌شده.

مخرج را هم ثبت کنید: تعداد درخواست واجد شرایط در هر حالت. موفقیت ۹۹ درصدی ارزشی ندارد اگر سامانه پرونده فارسی، تراکنش بزرگ یا مورد نیازمند مدرک جاری را بی‌صدا از محاسبه کنار گذاشته باشد.

برگه تصمیم پیش از حادثه

پیش از روشن‌کردن جابه‌جایی خودکار، برای هر مسیر مهم یک برگه تصمیم امضاشده بخواهید:

• کوچک‌ترین خدمت مفید چیست و کدام اصل باید حفظ شود؟
• چه شرطی حالت عادی، کم‌توان، تحویل یا توقف را مجاز می‌کند؟
• جزء جایگزین واقعاً هم‌ارز است یا فقط برای کارهای نام‌برده تأیید شده؟
• در هر حالت کدام داده، ابزار، نوشتن، زبان و گروه کاربر حذف می‌شود؟
• محدودیت چگونه به کاربر و سامانه پایین‌دست اعلام می‌گردد؟
• آیا مرز اجرای اثر بدون اعتماد به مدل، ممنوعیت را اعمال می‌کند؟
• تکلیف کار در حال اجرا و صف چیست؟
• مالک حالت، صف انسانی، حادثه و بازگشت چه کسی است؟
• کدام تمرین، رفتار را زیر بار و خرابی جزئی ثابت می‌کند؟
• پیش از بازگشت عادی کدام مدرک باید آماده باشد؟

نشانی پشتیبان فقط یک قلم موجودی است. قرارداد حالت کم‌توان یک تصمیم عملیاتی است. این قرارداد می‌پذیرد که خرابی جزئی رخ می‌دهد، فقط ارزشی را نگه می‌دارد که هنوز قابل دفاع است و کاهش اختیار را آشکار می‌کند. اگر سازمان نتواند بگوید سامانه بدون مدل اصلی چه اجازه‌ای دارد، تداوم طراحی نکرده است؛ انتشار بداهه‌ای را برای میانه حادثه آماده کرده است.

یادداشت منابع — بازبینی ۱ سپتامبر ۲۰۲۶

• NIST، هسته AI RMF: برنامه خرابی شخص ثالث، خرابی ایمن، راه غیرهوش‌مصنوعی، پایش، توقف، بازیابی و خاموش‌سازی.
• NIST، SP 800-34 Rev. 1: تحلیل اثر کسب‌وکار، نیاز تداوم، رویه بازیابی و تمرین؛ سندی عمومی از سال ۲۰۱۰.
• Google Cloud، طراحی کاهش تدریجی خدمت: محدودکردن بار، رد زودهنگام، خطای جزئی، پایش و آزمون فشار؛ آخرین بازبینی ۳۰ دسامبر ۲۰۲۴.
• AWS، اجرای کاهش کنترل‌شده خدمت: حفظ کار حیاتی، سادگی و آزمون مسیر خرابی و تعیین نیازهایی که باید باقی بمانند.
• Kubernetes، پروب‌های زنده‌بودن، آمادگی و شروع: جداسازی عمر فرایند، آمادگی ترافیک و شروع؛ آخرین تغییر ۳۰ ژوئن ۲۰۲۶.
• NCSC بریتانیا، عملیات و نگهداری امن: پایش ورودی و رفتار و ارزیابی تغییر مهم؛ منتشرشده در ۲۷ نوامبر ۲۰۲۳.
• اتحادیه اروپا، مقرره (EU) 2024/1689: الزامات ماده ۱۴ درباره نظارت انسانی و توقف امن برای سامانه‌های پرخطر در دامنه قانون.