التحدّي الحقيقي للذكاء الاصطناعي في الشركات لم يعد النموذج، بل طريقة تشغيله

في يونيو 2026، لم يعد المؤشر الأهم بالنسبة إلى الشركات هو إطلاق LLM جديد آخر، ولا حتى سباق benchmarks. التحوّل الحقيقي، كما يظهر لدى Google Cloud وAWS وMicrosoft وDatabricks، يحدث في مكان آخر: MLOps تتحوّل إلى تخصص لتشغيل الوكلاء الذكيين، مع أربعة تحديات تتصاعد في الوقت نفسه: السياق التجاري، الحوكمة، قابلية المراقبة، وتكلفة الاستدلال لكل وحدة. ومع إعادة جميع اللاعبين الكبار تنظيم رسائلهم حول runtime، والهوية، وgateways، والذاكرة، والتتبّع، والتقييم المستمر، لم يعد الأمر مجرّد موجة عابرة، بل تغيّرًا في الطبقة الأساسية نفسها.

بعبارة أخرى: في 2024 كان السؤال الأساسي هو أي نموذج نختار؟ أما في 2026، فالسؤال الذي يحسم الانتقال إلى الإنتاج هو: من يتحكم في السياق، والصلاحيات، والسجلات، والتكاليف، والقدرة على تبديل المورّد؟ تكتب Microsoft ذلك بشكل شبه صريح: عنق الزجاجة لم يعد قدرة النماذج، بل السياق المشترك داخل المؤسسة. ومن جهتها، تشرح Databricks أن الحلقة الوكيلية المرئية ليست سوى جزء صغير من العمل، وأن الباقي هو دين تقني مخفي يتكوّن من الأمن، والنشر، والمراقبة، والتكلفة، والجودة. أما AWS فتشدّد اليوم على التحسين المستمر انطلاقًا من آثار الإنتاج. بينما تدفع Google نحو منصة متكاملة لبناء الوكلاء ونشرهم وحوكمتهم وتحسينهم.

الذكاء الاصطناعي لا يدخل إلى السحابة؛ بل السحابة هي التي تعود لتصبح نظام التشغيل الخاص بالذكاء الاصطناعي.

التحوّل الواضح لدى جميع المورّدين

القاسم المشترك بين إعلانات هذا الربيع وهذا الشهر من يونيو واضح جدًا. فقد أطلقت Google Cloud منصة Gemini Enterprise Agent Platform بوصفها منصة مخصّصة لبناء الوكلاء وتوسيعهم وحوكمتهم وتحسينهم، عبر جمع اختيار النماذج، وأدوات التكامل، وDevOps، والتنسيق، والأمن ضمن طبقة واحدة. وفي Google Cloud Next '26، سلّطت Google الضوء أيضًا على Agent Developer Kit المبني على graphs، إلى جانب Agent Studio لبناء الوكلاء واختبارهم ونشرهم على نطاق واسع.

أما لدى Microsoft، فكانت الرسالة في Build 2026 بالكاد أقل وضوحًا. إذ تؤكد الشركة أن المشكلة لم تعد في قوة النموذج، بل في القدرة على توفير سياق بيانات متّسق لوكلاء يجب أن يعملوا داخل الأنظمة التجارية. وتبرز الصفحة الرسمية لـ Build 2026، ضمن أبرز الإعلانات، مكوّنات تمتد من observability to ROI for AI agents إلى الحوكمة المحمولة للوكلاء، مرورًا بالنشر والتشغيل واسع النطاق ضمن Foundry.

أما AWS فقد دفعت Bedrock AgentCore إلى منطق التشغيل الصناعي. فإعلانها في 18 يونيو 2026 عن قدرات التحسين الجديدة لا يركّز أولًا على إنشاء الوكلاء، بل على دورة تُستخدم فيها آثار الإنتاج لفهم ما يحدث، وتصحيح الأعطال، وإثبات أن الإصلاحات حسّنت النظام فعلًا. وتصف AWS الخطر الحقيقي بعبارات شديدة الوضوح: الأعطال الأكثر خطورة ليست تلك التي تُظهر رسالة خطأ، بل الإخفاقات الصامتة التي لا تظهر إلا لاحقًا في شكاوى العملاء.

