Microsoft تفصل مسؤولية مطور AI عن ناشره في معيارها الجديد
في 1 سبتمبر 2026، نشرت Microsoft تقريرها السنوي الثالث للشفافية في الذكاء الاصطناعي المسؤول، وكشفت إعادة تصميم معيارها الداخلي بحيث يفصل بين مسؤوليات مطور النظام والجهة التي تنشره، بحسب الإعلان التنفيذي عن التقرير. ويمتد أثر التغيير إلى ما بعد اختبارات البناء: قرار تشغيل التطبيق ومراقبته والتدخل عند ظهور مشكلة أصبح مجموعة واجبات مستقلة داخل حوكمة الشركة.
التغيير لا ينقل المسؤولية كاملة من المطور إلى الناشر، بل يقسمها بحسب ما يستطيع كل طرف التحكم فيه. وتؤكد تغطية Technology Record المنشورة في 2 سبتمبر أن فصل الناشر الجديد يخص استخدام تطبيقات ذكاء اصطناعي تابعة لأطراف خارجية داخل Microsoft، ويشمل فحص قدرات التطبيق وقيوده وضوابطه، ومخاطر النشر، والأداء والحوادث بعد التشغيل، والمعلومات المقدمة للمستخدم.
ما الذي تغير في توزيع المسؤولية؟
كان معيار Microsoft يجمع متطلبات الحوكمة حول النظام ودورة حياته، أما تصميمه المحدّث فيضيف فصلين يميزان دور المطور من دور الناشر. كما أصبحت المتطلبات موزعة بحسب طبقة التقنية، سواء كانت نموذجًا أو خدمة منصة أو تطبيقًا، مع قواعد أساسية وضوابط إضافية مرتبطة بسياقات الخطر الأعلى.
عمليًا، يبقى المطور مسؤولًا عن المعرفة التي لا يستطيع فريق النشر إنتاجها من تلقاء نفسه: قدرات النظام وحدوده، ووسائل الحماية المضمنة، وطرق قياس الأداء، والخصائص المتاحة للمراقبة. ويملك الناشر في المقابل معلومات لا تتوافر بالضرورة للمطور، مثل الغرض الفعلي من التطبيق، والبيانات التي سيصل إليها، وصلاحياته، والمستخدمين أو القرارات التي قد يتأثرون به.
لهذا تصبح عملية التسليم بين الطرفين نقطة حوكمة، لا مجرد نقل تقني. وثائق المطور تغذي تقييم النشر، لكن وجودها لا يعفي الجهة المشغلة من اختبار المخاطر التي تنشأ عن بيئتها واستخدامها المحددين.
أربع مراحل لحوكمة النشر داخل Microsoft
تحدد صفحة تقرير الشفافية لعام 2026 أربع مراحل مترابطة لتطبيقات الأطراف الخارجية التي تنشرها Microsoft: التقييم، والنشر، والرصد والاستجابة، وإبلاغ المستخدم. والرصد ليس فحصًا أخيرًا منفصلًا، بل نشاط مستمر يرافق تشغيل التطبيق والتواصل بشأنه.
- التقييم: مراجعة وثائق المزوّد المتعلقة بقدرات التطبيق وقيوده وضوابط الحماية وميزات المراقبة، والتأكد من أن قرار التشغيل يستند إلى معلومات يمكن فحصها.
- النشر: تحديد المخاطر الناتجة من الاستخدام المقصود والبيئة الفعلية، ثم تطبيق وسائل التخفيف والإشراف بما يحافظ على الحكم البشري والمساءلة.
- الرصد والاستجابة: متابعة الأداء وملاحظات المستخدمين والحوادث بعد الإطلاق، وتحديد المشكلات واتخاذ إجراء تصحيحي وتحسين الضوابط عند الحاجة.
- إبلاغ المستخدم: توضيح الاستخدامات المقصودة والقيود ووسائل الحماية المطبقة، كي يعرف المستخدم نطاق الاعتماد المناسب على التطبيق.
لا تعني هذه المراحل أن كل مؤسسة مطالبة بنسخ إجراءات Microsoft حرفيًا. قيمتها التشغيلية هي إظهار أن قبول التطبيق قبل الإطلاق لا يكفي وحده، وأن مالك بيئة الاستخدام يحتاج إلى صلاحية واضحة لتعليق التشغيل أو تقييده أو تعديل ضوابطه عندما تكشف المراقبة خطرًا جديدًا.
كيف تتوزع المهام في فريق منتج؟
يمكن تحويل الفصل الجديد إلى سجل مسؤوليات من دون افتراض وجود فريقين منفصلين تنظيميًا. فقد تؤدي المؤسسة دور المطور والناشر معًا، لكن عليها مع ذلك تمييز الأدلة والقرارات الخاصة بكل دور حتى لا تضيع المسؤولية عند الانتقال من البناء إلى التشغيل.
- قبل التسليم: يوثق المطور القدرات والقيود والاختبارات ووسائل الحماية وإمكانات الرصد، ويبين ما لم تغطه التقييمات.
- قبل التفعيل: يحدد الناشر الاستخدام المقصود والبيانات والأدوات والصلاحيات والأشخاص المتأثرين، ثم يختبر المخاطر المرتبطة بهذه البيئة.
- عند الإطلاق: يقرر الناشر ضوابط الوصول والإشراف البشري وحدود التشغيل وآلية التصعيد، مستندًا إلى معلومات المطور وتقييم السياق.
- بعد الإطلاق: يتابع الناشر الأداء والشكاوى والحوادث، بينما يحتاج المطور إلى استقبال المشكلات التي تكشف عيبًا في النظام أو وسيلة الحماية وإدخالها في الاختبارات والتحديثات اللاحقة.
هذه القائمة ترجمة تشغيلية لبنية المعيار المنشورة وليست نصًا تنظيميًا صادرًا للمؤسسات العربية. وهي تبرز خصوصًا ضرورة تحديد مالك لكل قرار: من يقبل المخاطر المتبقية، ومن يراقب المؤشرات، ومن يستطيع وقف الوكيل، ومن يبلغ المستخدمين عند تغير قدراته أو حدوده.
الوكلاء يجعلون المراقبة بعد الإطلاق أساسية
يرتبط تحديث المعيار باتساع استخدام الأنظمة الوكيلة القادرة على تنفيذ مهام متعددة الخطوات والتفاعل مع أدوات وبيانات وبيئات أخرى. في هذه الأنظمة لا يتحدد الخطر بسلوك النموذج منفردًا؛ فقد تغير الهوية الممنوحة للوكيل، وصلاحيات الأدوات، والذاكرة، ومصادر البيانات، أثر التطبيق بعد نشره.
قد يجتاز الوكيل تقييمًا في بيئة محدودة ثم يتغير نطاق خطره عند إضافة قاعدة بيانات أو أداة تنفيذ أو صلاحية أوسع. لذلك يحتاج فريق النشر إلى مراقبة الأفعال الفعلية والحوادث وملاحظات المستخدمين، وإلى مسار يعيد نتائج التشغيل إلى المطور عندما تكشف مشكلة قابلة للمعالجة في النظام نفسه.
بالنسبة للمؤسسات في الشرق الأوسط وشمال أفريقيا، ينطبق المنطق نفسه على الاستخدامات المحلية من دون أن يفترض التقرير مستوى خطر موحدًا لها. اختلاف اللغة والبيانات والقطاع والقوانين والصلاحيات يعني أن تقييم النظام الأصلي لا يجيب وحده عن سلامة كل نشر لاحق.
معيار داخلي وليس قاعدة قانونية عالمية
نطاق فصل الناشر محدد: إنه ينظم كيفية نشر Microsoft لتطبيقات ذكاء اصطناعي تابعة لأطراف أخرى داخل بيئتها. لذلك لا يحول تقرير الشفافية هذا المسار إلى قانون تفرضه الشركة على المؤسسات، ولا يحدد المسؤولية القانونية النهائية عند وقوع ضرر.
يمكن للفرق الاستفادة من تقسيم العمل، لكنها تظل مطالبة بتحديد واجباتها وفق قوانين الدولة والقطاع والعقود المطبقة عليها. كما أن تسمية طرف ما «مطورًا» أو «ناشرًا» داخل سير العمل لا تضمن تطابق دوره مع التعريفات القانونية المستخدمة في كل ولاية قضائية.
المؤكد حتى الآن هو أن Microsoft فصلت الدورين في معيارها وأدرجت الرقابة والاستجابة بعد الإطلاق ضمن واجبات النشر. أما الأثر العملي الأوسع فسيتوقف على تفاصيل تطبيق الفصول الجديدة، وجودة المعلومات التي تنتقل بين الأطراف، وما ستكشفه تقارير الشركة اللاحقة عن تنفيذ المتطلبات والحوادث والإجراءات التصحيحية.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.