شکاف مهندسی؛ دلیل شکست ۸۵٪ از پروژه‌های هوش مصنوعی

تصور کنید ماه‌ها بودجه و زمان صرف ساخت یک قابلیت هوش مصنوعی کرده‌اید، اما در لحظهٔ استقرار متوجه می‌شوید که سیستم حتی نمی‌تواند یک پاسخ صحیح را از غلط تشخیص دهد. این کابوسِ مدیران محصول است؛ چرا که طبق گزارش Teamvoy، بیش از ۸۵٪ پروژه‌های هوش مصنوعی هرگز به پتانسیل کامل خود نمی‌رسند. به نقل از ژانا یوسکویچ (Zhanna Yuskevych)، مدیر محصول Teamvoy، مقصر اصلی به‌ندرت خودِ مدل است. موانع واقعی در لایه‌های زیرساخت، بهداشت داده‌ها، حاکمیت سازمانی و کمبود مهارت‌های مهندسی نهفته‌اند؛ حوزه‌هایی که نظرسنجی‌های استانداردِ «سنجش آمادگی» معمولاً از آن‌ها می‌گذرند.

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

چارچوب خودارزیابی

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

نقاط بازرسی حیاتی

بر اساس مستندات این چارچوب، موارد زیر باید بررسی شوند:

• استراتژی: آیا یک ابتکار مشخص با خروجی تجاری تعریف‌شده وجود دارد یا برنامه فقط «کاوش در هوش مصنوعی» است؟
• داده‌ها: آیا تیم می‌تواند منبع دقیق داده‌ها را نام ببرد و تایید کند که داده‌ها برای اعتماد کافی، پاک هستند؟
• زیرساخت: آیا سیستم فعلی از تأخیر (Latency) و مقیاس‌پذیری مورد نیاز پشتیبانی می‌کند یا نیاز به بازسازی دارد؟
• حاکمیت: آیا مالک مشخصی برای تصمیمات هوش مصنوعی و مسیر تایید مستند وجود دارد، یا مسئولیت در هیچ جای مشخصی نیست؟
• فرهنگ: آیا مهندسان سازنده، پیش از این با ابزارهای مورد نظر کار کرده‌اند یا این اولین تجربه آن‌ها تحت فشار ضرب‌الاجل است؟
• سلامت کد: آیا یک مهندس جدید می‌تواند کد را به‌سادگی بفهمد و قطعه‌ای از هوش مصنوعی را اضافه کند، یا فرآیند جذب (Onboarding) هفته‌ها زمان می‌برد؟
• پوشش ارزیابی: آیا راهی خودکار برای بررسی صحت خروجی مدل وجود دارد یا یک انسان باید آن را بخواند؟
• شواهد رگولاتوری: در صنایع حساس، آیا مستندات ریسک مدل، ردپای حسابرسی (Audit Trail) و پاسخ به محل استقرار داده‌ها امروز آماده است یا هر سه باید از صفر ساخته شوند؟

دو حوزه «سلامت کد» و «پوشش ارزیابی» اصلی‌ترین دلایل توقف نسخه‌های آزمایشی (Pilots) هستند. در حالی که ۸۸٪ سازمان‌ها از هوش مصنوعی استفاده می‌کنند، کمتر از ۲۰٪ آن‌ها نتایج هوش مصنوعی زاینده (Generative AI) — شبیه به آشپزی که در آن باید هر بشقاب غذا را قبل از سرو به دقت بچشید تا از کیفیتش مطمئن شوید — را به‌طور مشخص ردیابی می‌کنند. این شکست در اندازه‌گیری، از لایه مهندسی شروع می‌شود، نه استراتژی.

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

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

حاکمیت در صنایع رگولاتوری

برای شرکت‌های فعال در حوزه‌های بانکی، پرداخت، وام‌دهی یا بیمه، «حاکمیت» یک ستون واحد نیست، بلکه ۶ الزام مجزا است که باید شواهدی قابل‌قبول برای طرف خارجی ارائه دهند:

• مدیریت ریسک مدل: اعتبارسنجی‌هایی شبیه به استاندارد SR 11-7 که شامل تاییدکننده مدل، پارامترهای تست و نظارت بر رانش (Drift) پس از استقرار باشد.
• ردپای حسابرسی: هر تصمیم مدل که بر تراکنش واقعی اثر می‌گذارد باید قابل بازیابی باشد، نه اینکه فقط در لاگ‌ها ثبت و فراموش شود.
• محل استقرار داده‌ها: مکان فیزیکی داده‌های آموزش و استنتاج؛ به‌ویژه اطمینان از اینکه ارائه‌دهندگان خارج از اتحادیه اروپا به داده‌های مشتریان اروپایی دسترسی ندارند.
• طبقه‌بندی قانون هوش مصنوعی اتحادیه اروپا: تعیین اینکه آیا قابلیت «پرریسک» است یا خیر، که بار مستندات را پیش از استقرار تغییر می‌دهد.
• SOC 2 و PCI DSS: اثبات اینکه لایه هوش مصنوعی، حفره‌ای در کنترل‌های امنیتی موجود ایجاد نکرده است.
• FFIEC و NYDFS Part 500: برآورده کردن انتظارات بازرسان درباره ریسک شخص ثالث در مورد تامین‌کنندگان هوش مصنوعی و تصمیمات تولید شده توسط AI.

شکست در این موارد فقط پروژه را به تاخیر نمی‌اندازد، بلکه شکست را به مرحلهٔ بررسی انطباق (Compliance) منتقل می‌کند، جایی که هزینه اصلاح آن به‌شدت افزایش می‌یابد.

دیدگاه استارتاپ‌های AI-Native

استارتاپ‌های متولد شده در عصر هوش مصنوعی با چالشی معکوس روبرو هستند: عبور از بررسی‌های امنیتی خریداران سازمانی. آن‌ها برای بستن یک قرارداد باید به ۵ سوال پاسخ دهند:

۱. جداسازی چندمستاجری (Multi-tenancy): آیا داده‌ها، پرامپت‌ها یا مصنوعات Fine-tuning یک مشتری می‌تواند به جلسه مشتری دیگر نفوذ کند؟ این همیشه اولین سوال است.
۲. بلوغ سیستم ارزیابی: وجود یک سیستم خودکار برای مسیرهای چندمرحله‌ای به‌جای بررسی‌های تصادفی قبل از انتشار.
۳. زیرساخت RAG: مدیریت نسخه‌های اسناد، کنترل دسترسی در سطح تکه‌های داده (Chunk) و شناسایی ایندکس‌های قدیمی.
۴. مانیتورینگ عملیاتی: قابلیت مشاهده‌پذیری (Observability) روی هر فراخوانی مدل و ابزار برای ردیابی خروجی‌های بد به ورودی دقیق مربوطه.
۵. آمادگی SOC 2: اینکه وضعیت امنیتی واقعی باشد، نه فقط ادعایی در اسلایدهای معرفی (Pitch Deck).

جلوگیری از تبدیل ابزارها به «زینت قفسه»

با این تغییر دیدگاه، نمره ۶۰٪ در سنجش آمادگی را نباید به عنوان یک نمره قبولی یا مردودی دید، بلکه باید آن را یک «لیست کارهای ضروری» دانست. انتظار برای نمره کامل، پروژه‌هایی را به تاخیر می‌اندازد که شاید تنها با سه اصلاح فنی کوچک، قابل عرضه باشند.

رایج‌ترین اشتباهاتی که باعث می‌شود نتایج ارزیابی‌ها به «زینت قفسه» (Shelfware) تبدیل شوند، عبارتند از: اجرای ارزیابی بدون حضور مهندسانی که قرار است قابلیت را بسازند، تلقی نمره به عنوان حکم نهایی، یا انتخاب ابزار بر اساس شهرت برند به‌جای دامنه کاربرد. یک ابزار استراتژیک می‌گوید آیا مدیریت هم‌سو است یا خیر؛ اما یک ابزار مهندسی می‌گوید آیا کدبیس توان تحمل این برنامه را دارد یا نه. این دو جایگزین یکدیگر نیستند.

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

گام بعدی شما

• اگر در حال مدیریت پروژه AI هستید، از تیم مهندسی بخواهید به جای مدیران، به ۸ سوال چارچوب یوسکویچ پاسخ دهند.
• سیستم ارزیابی انسانی خود را به یک سیستم ارزیابی خودکار (Automated Eval Harness) تبدیل کنید تا از فروپاشی در مقیاس جلوگیری شود.
• در صورت فعالیت در صنایع رگولاتوری، لیست الزامات SOC 2 و EU AI Act را پیش از شروع کدنویسی با تیم حقوقی چک کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.