جایگزینی برچسب‌های مبهم با «ردیابی مکانیسمی» در مدیریت ریسک هوش مصنوعی

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

این رویکرد شکافی حیاتی را در نحوه مدیریت ایمنی هوش مصنوعی (AI Safety) و حاکمیت داده‌ها می‌پوشاند. مدیریت ریسک سنتی معمولاً با هوش مصنوعی مانند یک جعبه سیاه برخورد می‌کند. نتیجه این برخورد، تولید اسنادی است که شاید بازرسان و حساب‌رسان را راضی کند، اما در عمل از کاربران محافظت نمی‌کند. برای تیم‌هایی که دستیارهای مبتنی بر تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را می‌سازند، مخاطرات تنها پاسخ‌های اشتباه یا «توهمات» ساده نیستند، بلکه خطراتی چون تراکنش‌های مالی غیرمجاز یا نشت داده‌های حساس هستند که می‌توانند ضربات جبران‌ناپذیری بزنند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی حفاظ‌های مدل‌ها اشاره کردیم، تمرکز بر لایه‌های بیرونی بدون شناخت لایه‌های داخلی خطرناک است. طبق چارچوب کاربردی منتشر شده در dev.to در ۷ آگوست ۲۰۲۶، شکست اصلی اکثر دفاتر ریسک، نبود توصیفات «مکانیسمی» است. مکانیسم در اینجا به صورت یک گزاره علت و معلولی تعریف می‌شود: «X باعث Y می‌شود». اگر نمی‌توانید ریسک را در این قالب بنویسید، یعنی هنوز آن را به‌قدر کافی نمی‌شناسید که بتوانید کنترلش کنید. در واقع، هر ریسکی که نتوان آن را در قالب یک رابطه علت و معلولی تعریف کرد، عملاً غیرقابل مدیریت است.

هدف از ثبت ریسک

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

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

کالبدشناسی یک ردیف ریسک کاربردی

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

• مکانیسم: یک جمله واحد که آنچه واقعاً رخ می‌دهد را در قالب علت و معلول شرح دهد. به‌جای عبارت کلی «خروجی نادرست»، بنویسید: «یک سند بازیابی‌شده حاوی دستورات، باعث می‌شود عامل (Agent) ابزار استرداد وجه را فراخوانی کند».
• پیش‌شرط: چه چیزی باید برقرار باشد تا ریسک اصلاً ممکن شود. این ستون اجازه می‌دهد یک ردیف را صادقانه ببندید؛ به این صورت که با حذف پیش‌شرط، ریسک به‌جای کاهش (Mitigation)، به‌طور کامل حذف (Eliminate) می‌شود.
• تأثیر: هزینه وقوع یک مورد واحد در واحدهای تجاری محاسبه شود (مانند مقدار پول از دست رفته، یک حادثه که نیاز به گزارش رسمی دارد، از دست دادن یک مشتری یا یک یافته نظارتی رگولاتور)، به‌جای اینکه مجموع تخمینی سالانه ارائه شود.
• احتمال: استفاده از بازه زمانی و فرکانس (مثلاً «بیشتر از یک‌بار در ماه»، «چند بار در سال» یا «کمتر از یک‌بار در سال») به‌جای احتمالات اعشاری فریبنده (مانند ۰.۳) که هیچ‌کس نمی‌تواند توجیه منطقی برای انتخاب آن‌ها ارائه دهد.
• کنترل: آنچه ریسک را کاهش می‌دهد. در اینجا باید دقیقاً مشخص شود که کنترل «پیشگیرانه» است (مانع وقوع حادثه می‌شود) یا «شناسایی‌کننده» (بعد از وقوع حادثه آن را می‌یابد). دفتری که فقط پر از کنترل‌های شناسایی‌کننده است، در واقع فهرستی از چیزهایی است که شما فقط بعد از وقوع فاجعه متوجه آن‌ها می‌شوید.
• شناسایی: روش دقیق فهمیدن وقوع حادثه. این ستون اغلب خالی می‌ماند، اما دقیقاً همین ستون است که تعیین می‌کند یک حادثه در یک ساعت شناسایی شود یا یک فصل بعد.
• مالک / ریسک باقی‌مانده / بازبینی: نام شخص مسئول، سطح ریسکی که پس از اعمال کنترل‌ها آگاهانه پذیرفته شده است، و تاریخ یا رویداد خاصی که بازبینی مجدد ردیف را فعال می‌کند.

۱۱ ریسک حیاتی برای دستیارهای هوش مصنوعی

این چارچوب ۱۱ مکانیسم مشخص را برای یک دستیار مبتنی بر بازیابی (RAG) که قابلیت استفاده از ابزار (Tool Use) را دارد، شناسایی کرده است:

• R1: تزریق از طریق محتوای بازیابی‌شده: متنی در یک سند بازیابی‌شده یا یک ایمیل ورودی، توسط مدل به عنوان دستور تلقی می‌شود و مدل اقدامی را انجام می‌دهد که کاربر هرگز نخواسته است. پیش‌شرط: مدل محتوای نامعتبر را بخواند و همزمان قابلیت اجرای ابزار را داشته باشد. کنترل: حذف یکی از این دو (قانون «هرگز هر سه مورد را همزمان نداشته باشید»). شناسایی: ثبت تمام فراخوانی‌های ابزار (Tool Calls) همراه با محتوای محرک و هشدار در مورد فراخوانی‌هایی که هیچ قصد کاربر در آن‌ها دیده نمی‌شود.
• R2: استخراج داده توسط لینک رندر شده: خروجی مدل حاوی یک تصویر مارک‌دان یا لینکی است که URL آن، محتوای گفتگو را به یک میزبان تحت کنترل مهاجم می‌فرستد و کلاینت آن را به‌طور خودکار رندر می‌کند. کنترل: استفاده از لیست سفید (Allowlisting) میزبان‌ها در سمت رندر.
• شناسایی: بررسی لاگ‌های درخواست‌های خروجی (Outbound) از سطح رندر.
• R3: بازیابی متقاطع مستاجران (Cross-tenant): یک فیلتر بازیابی گم شده یا اشتباه است و کاربر A محتوای مربوط به مشتری B را دریافت می‌کند. پیش‌شرط: استفاده از یک ایندکس واحد برای نگهداری داده‌های چندین مستاجر. کنترل: استفاده از ACL به عنوان یک فیلتر اجباری در پرس‌وجو (Query) به علاوه تست‌های CI که جداسازی را تأیید می‌کنند. شناسایی: شناسایی این مورد بسیار سخت است (به همین دلیل کنترل باید حتماً پیشگیرانه باشد).
• R4: تغییر مدل توسط ارائه‌دهنده: یک Alias (نام مستعار) به نسخه جدیدی ارجاع می‌دهد؛ در نتیجه فرمت خروجی، رفتار رد کردن (Refusal) یا طول پاسخ تغییر می‌کند و باعث شکست در پارسرهای پایین‌دستی یا افت کیفیت بی‌صدا می‌شود. کنترل: تثبیت نسخه‌ها (Version Pinning) در هر کجا که ممکن باشد. شناسایی: اجرای یک مجموعه تست کناری (Canary Suite) به صورت زمان‌بندی شده، نه تکیه بر گزارش‌های کاربران.
• R5: قطعی ارائه‌دهنده در ساعات کاری: وابستگی مدل از دسترس خارج می‌شود در حالی که این ویژگی در مسیر حیاتی (Critical Path) گردش کار کسی قرار دارد. کنترل: تعریف یک مسیر جایگزین (Fallback) و تعیین یک رفتار تخریب‌شده (Degraded Behavior) از پیش تصمیم‌گرفته شده. شناسایی: مانیتورینگ در دسترس بودن بر اساس فراخوانی‌های خودتان، نه تکیه بر صفحه Status ارائه‌دهنده.
• R6: افزایش هزینه پس از استقرار: تغییر در پرامپت، بازیابی یا تنظیمات استدلال باعث افزایش توکن‌ها در هر درخواست می‌شود و هزینه افزایش می‌یابد پیش از آنکه کسی متوجه شود. کنترل: تعریف یک تأییدیه هزینه (Cost Assertion) برای هر درخواست در CI و تعیین یک سقف سخت هزینه برای هر درخواست. شناسایی: رصد هزینه روزانه به ازای هر درخواست، نه مجموع ماهانه.
• R7: انکار کیف پول (Denial of Wallet): یک نقطه اتصال (Endpoint) بدون احراز هویت یا با محدودیت ضعیف، توسط شخص ثالث با حجم بالا بمباران می‌شود و بودجه را می‌بلعد. کنترل: احراز هویت، سقف‌های مصرف به ازای هر کلید و محدود کردن نرخ درخواست (Rate Limit). شناسایی: هشدار نرخ هزینه در دانه‌بندی‌های ریزتر از یک روز.
• R8: رسیدن جزئیات ساختگی به مشتری: یک پاسخ با اطمینان بالا و فرمت درست، حاوی یک سیاست، قیمت یا منبع ساختگی است و بدون بازبینی انسانی ارسال می‌شود. کنترل: مبنی‌سازی (Grounding) به همراه بازبینی انسانی برای هر چیزی که از شرکت خارج می‌شود. شناسایی: درجه‌بندی نمونه‌برداری شده (Sampled Grading) پیام‌های خروجی در مقابل منابع.
• R9: داده‌های شخصی در لاگ‌ها: پرامپت‌ها و پاسخ‌ها برای عیب‌یابی ثبت شده و بیش از بازه مجاز داده‌ها نگهداری می‌شوند. کنترل: حذف داده‌های حساس (Redaction) در لحظه ثبت و نه در لحظه پرس‌وجو، همراه با اعمال سیاست‌های نگهداری توسط Store.
• شناسایی: نمونه‌برداری دوره‌ای از ذخیره‌گاه لاگ‌ها برای یافتن شناسه‌های شخصی.
• R10: دسترسی تاییدنشده شخص ثالث: یک کارمند به یک برنامه AI اجازه دسترسی به ایمیل یا درایو سازمانی را می‌دهد و یک جریان داده دائمی به یک فروشنده بررسی‌نشده ایجاد می‌کند. کنترل: محدود کردن افرادی که می‌توانند دسترسی‌ها (Scopes) را تایید کنند. شناسایی: موجودی گرنت‌های OAuth در پیمایش‌های Shadow-AI که به صورت فصلی اجرا می‌شود.
• R11: توقف پشتیبانی از مدل یا تغییر شرایط: مدلی که به آن وابستگی دارید بازنشسته می‌شود یا شرایط استفاده در بازه زمانی کوتاه‌تری از زمان مورد نیاز برای مهاجرت شما تغییر می‌کند. کنترل: داشتن یک مدل جایگزین شناخته‌شده (Second-choice) و ایجاد یک لایه انتزاع (Abstraction) برای تعویض سریع مدل. شناسایی: هدایت اعلان‌های تغییر فروشنده به یک شخص خاص به‌جای یک صندوق پستی مشترک.

