وقتی هوش مصنوعی اشتباه می کند، چه کسی چه کاری انجام می دهد؟

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

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

داشبورد سبز، پاسخ درست نیست

پایش زیرساخت همچنان مهم است؛ اما پاسخ HTTP با کد ۲۰۰ تضمین نمی کند خروجی مفید یا امن بوده. سامانه بازیابی شاید از سند اشتباه نقل کند، ایجنت ابزار درست را برای کار نادرست به کار ببرد، یا مدل JSON معتبر بسازد که داخلش داده غلط است. این شکست معنایی است: اجزا کار می کنند، اما انتظار اصلی برآورده نشده.

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

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

راه جایگزین باید وابستگی خراب را دور بزند

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

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

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

نقش ها را پیش از بحران تقسیم کنید

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

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

راه اندازی دوباره نیاز به شاهد دارد

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

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