وتتبنّى Databricks القراءة نفسها، لكن بصياغة مختلفة. ففي تدوينة DAIS 2026، تشرح الشركة أن الحلقة الوكيلية ليست سوى «1%» المرئي، فيما تعود «99%» المتبقية إلى النشر، وسعة tokens، والأمن، والتقييم، وقابلية المراقبة، والسياق، والمشاركة. والأهم هنا ليس الإعلان المنتج بحد ذاته، بل الإطار الذي تضعه الشركة: فالمشكلة في السوق لم تعد كيف نصنع عرضًا تجريبيًا لوكيل، بل كيف نشغّل نظامًا وكليًا موثوقًا.

والخلاصة بالنسبة إلى صانع القرار بسيطة: عندما تتقارب Google وAWS وMicrosoft وDatabricks، كلٌّ بمصطلحاته الخاصة، حول اللبنات نفسها — runtime، والهوية، والذاكرة، وgateways، وtracing، وscoring، والحوكمة — فهذا يعني أننا نخرج من دورة «POC + hype» إلى دورة معمارية حقيقية. وبذلك ينتقل مركز الثقل في MLOps من النموذج إلى سلسلة التشغيل.

لماذا تتحول MLOps إلى AgentOps؟

هذا الانتقال يغيّر طبيعة الطبقة التقنية نفسها. ففي MLOps التقليدية، كان التركيز الأساسي على إصدار البيانات والنماذج، ونشر endpoint، وتتبع بعض المؤشرات، ثم إعادة تشغيل pipeline إعادة التدريب. أما في حزمة 2026، فيجب إضافة إدارة runtime للوكلاء، والذاكرة القصيرة والطويلة، وصلاحيات الفعل، والأدوات الخارجية، وآثار التنفيذ، وجودة الإجابات، وامتثال السلوك، وزمن الاستجابة في السلاسل متعددة الخطوات. وتوثّق Google هذا التراكم بالفعل: إذ تقدّم Agent Platform runtime مُدارًا، وجلسات، وMemory Bank، ووظائف logging وtracing وmonitoring، إضافة إلى هوية مستقلة لكل وكيل.

وأكثر التفاصيل إثارة للاهتمام هنا هي صعود الهوية الوكيلية. ففي وثائق Google، تعتمد Agent Identity على هوية موثَّقة تشفيريًا، مبنية على معيار SPIFFE، لمصادقة الوكيل أمام خوادم MCP، والموارد السحابية، وendpoints، والوكلاء الآخرين. وبعبارة أخرى، لم يعد السؤال فقط: «من يستدعي API؟»، بل: «أي وكيل يتصرف، وباسم من، وضمن أي نطاق من الصلاحيات؟». وهذا تحوّل كبير، لأن الأمن يرتقي هنا إلى مستوى السلوك المؤتمت نفسه.

وتسير AWS في الاتجاه ذاته عبر AgentCore Gateway، الذي يحوّل APIs وLambda functions والخدمات القائمة إلى أدوات متوافقة مع Model Context Protocol، مع مصادقة داخلة وخارجة، وتكاملات جاهزة للاستخدام، وتحكم دقيق في الوصول. وهذه الطبقة استراتيجية لأنها تربط عالم الوكلاء بعالم نظم المعلومات الفعلية: CRM، والبريد، والتذاكر، والوثائق، وقواعد البيانات، وسير العمل. وهنا تتوقف MLOps عن كونها موضوعًا «نموذجيًا» بحتًا، لتصبح موضوعًا يجمع المنصة + التكامل + الأمن.

أما التحوّل الآخر فهو في قابلية المراقبة النوعية. إذ توحّد MLflow 3 لدى Databricks بالفعل التتبّع، والتقييم، وقابلية المراقبة لتطبيقات ووكلاء GenAI عبر آثار لحظية، ومقيّمين scorers، وتغذية راجعة بشرية، وإدارة الإصدارات. وفي الإنتاج، تقدّم Databricks مراقبةً تُشغّل تلقائيًا scorers على عينات من الآثار لتقييم الجودة بشكل مستمر — وهو ما يعني أننا لم نعد نقيم نسخة قبل النشر فقط، بل نراقب السلوك الفعلي بعد الإطلاق. وتقول AWS الشيء نفسه بصياغة مختلفة: إذ توفّر AgentCore Observability مؤشرات لحظية حول عدد الجلسات، وزمن الاستجابة، والمدة، واستخدام tokens، ومعدلات الخطأ، مع إمكان التصفية عبر البيانات الوصفية لتسهيل التحقيق.

