لماذا تفشل مشاريع الذكاء الاصطناعي، والحل العملي لكل سبب

لماذا تفشل مشاريع الذكاء الاصطناعي: ماذا تقول الأبحاث؟

تتفق الأبحاث على أن معظم المشاريع تتعثر بين المرحلة التجريبية والإنتاج، وأن النموذج نادرًا ما يكون السبب. فقد أفادت MIT NANDA في يوليو 2025 بأن 95% من المؤسسات لم تحقق عائدًا قابلًا للقياس في الأرباح والخسائر من الذكاء الاصطناعي التوليدي، وأشارت إلى سير العمل الهش، والأدوات التي لا تتعلم من السياق، وضعف الملاءمة مع العمل اليومي.

ووجد تقرير BCG الصادر في أكتوبر 2025 عن اتساع فجوة القيمة في الذكاء الاصطناعي أن أقلية صغيرة فقط من الشركات تحقق قيمة من الذكاء الاصطناعي على نطاق واسع. ووفقًا لاستطلاع أجرته S&P Global Market Intelligence، تخلت نسبة متزايدة من الشركات عن معظم مبادراتها في الذكاء الاصطناعي في عام 2025، مشيرة إلى التكلفة وخصوصية البيانات والأمن. وتوقعت Gartner في يونيو 2025 أن يُلغى أكثر من 40% من مشاريع الذكاء الاصطناعي الوكيلي بحلول نهاية 2027 بسبب التكلفة أو عدم وضوح القيمة أو ضعف ضوابط المخاطر، وحذّرت من ظاهرة agent washing (تسويق منتجات على أنها وكلاء ذكاء اصطناعي وهي ليست كذلك).

وعند قراءة هذه النتائج معًا، فإنها تشير إلى سبعة أسباب. وتتناولها الأقسام التالية واحدًا تلو الآخر، مع الحل الذي نطبقه لكل منها.

السبب 1: لم يقِس أحد نقطة البداية

لا يستطيع المشروع إظهار قيمته إذا لم يسجل أحد كيف كان العمل يسير قبله. و«عدم وضوح القيمة» الذي تذكره Gartner كثيرًا ما يكون هذا بالضبط: النظام يعمل، لكن لا يوجد رقم سابق للمقارنة به، فلا تجد مراجعة الميزانية ما تستند إليه.

والحل هو القياس قبل البناء. سجّلوا لسير العمل المختار الدقائق لكل مهمة، وعدد المهام شهريًا، ومعدل الخطأ أو إعادة العمل، ومن يؤديها. واتفقوا على الهدف بالوحدات نفسها (مثل وقت إدخال الفاتورة ونسبة الفواتير التي تحتاج إلى تصحيح)، وضعوا المقارنة في تقرير شهري منذ الإطلاق فصاعدًا.

وإذا لم تتمكنوا من قياس خط الأساس بعد، فخصصوا أسبوعين لتسجيله يدويًا قبل تمويل البناء. فهذا رخيص، وكثيرًا ما يكشف أن عنق الزجاجة الحقيقي في مكان غير الذي افترضه الجميع.

السبب 2: سير العمل ينهار أمام المدخلات الحقيقية

سير العمل الهش، وهو أول سبب ذكرته MIT NANDA، ينشأ عادةً من الاختبار على عينات مرتبة. أما المدخلات الحقيقية فتشمل ملفات PDF ممسوحة ضوئيًا، وسلاسل بريد إلكتروني مُعاد توجيهها، ومتصلين يغيّرون الموضوع في منتصف المكالمة، وسجلات موجودة أصلًا في نظام CRM باسم مختلف قليلًا.

والحل هو مجموعة تقييم مبنية من أمثلة حقيقية غير مرتبة ذات إجابات صحيحة معروفة، يُعاد تشغيلها بعد كل تغيير في التعليمات أو الاسترجاع أو النموذج. وأضيفوا تحققًا على مستوى الحقول (مجاميع يجب أن تتطابق، وتواريخ يجب أن تقع ضمن نطاق، ومعرّفات يجب أن تكون موجودة في NetSuite أو QuickBooks)، وعتبة ثقة تُحيل العناصر المشكوك فيها إلى قائمة مراجعة بشرية بدلًا من التخمين.

• مجموعة تقييم مستمدة من المدخلات الفعلية في الأشهر الأخيرة، بما فيها حالات الإخفاق.
• قواعد تحقق على كل حقل يُكتب في نظام السجلات الرسمي.
• قائمة مراجعة بشرية لكل ما يقع دون عتبة الثقة.

السبب 3: الأداة تقع خارج العمل اليومي

ضعف الملاءمة مع العمل اليومي، وهو السبب الثالث لدى MIT NANDA، يظهر في صورة نافذة محادثة أو لوحة معلومات منفصلة يجب على الموظفين تذكّر فتحها. وخلال أسابيع يتوقفون عن فتحها، ويهبط الاستخدام بصمت إلى الصفر.

والحل هو تسليم المخرجات حيث يجري العمل أصلًا: مسودة رد داخل تذكرة Zendesk، أو سجل مكتمل في HubSpot أو Salesforce، أو فاتورة مورد تنتظر الاعتماد في نظام ERP، أو ملخص منشور في القناة التي يستخدمها الفريق. وتُظهر إحدى دراسات الحالة لدينا المبدأ نفسه دون أي روبوت محادثة: فقد نقل مقدّم خدمات علاجية أخصائييه إلى بوابة AppSheet موجّهة مع التحقق ومزامنة الفوترة، فانخفض إدخال البيانات من 10-15 دقيقة يوميًا إلى أقل من 3 دقائق، وأُوقفت الأخطاء من مصدرها.

