أوراكل تضع تنسيق الوكلاء داخل ERP، وهذا يغيّر معادلة الحوكمة

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

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

الفجوة التي يظل الجميع يستشهد بها

الأرقام التي تشرح هذا التحول أصبحت مألوفة الآن. نحو 85% من الشركات الكبرى تجرب وكلاء الذكاء الاصطناعي، لكن نحو 5% فقط نقلت تقنية الوكلاء إلى الإنتاج، وحوالي 11% إلى 14% من المشاريع التجريبية تتوسع. وتتوقع Gartner أن أكثر من 40% من مشاريع الذكاء الاصطناعي الوكيلي سيُلغى بحلول 2027، وتُعزي ذلك إلى مشكلات التكامل والتنسيق لا إلى جودة النموذج. وفي المقابل، تتوقع IDC وجود نحو 1.3 مليار وكيل ذكاء اصطناعي قيد الاستخدام عالمياً بحلول 2028.

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

الحوكمة تُطرح كفئة منتج

Oracle أحد المشاركين في شهر أنتج قدراً مفاجئاً من البنية التحتية لحوكمة الوكلاء. أطلقت OpenAI منتج Presence، وهي طبقة تشغيلية لنشر وكلاء صوتيين ودردشة بنطاق عمل محدد، ووصول محدود إلى المعرفة، وإجراءات معتمدة، وتستهدف دعم الفوترة ومطالبات التأمين وطلبات تقنية المعلومات للموظفين. وجاء Classie Supervise إلى جانبها ليمنح المؤسسات تتبعاً ومحاسبة في الوقت الفعلي للوكلاء الموجودين بالفعل في الإنتاج.

أعلنت Salesforce وAWS عن Agentforce 360 for AWS، وهي منصة مشتركة يعمل محرك Atlas Reasoning Engine الخاص بها على نماذج Claude من Anthropic عبر Amazon Bedrock، والأهم أنها تولّد مسارات تدقيق غير قابلة للتغيير لكل قرار يتخذه الوكيل. ويُذكر CrowdStrike بين المتبنين الأوائل، مستشهداً ببساطة الشراء إلى جانب الأمان، وهي طريقة مؤسسية جداً للقول إن شراء شيء واحد أفضل من تجميع خمسة.

وفي مكان آخر، وسّعت OneTrust منصتها عبر AI Control Plane وGovernance Command Center، مع تكاملات مع ChatGPT وClaude وCopilot وGlean. وتجادل Red Hat بأن الضمانات على مستوى النموذج غير كافية بمجرد أن يتمكن الوكلاء من تنفيذ إجراءات، وتدفع نحو دفاع متعدد الطبقات عبر الهوية ووقت التشغيل والشبكات والبنية التحتية. وقدمت Nvidia منصة Open Agent Safety Platform المبنية مع أكثر من 100 شريك، والمصممة لعزل وكيل مارق في غضون مللي ثوانٍ.

كل من هذه المنتجات يهاجم المشكلة نفسها من ارتفاع مختلف. ورهان Oracle هو أن مسار التدقيق يجب أن يكون المعاملة نفسها، لا سجلاً موازياً. وإذا كانت الإجراءات المعتمدة للوكيل معرّفة كقواعد داخل ERP، فإن كل قرار يتخذه يخضع بالفعل للضوابط والأذونات والتقارير التي تستخدمها فرق المالية والالتزام لكل شيء آخر.

لماذا يُعد ERP موطناً طبيعياً

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

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

قراءة متشككة

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

ماذا تفعل بهذا

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

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

سؤال الدمج

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

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

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

ما لا يقوله البائعون

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

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