«تأییدات اداری»؛ سدِ اصلی در مسیر تبدیل مدل‌های هوش مصنوعی به محصول

تصور کنید برنامه‌نویسی هستید که در یک بعدازظهر ابزاری می‌سازد که پیش از این ساختنش یک فصل کامل تلاش مهندسی زمان می‌برد، اما تا ژوئیه ۲۰۲۶، فرآیندهای بوروکراتیک برای تأیید آن پروژه همچنان همان شش هفته‌ای است که در سال ۲۰۱۵ بود. این تضاد شدید میان سرعت مهندسی و کندی بوروکراسی، دلیل اصلی مرگ خاموش ابتکارات هوش مصنوعی در شرکت‌های بزرگ است. هر هفته یک شرکت ابتکار جدیدی در زمینه هوش مصنوعی را اعلام می‌کند و هر هفته، پروژه دیگری در سکوت ناپدید می‌شود. توضیح معمول این است که تکنولوژی هنوز آماده نبود، اما واقعیت این است که مدل‌ها سریع‌تر از آن رشد می‌کنند که اکثر سازمان‌ها بتوانند آن‌ها را جذب و جذب نمایند. در حالی که تیم‌های فنی اکنون در چند ساعت نمونه‌های اولیه را می‌سازند، زیرساخت‌ها و ابزارها پیش از این بالغ و فراوان شده‌اند، اما فرآیندهای تأییدی همچنان بر اساس استانداردهای سال ۲۰۱۵ پیش می‌روند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی چالش‌های استقرار مدل‌های بازمتن اشاره کردیم، مشکل اصلی دیگر دسترسی به تکنولوژی نیست، بلکه توانایی سازمان در پذیرش سرعتِ این تکنولوژی است. این موضوع با یافته‌های پژوهش‌های گسترده‌تر همسو است، چرا که بسیاری از پروژه‌های هوش مصنوعی سازمانی به‌دلیل همین شکاف‌های ساختاری پیش از رسیدن به مرحله بهره‌برداری شکست می‌خورند.

این الگو جدید نیست. سازمان‌ها در زمان ظهور وب، رایانش ابری (Cloud Computing)، موبایل، سیستم‌های ERP و معماری‌های کلاینت-سرور (Client-Server) نیز همین کشمکش را داشتند. در هر یک از این موج‌ها، فورانی از اشتیاق منجر به ایجاد دم‌درازی از پروژه‌های آزمایشی (Pilot) شد که هرگز به مرحله تولید (Production) نرسیدند. رشته مشترک در تمامی این موارد، هرگز بلوغ تکنولوژی نبود، بلکه شکست مدیریت در تکامل همگام با ابزارها بود.

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

نابرابری انگیزه‌ها در تصمیم‌گیری

تکانه (Momentum) پروژه‌ها معمولاً روی میز کسی می‌میرد که باید بودجه، دسترسی به داده‌ها، تدارکات یا استقرار در محیط تولید را تأیید کند. این اتفاق به‌ندرت به‌دلیل ترس یا تردید فردی است و بیشتر به انگیزه‌های متضاد و نامتقارن بازمی‌گردد:

• ریسک «بله»: پروژه‌ای که تأیید شده باشد و سپس شکست بخورد، اثری مرئی بر سابقه تصمیم‌گیرنده می‌گذارد. شکست آن پروژه، نام او را بر پیشانی خود دارد.
• امنیت «نه»: رد کردن پروژه‌ای که می‌توانست موفق شود، هیچ هزینه مرئی ندارد؛ زیرا حالت جایگزین (Counterfactual) نامرئی است و هیچ‌کس برای هزینه‌ای که هرگز پرداخت نشده یا سودی که هرگز به دست نیامده، بازخواست نمی‌شود.

در این شرایط، عبارت «هنوز زود است» به انتخاب منطقی برای یک فرد تبدیل می‌شود، حتی اگر برای کل شرکت یک فاجعه تدریجی ایجاد کند. شما نمی‌توانید این مشکل را با تشویق‌ها یا برگزاری جلسات عمومی (All-hands) درباره «جسور بودن» حل کنید. در عوض، مدیریت باید هزینه تصمیم‌گیری را با استفاده از دو اهرم مشخص تغییر دهد:

۱. کوچک کردن شرط (Shrink the bet): اندازه پروژه را تا حدی کاهش دهید که تأیید آن دیگر یک ریسک تعیین‌کننده برای مسیر شغلی نباشد.
۲. تعیین سقف بودجه و محدوده اثر (Blast-radius ceiling): یک عدد واقعی و مکتوب را تعیین کنید که زیر آن، هیچ‌کس به هیچ‌گونه تأییدیه نیاز نداشته باشد. این کار باعث می‌شود ترافیک تأییدات از درخواست‌های کوچک و بی‌فایده که هرگز آن‌قدر بزرگ نبودند که نیاز به اجازه داشته باشند، پاک شود.

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

