پروژهٔ AI را ادامه دهیم، اصلاح کنیم یا متوقف؟

Go/No-Go پروژه با چه تصمیمی فرق دارد؟

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

این سؤال با چند موضوع نزدیک یکی نیست:

Go/No-Go پروژه پرسش متحرک‌تری است: با شواهد تازه، آیا ادامه‌دادن همین initiative در همین دامنه و با همین منابع هنوز بهترین گزینه است؟

• Business case می‌پرسد چرا ارزش دارد روی ایده سرمایه‌گذاری کنیم و فرض‌های اولیهٔ منفعت/هزینه چیست.
• ارزیابی قابلیت پیش از launch می‌سنجد آیا یک محصول یا feature برای انتشار، در شرایط و معیارهای مشخص آماده است.
• مدیریت portfolio می‌گوید با چند پروژهٔ هم‌زمان، منابع را چگونه میان فرصت‌ها تقسیم کنیم.
• Sunset قابلیت دربارهٔ خاموش‌کردن یا جایگزین‌کردن یک feature عملیاتی است.
• طراحی پایلوت مشخص می‌کند چه چیزی و چگونه آزمایش شود؛ این مقاله معیار ادامهٔ پروژه را پس از طراحی آزمایش بررسی می‌کند.
• بازبینی ۳۰روزهٔ پس از launch outcome محصول live را می‌سنجد؛ Go/No-Go دربارهٔ ادامهٔ همان initiative در نقطه‌های تصمیم پروژه است.

آنچه منابع رسمی می‌گویند

NIST در AI Risk Management Framework کارکرد Map را برای ساختن context، فهم هدف، کاربران، آثار، محدودیت‌ها و risk tolerance معرفی می‌کند. NIST می‌گوید نتیجهٔ این شناخت می‌تواند به تصمیم اولیه دربارهٔ نیاز یا تناسب طراحی، توسعه یا استقرار یک سیستم AI کمک کند. اگر تصمیم ادامه باشد، Measure و Manage به ارزیابی و رسیدگی پیوسته به ریسک کمک می‌کنند. این چارچوب داوطلبانه است و کارکردهایش چک‌لیست یا توالی اجباری برای هر سازمان نیستند. صفحهٔ رسمی NIST می‌گوید نسخهٔ ۱٫۰ در دست بازنگری است؛ هنگام استفاده باید نسخه و به‌روزرسانی‌های جاری را دوباره بررسی کرد.

یک منبع تازه‌تر، AI Risk Management Toolkit وزارت علوم، نوآوری و فناوری بریتانیاست که ۸ سپتامبر ۲۰۲۶ منتشر شد. این راهنما برای تیم‌های چندرشته‌ای پروژه‌های AI بخش عمومی بریتانیا نوشته شده و دربارهٔ risk appetite، پیامد مالی، ریسک فنی و حقوقی و بازبینی در چرخهٔ عمر راهنمایی می‌دهد؛ همچنین برای likelihood و impact هر ریسک شناسایی‌شده از مقیاس ۱ تا ۵ استفاده می‌کند. این امتیاز به سنجش ریسک کمک می‌کند و نمرهٔ کلی ارزش/سرمایه‌گذاری برای Go/No-Go نیست. برای شرکت‌های دیگر، پرسش‌های toolkit می‌تواند مفید باشد، اما راهنمای دولتی بریتانیاست، نه قانون جهانی یا فرمول آمادهٔ ادامه/توقف.

Digital, Data and Technology Playbook دولت بریتانیا، در زمینهٔ خرید و تحویل فناوری، از معیار روشن و breakpoint پایان مرحله برای ارزیابی وضعیت پایلوت، تناسب گسترش و تمدید یا توسعهٔ محدود می‌گوید. خود Playbook برای پروژه‌های جدید DDaT وزارتخانه‌های دولت مرکزی و سازمان‌های وابسته (ALBها) بر مبنای comply or explain الزامی است و از بخش عمومی گسترده‌تر انتظار می‌رود آن را مدنظر قرار دهد؛ این دامنه، الزام برای بخش خصوصی یا جهان نیست. برداشت اجرایی حکیم این است که نقطه‌های ادامه / مکث / توقف و تاریخ تصمیم را از پیش ثبت کنیم تا پایلوت بی‌تصمیم ادامه پیدا نکند؛ این سه‌گانه جمع‌بندی پیشنهادی ماست، نه فهرست عینی گزینه‌های Playbook.

پیش از دیدن نتیجه، برگهٔ تصمیم را ببندید

این شش بخش پیشنهاد اجرایی حکیم برای آماده‌کردن یک جلسهٔ Go/Pivot/Pause/Stop است:

۱. تصمیم و baseline را دقیق کنید: مشخص کنید چه چیزی در معرض تصمیم است: کدام فرایند، کدام کاربر، کدام مرحله و چه دامنه‌ای از اختیار AI. وضعیت فعلی را هم ثبت کنید: کار کاملاً انسانی، ابزار نرم‌افزاری معمولی، تغییر فرایند یا هیچ اقدامی.

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

