لماذا فشلت مشاريع AI في الشرق الأوسط‏.

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

هذا المقال ليس خطبة أخلاق. نحن نبنيه ونبيعه. لكننا نرى في نقطة أن منطقة الشرق الأوسط وشمال أفريقيا تعاقدت مع «سحر العرض» أسرع مما بنت عقد قياس، فصار الفشل يبدو تقنياً وهو في الأغلب مؤسسي [١][٢]. أدناه خمسة أنماط نراجعها مع عملائنا قبل أي عقد — مع جدول مقارنة سريع ومسار عملي لأربعة أسابيع.

لماذا يُسمّى النجاح فشلاً في الشهر الثاني عشر‏.

تعريفنا العملي للفشل هنا بسيط: نظام لا يُستعمل، أو يُستعمل لكن لا يُقاس، أو يُقاس لكن لا يُربط بقرار مثل تخفيض زمن الرد، خفض أخطاء التدقيق، أو رفع عدد المعاملات المنجزة بدون زيادة رؤوس.

عندما نقول لماذا فشلت مشاريع AI في الشرق الأوسط فإننا لا نلوم «البيئة». نلوم غياب قرار واحد قبل الشراء — من يمتلك البيانات، من يمتلك القياس، ومن يوقف التجربة إن لم تتحقق نسبة نجاح رقمية [٣][٥].

النمط الأول: مسرح إثبات المفهوم‏.

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

العلاج الذي نطبقه مع الفرق: أسبوعان لخط أنابيب على عيّنة قذرة بحجم محدّد قبل شراء GPUs أو توسيع اشتراك API؛ إن لم تنجح المرحلة، نوقف المشروع بثمن بخس لا بمليون تصحيح [٦]. لمزيد حول هذا السياق، راجعوا مسرح PoC والعروض.

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

النمط الثاني: بيانات مفقودة أو غير قابلة للاستعمال‏.

الفشل هنا ليس نقص مهندسين؛ هو أن شركة اشترت «نموذجاً يفهم العربية» دون owing ملكية لتسميات الحقول ووجود OCR يقرأ الجداوسكان. الواقع الذي نكرره في التدقيق: كثافة منخفضة من الملفات التي يمكن استخدامها في تدريب أو RAG؛ وبطاقات وصف ناقصة؛ وخط فصل حقيقي بين ما يمكن إدخاله للنموذج وما يمنع تنظيمياً.

اختصار المرحلة الأولى قبل أي تشغيل: جرد بيانات + سياسة احتفاظ + تحديد أصحاب الحقول. بدونها، مشروع الذكاء يصير مشروع «تنظيف أرشيف» بلا نهاية [٣].

النمط الثالث: عقد مع بائع بلا مالك داخلي‏.

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

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

النمط الرابع: إعادة عرض كل ربع‏.

كل ثلاثة أشهر يظهر نموذج جديد، فيُفتح «مشروع جديد» دون أن يُقفل السابق. النتيجة: بنية لا تستقر، ومعايير لا تتوحّد، وفرق تشغيل تتعب من «تبديل الاسم لا السلوك».

القرار الذي نفرضه في هيكل الشراء: تجميد اسم النموذج لثلاث دورات قياس، مع استثناء واحد مسبب بتقرير مخاطرة. كل تغيير بدون هذا الاستثناء يعود إلى لجنة شراء لا تضم المزوّد فقط [٥].

النمط الخامس: أهداف بلا أرقام‏.

«نريد كفاءة» ليست استراتيجية؛ هي نية. حين يصل المشروع لشهر ١٢ ويسأل المجلس عن العائد، يُفضح غياب خط أساس وغياب معيار قبول رقمي.

قبل أول دولار API، نحدد مع العميل: زمن، دقة، تكلفة لكل ألف حالة، وعتبة قبول؛ إذا لم يُصدق المعيار، نعيد ضبط المهمة أو نوقفها [٢][٣].

جدول قرار سريع: أين تقعوا‏.

• البيانات — خط أحمر إن لم تقيّدوا أسبوعين على عيّنة متسخة حقيقية؛ جاهزون إن OCR+RAG تعملوا على جزء حقيقي من الأرشيف.
• القياس — خط أحمر إن لم تُكتب KPI رقم واحد قبول قبل الشراء؛ جاهزون إن المعيارات تُدار أسبوعياً أمام منتج وفقياً وليس طرف المزود فقط.
• المالك الداخلي — خط أحمر إن رئيس تقنية وحده يوقّع؛ جاهزون إن مالك منتج، أمن، ومسار إيقاف مُفعّل فعلاً.
• المزود — خط أحمر إن العروض تتجدد كل ربع دون قرار؛ جاهزون إن الاسم الثابت مربوط بثلاث دورات قياس وخط خروج.

مسار أربعة أسابيع قبل التوقيع الكبير‏.

• الأسبوع ١: جرد بيانات + قائمة قيود PDPL/امتثال.
• الأسبوع ٢: خط أنابيب على بيانات حقيقية بألف حدث عالي القيمة.
• الأسبوع ٣: تعريف KPI وخط أساس يدوي.
• الأسبوع ٤: قرار «توسيع / إيقاف / إعادة صياغة المهمة» موقّع من المالك والامتثال.

خاتمة: البناء صعب، لكن الفشل ليس حتماً‏.

الذكاء الاصطناعي في المنطقة لا يحتاج مزيد إثارة؛ يحتاج عقود قياس واضحة. نحن في نقطة نفضّل إيقاف مشروع في أربعة أسابيع على إنفاق سنة «لأننا بدأنا».

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

أسئلة شائعة‏.

• لماذا تفشل مشاريع الذكاء في الشرق الأوسط غالباً؟ لأن الشراء يتقدّم على جودة البيانات والقياس، فيتحول المشروع إلى عرض متكرر بلا منتج منتظم [٢][٣].
• هل المشكلة في النموذج؟ نادراً ما تكون وحيدة؛ المعظم يفشل عند نقطة تركيب البيانات أو غياب مالك داخلي قبل نضج التشغيل [٥][٦].
• كم وقت نحتاج قبل الإنتاج؟ أربعة أسابيع تكفي لخط أنابيب أول وفحص KPI إن وفرت البيانات؛ غياب البيانات يمدد لا يختصر [٣].
• هل نستعين بمزود خارجي؟ نعم، مع عقد يحدد المعيارات وحقوق الخروج — راجع بنود عقد الذكاء في عُمان.
• ما أول خطوة إن كان لدينا عشرات المشاريع العالقة؟ جرد ثلاثة استخدامات عالية القيمة، وحسم واحد بحزم هذا الشهر — لا كل شيء دفعة واحدة.

المصادر‏.

[١] McKinsey — "The State of AI" — تقارير سنوية عن نضج الشركات في تبني الذكاء الاصطناعي.

[٢] Gartner — مواد حول مخاطر تبني الذكاء الاصطناعي وحوكمة المشتريات (مرجع عام لقيود الشراء ومخاطر PoC).

[٣] NIST — AI Risk Management Framework (AI RMF 1.0) — التفكير في المخاطر والقياس.

[٤] OECD — OECD AI Principles (إطار حوكمة ومساءلة عام).

[٥] نقطة — ملاحظات داخلية من مراجعات توريد ونشر قبل الإنتاج، مايو ٢٠٢٦ (Nuqta internal procurement retrospectives, May 2026).

[٦] نقطة — قائمة تحقق بيانات عربية/خليجية لمسارات RAG، أبريل ٢٠٢٦ (Nuqta internal RAG readiness checklist, April 2026).