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

ساعت ۱۰:۱۲ صبح است. یک دستیار داخلی شروع می‌کند به استناد کردن به سیاستی که دو ماه پیش منقضی شده. سرویس در دسترس است، پاسخ‌ها با تأخیر عادی می‌رسند و ارائه‌دهنده‌ی مدل هم از قطعی خبر نمی‌دهد. بااین‌حال، سامانه در کاری که کسب‌وکار به آن سپرده از کار افتاده است.

حالا باید چه کرد؟

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

این همان خلأ عملیاتی در بسیاری از محصولات هوش مصنوعی است. تیم‌ها پیش از راه‌اندازی درباره‌ی دقت، امنیت و زمانِ در دسترس بودن صحبت می‌کنند، اما روشن نمی‌کنند چه اتفاقی باید بیفتد تا یک ناهنجاری به رخداد (incident) تبدیل شود. ابزار پایش دارند، اما برای اقدام آستانه‌ای تعیین نکرده‌اند؛ نسخه‌ی پشتیبان دارند، اما بازگشت به آن را تمرین نکرده‌اند؛ و مرحله‌ی تأیید دارند، اما معلوم نیست چه کسی اختیار تصمیم‌گیری دارد.

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

رخداد اول: سرویس روشن است، پس داشبورد سبز مانده

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

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

پس برنامه‌ی واکنش به رخداد باید چند نوع نشانه را در نظر بگیرد:

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

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

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

رخداد دوم: کسی نمی‌داند نگرانی چه وقت باید به اقدام برسد

قاعده‌ی مفید برای رخداد این نیست که بگوییم «کیفیت پاسخ‌ها را زیر نظر بگیرید». بهتر است چیزی شبیه این بگوییم: «اگر بیش از ۲ درصد پاسخ‌های نمونه‌برداری‌شده در یک ساعت به سیاستی منسوخ استناد کردند، پاسخ‌گویی خودکار برای آن گروه سیاست را خاموش کنید و درخواست‌ها را به میز پشتیبانی بفرستید.»

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

این ماتریس ساده‌ی شدت رخداد را می‌توانید پیش از راه‌اندازی با شرایط سازمان خودتان تطبیق دهید:

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

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

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

رخداد سوم: راهکار جایگزین همان مشکل را تکرار می‌کند

«از یک مدل دیگر استفاده کنیم» به‌تنهایی برنامه‌ی بازیابی نیست.

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

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

راهکار جایگزین اغلب توانایی کمتری دارد، اما امن‌تر است:

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

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

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

رخداد چهارم: تیم نمی‌تواند بفهمد سامانه چطور به این تصمیم رسید

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

مشاهده‌پذیری را طوری طراحی کنید که بتوانید به پرسش‌هایی پاسخ دهید که هنگام رخداد پیش می‌آیند:

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

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

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

رخداد پنجم: برنامه فرض می‌کند فرد مناسب همیشه در دسترس است

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

برای هر مسئولیت، یک مالک و جانشین مشخص کنید:

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

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

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

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

رخداد ششم: تمرین انجام می‌شود، اما چیزی تغییر نمی‌کند

تمرین‌های دورمیزی (tabletop) ارزشمندند، چون وابستگی‌های سازمانی را آشکار می‌کنند که آزمون واحد نرم‌افزار نشان نمی‌دهد. اما صرفِ شرکت کردن در تمرین به معنی موفقیت آن نیست. تمرین زمانی موفق است که چیزی در سامانه یا روش کار را تغییر دهد.

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

هنگام تمرین، چند مانع هم وارد سناریو کنید:

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

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

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

رخداد هفتم: فکر می‌کنیم بازیابی یعنی قابلیت را دوباره روشن کنیم

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

هدف‌های بازیابی را برای فرایند کسب‌وکار تعریف کنید، نه فقط برای سرویس:

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

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

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

برای تصمیم‌های سخت آماده شوید، نه برای تک‌تک فاجعه‌ها

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

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

این روش رخدادهای هوش مصنوعی را از بین نمی‌برد، اما کمک می‌کند زودتر متوجهشان شویم، نگذاریم گسترده‌تر شوند و برای مهارشان به شجاعتِ بداهه و تصمیم‌های لحظه‌ای متکی نمانیم.

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