منطق امتیازدهی و کنترل

یکی از تغییرات اثرگذار در این چارچوب، رد کامل امتیازدهی عددی (مثلاً احتمال ۰.۳ × تأثیر ۷) است. چنین اعدادی دقتی را القا می‌کنند که در دنیای هوش مصنوعی وجود ندارد؛ نتیجه‌ای مانند ۲.۱ شبیه به دانش به نظر می‌رسد اما در واقع نیست. به‌جای آن، از «بازه‌ها» برای یک هدف واحد استفاده کنید: مرتب‌سازی (Sorting).

بازه احتمال:

• اغلب: بیشتر از ماهیانه
• گاهی: چند بار در سال
• نادر: کمتر از سالانه

بازه تأثیر:

• شدید: نیاز به گزارش رسمی، نقض قرارداد یا از دست دادن یک مشتری
• مادی: یک روز بد، ضرر مالی واقعی، یا نیاز به عذرخواهی
• جزئی: جذب شده در عملیات عادی و قابل چشم‌پوشی

منطق نهایی یک قانون صریح است، نه یک ماتریس پیچیده:

• تأثیر شدید + هر چیزی بالاتر از نادر: نیاز به کنترل پیشگیرانه (Preventive) پیش از عرضه دارد.
• تأثیر مادی + اغلب: نیاز به کنترل پیشگیرانه یا یک استثنای پذیرفته شده و تاریخ‌دار دارد.
• بقیه موارد: نیاز به مکانیسم شناسایی (Detection) و یک تاریخ بازبینی مشخص دارند.

برای مثال، بازیابی متقاطع (R3) احتمال پایین اما تأثیر شدید دارد و در عین حال شناسایی‌اش بسیار سخت است. این ترکیب تقاضای یک کنترل پیشگیرانه و یک تست سخت‌گیرانه را دارد. در مقابل، افزایش هزینه (R6) متداول است، به ندرت شدید است و کاملاً قابل شناسایی است؛ بنابراین یک چک خودکار و ارزان، بسیار برتر از دقت دستی و نظارت انسانی است.

عملیاتی کردن سند

برای اینکه دفتر ریسک به یک اثر باستانی یا یک سند خاک‌خورده تبدیل نشود، این چارچوب بازبینی‌های سالانه مبتنی بر تقویم را با «محرک‌های خاص» (Triggers) جایگزین می‌کند. بازبینی سالانه معمولاً سندی است که ۱۱ ماه کسی آن را نخوانده است. به‌جای آن از این محرک‌ها استفاده کنید:

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

هر حادثه واقعی باید منجر به یک ردیف جدید یا ویرایش ردیف قبلی شود. این تضمین می‌کند که دفتر ریسک یک سند زنده باقی بماند و نه صرفاً یک اثر جانبی از زمان عرضه (Launch Artifact). معمولاً در این مرحله است که ستون «شناسایی» اصلاح و دقیق می‌شود. در نهایت، ردیف‌های بسته شده باید با ذکر دلیل بسته شدن حفظ شوند. ردیفی که به دلیل حذف یک پیش‌شرط بسته شده، مرجعی مفید است برای زمانی که کسی در آینده پیشنهاد دهد آن پیش‌شرط را دوباره اضافه کند، بدون اینکه بداند چرا قبلاً حذف شده بود.

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

گام بعدی شما

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

اما مدیریت این ریسک‌ها در مقیاس بزرگ، نیاز به ابزارهای رصد خودکار دارد — به بررسی ما درباره سامانه‌های مانیتورینگ LLM مراجعه کنید.