ضوابط حوكمة الذكاء الاصطناعي الوكيلي Agentic AI في الإمارات

الخلاصة التنفيذية

أدخلت دولة الإمارات في 2026 مفهوم Agentic AI إلى قلب نموذج العمل الحكومي، مع توجه رسمي نحو أنظمة تستطيع تنفيذ مهام وسلاسل من الإجراءات واتخاذ قرارات ديناميكية ضمن أطر حوكمة محددة.

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

عند هذه النقطة تتغير طبيعة الحوكمة.

لم يعد السؤال فقط:

• هل النموذج دقيق؟
• هل البيانات جيدة؟
• هل المخرجات عادلة؟
• هل توجد سياسة للذكاء الاصطناعي؟

بل تصبح هناك أسئلة إضافية:

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

هذه المقالة تقدم نموذجًا تشغيليًا من سيادة AI للإجابة عن هذه الأسئلة.

أولًا: ما هو رسمي وما هو تحليل سيادة؟

هناك فصل يجب الحفاظ عليه طوال المقال.

الطبقة الرسمية الإماراتية

تستند إلى:

• المنظومة الحكومية الإماراتية للـAgentic AI.
• ميثاق تطوير واستخدام الذكاء الاصطناعي.
• مبادئ وإرشادات أخلاقيات الذكاء الاصطناعي.
• التوجه الرسمي نحو الحوكمة والمساءلة والإشراف والمسؤولية.

طبقة سيادة التشغيلية

المفاهيم التالية في هذه المقالة هي صياغة حوكمية وتشغيلية من سيادة AI:

• Least Agency.
• Agent Authority.
• Action Boundary.
• Scoped Permissions.
• Transaction Authority.
• Transaction Limits.
• Event-Triggered Review.
• Siyada Agentic Authority Chain™.

وجودها هنا لا يعني أنها وردت بهذه الأسماء كمتطلبات رسمية في الإطار الحكومي الإماراتي.

الهدف هو ترجمة المبادئ العليا إلى ضوابط قابلة للتطبيق داخل المؤسسة.

لماذا تختلف حوكمة Agentic AI؟

النظام التقليدي قد ينتج توصية خاطئة.

لكن الوكيل قد:

• يرسل رسالة.
• يعدل سجلًا.
• يستدعي API.
• ينشئ طلب شراء.
• يبدأ Workflow.
• يوافق على خطوة.
• يغير إعدادًا.
• ينقل بيانات.
• يتعامل مع وكيل آخر.
• ينفذ سلسلة كاملة من الإجراءات.

إذن المخاطر لم تعد مرتبطة فقط بـOutput Risk.

نحن أمام:

Action Risk.

وقد تتحول إلى:

Transaction Risk.

ولهذا يجب أن تنتقل الحوكمة من:

Model Governance

إلى:

Model + Authority + Action Governance.

ما الذي يجب أن تحكمه المؤسسة؟

يمكن تلخيص نطاق حوكمة الوكيل في عشر طبقات:

1. الهدف.
2. التفويض.
3. السلطة.
4. الهوية.
5. الوصول.
6. القرار.
7. الفعل.
8. المعاملة.
9. الأدلة.
10. الإشراف والمساءلة.

إذا عرفت المؤسسة النموذج لكنها لم تعرف هذه العناصر، فهي لا تملك صورة كاملة عن Agentic AI.

الهدف والتفويض

كل وكيل يجب أن يبدأ بهدف مؤسسي محدد.

ليس:

"استخدم الذكاء الاصطناعي لتحسين المشتريات."

بل مثلًا:

"ساعد فريق المشتريات على جمع عروض الموردين ومقارنتها وتجهيز توصية، دون إنشاء أمر شراء نهائي."

هذا الفرق مهم لأنه يحدد منذ البداية:

• النتيجة المطلوبة.
• حدود المهمة.
• مستوى الاستقلالية.
• من فوض النظام.
• متى تعتبر المهمة مكتملة.

كلما كان الهدف فضفاضًا ازدادت احتمالات أن يتوسع سلوك الوكيل بصورة غير مقصودة.