شکاف انضباطی در نمونه‌های اولیه

بسیاری از پروژه‌های آزمایشی شکست می‌خورند چون بر اساس «حس خوب» (Vibe) ساخته شده‌اند و نه شواهد. یک ابتکار ممکن است خروجی‌های پذیرفتنی تولید کند و در دمو عالی به نظر برسد، اما وقتی نوبت به بودجه‌بندی واقعی می‌رسد، مشخص می‌شود هیچ‌کس هرگز تعریف نکرده که «موفقیت» یعنی چه، هیچ‌کس فرآیند را پیش از خودکارسازی اندازه‌گیری نکرده و هیچ مبنایی (Baseline) برای مقایسه وجود ندارد.

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

• کدام مورد به‌طور مشخص سریع‌تر، ارزان‌تر یا بهتر می‌شود؟
• چگونه متوجه این بهبود خواهیم شد (از طریق چه معیاری)؟
• چه عددی/معیاری باعث می‌شود تصمیم بگیریم پروژه را متوقف کنیم؟

۱۵ دقیقه برنامه‌ریزی در ابتدا، تفاوت میان پروژه‌ای است که به محصول تبدیل می‌شود و پروژه‌ای که به‌دلیل نبود دفاعیه از داده‌ها و تکیه بر روایت‌های پراکنده، بودجه‌اش در سکوت قطع می‌شود.

تله مالکیت

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

وقتی تیم مهندسی پیشنهاد می‌دهد که نمونه را با معماری درست، امنیت، تست‌ها و سیستم‌های نظارتی (Observability) بازسازی کنند، بحث دیگر فنی نیست. پرسش از «چه چیزی برای شرکت بهتر است» به این تغییر می‌کند که «چه کسی مالک این است». رها کردن پروژه سخت‌ترین بخش است و سازمان‌ها به‌طور مداوم دست‌کم می‌گیرند که چقدر از ظرفیت تحویل محصول، به‌دلیل این تک emotion (احساس) رسیدگی‌نشده از دست می‌رود.

برای حل این موضوع، انتقال پروژه باید شبیه به یک «ترفیع» باشد، نه «مصادره»:

• شناخت عمومی: نام پدیدآورنده به‌طور علنی و دائمی به عنوان خالق ثبت شود.
• همکاری مستمر: پدیدآورنده به‌عنوان مالک محصول یا متخصص موضوعی (SME) در پروژه باقی بماند، در حالی که مهندسان ساخت فنی را بر عهده می‌گیرند.
• مسیر ارتقای تعریف‌شده: بازسازی پروژه را به عنوان یک فرآیند رسمی «فارغ‌التحصیلی» (Graduation) با مسیری شفاف معرفی کنید تا کسی غافلگیر نشود.

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

انتظار منطقی در برابر انتظار بازتابی

گاهی صبر کردن حرکت صحیحی است؛ به‌ویژه در محیط‌هایی با مقررات سخت‌گیرانه که هنوز با تکنولوژی هماهنگ نشده‌اند، یا زمانی که یک حالت شکست (Failure mode) منجر به نشت داده‌های حساس یا ارائه پاسخی مادی-اشتباه به مشتری در مقیاس گسترده شود. اگر ارزش مورد انتظار (Expected value) صادقانه منفی باشد، توقف یک «تصمیم» است، نه «فرار». حاکمیت (Governance) با بوروکراسی یکی نیست؛ برخی از قوانین به این دلیل وجود دارند که در گذشته آسیبی پرهزینه رخ داده است.

تفاوت در این است که آیا این انتظار منطقی است یا بازتابی (Reflexive):

• انتظار منطقی: شرط دقیقی را نام می‌برد که منتظرش است و تاریخی را تعیین می‌کند که تصمیم دوباره بررسی شود.
• انتظار بازتابی: هیچ شرطی نمی‌گوید، چیزی را بازبینی نمی‌کند و تا ابد تکرار می‌شود در حالی که نام خود را «احتیاط» می‌گذارد.

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

وقتی این تست شکست می‌خورد، شما باید خودتان پاسخ را در یک پیشنهاد یک‌صفحه‌ای بنویسید که شامل شرطِ «بله» گفتن، تاریخ بازبینی و هزینه تأخیر با واحدهایی باشد که سازمان به آن‌ها اهمیت می‌دهد (مثلاً هزینه دلاری یا فرصت از دست رفته). این را برای تصمیم‌گیرنده بفرستید تا اصلاح کند. یا آن‌ها وارد عمل شده و پروژه را باز می‌کنند، یا به‌طور مکتوب رد می‌کنند—که بسیار مفیدتر از سکوت است. اکثر ابتکارات متوقف‌شده هرگز رد نمی‌شوند؛ آن‌ها صرفاً هرگز آن‌قدر ملموس نمی‌شوند که بتوان در موردشان رد یا قبول داد.