السبب 4: النظام لا يتعلم من السياق

النظام الذي يجيب من تعليمات ثابتة يكرر الأخطاء نفسها، ولهذا دخلت الأدوات التي لا تتعلم من السياق قائمة MIT NANDA. فالسياسات تتغير، وقوائم الأسعار تُحدَّث، والموظفون يصححون الخطأ نفسه كل أسبوع دون أثر.

والحل من جزأين. أولًا، أسندوا الإجابات إلى مستندات الشركة الحالية عبر الاسترجاع مع ذكر المصادر، بحيث يؤدي تحديث ملف في SharePoint أو Google Drive إلى تحديث الإجابة، ويستطيع المراجع رؤية المصدر. ثانيًا، أغلقوا الحلقة: كل تصحيح يُجرى في قائمة المراجعة يُسجَّل ويُضاف إلى مجموعة التقييم ويُستخدم لضبط التعليمات أو القواعد وفق جدول منتظم.

وبالنسبة للوكلاء الصوتيين، تنطبق الفكرة نفسها على نصوص المكالمات: فالمكالمات التي حوّلها الوكيل أو أساء فهمها أو فقد فيها المتصل هي أفضل مادة لتطوير الجولة التالية من تغييرات التعليمات والتوجيه.

السبب 5: التكاليف تنمو أسرع من القيمة

التكلفة هي السبب الذي يظهر في نتائج S&P Global وGartner معًا. ففواتير الاستخدام لرموز النماذج ودقائق الصوت ترتفع مع الحجم، والوكيل العالق في حلقة متكررة قد ينفق في فترة بعد الظهر أكثر مما تستحقه مهمته.

والحل هو هندسة الميزانية داخل النظام. ضعوا سقفًا للتكلفة لكل مهمة يوقف التشغيل وينبّه أحدًا، وسجّلوا الرموز والدقائق لكل مهمة منذ الاختبار الأول، ووجّهوا التصنيف البسيط إلى نموذج أصغر واحتفظوا بالنموذج الأكبر للاستدلال الحقيقي، وراجعوا تكلفة كل مهمة مقابل قيمتها كل شهر. ويسرد دليلنا لتكلفة تنفيذ الذكاء الاصطناعي مكونات تكلفة التشغيل التي يجب تتبعها.

السبب 6: مخاوف الخصوصية والأمن توقف النشر

خصوصية البيانات والأمن هما السببان الآخران اللذان ذكرهما استطلاع S&P Global، وكثيرًا ما يظهران متأخرين، عندما يرى الفريق القانوني أو فريق تقنية المعلومات التصميم لأول مرة. فالمشروع التجريبي المبني على حساب محادثة استهلاكي لا يمكن نقله إلى الإنتاج مع بيانات العملاء أو المرضى.

والحل هو حسم طريقة التعامل مع البيانات في الأسابيع الأولى. استخدموا مستويات API أو باقات المؤسسات التي تناسب شروطها بياناتكم، واحصلوا على اتفاقية شريك أعمال (BAA) موقّعة من كل مورّد يتعامل مع المعلومات الصحية المحمية، وامنحوا النظام أضيق صلاحية يحتاجها فقط، وسجّلوا كل تعليمة وكل مخرج. ويملك العملاء الحسابات، فتبقى البيانات خاضعة لعقود يتحكمون فيها.

أشركوا تقنية المعلومات والفريق القانوني في المراجعة قبل البناء، لا بعده. فمخطط تدفق بيانات من صفحة واحدة يوضح الأنظمة التي يُقرأ منها، والتي يُكتب فيها، والمورّدين الذين يرون البيانات، ومكان تخزين السجلات، يجيب عن معظم أسئلتهم مبكرًا.

السبب 7: الوكلاء يتصرفون دون رقابة كافية

ضعف ضوابط المخاطر هو السبب الثالث في توقعات Gartner للإلغاء، والوكلاء يرفعون المخاطر لأنهم ينفّذون إجراءات، لا يكتبون نصوصًا فقط. وتزيد ظاهرة agent washing المشكلة سوءًا: منتجات تُباع على أنها وكلاء مستقلون وهي في الحقيقة نصوص برمجية بسيطة، أو تتصرف بحرية أكبر بكثير مما أدركه المشتري.

والحل هو تحديد ما يُسمح للوكيل بفعله. اسردوا أدواته صراحةً، وامنحوا كل أداة الحد الأدنى من الصلاحيات، واشترطوا موافقة بشرية على أي شيء يحرّك أموالًا أو يتواصل مع عميل أو يغيّر سجلات خاضعة للتنظيم، واحتفظوا بمسار تراجع يمكنه إيقاف الوكيل وإعادة العمل إلى الموظفين. وعند تقييم أي مورّد، اطلبوا منه عرض استدعاءات الأدوات والسجلات من تشغيل حقيقي، لا الإجابة النهائية فقط.

هل تبنون داخليًا أم مع شريك متخصص؟

أفادت MIT NANDA بأن المشاريع المشتراة من شركاء متخصصين أو المبنية معهم نجحت أكثر من المشاريع الداخلية. ووجد البحث نفسه أن أكبر العوائد جاءت من أتمتة المكاتب الخلفية، رغم أن الميزانيات مالت نحو المبيعات والتسويق.

وأيًا كان المسار الذي تختارونه، فالحلول أعلاه هي ما يهم. نحدد نطاق كل مشروع في مراجعة مجانية، ونسعّره كبناء بسعر ثابت، ونسلّم الشيفرة والتعليمات والحسابات حتى يتمكن فريقكم من تشغيله. ويعرض دليلنا لخارطة طريق التنفيذ المراحل بالترتيب.