ما هو هذا الإطار؟
إطار Model AI Governance Framework for Agentic AI الصادر عن Infocomm Media Development Authority (IMDA) في سنغافورة هو إطار حوكمة مؤسسي مخصص للذكاء الاصطناعي الوكيلي Agentic AI. أُطلق الإصدار الأول في يناير 2026 ثم حدّثته IMDA في 20 مايو 2026 إلى النسخة v1.5 بعد تلقي ملاحظات ومساهمات من أكثر من ستين جهة، وأضافت إليه ممارسات أكثر تفصيلًا حول الأنظمة متعددة الوكلاء، والوكلاء المقدمين من أطراف ثالثة، والتحيز الناتج عن الاعتماد المفرط على الأتمتة، وإدارة التغيير، إلى جانب أكثر من عشر دراسات حالة توضح كيف يمكن تشغيل توصيات الإطار في بيئات حقيقية.
الإطار ليس قانونًا ولا لائحة ملزمة، ولا ينبغي عرضه في سيادة AI بهذه الصفة. قيمته أنه يحول النقاش حول «الذكاء الاصطناعي الوكيلي» من تعريف تقني أو موجة تسويقية إلى مجموعة أسئلة تشغيلية: ما الذي يستطيع الوكيل فعله؟ إلى أي درجة يستطيع تقرير كيفية تنفيذ العمل؟ ما الأنظمة والبيانات والأدوات التي يصل إليها؟ أي أفعال يمكن عكسها وأيها لا يمكن؟ متى يجب أن يتوقف ويطلب موافقة بشرية؟ كيف نثبت هوية الوكيل ومن فوّضه؟ وكيف نراقب ما فعله بعد التنفيذ؟
لماذا يحتاج Agentic AI إلى حوكمة مختلفة؟
النظام التوليدي التقليدي قد ينتج نصًا أو صورة أو توصية ثم يترك التنفيذ للإنسان. أما الوكيل فقد يخطط لسلسلة خطوات، يختار أدوات، يصل إلى ملفات أو APIs، يرسل طلبات، يعدّل بيانات، يشغّل أوامر، أو ينسق مع وكلاء آخرين. هذه النقلة تعني أن الخطر لا يرتبط فقط بصحة المخرجات، بل كذلك بسلطة التنفيذ. قد تكون الإجابة الخاطئة مزعجة، لكن الإجراء الخاطئ قد يغيّر سجلًا، يرسل رسالة، يفتح صلاحية، ينفذ معاملة، أو يطلق سلسلة إجراءات يصعب إيقافها بعد بدئها.
لذلك يضع الإطار المسؤولية البشرية في المركز: استخدام وكيل لا ينقل المساءلة من المؤسسة أو الإنسان إلى النظام. وظيفة الحوكمة هي تحديد حدود الفعل قبل التشغيل، وليس فقط تحليل الحادثة بعد وقوعها.
البعد الأول: تقييم المخاطر وتقييدها مسبقًا
يركز البعد الأول على اختيار حالات الاستخدام المناسبة وتحديد حدود قدرات الوكيل قبل السماح له بالعمل. التقييم لا ينبغي أن يسأل فقط «هل النموذج جيد؟»، بل يجب أن يشمل شدة الأثر المحتمل، وقابلية عكس الإجراء، وإمكانية تدخل الإنسان، والوصول إلى البيانات الحساسة، والوصول إلى الأنظمة الخارجية، ومستوى الاستقلالية، وتعقيد سلسلة العمل، واعتماد الوكيل على مكونات أو خدمات من أطراف ثالثة.
هنا يظهر فرق مهم بين Action-Space وAutonomy. مساحة الفعل تصف ما تسمح البيئة للوكيل بفعله: قراءة بريد، تعديل ملف، تشغيل أمر، طلب شبكة، استدعاء أداة، إرسال معاملة، أو تغيير صلاحية. أما الاستقلالية فتصف مقدار الحرية الممنوحة له في تقرير متى وكيف ينفذ تلك الأفعال. وكيل بقدر عال من الاستقلالية داخل مساحة فعل ضيقة قد يكون أقل خطورة من وكيل باستقلالية أقل لكنه يملك قدرة على تنفيذ فعل مالي أو أمني شديد الأثر. لذلك لا يجوز اختزال المخاطر في «درجة الاستقلالية» وحدها.
يقدم التحديث حالات عملية توضح هذا المنطق. في حالة Dayos جرى تصنيف إجراءات تذاكر تقنية المعلومات بحسب شدة الأثر وقابلية العكس وإمكانية الإشراف البشري. الإجراءات منخفضة الأثر والقابلة للعكس يمكن أتمتتها مع المراجعة، بينما الإجراءات المتوسطة قد تتطلب اقتراحًا من الوكيل وموافقة بشرية قبل التنفيذ، أما الإجراءات عالية الأثر ومحدودة القابلية للعكس مثل تغييرات معينة على الصلاحيات فقد تُحجب عن الوكيل أصلًا. هذه الفكرة مهمة لأنها تحوّل تقييم المخاطر إلى حدود تشغيلية وليس إلى سجل مخاطر منفصل عن النظام.
البعد الثاني: جعل البشر مسؤولين بصورة فعلية
وجود زر «موافقة» لا يساوي إشرافًا بشريًا فعليًا. الإطار يركز على significant checkpoints، أي نقاط تدخل ذات معنى توضع عند الأفعال التي تستحق قرارًا بشريًا بسبب أثرها أو حساسيتها أو عدم قابليتها للعكس. يجب كذلك أن يحصل الشخص الذي يوافق على معلومات كافية لفهم ما الذي سيحدث ولماذا، وإلا يتحول التدخل البشري إلى إجراء شكلي.
دراسة Tencent CodeBuddy توضح هذا بصورة عملية: بعض الأفعال مثل تعديل الملفات، تشغيل أوامر shell، تنفيذ طلبات شبكة، أو استخدام أدوات خارجية يمكن أن تستدعي موافقة بشرية. كما تُشرح الأوامر المعقدة بلغة مفهومة حتى لا يوافق المستخدم على شيء لا يفهمه. ويستمر الرصد الآلي كطبقة حماية إضافية؛ فإذا اعتبر النظام أمرًا مشبوهًا يمكن أن يطلب موافقة جديدة حتى لو كان نمط مشابه قد سُمح به سابقًا.
هذا البعد يعالج أيضًا خطر automation bias: عندما يعتاد المستخدم أن أغلب اقتراحات الوكيل مقبولة قد تتحول الموافقة البشرية إلى ضغط تلقائي على زر Approve. لذلك جودة الإشراف تقاس بقدرة الإنسان على الفهم والاعتراض والإيقاف، لا بمجرد وجوده اسميًا في التدفق.
البعد الثالث: الضوابط التقنية والعمليات عبر دورة الحياة
الضوابط يجب أن تعمل قبل النشر وأثناءه وبعده. ويشمل ذلك الاختبار الأساسي للقدرات، التحكم في الوصول إلى الخدمات والأدوات، تقييد الاتصالات الخارجية، التسجيل المركزي، المراقبة، الحماية من إساءة استخدام الأدوات، والتوسع التدريجي بدل القفز مباشرة إلى صلاحيات واسعة.
تعرض حالة GovTech Singapore منطق النشر المرحلي بوضوح. بدأ استخدام مساعدين برمجيين وكيليين ضمن نطاق محدود لموظفين داخليين، ومن دون السماح بأدوات خارجية مثل MCP servers، وعلى أنظمة منخفضة المخاطر. هذا خفض نطاق الضرر المحتمل وأعطى الفريق فرصة لبناء ضوابط إضافية مثل التسجيل المركزي والمراقبة وإطار يسمح لاحقًا بالاتصال الآمن بالأدوات الخارجية المعتمدة. كما أتاح اختبار النظام ضد هجمات محتملة ومعالجة المشكلات التشغيلية وتقليل العبء المعرفي على الأشخاص المكلفين بالموافقة.
هذه الممارسة مهمة لأنها تكسر افتراضًا شائعًا: أن جاهزية الوكيل تقاس بقدرته على أداء المهمة. في الحوكمة، الجاهزية تشمل كذلك قدرة المؤسسة على رؤية الأفعال، تفسيرها، منعها، إيقافها، والتحقيق فيها.
إدارة التغيير ليست شأنًا تقنيًا ثانويًا
في النظام الوكيلي، تغيير صغير في نموذج أو prompt أو أداة أو صلاحية أو API قد يغيّر السلوك النهائي بطرق غير مباشرة، خاصة عندما يعمل الوكيل ضمن سلسلة أو نظام متعدد الوكلاء. لذلك تصبح إدارة التغيير جزءًا من الحوكمة: ما الذي تغير؟ ما القدرات الجديدة التي ظهرت؟ هل اتسعت مساحة الفعل؟ هل ظهرت جهة خارجية جديدة؟ هل أصبح الإجراء أقل قابلية للعكس؟ وهل تحتاج الضوابط أو نقاط الموافقة إلى إعادة تصميم؟
تزداد أهمية هذا في الأنظمة متعددة الوكلاء، حيث يمكن لخطأ أو معلومة غير صحيحة أو تعليمة ملوثة أن تنتقل من وكيل إلى آخر وتتحول إلى أثر مركب. لا يكفي تقييم كل وكيل منفردًا إذا كانت المخاطر تنشأ من التفاعل بينهم.
مخاطر الأنظمة متعددة الوكلاء والأطراف الثالثة
التحديث v1.5 وسّع الاهتمام بالأنظمة متعددة الوكلاء وبالوكلاء المقدمين من أطراف ثالثة. هذه نقطة مركزية لأن المؤسسة قد لا تبني كل وكيل بنفسها. قد تستخدم وكيلًا من مزود SaaS، نموذجًا خارجيًا، MCP server، API، ذاكرة مشتركة، أو وكيلًا فرعيًا ينشئه نظام آخر. كل عنصر جديد يضيف اعتمادًا وحدود ثقة جديدة.
من منظور سيادة AI، السؤال لا ينبغي أن يكون فقط «من هو المورد؟» بل: ما الذي يستطيع مكوّنه أن يفعل داخل بيئتنا؟ تحت أي هوية؟ هل يستطيع استدعاء أدوات؟ هل يستطيع تمرير بيانات؟ هل يستطيع إنشاء أو تفويض وكيل فرعي؟ أين تسجل أفعاله؟ وما الذي يحدث عندما تتغير الخدمة من جهة المورد؟ هذه الأسئلة تجعل حوكمة الطرف الثالث جزءًا من حوكمة السلطة وليس مجرد due diligence تعاقدية.
البعد الرابع: تمكين مسؤولية المستخدم النهائي
لا تستطيع المؤسسة وضع العبء كله على controls غير المرئية. المستخدم يحتاج إلى معرفة أنه يتعامل مع وكيل، وفهم نطاق عمله والحدود المهمة لاستخدامه. تعرض حالة Workday هذا المبدأ من خلال إبلاغ المستخدمين بأن التفاعل يتم مع أداة مدعومة بالذكاء الاصطناعي، وإظهار معلومات تساعدهم على مراجعة النتائج واستخدامها بصورة مسؤولة.
الشفافية هنا ليست مجرد label يقول «AI generated». في الأنظمة الوكيلية تصبح المعلومات الأهم: من أو ما الذي سينفذ؟ ماذا يمكنه أن يفعل؟ هل الفعل مجرد اقتراح أم تنفيذ فعلي؟ هل سيستخدم أدوات خارجية؟ ومتى يحتاج المستخدم إلى مراجعة أو تأكيد؟
هوية الوكيل والسلطة والوصول
على الرغم من أن الإطار لا يحول نفسه إلى معيار IAM، فإن منطقه يقود بوضوح إلى ضرورة إدارة هوية الوكيل وصلاحياته وحدود الوصول بصورة منظمة. الوكيل لا ينبغي أن يرث بصورة غير مدروسة كل صلاحيات المستخدم البشري. يجب أن تكون قدرته متناسبة مع المهمة، وأن تكون الصلاحيات قابلة للتقييد والإلغاء والمراجعة.
هذا يتقاطع مباشرة مع مفاهيم موجودة في سيادة AI مثل Agent Identity وAgent Authority وAuthority Envelope وAutonomy Ceiling. الفائدة من IMDA هنا ليست استبدال النموذج المعرفي لسيادة، بل توفير مرجع خارجي رسمي يثبت أن قضايا الهوية والصلاحية والاستقلالية ونقاط التدخل أصبحت عناصر تشغيلية في حوكمة Agentic AI.
العلاقة مع MCP والأدوات الخارجية
MCP أو أي آلية مماثلة لا ينبغي التعامل معها كتكامل تقني محايد. عندما يتيح MCP server للوكيل الوصول إلى نظام أو قاعدة بيانات أو وظيفة تنفيذية، فإنه يوسّع مساحة الفعل الفعلية للوكيل. لذلك يجب أن تخضع الأدوات الخارجية لقائمة سماح، وتحديد صلاحيات، واختبار، ورصد، ومراجعة عند التغيير.
حالة GovTech مهمة هنا لأنها بدأت بدون أدوات MCP خارجية ثم بنت إطارًا للربط الآمن بالأدوات المعتمدة. الرسالة العملية: لا تجعل اتصال الوكيل بالأدوات هو نقطة البداية الافتراضية. ابدأ بأقل مساحة فعل لازمة، ثم وسّعها عندما تصبح المراقبة والتحكم والهوية والمساءلة جاهزة.
ما الذي لا يقوله الإطار؟
الإطار ليس معيار شهادة، ولا يحدد نظام scoring موحدًا، ولا يقدم حدًا رقميًا عامًا يمكن تطبيقه على كل المؤسسات لتحديد «مستوى آمن من الاستقلالية». كما أنه لا يحل محل قوانين حماية البيانات أو الأمن السيبراني أو المتطلبات القطاعية. أي استخدام للإطار يجب أن يظل مرتبطًا بالسياق القانوني والقطاعي الفعلي للمؤسسة.
كذلك لا ينبغي تفسير دراسات الحالة على أنها control catalogue ملزم. قيمتها أنها تبين كيف حوّلت مؤسسات مختلفة المبادئ إلى حدود تشغيلية: تصنيف إجراءات، نقاط موافقة، نشر تدريجي، منع أدوات خارجية في المرحلة الأولى، تسجيل ومراقبة، وشفافية للمستخدم.
كيف تستخدم المؤسسة الإطار عمليًا؟
يمكن تحويل الإطار إلى سلسلة قرار مؤسسية:
- تحديد use case والهدف التجاري بدقة.
- تحديد مساحة الفعل: البيانات والأنظمة والأدوات والإجراءات المتاحة للوكيل.
- تحديد مستوى الاستقلالية المطلوب، وعدم منحه استقلالية أعلى من حاجة المهمة.
- تصنيف الأفعال بحسب الأثر وقابلية العكس وحساسية البيانات وإمكانية الإشراف البشري.
- وضع الأفعال عالية الحساسية خارج نطاق التنفيذ المستقل أو خلف نقاط موافقة بشرية.
- تثبيت هوية الوكيل والمالك أو المفوض المسؤول عنه.
- فرض least privilege على البيانات والأدوات والـAPIs.
- اختبار السلوك والحدود والسيناريوهات غير الطبيعية قبل الإنتاج.
- الإطلاق المرحلي مع logging وmonitoring وقدرة على الإيقاف أو تقليص الصلاحيات.
- إعادة التقييم عند أي تغيير جوهري في النموذج أو الأدوات أو الصلاحيات أو الطرف الثالث أو البنية متعددة الوكلاء.
موقع الإطار داخل مكتبة سيادة AI
يجب استخدام هذا السجل كمرجع خارجي رسمي تحت موضوع حوكمة الذكاء الاصطناعي الوكيلي، وربطه بالمحتوى الخاص بهوية الوكيل، سلطة الوكيل، نطاق السلطة، سقف الاستقلالية، الإشراف البشري، MCP، ومخاطر الأنظمة متعددة الوكلاء. لا ينبغي نسخه إلى نموذج Siyada Agentic Authority Chain™ أو عرضه كأنه مصدر ذلك النموذج؛ العلاقة الصحيحة هي crosswalk وتحليل مقارن واضح يفصل بين ما تقوله IMDA وما تضيفه منهجية سيادة.
الحالة المرجعية
النسخة المرجعية المعتمدة هنا هي v1.5 المحدثة في 20 مايو 2026. النسخة التي أطلقت في يناير 2026 تظل مهمة لفهم الأصل، لكن أي تفسير حالي للإطار داخل سيادة يجب أن يبدأ من النسخة الأحدث لأن IMDA أضافت ممارسات ودراسات حالة ومخاطر لم تكن بالتفصيل نفسه في الإصدار الأول.