چک‌لیست عرضه قابلیت هوش مصنوعی برای تصمیم Go/No-Go؛ از تعریف ریسک و Eval تا امنیت، تجربه کاربر، rollout، rollback و پایش پس از انتشار.
چک‌لیست عرضه قابلیت هوش مصنوعی قرار نیست یک فرم تشریفاتی در پایان پروژه باشد. این چک‌لیست باید به تیم کمک کند درباره سه تصمیم شفاف به توافق برسد: آیا قابلیت برای یک دامنه مشخص آماده است؟ با چه محدودیت و درصدی عرضه می‌شود؟ چه سیگنالی باعث توقف یا بازگشت می‌شود؟
قابلیت AI ممکن است در دمو عالی باشد و در محصول واقعی شکست بخورد؛ چون ورودی کاربران متنوع است، خروجی قطعی نیست و یک پاسخ قانع‌کننده می‌تواند اشتباه باشد. پس «کد deploy می‌شود» معادل «محصول آماده عرضه است» نیست.
این راهنما در ۷ اکتبر ۲۰۲۶ با منابع جاری بازبینی شده است. اگر هنوز معیار کیفیت ندارید، ابتدا آموزش طراحی Eval برای محصولات هوش مصنوعی را بخوانید. برای قابلیت‌هایی که به ابزار دسترسی دارند نیز تفاوت AI Agent، چت‌بات و Automation کمک می‌کند سطح کنترل را با اختیار واقعی سیستم هماهنگ کنید.
جلسه Go/No-Go بدون تعریف مشترک، به نظرهای کلی مثل «خروجی خوب به نظر می‌رسد» ختم می‌شود. پیش از جلسه این هشت مورد را روی یک صفحه بنویسید:
«دستیار پشتیبانی» دامنه مبهمی است؛ اما «پیشنهاد پاسخ به پرسش‌های مرجوعی برای کارشناسان، فقط براساس سه سند تأییدشده و بدون ارسال خودکار» قابل ارزیابی است.
تیم باید نشان دهد AI نسبت به قانون ثابت، جست‌وجوی معمولی یا بهبود رابط، ارزش اضافه می‌کند. نتیجه مطلوب را رفتاری بنویسید: مثلاً کاهش زمان آماده‌سازی پاسخ معتبر از ۱۲ دقیقه به ۵ دقیقه، بدون افزایش نرخ اصلاح اساسی.
برای هر قابلیت، موارد خارج از دامنه را هم اعلام کنید. اگر سیستم برای مشاوره حقوقی، تصمیم استخدام یا تشخیص پزشکی ساخته نشده، این مرز باید هم در طراحی و هم در پیام کاربر دیده شود. برای جداکردن جذابیت راه‌حل از ارزش واقعی، طراحی آزمایش محصول کم‌هزینه را به شواهد پیش از عرضه وصل کنید.
شرط عبور: مسئله، بخش کاربری، نتیجه قابل‌اندازه‌گیری، گزینه ساده‌تر و محدودیت دامنه مستند و توسط محصول، طراحی و مهندسی پذیرفته شده‌اند.
یک خلاصه ایمیل داخلی با پیشنهاد معامله مالی یکسان نیست. شدت پیامد، برگشت‌پذیری، تعداد افراد در معرض، حساسیت داده و میزان اختیار سیستم را امتیاز دهید. سپس عمق review، سطح تأیید انسانی و درصد rollout را براساس همان امتیاز تنظیم کنید.
راهنمای Responsible AI مایکروسافت که ۱۴ ژوئیه ۲۰۲۶ به‌روزرسانی شده، پیشنهاد می‌کند ارزیابی مسئولانه یک Release Gate متناسب با ریسک باشد؛ اقدام‌های اثرگذار بر انسان، پول یا انطباق نیز به تأیید انسانی برسند. نام مالک محصول کافی نیست: برای کیفیت، امنیت، حریم خصوصی، عملیات و پاسخ به رخداد، صاحب تصمیم مشخص کنید.
شرط عبور: Risk Tier ثبت شده، امضاکنندگان متناسب با ریسک حاضرند و هیچ حوزه مهمی بدون مالک نمانده است.
نقشه جریان داده را از ورودی کاربر تا مدل، retrieval، لاگ، analytics و ابزارهای بیرونی بکشید. بپرسید چه داده شخصی یا محرمانه‌ای وارد می‌شود، کجا ذخیره می‌شود، چه مدت می‌ماند و چه کسی دسترسی دارد. داده غیرضروری را حذف یا ماسک کنید و دسترسی را بر پایه کمترین مجوز لازم بسازید.
Prompt نباید تنها دیوار امنیتی باشد. مجوز در لایه ابزار و backend اعمال شود؛ کاربر A حتی با دستور هوشمندانه نباید سند کاربر B را بازیابی کند.
شرط عبور: Data Flow، مبنای استفاده، retention، کنترل دسترسی، secrets، vendor review و تست نشت داده تأیید شده‌اند.
یک مجموعه کوچک از مثال‌های خوش‌ساخت کافی نیست. دیتاست Eval باید کارهای پرتکرار، موارد مرزی، زبان و لحن کاربران واقعی، ورودی ناقص، سند قدیمی، پاسخ ناموجود و نمونه‌های پرریسک را پوشش دهد. داده را به حداقل سه دسته تقسیم کنید: capability، regression و safety.
برای هر task معیار قبولی روشن بسازید: درستی، groundedness، امتناع مناسب، صحت citation یا رسیدن به وضعیت نهایی. در خروجی‌های ذهنی‌تر، rubric انسانی را با grader مدلی ترکیب و با داور متخصص کالیبره کنید. میانگین کل می‌تواند شکست یک بخش حساس را پنهان کند.
پروفایل GenAI چارچوب مدیریت ریسک NIST تست پیش از استقرار، حاکمیت، منشأ محتوا و گزارش رخداد را چهار محور اصلی می‌داند و ارزیابی مستمر توانایی‌ها و استحکام کنترل‌ها را توصیه می‌کند. این یعنی Eval یک گزارش یک‌باره نیست؛ با هر تغییر مدل، Prompt، منبع یا ابزار باید دوباره اجرا شود.
شرط عبور: آستانه قبولی و حداکثر خطای بحرانی پیشاپیش ثبت شده، regression نسبت به نسخه مبنا وجود ندارد و شکست‌ها بررسی شده‌اند.
Red Team را به چند ناسزا محدود نکنید. Prompt Injection مستقیم و غیرمستقیم، استخراج دستور سیستم، نشت داده، دورزدن نقش‌ها، ورودی بسیار طولانی، فایل آلوده، منبع بازیابی مسموم، درخواست خارج از دامنه و استفاده ابزاری غیرمجاز را آزمایش کنید.
راهنمای ایمنی OpenAI علاوه بر moderation، آزمایش خصمانه، نظارت انسانی، محدودکردن ورودی و خروجی، امکان گزارش مشکل و توضیح محدودیت‌ها را توصیه می‌کند. نتیجه Red Team باید به کنترل قابل‌آزمون تبدیل شود؛ عبارت «مدل نباید فریب بخورد» معیار نیست، اما «هیچ ورودی بازیابی‌شده‌ای اجازه تغییر گیرنده پرداخت ندارد» قابل تست است.
شرط عبور: سناریوهای abuse متناسب با محصول اجرا شده‌اند، آسیب بحرانی باز حل‌نشده وجود ندارد و rate limit، audit و مسیر گزارش فعال‌اند.
به کاربر بگویید با AI روبه‌روست، سیستم چه کاری می‌کند و کجا ممکن است خطا کند. citation قابل بازکردن، زمان سند، گزینه ویرایش، رد پیشنهاد و ارجاع به انسان را در لحظه تصمیم قرار دهید.
از ۲ اوت ۲۰۲۶، بخشی از الزامات شفافیت AI Act اروپا لازم‌الاجرا شده‌اند. راهنمای کمیسیون اروپا درباره شفافیت بر اطلاع‌دادن تعامل با AI و قابل‌شناسایی‌کردن برخی محتوای تولیدی یا دستکاری‌شده تأکید دارد. حتی اگر محصول شما مشمول این قانون نیست، افشای روشن و به‌موقع یک الگوی اعتمادساز است، نه متن پنهان در Terms.
برای طراحی حالت‌های loading، uncertainty، refusal، correction و recovery، راهنمای تجربه کاربری محصولات هوش مصنوعی را کنار این Gate بگذارید.
شرط عبور: کاربر ماهیت AI، محدودیت، منبع، راه اصلاح و مسیر انسان را در جریان اصلی و حالت خطا می‌بیند.
Human in the Loop یعنی فرد بررسی‌کننده زمینه، زمان و اختیار توقف دارد. اگر فقط دکمه «تأیید» را زیر یک خروجی طولانی بگذارید، احتمال automation bias بالا می‌رود. سند اصلی، تغییر پیشنهادی، دلیل یا evidence و اثر اقدام را کنار هم نشان دهید.
اقدام‌های برگشت‌ناپذیر یا اثرگذار بر پول، حق کاربر، انتشار عمومی و داده حساس باید تأیید صریح داشته باشند. برای موارد مبهم، escalation بسازید و SLA پاسخ انسان را تعریف کنید. اگر انسان در دسترس نیست، سیستم باید safely fail کند، نه اینکه اختیار بیشتری بگیرد.
شرط عبور: نقاط تأیید، نقش بررسی‌کننده، اطلاعات لازم، SLA و رفتار در نبود انسان با تست انتها‌به‌انتها تأیید شده‌اند.
کیفیت بدون latency و قابلیت اطمینان قابل قبول، تجربه خوبی نمی‌سازد. p50 و p95 زمان پاسخ، timeout، rate limit، سقف token، هزینه هر task و بودجه ماهانه را بسنجید. سپس قطعی مدل، vector store و ابزار بیرونی را آزمایش کنید.
Fallback می‌تواند جست‌وجوی سنتی، ذخیره draft یا انتقال به انسان باشد. برای تغییر مدل یا Prompt نیز version، feature flag و امکان بازگشت مستقل داشته باشید.
شرط عبور: SLO، سقف هزینه، alert، timeout، fallback و ظرفیت پشتیبانی زیر بار واقع‌بینانه آزموده شده‌اند.
پیش از rollout مشخص کنید چه چیزی ثبت می‌شود: نسخه مدل و Prompt، منبع‌های بازیابی‌شده، ابزارهای فراخوانی‌شده، latency، هزینه، refusal، escalation، feedback و outcome. لاگ باید برای debugging کافی باشد اما داده حساس را بی‌دلیل نگه ندارد.
داشبورد را به سه لایه تقسیم کنید: سلامت سیستم، کیفیت AI و نتیجه محصول. آستانه alert، on-call، مسیر ارتباط با کاربر و postmortem را پیش از رخداد تعریف کنید. راهنمای اعتماد و مدیریت خطا در محصولات هوش مصنوعی الگوی کامل‌تری برای این بخش دارد.
شرط عبور: dashboard، alert، feedback، playbook رخداد و مالک کشیک پیش از ورود نخستین کاربر آماده‌اند.
از عرضه هم‌زمان برای همه شروع نکنید. ابتدا dogfood داخلی، سپس پایلوت، درصد کمی از ترافیک و در نهایت گسترش مرحله‌ای. هر مرحله باید معیار خروج و گاردریل داشته باشد.
Kill Switch باید واقعاً کار کند. تیم باید بتواند قابلیت، یک ابزار، یک مدل یا یک منبع داده را بدون deploy پیچیده غیرفعال کند. Rollback را یک‌بار در محیط نزدیک به تولید تمرین و زمان بازیابی را ثبت کنید.
شرط عبور: برنامه درصدی rollout، معیار گسترش، آستانه توقف، صاحب تصمیم و rollback آزمایش‌شده وجود دارد.
فرض کنید AI برای کارشناس پشتیبانی draft پاسخ می‌سازد. Eval روی ۲۰۰ تیکت واقعیِ ناشناس‌شده، صحت سیاست مرجوعی را ۹۷ درصد نشان می‌دهد، اما در تیکت‌های کالای تخفیف‌دار فقط ۸۴ درصد است. میانگین خوب به نظر می‌رسد، ولی همان بخش می‌تواند زیان مالی و بی‌اعتمادی بسازد.
تصمیم درست الزاماً توقف کامل نیست. تیم می‌تواند با Go مشروط عرضه کند: کاربران داخلی منتخب، فقط دسته‌های غیرتخفیفی، citation اجباری، ارسال صرفاً با تأیید کارشناس، alert روی اصلاح اساسی و خاموش‌بودن خودکار دسته تخفیفی. هم‌زمان نمونه‌های شکست به regression suite اضافه می‌شوند. وقتی آستانه آن بخش عبور کرد، دامنه گسترش می‌یابد.
«Go مشروط» نباید قبرستان بدهی باشد. هر شرط باید ریسک، اقدام، مالک، موعد و معیار بسته‌شدن داشته باشد. پذیرش ریسک بحرانی فقط با فرد دارای اختیار انجام می‌شود، نه با سکوت جلسه.
عرضه قابلیت AI یک لحظه نیست؛ قراردادی عملی میان محصول، مهندسی، طراحی، داده، امنیت، حقوقی و عملیات است. تیم خوب به‌دنبال اثبات بی‌نقص‌بودن مدل نیست؛ دامنه‌ای پیدا می‌کند که در آن ارزش قابل‌اندازه‌گیری است، خطا دیده و مهار می‌شود و بازگشت ممکن است.
برای شروع، Release Brief همین مقاله را برای یک قابلیت واقعی پر کنید و فقط سه عدد را بدون ابهام بنویسید: حداقل کیفیت قابل قبول، حداکثر خطای بحرانی و آستانه توقف rollout. اگر برای نقد Eval یا اجرای جلسه Go/No-Go کمک می‌خواهید، پروداکت کلاب راه چابکی، دوره AI Native Product Manager و منتورینگ مدیریت محصول مسیرهای عملی بعدی‌اند.
