مقالهایجنت‌های هوش مصنوعی
چرا بیش از ۴۰٪ پروژههای ایجنت هوش مصنوعی متوقف می‌شوند؟ ۷ دلیل و راه پیشگیری
گارتنر در ژوئن ۲۰۲۵ پیشبینی کرد بیش از ۴۰ درصد پروژههای هوش مصنوعی عاملمحور تا پایان ۲۰۲۷ به دلیل هزینه رو به افزایش، ارزش تجاری نامشخص یا کنترل ناکافی ریسک لغو شوند. هفت دلیل اصلی توقف: انتخاب مسئله نادرست، نبود خط پایه و معیار، هزینه پنهان، کنترل ریسک ضعیف، داده آماده‌نشده، ایجنتشویی و نبود مالک و پذیرش. راه پیشگیری شروع از یک فرایند پرچم، یک قابلیت و معیار دقت روشن با تأیید انسان است.
خلاصه در چند نکته
- پیشبینی گارتنر درباره پروژههای عاملمحور است، نه همه پروژههای هوش مصنوعی.
- بسیاری از کاربردهای «ایجنتی» اصلاً به ایجنت نیاز ندارند.
- بدون خط پایه و معیار مکتوب، ارزش پروژه قابل اثبات نیست.
- هزینه را برای هر کار تمام‌شده برآورد کنید، نه هر فراخوانی مدل.
- ۷۸٪ سازمان‌های دارای ایجنت عملیاتی در گزارش Contentstack با مشکل آمادگی داده روبه‌رو شدند.
- گارتنر تنها حدود ۱۳۰ فروشنده از هزاران مدعی را ایجنت واقعی می‌داند.
- الگوی کم‌ریسک: یک فرایند، یک قابلیت، معیار دقت روشن.
فهرست مطالب
در ژوئن ۲۰۲۵، مؤسسه گارتنر پیشبینی کرد که بیش از ۴۰ درصد پروژههای هوش مصنوعی عاملمحور تا پایان سال ۲۰۲۷ لغو خواهند شد. دلایلی که گارتنر برشمرد سه مورد بود: هزینه‌های رو به افزایش، ارزش تجاری نامشخص و کنترل ناکافی ریسک. به گفته تحلیلگر این مؤسسه، بیشتر پروژههای ایجنتی در آن زمان آزمایش‌های اولیه یا اثبات مفهومی بودند که عمدتاً تحت تأثیر هیاهو پیش می‌رفتند و اغلب در جای نادرست به کار گرفته می‌شدند.
این عدد برای سازمان‌های ایرانی که تازه به ایجنت‌ها فکر می‌کنند، یک هشدار و یک فرصت است. هشدار، چون نشان می‌دهد حتی سازمان‌های بزرگ با بودجه کافی هم در این مسیر زمین میخورند. فرصت، چون دلایل شکست شناخته‌شده‌اند و می‌توان از آنها پیشگیری کرد. در این مقاله هفت دلیل اصلی توقف پروژههای ایجنت را بررسی می‌کنیم و برای هرکدام راه پیشگیری عملی پیشنهاد می‌دهیم.
پیش از شروع: این عدد دقیقاً چه می‌گوید؟
نقل دقیق اهمیت دارد. پیشبینی گارتنر درباره پروژههای هوش مصنوعی عاملمحور است، نه همه پروژههای هوش مصنوعی. این یک پیشبینی تحلیلی است، نه آمار پروژههای شکست‌خورده. همان گزارش اشاره می‌کند که در نظرسنجی ژانویه ۲۰۲۵ از ۳٬۴۱۲ شرکت‌کننده یک وبینار، ۱۹ درصد گفته‌اند سازمانشان سرمایه‌گذاری قابل‌توجهی روی هوش مصنوعی عاملمحور کرده، ۴۲ درصد سرمایه‌گذاری محتاطانه، ۸ درصد هیچ سرمایه‌گذاری و ۳۱ درصد در حال صبر و تماشا یا نامطمئن بوده‌اند. گارتنر در عین حال پیشبینی کرده تا ۲۰۲۸ دست‌کم ۱۵ درصد تصمیم‌های روزمره کاری به‌صورت خودکار از طریق هوش مصنوعی عاملمحور گرفته شود. بنابراین پیام اصلی «ایجنت‌ها شکست میخورند» نیست؛ پیام این است که ایجنت در جای نادرست شکست می‌خورد.
هفت دلیل اصلی توقف پروژههای ایجنت
دلایل زیر از گزارش‌های تحلیلی و تجربه پروژههای اتوماسیون جمع‌بندی شده‌اند. معمولاً یک پروژه شکست‌خورده نه با یک دلیل، بلکه با ترکیبی از دو یا سه مورد متوقف می‌شود.
دلیل ۱: انتخاب مسئله نادرست
بسیاری از پروژه‌ها از فناوری شروع می‌شوند، نه از مسئله. تیمی ابزار ایجنت را می‌بیند، شگفت‌زده می‌شود و دنبال جایی برای استفاده از آن می‌گردد. نتیجه، پروژه‌ای است که مشکل واقعی کسی را حل نمی‌کند. گارتنر صریحاً می‌گوید بسیاری از کاربردهایی که امروز «عاملمحور» معرفی می‌شوند، اصلاً به پیاده‌سازی عاملمحور نیاز ندارند.
راه پیشگیری: از فرایندی شروع کنید که امروز درد واقعی دارد: زمان چرخه طولانی، رفت‌وبرگشت زیاد یا حجم بالای کار تکراری. سپس بپرسید آیا این مشکل با یک قاعده، یک گردش کار یا یک دستیار ساده حل می‌شود. معیار تصمیم «ایجنت یا قاعده» را در مقاله گردش کار عاملمحور یا BPMS توضیح داده‌ایم. برای انتخاب فرایند هم مقاله کدام فرایندها را اول خودکار کنیم کمک می‌کند.
دلیل ۲: ارزش تجاری نامشخص و نبود خط پایه
پروژه‌ای که از ابتدا معیار موفقیت ندارد، در جلسه بودجه سال بعد دفاع‌ناپذیر است. «کارکنان راضی‌اند» یا «دموی خوبی بود» جای عدد را نمی‌گیرد. وقتی نمی‌دانید امروز یک کار چقدر طول می‌کشد، نمی‌توانید ثابت کنید ایجنت آن را سریع‌تر کرده است.
راه پیشگیری: پیش از پایلوت، دو یا سه شاخص را با مالک کسب‌وکار توافق کنید: زمان چرخه، نرخ خطا، تعداد درخواست رسیدگی‌شده در روز یا زمان صرف‌شده برای خواندن پرونده. خط پایه را از داده واقعی بگیرید. معیار قبول پایلوت را هم مکتوب کنید؛ مثلاً «اگر دقت استخراج فیلد در نمونه واقعی به حد توافق‌شده نرسید، گسترش نمی‌دهیم».
دلیل ۳: هزینه‌ای که در دمو دیده نمی‌شد
هر گام ایجنت یعنی یک یا چند فراخوانی مدل. کاری که در دمو با ده درخواست ارزان به نظر می‌رسید، در مقیاس هزاران درخواست روزانه و با گام‌های تکراری یا حلقه‌های خطا، هزینه محاسباتی سنگینی می‌سازد. به این باید هزینه یکپارچه‌سازی با سامانه‌های قدیمی، نگه‌داری، نظارت و آموزش را هم اضافه کرد. گارتنر تأکید می‌کند که ادغام ایجنت با سامانه‌های قدیمی می‌تواند از نظر فنی پیچیده باشد و گردش‌های کاری را مختل کند.
راه پیشگیری: هزینه هر کار تمام‌شده را برآورد کنید، نه هزینه هر فراخوانی. برای تعداد گام و مصرف سقف بگذارید. ساده‌ترین معماری را که پاسخ می‌دهد انتخاب کنید؛ اغلب یک زنجیره ثابت با یک نقطه تصمیم مدل، ارزان‌تر و پایدارتر از ایجنت آزاد است.
دلیل ۴: کنترل ریسک ناکافی
ایجنتی که به ایمیل، سامانه مالی و بایگانی دسترسی گسترده دارد، در صورت اشتباه یا فریب‌خوردن می‌تواند آسیب جدی بزند. تزریق پرامپت، یعنی پنهان‌کردن دستور در یک سند یا ایمیل که ایجنت آن را می‌خواند، یکی از ریسک‌های شناخته‌شده‌ای است که پروژه OWASP در فهرست ده ریسک برتر کاربردهای مدل زبانی در رتبه نخست آورده است. وقتی واحد امنیت یا حقوقی دیر وارد پروژه می‌شود، معمولاً پروژه در آستانه بهره‌برداری متوقف می‌شود.
راه پیشگیری: از روز اول، اصل «حداقل دسترسی لازم» را اجرا کنید: ایجنت فقط به ابزار و داده‌ای دسترسی داشته باشد که برای آن کار مشخص لازم است و همیشه در محدوده نقش کاربر. برای اقدام‌های پرریسک نقطه تأیید انسانی بگذارید و همه پیشنهادها و اقدام‌ها را ثبت کنید. امنیت و حقوقی را در طراحی شریک کنید، نه در تأیید نهایی.
دلیل ۵: داده آماده نیست
ایجنت فقط به اندازه داده‌ای که می‌خواند خوب است. اسناد بدون نسخه، نامه‌های بدون طبقه‌بندی، پوشه‌های شبکه با نام‌گذاری بی‌قاعده و دانش پراکنده در ایمیل‌ها، کیفیت هر سامانه هوشمندی را پایین می‌آورد. در گزارش «سازمان عاملمحور ۲۰۲۶» شرکت Contentstack، ۷۸ درصد سازمان‌هایی که ایجنت را به بهره‌برداری رسانده بودند گفتند با مشکلات آمادگی محتوا و داده روبه‌رو شده‌اند که به بازکاری جدی یا کندی استقرار انجامیده و ۸۸ درصد گفتند کاش زودتر روی زیرساخت محتوا و داده سرمایه‌گذاری کرده بودند.
راه پیشگیری: پیش از ایجنت، داده را مرتب کنید: نسخه معتبر اسناد را مشخص کنید، برای هر مجموعه دانش مالک بگذارید، تاریخ اعتبار ثبت کنید و دسترسی‌ها را بازبینی کنید. این کار حتی اگر ایجنتی هم ساخته نشود، برای سازمان ارزشمند است.
دلیل ۶: «ایجنتشویی» و انتظار غیرواقعی
گارتنر از پدیده‌ای به نام ایجنتشویی (Agent Washing) نام برده است: بازنامگذاری محصولات موجود مثل دستیارهای هوش مصنوعی، RPA و چتباتها بدون قابلیت عاملمحور واقعی. برآورد این مؤسسه آن بود که از میان هزاران فروشنده مدعی، تنها حدود ۱۳۰ فروشنده واقعاً ایجنت ارائه می‌کنند. سازمانی که بر اساس وعده بازاریابی خرید کرده، پس از استقرار با فاصله میان انتظار و واقعیت روبه‌رو می‌شود.
راه پیشگیری: از فروشنده بخواهید یک سناریوی واقعی را روی داده نمونه شما زنده اجرا کند. بپرسید کدام گام بدون انسان انجام می‌شود، چگونه اشتباه کشف و برگردانده می‌شود و داده کجا پردازش می‌شود. وعده‌هایی مثل «حذف نیمی از نیروی انسانی در سه ماه» نشانه هشدار است.
دلیل ۷: نادیده‌گرفتن انسان‌ها و مالکیت
حتی ایجنت دقیق هم اگر کارکنان به آن اعتماد نکنند یا ندانند چه زمانی باید آن را اصلاح کنند، بلااستفاده می‌ماند. ترس از جایگزینی، نبود آموزش و نامشخص بودن اینکه «اگر ایجنت اشتباه کرد مسئول کیست»، پذیرش را کند می‌کند. در گزارش Contentstack، ۴۲ درصد مدیران گفتند نبود یک مالک داخلی مشخص، مستقیماً یک پروژه ایجنتی را در سازمانشان به تأخیر انداخته است.
راه پیشگیری: برای هر پروژه یک مالک کسب‌وکار تعیین کنید، نه فقط یک مدیر فنی. نقش کارکنان را از «انجام‌دهنده» به «بازبین و تأییدکننده» تعریف کنید و این تغییر را آموزش دهید. تجربه پروژههای اتوماسیون نشان می‌دهد که مدیریت تغییر به اندازه فناوری مهم است؛ مقاله مقاومت کارکنان در برابر اتوماسیون اداری همین موضوع را بررسی می‌کند.
جدول خلاصه: دلیل، نشانه هشدار، اقدام پیشگیرانه
| دلیل توقف | نشانه هشدار | اقدام پیشگیرانه |
|---|---|---|
| مسئله نادرست | «بیایید جایی برای ایجنت پیدا کنیم» | شروع از درد واقعی یک فرایند |
| ارزش نامشخص | معیار موفقیت مکتوب نیست | خط پایه و شاخص پیش از پایلوت |
| هزینه پنهان | برآورد فقط بر اساس دمو | هزینه هر کار تمام‌شده و سقف گام |
| ریسک کنترل‌نشده | دسترسی گسترده، امنیت دیر وارد شده | حداقل دسترسی، تأیید انسانی، ثبت سابقه |
| داده آماده نیست | اسناد بدون نسخه و مالک | پاک‌سازی و مالکیت داده پیش از شروع |
| ایجنتشویی | وعده‌های کلی بدون نمایش زنده | آزمون روی داده واقعی سازمان |
| نبود مالک و پذیرش | پروژه فقط در دست IT | مالک کسب‌وکار و برنامه آموزش |
الگوی کم‌ریسک: یک فرایند پرچم، یک قابلیت، معیار دقت روشن
جمع‌بندی همه این درس‌ها یک الگوی ساده است:
- یک فرایند پرچم انتخاب کنید که حجم بالا و ریسک متوسط یا پایین دارد.
- یک قابلیت را روشن کنید؛ مثلاً استخراج فیلد از پیوست یا خلاصه پرونده برای مدیر، نه «هوش همه‌جا».
- معیار دقت را با نمونه‌های واقعی و بازبینی کارشناس بسنجید.
- فرایند باید بدون هوش مصنوعی هم کار کند تا قطعی یا خطای مدل، کار را متوقف نکند.
- فقط پس از رسیدن به معیار، قابلیت دوم یا فرایند دوم را اضافه کنید.
این همان مسیری است که در نقشه راه پیاده‌سازی اتوماسیون اداری هم توصیه کرده‌ایم: گام‌های کوچک، قابل سنجش و قابل برگشت.
رویکرد آریا آی‌تی
آریا آی‌تی در خدمات پیاده‌سازی همین الگو را دنبال می‌کند: شناخت فرایند پرچم، طراحی سفارشی، پایلوت با یک درخواست واقعی و سپس گسترش. در محصول ما مدل پیشنهاد می‌دهد و انسان تأیید می‌کند؛ ایجنت خودمختاری که به‌تنهایی پرداخت کند یا نامه رسمی صادر کند وجود ندارد. پردازش روی سرور سازمان یا سرورهای آریا آی‌تی انجام می‌شود. برای مرور مفاهیم پایه، مقاله ایجنت هوش مصنوعی چیست را ببینید.
جمع‌بندی
پیشبینی گارتنر درباره لغو بیش از ۴۰ درصد پروژههای عاملمحور، به معنای ناکارآمدی فناوری نیست؛ به معنای استفاده نادرست از آن است. پروژه‌هایی که از مسئله واقعی شروع می‌کنند، معیار روشن دارند، هزینه را واقع‌بینانه می‌سنجند، دسترسی را محدود می‌کنند، داده را آماده می‌کنند و انسان‌ها را همراه می‌کنند، شانس بسیار بیشتری برای رسیدن به بهره‌برداری دارند.
مشاوره رایگان: پیش از سرمایه‌گذاری روی ایجنت، با کارشناسان آریا آی‌تی فرایند پرچم و معیار پایلوت را مشخص کنید.
پرسش‌های متداول
آیا واقعاً ۴۰ درصد پروژههای هوش مصنوعی شکست میخورند؟
+
عدد گارتنر یک پیشبینی است و فقط درباره پروژههای هوش مصنوعی عاملمحور: بیش از ۴۰ درصد آنها تا پایان ۲۰۲۷ لغو خواهند شد. این عدد آمار همه پروژههای هوش مصنوعی نیست.
ایجنتشویی (Agent Washing) یعنی چه؟
+
اصطلاحی که گارتنر برای بازنامگذاری محصولات موجود مثل دستیارها، RPA و چتباتها بهعنوان ایجنت، بدون قابلیت عاملمحور واقعی، به کار برده است.
مهم‌ترین اقدام برای جلوگیری از شکست چیست؟
+
شروع از یک مسئله واقعی با معیار موفقیت مکتوب و خط پایه. سپس انتخاب ساده‌ترین راه‌حل، محدودکردن دسترسی، آماده‌سازی داده و تعیین مالک کسب‌وکار.
پایلوت هوش مصنوعی را چگونه شروع کنیم؟
+
یک فرایند پرچم با حجم بالا و ریسک پایین یا متوسط انتخاب کنید، فقط یک قابلیت را روشن کنید، دقت را روی نمونه واقعی با بازبینی کارشناس بسنجید و مطمئن شوید فرایند بدون هوش مصنوعی هم کار می‌کند.