وأخيرًا، أصبحت بنية الاستدلال نفسها أقرب إلى «منصة» منها إلى «استضافة GPU» بسيطة. وتذكّر CNCF بأن Inference Gateway المبني على Gateway API أصبح الآن GA، ويتيح توجيه الحركة وفق اسم النموذج، ومحوّلات LoRA، وحالة endpoints، بهدف تحسين مشاركة مجموعات الخوادم ورفع استخدام المسرّعات. وتعزّز Google هذا الاتجاه عبر دمج NVIDIA Dynamo مع GKE Inference Gateway، مع الإعلان عن G4 VMs قابلة للتجزئة لتحسين قياس الأحمال. وهنا أيضًا، لم يعد السؤال فقط: أين نجد GPU؟، بل: كيف نستخدم سعة الاستدلال بانضباط، ومشاركة، ومفاضلة دقيقة؟

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

التكلفة الخفية التي تنتهي بالظهور في الميزانية

وهنا يصبح الموضوع قرارًا فعليًا. فبحسب تقرير State of the Cloud 2026 الصادر عن Flexera، تستخدم 58% من المؤسسات بالفعل خدمات GenAI السحابية العامة، وتقول 45% إنها تستخدمها على نطاق واسع، وتعمل 73% ضمن بنية هجينة، وتعتمد 49% الآن على unit economics لربط الإنفاق السحابي بالنتائج التجارية، فيما ترتفع نسبة الهدر المقدَّر في IaaS/PaaS إلى 29%. كما تلاحظ Flexera أن 64% من المؤسسات باتت تقيس السحابة اليوم من خلال القيمة المقدَّمة للأعمال أكثر من قياسها بالكفاءة/التكلفة وحدها. وهذا ليس تفصيلًا هامشيًا: فالنقاش ينتقل من «كم التكلفة؟» إلى «ما تكلفة الخدمة الواحدة، والاستخدام الواحد، وسير العمل الواحد، والفريق الواحد، والعميل الواحد؟».

وهذا التطور ينسجم مع ما تراه الشركات الأوروبية بالفعل على الأرض. إذ تشير Reuters إلى أن مجموعات مثل Siemens وRenault وOrange وChapsVision تكثّف عدد المورّدين للحد من خطر الاعتماد، وأيضًا لأن تكلفة token أصبحت مسألة أكثر حساسية كلما زاد اعتماد الوكلاء على أتمتة المهام. وتذكر المقالة صراحةً صعود هذا الهوس بالتكلفة لكل وحدة، مع مثال على ميزانية tokens استُهلكت بسرعة أكبر بكثير من المتوقع. وحتى الأسواق المالية باتت تقلق الآن من مستوى الإنفاق على بنية الذكاء الاصطناعي لدى مزوّدي السحابة العملاقة، وهو ما يدل على أن مسألة العائد الاقتصادي خرجت من الدائرة التقنية الضيقة.

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

لذلك، فإن الزاوية الميزانية الصحيحة بالنسبة إلى CIO أو CFO لم تعد: «كم يكلفني prompt؟»، بل: «ما التكلفة الكاملة لكل وكيل فعّال؟». وتشمل هذه التكلفة، في الحد الأدنى، النموذج، والأدوات الخارجية، والذاكرة، وlogging، وtracing، والأمن، والضوابط، والتخزين، وبيانات السياق، والزمن البشري اللازم للتقييم والمعالجة. وإذا لم تتابع المؤسسة هذه الوحدة الاقتصادية، فقد ترى تبنّيًا متزايدًا من دون أن تعرف إن كان يخلق قيمة فعلية أم مجرد عبء سحابي.

ولهذا السبب تتغير طبيعة FinOps. فـ Flexera لا تعلن اليوم مجرد وظائف تقليدية لإدارة كلفة السحابة، بل طبقة AI Cost Management تغطي التطبيقات، والوكلاء، والنماذج، ومنصات البيانات، والحوسبة. والرسالة الضمنية واضحة: إنفاق الذكاء الاصطناعي لم يعد ملحقًا بإنفاق السحابة؛ بل أصبح بندًا مستقلًا في القيادة والتحكم، معقدًا بما يكفي ليحتاج إلى أدوات مخصصة.

السحابة الخاصة بالذكاء الاصطناعي تعود لتصبح خيارًا سياديًا

