الحوكمة كشرط للدخول إلى الذكاء الاصطناعي المؤسسي
اتخذت مايكروسوفت قراراً هادئاً نسبياً خلال مؤتمر Build 2026، يستحق من الاهتمام أكثر مما حظي به: فبدلاً من الإعلان عن نموذج أكثر قدرة أو عميل أكثر كفاءة، أتاحت حزمة تطوير البرمجيات Agent 365 SDK للتوافر العام، وأحاطتها بضوابط متكاملة للهوية والسياسات والبيانات تُفعَّل أثناء مرحلة التصميم، لا بعد أن يتسبب العميل في أضرار داخل بيئة الإنتاج. والرهان الضمني هنا هو أن قدرة النموذج لم تعد تمثّل نقطة الاختناق بالنسبة للمؤسسات الكبيرة. ما يُعطّل مشاريع العملاء الآليين ليس قوة النظام، بل عجز المؤسسات عن إثبات أن ثمة من يعلم ما يفعله هذا العميل، وبأي بيانات يعمل، وبموجب أي تفويض، وباسم من يتصرف.
وهذا ليس جدلاً تقنياً بالمعنى الدقيق. إنه جدل يتعلق بهندسة السلطة داخل المؤسسات.
إذ إن السبب الذي يجعل مشاريع العملاء الآليين تتوقف في مرحلة المراجعة القانونية، أو أمام لجان المخاطر، أو على مكتب المسؤول الأمني التنفيذي (CISO)، ليس أن النموذج رديء. السبب هو أن أحداً لا يستطيع الإجابة عن ثلاثة أسئلة جوهرية: من أجاز وجود هذا العميل الآلي؟ وما الذي يملك صلاحية الوصول إليه؟ وكيف يمكن إثبات ذلك أمام مراجعة حسابات خارجية؟ لقد رصدت مايكروسوفت هذه النقطة الحساسة وقررت بناء منصتها حولها.
ما الذي فهمته مايكروسوفت في حين يواصل منافسوها السعي نحو السرعة
تأتي حزمة Agent 365 SDK مزوّدة بسجل مركزي تصفه مايكروسوفت بأنه "مصدر الحقيقة" لجرد العملاء الآليين في البيئة المؤسسية. ويتصل هذا السجل بـ Defender وPurview وEntra وFoundry، مما يعني أن ضوابط الأمن والهوية والامتثال التي تمتلكها المؤسسة الكبيرة مسبقاً لا تحتاج إلى إعادة البناء من أجل العملاء الآليين، بل تمتد لتشملهم. ويمكن لكل عميل آلي أن يمتلك هوية فريدة مستقلة تماماً عن أي مستخدم بشري. كما يمكن للمسؤولين تحديد أي العملاء يمكن اكتشافه، وأيهم يخضع للعزل، ومن يملك حق إنشائها، وتحت أي شروط تعمل.
يكشف السجل أيضاً عن عملاء آليين يعملون دون أن يكون أحد قد أجازهم. وتقول مايكروسوفت إن النظام يتعرف على أكثر من عشرين نوعاً من العملاء المحليين، من بينها خوادم بروتوكول سياق النموذج (Model Context Protocol)، وهي بالتحديد نوع البنية التحتية التي تنشرها فرق الهندسة بسرعة دون المرور بدورة المشتريات الرسمية. تسمية ذلك "الانتشار الفوضوي للعملاء" هي الصياغة الأنيقة للقول بأن المؤسسات باتت تُشغّل عملاء آليين خارج أي إطار رقابي، وأن ذلك يُشكّل مشكلة حوكمة قبل أن يكون مشكلة أمنية.
مقارنةً بـ Google Cloud التي بنت منصة عملائها الآليين حول هويات تشفيرية فريدة لكل عميل، وبـ AWS التي راهنت على مسار أسرع وأخف وزناً عبر Bedrock AgentCore، اختارت مايكروسوفت الملعب الذي تتفوق فيه أصلاً: البنية التحتية للرقابة التي يمتلكها أكبر عملائها المؤسسيين ويثقون بها. هذه ليست أفضلية تقنية. إنها أفضلية رأس مال اجتماعي متراكم مع فرق الأمن المؤسسي على مدى عقدين من الزمن.
والنمط الذي يبرز ليس محض مصادفة. يتقارب كبار مزودي الخدمات السحابية الثلاثة نحو البنية المفاهيمية ذاتها: مستوى تحكم للعملاء الآليين يستنسخ ما كانت عليه Kubernetes بالنسبة للحاويات. والفارق هو أن مايكروسوفت تصل إلى هذا الملعب وفي جعبتها Entra وIntune وDefender وPurview، المنتشرة مسبقاً في غالبية المؤسسات الكبيرة. وحوكمة العملاء الآليين لا تأتي بوصفها منصة جديدة تحتاج إلى مبرر في الميزانية، بل تأتي امتداداً طبيعياً لما يديره فريق الأمن بالفعل اليوم.
من كان في الغرفة حين صُمِّم هذا النظام، وما الذي يكشفه ذلك
هنا تصبح القصة أكثر إثارة من منظور التصميم الهيكلي. لقد بُنيت حزمة Agent 365 SDK لحل مشكلة المشتري المؤسسي، لا مشكلة المطور الراغب في التحرك بسرعة. الوظائف التي أولتها مايكروسوفت الأولوية، السجل وضوابط الوصول والحماية من فقدان البيانات في وقت التشغيل وضوابط Windows على مستوى نظام التشغيل، صُمِّمت لإقناع المسؤول الأمني التنفيذي أو الفريق القانوني أو مسؤول الامتثال بأن العميل الآلي قابل للنشر. هذا خيار تصميمي يكشف من يملك حق النقض في دورة التبني.
وهذه ليست تفصيلة عابرة. حين تُصمَّم منصة لتقليص الاحتكاك أمام المدقق قبل تقليصه أمام المطور، فهذا اعتراف صريح بأن قوة الإعاقة في المؤسسات الكبيرة ليست في الفريق التقني. إنها في وظائف الرقابة. رهنت مايكروسوفت بأنها ستكسب حصة سوقية أوسع بإقناع فريق المخاطر لا بإقناع فريق الهندسة، وهذا الرهان يحمل تداعيات تهم كل مؤسسة تفكر في تبني أدواتها الخاصة من العملاء الآليين.
السؤال الهيكلي الذي يطرحه هذا الوضع هو: من الذي أُقصي من غرفة التصميم؟ تُعلن حزمة SDK التوافق مع أي منصة من منصات العملاء الآليين، لا مع منصة مايكروسوفت وحدها، وهي إشارة إلى انفتاح تكتيكي. غير أن بنية التحكم الأكثر متانة تعمل داخل محيط Windows وEntra وMicrosoft Foundry. المؤسسة التي تُشغّل عملاء آليين على AWS وعلى Google Cloud وعلى مجموعة من أدوات SaaS الموروثة تحصل على رؤية فعلية داخل الحدود التي ترسمها مايكروسوفت، غير أنها تورث في الوقت ذاته تبعية أعمق لتلك الحدود. وحوكمة البيئات متعددة السحابة لا تزال، في الواقع العملي، مشكلة لم يحلها أيٌّ من كبار المزودين الثلاثة. ووجود بائعين مستقلين كـ Saviynt وTrueFoundry ناجم تحديداً عن أن هذا الطلب حقيقي وغير ممتثَل من قِبَل منصات الـ Hyperscalers.
ثمة أمر آخر يستحق التسمية بدقة: أطلقت مايكروسوفت حزمة Agent Governance Toolkit مشروعاً مفتوح المصدر برخصة MIT في أبريل 2026، أي قبيل مؤتمر Build. وتضعه الشركة بوصفه أول مجموعة أدوات تعالج العشرة مخاطر للذكاء الاصطناعي العميلي التي حددتها OWASP، مع تطبيق سياسات حتمي في أقل من ميلي ثانية واحدة. هذا تحرك لتحديد المعيار قبل أن يسبق إليه أحد. حين يُصدر لاعب مهيمن إطار الأمان المرجعي في صيغة مفتوحة المصدر، فهو لا يُبدي كرماً. إنه يضع بنيته المفاهيمية في صميم نقاش الصناعة.
تكلفة الحوكمة التي لا تذكرها أي عروض المبيعات
لا تحل مايكروسوفت جميع المشكلات التي تُنشئها. ثمة ثلاثة أوجه للاحتكاك يجب على أي مؤسسة تتبنى هذه البنية أن تُسمّيها قبل أن تلتزم بها.
الأول هو أن جزءاً مهماً مما أُعلن عنه في Build 2026 لا يزال في مرحلة المعاينة، وليس في التوافر العام. التكامل بين Defender وGitHub Code Security متاح. وWindows 365 للعملاء الآليين متاح. لكن نظام MDASH للفحص العميلي بأكثر من مئة عميل متخصص، وضوابط وقت التشغيل في Purview، وعدد من قدرات Defender، لا تزال في مرحلة المعاينة أو بمواعيد إتاحة لم تُحدد بعد. وخطة الحوكمة المبنية على قدرات لا تزال في المعاينة هي خطة تحمل فراغاً في صميمها.
الاحتكاك الثاني ذو طابع تشغيلي. فكل طبقة من طبقات الرقابة التي تحمي المؤسسة تُبطئ المطور في الوقت ذاته. الفرق التي تُضبط ضوابطها بشكل مفرط ستجد مهندسيها يبحثون عن مسارات بديلة، وينشرون عملاء آليين خارج السجل لأن إجراءات الموافقة تستغرق ثلاثة أسابيع. إن الحوكمة التي تُولّد احتكاكاً مفرطاً تُنتج تحديداً الانتشار الفوضوي للعملاء غير الخاضعين للرقابة الذي وُجد السجل أصلاً للكشف عنه. هذه مشكلة في التصميم التنظيمي، لا في التكنولوجيا.
الاحتكاك الثالث استراتيجي. المؤسسات التي تتبنى Agent 365 بوصفه طبقة رقابتها تكسب رؤية فعلية داخل المحيط الذي ترسمه مايكروسوفت. وما تُورثه في آنٍ معاً هو تبعية أعمق لذلك المحيط. هذا ليس حجة ضد المنصة. إنه متغير ينبغي أن يظهر في أي قرار معماري أمين. وقابلية نقل الحوكمة عبر معايير كـ Model Context Protocol الذي يدّعي كبار المزودين الثلاثة دعمه، قد لا تكون متاحة في الممارسة الفعلية بالقدر الذي توحي به البيانات الصحفية.
الهوية غير البشرية بوصفها الحدود الجديدة للرقابة المؤسسية
ما تبنيه مايكروسوفت، حين نصفه بمعزل عن مصطلحات المنتج، هو نظام هوية وتفويض لكيانات لا تنتمي إلى البشر لكنها تستطيع التصرف كما لو كانت كذلك: تقرأ البيانات الحساسة، وتستدعي الأدوات، وتُشغّل العمليات، وتتخذ القرارات بالنيابة عن المؤسسة. هذه المشكلة لم تكن موجودة بهذا الحجم قبل عامين.
التداعية على الميزانية مباشرة. الإنفاق الذي كان يتجه نحو الوصول إلى النماذج والتجريب بات يحتاج إلى بند خاص بطبقة الهوية والحوكمة التي تحوّل التجارب إلى منشورات معتمدة. هذا الإنفاق لا يبقى اختيارياً حين يصبح العملاء الآليون قادرين على قراءة البيانات وتفعيل الإجراءات باستقلالية. وتتحول الهوية غير البشرية إلى مشكلة من الدرجة الأولى، بالإلحاح ذاته الذي تتعامل به المؤسسات مع الهوية البشرية منذ أن كفّ المحيط المؤسسي عن كونه سوراً مادياً.
لا يحل تحرك مايكروسوفت سؤال مدى فعالية الحوكمة حين تعمل المؤسسة في سحابات متعددة مع عشرات أدوات SaaS وعملاء آليين مبنيين على منصات أطراف ثالثة. لكنه يكشف ميكانيكا السلطة التي ستحدد أي المؤسسات تستطيع توسيع نطاق عملائها الآليين وأيها سيبقى أسيرة دورة المشاريع التجريبية التي تموت في مرحلة المراجعة القانونية. إن القدرة على إثبات ما فعله كل عميل آلي، وبأي بيانات، وبموجب أي تفويض، قبل أن يطلب ذلك مُنظِّم أو مجلس إدارة، هي المعيار الذي سيُفرّق بين من ينشر فعلاً ومن يواصل التجريب إلى أجل غير مسمى.
البنية التي قدمتها مايكروسوفت في Build 2026 ليست الطريقة الوحيدة لحل تلك المشكلة. لكنها الأولى التي تصل مُعبَّأة مع البنية التحتية للرقابة التي تمتلكها المؤسسات الأكبر مسبقاً. هذه الأفضلية في التوزيع ليست تقنية. إنها أفضلية هيكلية، ويصعب تكرارها بكثير أكثر مما يصعب تكرار معيار أداء أمني.
