از دمو تا سامانه قابل اتکا: چک‌لیست آمادگی هوش مصنوعی

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

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

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

دروازه ۱: هدف، مرز و مالک را نام‌گذاری کنید

یک منشور یک‌صفحه‌ای برای سامانه بنویسید:

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

اگر مالکیت تقسیم شده، ماتریس مسئولیت و یک فرمانده رخداد مشخص کنید. عبارت «تیم هوش مصنوعی» در نیمه‌شب مالک قابل اقدام نیست.

شاهد انتشار: منشور تأییدشده، مالک سرویس، مسیر آنکال، سطح ریسک و فهرست استفاده ممنوع.

دروازه ۲: موفقیت و شکست غیرقابل قبول را تعریف کنید

دقت مدل به‌تنهایی محصول را توصیف نمی‌کند. سه لایه معیار لازم است:

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

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

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

دروازه ۳: ارزیابی نماینده واقعیت بسازید

نمونه‌ها باید از توزیع واقعی بیایند، نه از دموهای مرتب. این موارد را پوشش دهید:

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

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

بخش سنجش AI RMF در NIST بر آزمون پیش از استقرار و پایش منظم، گزارش عدم قطعیت، مقایسه با خط پایه و مستندسازی تأکید دارد.

شاهد انتشار: مجموعه نسخه‌بندی‌شده، rubric، گزارش گروه‌ها، شکست‌های مسدودکننده، خط پایه انسانی و تاریخچه رگرسیون.

دروازه ۴: مرز داده و امنیت را اجرا کنید

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

حداقل کنترل‌ها:

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

ده ریسک اصلی OWASP برای برنامه‌های عامل‌محور در ۲۰۲۶ ورودی خوبی برای مدل تهدید است. راهنمای مجوز حداقلی ابزارهای عامل طراحی قابلیت را دقیق‌تر بررسی می‌کند.

شاهد انتشار: مدل تهدید، نمودار جریان داده، ماتریس مجوز، نتیجه ردتیم، اسکن راز و سقف سوءاستفاده.

دروازه ۵: اقدام را امن و برگشت‌پذیر کنید

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

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

شاهد انتشار: قرارداد ابزار، آزمون اعتبارسنجی، برنامه بازگشت، آزمون شرط نهایی و آزمون اجرای تکراری.

دروازه ۶: جایگزین و ارجاع انسانی را طراحی کنید

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

مطلب طراحی مرز تأیید انسانی الگوهای رابط و اختیار را توضیح می‌دهد.

شاهد انتشار: ماتریس جایگزین، مالک صف، آزمون حفظ زمینه، متن کاربر و هدف بازیابی.

دروازه ۷: مسیر تصمیم را مشاهده‌پذیر کنید

فقط uptime و تأخیر کافی نیست. مسیر نیت کاربر تا بازیابی، مدل، ابزار، تأیید، اجرا و نتیجه را ردیابی کنید.

موارد مهم:

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

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

شاهد انتشار: نمونه trace، فرهنگ معیار، طبقه‌بندی لاگ، هشدار، مالک پایش و سیاست نگهداری.

دروازه ۸: تمام اجزای تغییرپذیر را کنترل کنید

مدل، ارائه‌دهنده، پرامپت، corpus بازیابی، chunking، embedding، ranking، ابزار، سیاست، آستانه، رابط تأیید، زبان و تبدیل داده همگی رفتار محصول را تغییر می‌دهند.

این اجزا را در یک manifest انتشار نسخه‌بندی کنید. پیش از عرضه ارزیابی مرتبط را اجرا، نسخه جدید را با canary یا shadow traffic مقایسه و مسیر بازگشت فوری را حفظ کنید. تغییر بی‌صدای alias مدل نزد ارائه‌دهنده باید مانند تغییر داخلی بازبینی شود.

شاهد انتشار: manifest، نقشه اثر، نتیجه رگرسیون، برنامه canary و مالک rollback.

دروازه ۹: اقتصاد را زیر بار واقعی ثابت کنید

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

هزینه هر نتیجه =
  مدل و زیرساخت
  + بازیابی و ابزار
  + نیروی بازبینی
  + تکرار و مسیر جایگزین
  + هزینه مورد انتظار رخداد و دوباره‌کاری

مسیر رایج و بدترین حالت را load test کنید. برای توکن، حلقه ابزار، زمان و صف بازبینی سقف بگذارید. بسنجید آیا اتوماسیون کار را سریع‌تر می‌کند یا فقط زحمت را به بازبین منتقل می‌کند.

شاهد انتشار: پیش‌بینی حجم، اقتصاد واحد، آزمون بار، هشدار هزینه و بودجه سخت اجرا.

دروازه ۱۰: رخداد و بازنشستگی را آماده کنید

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

بازنشستگی نیز مهم است: حافظه، embedding، لاگ، اعتبارنامه، داده ارزیابی و یکپارچه‌سازی پایین‌دستی باید حذف، نگهداری، مهاجرت یا لغو شوند. راهنمای Manage در NIST پایش، اعتراض، لغو، بازنشستگی، رخداد، بازیابی و کنترل تغییر را به هم مرتبط می‌کند.

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

«روز بد» را تمرین کنید

پیش از عرضه یک tabletop و یک تمرین فنی اجرا کنید:

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

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

کارت امتیاز انتشار

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

عرضه را کنترل‌شده توسعه دهید

1. ارزیابی آفلاین.
2. حالت سایه بدون خروجی قابل مشاهده.
3. پیشنهاد به انسان بدون اقدام خودکار.
4. اقدام با تأیید.
5. اقدام خودکار محدود با سقف سخت.
6. توسعه دامنه فقط پس از شواهد تولید.

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

پرسش‌های رایج

آیا عبور از benchmark یعنی آمادگی تولید؟

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

ارزیابی هر چند وقت یک بار اجرا شود؟

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

چه چیزی باید عرضه را متوقف کند؟

شکست غیرقابل قبول بدون کنترل اجرایی، مالکیت مبهم، دسترسی حساس بدون سقف، نبود مسیر شکست امن، ناتوانی در ردیابی و توقف اقدام مهم، یا هزینه‌ای که قابل محدودکردن نیست.

منابع و تاریخ بازبینی

این راهنما در ۸ مرداد ۱۴۰۵ (۳۰ ژوئیه ۲۰۲۶) به‌طور اساسی با منابع زیر بازبینی شد:

• هسته چارچوب مدیریت ریسک هوش مصنوعی NIST
• راهنمای عملی NIST AI RMF
• گزارش NIST AI 800-4 درباره پایش پس از استقرار
• ده ریسک اصلی OWASP برای برنامه‌های عامل‌محور در ۲۰۲۶
• قراردادهای معنایی GenAI در OpenTelemetry

آمادگی تولید سندی با یک امضا نیست؛ انضباطی عملیاتی است که دمو را پس از عرضه نیز مفید نگه می‌دارد.