والخطأ التحليلي الآخر هو التعامل مع سحابة الذكاء الاصطناعي باعتبارها مجرد مفاضلة تقنية بين AWS وAzure وGoogle Cloud. ففي أوروبا، خلال يونيو 2026، أصبح الموضوع أيضًا مسألة استمرارية أعمال وسيادة تشغيلية. فقد اعتمدت المفوضية الأوروبية في 3 يونيو مقترح Cloud and AI Development Act، بوصفه رافعة لتعزيز منظومة السحابة والذكاء الاصطناعي الأوروبية واستثماراتها وبناها التحتية. وفي الوقت نفسه، يذكّر الجدول الرسمي بأن AI Act سيصبح قابلًا للتطبيق الكامل ابتداءً من 2 أغسطس 2026، مع دخول قواعد الشفافية حيّز التنفيذ في أغسطس 2026، ومع إطار عام يعزز مسؤوليات المورّدين والجهات الناشرة.

وهذا البعد السياسي ينعكس بالفعل في معماريات المؤسسات. إذ تشرح Reuters أن مجموعات أوروبية تسرّع تنويع نماذجها ومورّديها بعد قيود على الوصول إلى بعض الخدمات الأمريكية، تحديدًا لأن الخدمة الاحتكارية البعيدة قد يقيّدها مورّدها، ولا تكون بالضرورة قابلة للتشغيل على خوادم العميل نفسه. وفي هذا السياق، لا تعني السيادة الانعزال؛ فـ Siemens وOrange وRenault يتحدثون أساسًا عن المرونة، ومزيج المورّدين، والقدرة الاحتياطية إذا أغلق أحد الأطراف الوصول أو غيّر شروطه.

وفي هذا الإطار ينبغي قراءة إعلان OVHcloud. فـ Reuters تنقل أن المجموعة الفرنسية تريد تدريب نماذج حدودية لتصبح ثاني لاعب أوروبي كبير في LLM، مع تكلفة تقديرية تتراوح بين 150 و200 مليون يورو لهذه الدورة التكنولوجية الجديدة، أي أقل بكثير من المليار يورو الذي كان يُتداول سابقًا. وسواء نجحت المبادرة تجاريًا أم لا، فهي تقول شيئًا مهمًا: سيادة سحابة الذكاء الاصطناعي لم تعد خطابًا مؤسسيًا مجردًا؛ بل بدأت تصعد إلى قلب استراتيجية المنتج والبنية التحتية لدى اللاعبين الأوروبيين الكبار.

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

الإطار العملي لاتخاذ القرار الآن

السؤال إذن ليس: «هل يجب أن نطبق MLOps على الذكاء الاصطناعي التوليدي؟»، بل: أي نوع من التشغيل نريد أن نُوحّده؟ يوجز الجدول التالي ما الذي تغيّره إشارات يونيو 2026 فعليًا بالنسبة إلى المؤسسة. وهو مفيد للمفاضلة بين الميزانية، أو مسار المعمارية، أو اختيار المورّد.

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

ما الذي فهمه اللاعبون المتقدمون بالفعل؟

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

ومن الضروري طبعًا الحفاظ على قدر من التحفّظ المنهجي. فجزء مهم من الإشارة يأتي من إعلانات المورّدين ووثائق المنتجات؛ وبعض الوظائف ما تزال في beta أو preview، مثل مراقبة الإنتاج MLflow 3 لدى Databricks. وهذا يعني أن التبنّي الفعلي سيكون أبطأ وأقل تجانسًا مما توحي به keynotes. لكن هذا القيد لا يغيّر الاستنتاج الجوهري: عندما تتقارب المنظومات الأربع الكبرى في السحابة والبيانات نحو اللبنات التقنية نفسها، فثمة احتمال كبير أن يكون هذا التحول طويل الأمد.

وعليه، فالجملة الأطروحة التي تستحق أن تُحفظ هي التالية: القضية الحقيقية لـ MLOps وCloud AI في 2026 لم تعد تقديم نموذج، بل تشغيل وكلاء بسياق، وأدلة، وضوابط. أما الشركات التي ستتعامل مع ذلك على أنه مجرد موضوع أدوات، فستتأخر. بينما ستكون الشركات التي ترى فيه إعادة صياغة لحوكمة السحابة، والرقابة المالية، والإدارة التشغيلية، في موقع أفضل لاستيعاب الموجة التالية.