سلطة الوكيل وحدود الأفعال

Agent Authority هي السلطة التي تمنح للوكيل داخل البيئة المؤسسية.

يجب عدم مساواتها بالقدرة التقنية.

قد يكون الوكيل قادرًا تقنيًا على حذف سجل من قاعدة بيانات.

هذا لا يعني أنه ينبغي أن يمتلك السلطة المؤسسية للقيام بذلك.

لذلك تحتاج المؤسسة إلى Action Boundary يحدد:

مسموح

• قراءة بيانات محددة.
• إنشاء Draft.
• إرسال طلب مراجعة.
• تحديث حالة منخفضة المخاطر.

يحتاج موافقة

• إرسال رسالة خارجية.
• اعتماد مورد.
• تنفيذ دفعة.
• تغيير سياسة.
• نشر محتوى رسمي.

ممنوع

• تجاوز صلاحيات المستخدم.
• تعديل سجلات تدقيق.
• تعطيل ضوابط الأمن.
• منح نفسه صلاحيات جديدة.

حدود الأفعال يجب أن تكون جزءًا من تصميم الوكيل، لا تعليمات عامة في Prompt فقط.

مبدأ الحد الأدنى من الوكالة

تقترح سيادة مفهوم:

Least Agency Principle.

فكرته بسيطة:

امنح النظام أقل قدر من الاستقلالية اللازمة لتحقيق الهدف.

إذا كان الهدف يمكن تحقيقه بنظام يقدم توصية، فلا تمنحه تنفيذًا تلقائيًا.

إذا كان التنفيذ ممكنًا ضمن مبلغ 1,000 درهم، فلا تمنحه قدرة على تنفيذ معاملة بقيمة 100,000.

إذا كان يحتاج القراءة، فلا تمنحه الكتابة.

هذا امتداد منطقي لمبدأ Least Privilege في الأمن، لكن على مستوى الوكالة والاستقلالية نفسها.

الصلاحيات والوصول

يجب تحديد:

• البيانات التي يقرأها.
• الأنظمة التي يدخل إليها.
• الأدوات التي يستطيع استدعاءها.
• APIs المتاحة.
• نوع العمليات.
• مدة الصلاحية.
• نطاق المستخدمين أو الحسابات.
• البيئة: Test أم Production.

ويفضل أن تكون الصلاحيات:

Scoped + Time-bound + Purpose-bound.

أي محددة بالنطاق، والوقت، والغرض.

القرار والفعل والمعاملة

من المفيد فصل ثلاث قدرات:

Decision

هل يستطيع النظام اختيار مسار؟

Action

هل يستطيع تنفيذ إجراء تقني؟

Transaction

هل يستطيع إنشاء أثر مالي أو قانوني أو تشغيلي حقيقي؟

مثل:

• دفع مبلغ.
• قبول عقد.
• إنشاء Purchase Order.
• إلغاء اشتراك.
• تغيير صلاحية مستخدم.
• إرسال عرض رسمي.

كل انتقال من مستوى إلى المستوى التالي يحتاج حوكمة أقوى.

الإشراف والتدخل البشري

الإشراف البشري ليس خيارًا واحدًا.

قد يكون:

Human-in-the-Loop

الإنسان يوافق قبل تنفيذ الإجراء.

Human-on-the-Loop

النظام يعمل، لكن الإنسان يراقب ويستطيع التدخل.

Human Override

يمتلك الإنسان القدرة على إلغاء أو تغيير قرار النظام.

Human Escalation

يعيد النظام الحالة للإنسان عند تجاوز شرط محدد.

النموذج المناسب يعتمد على أثر القرار وإمكانية الرجوع عنه.

الأدلة وقابلية التدقيق

كل نظام وكيلي مهم يجب أن يترك أثرًا قابلًا للمراجعة.

يجب أن نعرف:

• متى بدأ.
• بأي هوية عمل.
• ما الهدف.
• ما البيانات التي استخدمها.
• ما الأدوات التي استدعاها.
• ما القرارات التي اتخذها.
• ما الأفعال التي نفذها.
• ما الموافقات البشرية.
• ما الاستثناءات.
• النتيجة النهائية.