مکانیزم‌های سازمان‌های برنده

شرکت‌هایی که در رقابت هوش مصنوعی پیروز می‌شوند، لزوماً مدل‌های بهتری نمی‌خرند—چون اکثر شرکت‌ها به مدل‌های یکسان با قیمت مشابه در یک بازه زمانی یکسان دسترسی دارند. دسترسی به مدل، عامل تمایز نیست. در عوض، آن‌ها مکانیزم‌های مدیریتی «خسته‌کننده، مشخص و پایدار» را پیاده می‌کنند:

• ضرب‌الاجل‌های تصمیم‌گیری ثابت: هر درخواست بودجه، دسترسی یا استقرار باید در یک پنجره زمانی مشخص پاسخ داده شود. اگر پاسخ داده نشود، به‌طور خودکار به سطح مدیریت بالاتر ارجاع (Escalate) می‌شود بدون اینکه درخواست‌کننده نیاز به شروع فرآیند ارجاع داشته باشد.
• سندباکس‌های پیش‌تأیید (Pre-authorized Sandboxes): یک بودجه نام‌گذاری شده، یک مجموعه داده مشخص و حریم‌های حفاظتی (Guardrails) مکتوب که در آن هیچ اجازه‌ای نیاز نیست. یک مالک ارشد این سقف را دفاع کرده و سالی دو بار بازبینی می‌کند.
• استانداردهای تفکیک‌شده: دو سند مجزای یک‌صفحه‌ای که معیارهای «آزمایش» (Experimentation) در برابر «تولید» (Production) را تعریف می‌کنند. این کار باعث می‌شود بحث بر سر اینکه «آیا این مدل به اندازه کافی خوب است» متوقف شود، چون مشخص است کدام صفحه اعمال می‌شود.
• مسیرهای مکتوب فارغ‌التحصیلی: برنامه‌ای پیش‌تعیین‌شده قبل از شروع پروژه که با جزئیات مشخص کند چه کسی مالک می‌شود، چه چیزی بازسازی می‌گردد، پدیدآورنده چه چیزی را حفظ می‌کند و جدول زمانی انتقال چگونه است.
• مالکان پیش‌فرض: تعیین یک شخص (نه یک تیم یا کمیته) که هر ابتکاری را که برای مدتی مشخص بدون مالک ماند، به ارث ببرد. این کار ابهام را به اقدام یا تصمیمی صریح برای توقف تبدیل می‌کند.

استراتژی‌های مشارکت‌کنندگان فردی (IC)

برای کسانی که نمی‌توانند سیاست‌های شرکت را تغییر دهند یا ضرب‌الاجل‌های تصمیم‌گیری را نصب کنند، حرکت‌های متفاوتی در دسترس است:

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

شکاف واقعی

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

هوش مصنوعی یک شکاف تکنولوژیک را آشکار نمی‌کند؛ بلکه یک شکاف مدیریتی را افشا می‌کند. شرکت‌هایی که این موضوع را زودتر تشخیص دهند، نه به‌دلیل داشتن هوش مصنوعی بهتر، بلکه به‌دلیل تبدیل شدن به سازمان‌های بهتر پیروز خواهند شد—و این مزیت، مدت‌ها پس از اینکه عرضه هر مدل خاص دیگر اهمیتی نداشت، به‌صورت ترکیبی (Compound) رشد خواهد کرد.

گام بعدی شما

• اگر پروژه‌ای در سازمانتان متوقف شده، یک پیشنهاد یک‌صفحه‌ای بنویسید که در آن شرط «بله» گفتن و هزینه تأخیر را به‌طور عددی بیان کنید.
• برای هر ابزاری که می‌سازید، ابتدا معیارهای موفقیت (KPI) را مکتوب کنید تا در جلسه بودجه به‌جای «حس خوب»، عدد ارائه دهید.
• محیط‌های کوچک و بدون نیاز به اجازه (Sandboxes) را در تیم خود شناسایی کرده و حداکثر ظرفیت آن‌ها را برای تست سریع مدل‌ها به کار بگیرید.

اما این گلوگاه مدیریتی تنها بخشی از داستان است؛ اثر این کندی بر انتخاب سخت‌افزارهای مقیاس‌بزرگ را در تحلیل ما درباره تراشه‌های Blackwell بررسی کنید.