۲. outcome را از output جدا کنید: «مدل جواب تولید کرد» یا «تیم از ابزار استفاده کرد» نتیجهٔ کسب‌وکار نیست. outcome را با کاری که برای کاربر، کارمند یا سازمان باید بهتر شود تعریف کنید. کنار آن یک معیار کیفیت یا زیان احتمالی بگذارید تا بهبود سرعت، افت دقت یا انتقال هزینه به تیم پشتیبانی را پنهان نکند.

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

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

هزینهٔ فرصت را هم نام ببرید: با ادامهٔ این پروژه چه قابلیت، مشتری یا بدهی فنی عقب می‌افتد؟ اگر عدد دقیق ندارید، دامنه و فرض را نشان دهید؛ تخمین نامطمئن را به‌صورت اندازه‌گیری قطعی ننویسید.

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

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

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

۶. معیار و تاریخ تصمیم را پیش از آزمایش ثبت کنید: یک معیار اصلی outcome، guardrailهای کیفیت/ریسک، دامنهٔ آزمایش، سقف منابع و موعد بازبینی بنویسید. مشخص کنید چه شواهدی تصمیم را از ادامه به pivot یا stop می‌برد و چه کسی نتیجه را تأیید می‌کند. اگر معیار را فقط بعد از دیدن نتیجه تعیین کنیم، ممکن است هر نتیجه‌ای را به‌نفع ادامه توجیه کنیم.

جلسه را به چهار خروجی روشن ببندید

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

• ادامه: معیارهای ازپیش‌تعیین‌شده به‌اندازهٔ کافی برآورده شده‌اند، outcome با baseline قابل‌مقایسه است، ریسک باقی‌مانده در risk appetite سازمان قرار دارد و مالک/ظرفیت اجرای مرحلهٔ بعد مشخص است. دامنه را فقط تا سطحی گسترش دهید که evidence پشتیبانی می‌کند.
• تغییر مسیر (pivot): مسئله همچنان مهم است، اما راه‌حل یا دامنهٔ فعلی ارزش را نشان نداده. یک فرض اصلی را عوض کنید، آن را با آزمایش کوچکتر بسنجید و معیار تازه را پیش از شروع ثبت کنید.
• مکث برای شواهد: یک ابهام مشخص مانع تصمیم است و می‌توان آن را با آزمایشی زمان‌دار، کم‌هزینه و امن پاسخ داد. مسئول جمع‌آوری داده، سقف کار و تاریخ برگشت به تصمیم را بنویسید؛ «بعداً بررسی می‌کنیم» برنامه نیست.
• توقف: outcome لازم در محدودهٔ آزمایش دیده نشده، گزینهٔ دیگری همان مسئله را با هزینه/ریسک کمتر حل می‌کند، ریسک از حد سازمان فراتر است، یا مالک و توان عملیاتی لازم وجود ندارد. دارایی، یادگیری و تعهد قراردادی را جمع‌بندی کنید و از ادامهٔ خودکار هزینه جلوگیری کنید.

AI در آماده‌کردن تصمیم چه نقشی دارد؟

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

trade-off اصلی، آماده‌شدن سریع‌تر جلسه در برابر اطمینان کاذب و نادیده‌گرفتن داده‌هایی است که به‌آسانی به عدد تبدیل نمی‌شوند: اعتماد، اثر بر کار، تجربهٔ کاربر و هزینهٔ انتقال به تیم دیگر. معیار بازبینی پیشنهادی: هر ادعا در برگهٔ تصمیم باید به منبع خام، فرض مشخص یا علامت unknown وصل باشد؛ model owner این ردیابی را بررسی کند.

تصمیم دربارهٔ سرمایه، تعهد به مشتری، risk appetite و خاموش‌کردن یا گسترش پروژه را sponsor انسانی می‌گیرد. مدیر فنی، risk owner و افراد متأثر باید ورودی بدهند؛ AI می‌تواند استدلال را مرتب کند، اما پاسخ‌گویی را صاحب نمی‌شود.

مثال فرضی: دستیار پاسخ به درخواست داخلی

مثال ساختگی برای توضیح چارچوب: تیمی دستیار AI برای پیدا‌کردن پاسخ در راهنمای داخلی ساخته است. در پایلوت، پاسخ‌های ساده زودتر پیدا می‌شوند، اما بخشی از سؤال‌های استثنایی هنوز نیاز به بررسی متخصص دارند و اسناد داخلی هم چند نسخهٔ قدیمی دارند.

تصمیم عجولانه ممکن است «یا همه‌چیز خودکار شود یا پروژه شکست خورده» باشد. برگهٔ تصمیم دامنه را جدا می‌کند: آیا مسئلهٔ اصلی فقط زمان جست‌وجو است؟ آیا اتصال به نسخهٔ معتبر اسناد ممکن است؟ برای سؤال‌های حساس چه کسی پاسخ را تأیید می‌کند؟

تیم می‌تواند به‌جای rollout کامل، pivot به یک copilot با ارجاع منبع و escalation انسانی را پیشنهاد کند؛ برای آن سناریوهای آزمایش، معیار کیفیت، سقف مصرف و تاریخ تصمیم مشخص می‌گذارد. اگر مشکل نسخهٔ اسناد حل نشد یا آزمون بعدی outcome مورد انتظار را نشان نداد، پروژه متوقف می‌شود. این فقط مثال تصمیم‌گیری است، نه گزارشی از نتیجهٔ واقعی.