سجل المحادثة وحده ليس Audit Trail كافيًا.

المراقبة بعد النشر

Agentic AI قد يتغير سلوكه حتى دون تغيير النموذج نفسه.

قد يتغير:

• API.
• مصدر البيانات.
• Prompt.
• صلاحية.
• أداة.
• Workflow.
• مورد خارجي.
• حجم الاستخدام.

لذلك تحتاج المؤسسة إلى Post-Deployment Monitoring تشمل:

• أخطاء التنفيذ.
• محاولات تجاوز السلطة.
• حالات التصعيد.
• المعاملات غير الطبيعية.
• تغير الأداء.
• الحوادث الأمنية.
• عدد تدخلات البشر.
• نسبة الأفعال الملغاة.

متى يجب إعادة التقييم؟

لا يكفي تقييم الوكيل عند الإطلاق.

تقترح سيادة Event-Triggered Review عند أحداث مثل:

• إضافة Tool جديد.
• رفع مستوى الصلاحيات.
• السماح بمعاملات مالية.
• توصيله بنظام جديد.
• تغيير البيانات الحساسة التي يعالجها.
• الانتقال من Recommendation إلى Action.
• رفع حدود المعاملات.
• تشغيل Multi-Agent architecture.
• تغيير مزود أساسي.
• وقوع حادث مؤثر.

الأطراف الثالثة والوكلاء المتعددون

الوكيل قد يعتمد على:

• نموذج خارجي.
• Cloud.
• API.
• SaaS.
• Plugin.
• Agent آخر.

لذلك يجب ألا تنتهي الحوكمة عند حدود المؤسسة التقنية.

يجب معرفة:

• من يملك كل Dependency؟
• أين تعالج البيانات؟
• ماذا يحدث إذا تعطل المزود؟
• هل يمكن للوكيل الخارجي تنفيذ فعل داخل بيئتنا؟
• كيف يتم توثيق الأفعال بين الوكلاء؟
• من يتحمل المسؤولية عند فشل سلسلة متعددة الأطراف؟

نموذج ضوابط تشغيلي

يمكن للمؤسسة استخدام الجدول التالي كحد أدنى:

أخطاء شائعة

منح الوكيل صلاحيات Administrator

سهولة التطوير ليست مبررًا للسلطة المفرطة.

الاعتماد على Prompt كضابط أمني

التعليمات ليست بديلًا عن enforcement تقني.

عدم فصل القدرة عن السلطة

"النظام يستطيع" لا تعني "النظام مسموح له".

تقييم النموذج وترك الأدوات

الوكيل + الأدوات هو النظام الحقيقي.

عدم إعادة التقييم

قد يصبح الوكيل عالي المخاطر بعد إضافة Tool واحدة.

نسبة ضوابط سيادة إلى الحكومة الإماراتية

هذا المقال يقدم Siyada Operational Synthesis وليس لائحة تنظيمية إماراتية.

Siyada Agentic Authority Chain™

تقترح سيادة السلسلة التالية:

Objective → Delegation → Authority → Identity → Access → Decision → Action → Transaction → Evidence → Oversight → Intervention → Accountability

فائدة السلسلة أنها تجبر المؤسسة على تتبع السلطة من البداية إلى النهاية.

إذا لم تستطع الإجابة عن إحدى حلقاتها، توجد فجوة حوكمة.

خلاصة سيادة

Agentic AI يغير موضوع الحوكمة نفسه.

في السابق كان السؤال المركزي:

هل يمكن الوثوق بمخرجات النظام؟

أما الآن فأصبح هناك سؤال إضافي:

هل يمكن الوثوق بما يُسمح للنظام أن يفعله؟

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

والقاعدة الأساسية هي:

لا تمنح النظام سلطة لأنه يستطيع استخدامها؛ امنحه فقط السلطة الضرورية والمبررة والقابلة للمراقبة والمراجعة والإيقاف.