دليل حوكمة Agentic AI للمؤسسات في دولة الإمارات

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

Agentic AI يغير طبيعة حوكمة الذكاء الاصطناعي.

مع الأنظمة التقليدية كان السؤال غالبًا:

What can the model say or predict?

مع الوكلاء يصبح السؤال:

What can the system do?

يمكن للوكيل أن:

• يقرأ بيانات.
• يستخدم أدوات.
• يستدعي APIs.
• يفتح تذاكر.
• يرسل رسائل.
• يعدل سجلات.
• ينفذ عمليات.
• ينشئ طلبات.
• يتعامل مع أنظمة أخرى.
• يتخذ قرارات ضمن حدود معينة.
• ينفذ معاملات.

وهنا تنتقل المؤسسة من:

Model Risk

إلى:

Model Risk + Authority Risk + Action Risk + Transaction Risk.

ولهذا تحتاج Agentic AI إلى نموذج حوكمة مختلف.

Agentic AI في السياق الإماراتي

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

ويشير الإعلان الرسمي إلى:

• autonomous execution.
• decision-making.
• proactive task execution.
• redesign of policies and processes.
• continuous performance measurement.
• impact assessment.

وفي مايو 2026 اعتمد مجلس الوزراء إطار أدوار ومسؤوليات الوزارات والجهات الاتحادية لتنفيذ المشروع.

هذه التطورات تؤكد أن Agentic AI لم يعد مجرد موضوع تقني تجريبي.

لكن يجب التمييز بين:

Government Agentic AI programme

و:

general legal obligation on every private enterprise.

هذا الدليل هو Siyada enterprise governance synthesis، وليس نصًا حكوميًا ملزمًا للقطاع الخاص.

من Model Risk إلى Authority Risk

النموذج قد ينتج نصًا خاطئًا.

أما الوكيل فقد يحول النص الخاطئ إلى فعل.

مثلًا:

النموذج يقترح:

"ألغِ حساب العميل."

لكن Agent قد يستطيع فعليًا:

call API → disable account.

وهنا الفرق جوهري.

الخطر لم يعد فقط:

Wrong answer.

بل:

Wrong authorised action.

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

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

متى يصبح النظام Agentic؟

ليس كل Chatbot Agent.

يمكن التفكير في مستوى Agency كطيف.

Level 0 — Informational

يعطي معلومات فقط.

Level 1 — Recommend

يحلل ويقترح.

Level 2 — Prepare

يجهز فعلًا لكن إنسان ينفذه.

Level 3 — Execute with approval

ينفذ بعد موافقة بشرية.

Level 4 — Bounded autonomous execution

ينفذ تلقائيًا داخل حدود محددة.

Level 5 — Higher autonomy

يخطط وينفذ ويتكيف عبر عدة خطوات وأدوات ضمن نطاق واسع.

كل انتقال يرفع أهمية Authority Governance.

Siyada Agentic Authority Chain™

تستخدم سيادة نموذجًا تشغيليًا لحوكمة السلطة المفوضة للوكيل:

Objective

→ Delegation

→ Authority

→ Identity

→ Access

→ Decision

→ Action

→ Transaction

→ Evidence

→ Oversight

→ Intervention

→ Accountability

هذا النموذج:

Siyada Operational Governance Synthesis.

ليس إطارًا رسميًا صادرًا عن حكومة دولة الإمارات.

وظيفته تحويل المبادئ العامة إلى سلسلة Controls يمكن للمؤسسة تنفيذها وتدقيقها.

1. Objective — الهدف

قبل منح أي صلاحية يجب تحديد:

What is the agent trying to achieve?

الهدف يجب أن يكون:

• محددًا.
• مشروعًا.
• مرتبطًا بعملية معروفة.
• قابلًا للقياس.
• محدود النطاق.

مثال ضعيف:

Improve customer operations.

مثال أفضل:

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

كلما كان الهدف غامضًا توسعت مساحة التفسير الذاتي للوكيل.

2. Delegation — التفويض

السؤال التالي:

Who delegated the objective to the agent?

يجب ألا تأتي سلطة الوكيل فقط من Developer Configuration.

يجب أن يكون هناك Business Authority.

التفويض يحدد:

• الغرض.
• المدة.
• النطاق.
• الأنظمة.
• القيود.
• مستوى autonomy.
• شروط التصعيد.

التفويض المؤسسي يجب أن يكون قابلاً للإثبات.

3. Authority — السلطة

Capability ليست Authority.

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

لكن هذا لا يعني أن المؤسسة سمحت له بالحذف.

يجب تعريف:

Permitted authority

و:

Prohibited authority.

مثلًا:

يمكنه:

• إنشاء Draft.
• اقتراح قرار.
• تحديث حقل معين.

ولا يمكنه:

• حذف الحساب.
• تغيير Master Data.
• إجراء Refund.
• اعتماد موظف.
• توقيع التزام قانوني.

هذه الحدود يجب أن تكون Policy + Technical Enforcement.

4. Identity — هوية الوكيل

كل وكيل يجب أن يكون له Identity واضحة.

لا ينبغي تشغيل عدة وكلاء من حساب إداري مشترك إذا كان ذلك يمنع Attribution.

نحتاج القدرة على معرفة:

• أي Agent؟
• أي Version؟
• تحت أي Service Identity؟
• من Owner؟
• ما Environment؟
• ما Permissions؟

Agent Identity أساس المساءلة التقنية.

5. Access — الوصول والصلاحيات

بعد Identity تأتي Permissions.

المبدأ:

Scoped Permissions.

لا تمنح Agent صلاحية كاملة لأن التكامل أسهل.

يجب استخدام:

• least privilege.
• role-based access.
• scoped tokens.
• short-lived credentials where suitable.
• environment separation.
• resource-specific permissions.

يجب أن تكون صلاحيات Agent أضيق من صلاحيات الإنسان إذا كان الهدف يتطلب ذلك.

6. Decision — سلطة القرار

هناك فرق بين:

Generate information

و:

Recommend

و:

Decide.

يجب تحديد القرارات التي:

يمكن للوكيل اتخاذها

مثل Routing منخفض المخاطر.

تحتاج Approval

مثل إلغاء عملية أو تغيير حالة حساسة.

لا يجوز تفويضها

مثل قرارات معينة ذات أثر قانوني أو مالي أو بشري مرتفع وفق سياق المؤسسة.

يجب ربط Decision Rights بالـRisk Tier.

7. Action — حدود الأفعال

حتى إذا استطاع Agent اتخاذ قرار يجب تحديد:

What actions may follow?

Action Boundary قد تشمل:

• أدوات مسموحة.
• APIs مسموحة.
• جداول مسموح تعديلها.
• قنوات اتصال مسموحة.
• ساعات تشغيل.
• عدد العمليات.
• أنواع الملفات.
• البلدان.
• العملاء.
• البيئات.

مثال:

يمكن لوكيل دعم العملاء إنشاء Draft Email.

لكن لا يستطيع إرساله دون Approval.

هذه ليست نفس الصلاحية.

8. Transaction — سلطة المعاملات

Transaction Authority تحتاج طبقة مستقلة.

لأن الوكيل قد يستطيع:

• purchase.
• refund.
• transfer.
• order.
• booking.
• contract workflow.
• payment instruction.

يجب تحديد:

Per-transaction limit

مثل حد مالي لكل عملية.

Aggregate limit

إجمالي يومي أو شهري.

Counterparty restrictions

لمن يمكن الدفع أو الشراء؟

Category restrictions

ما أنواع المعاملات؟

Approval threshold

متى يصبح Human Approval إلزاميًا؟

Agent لديه القدرة على تنفيذ معاملة لا يعني أنه يملك سلطة غير محدودة لتنفيذها.

9. Evidence — الأدلة

Agentic AI يحتاج Evidence أعمق من Chat Logs.

يجب أن نعرف:

• الهدف.
• plan where available.
• input.
• context.
• tool selected.
• tool arguments where appropriate.
• data accessed.
• decision.
• action.
• transaction.
• result.
• exception.
• approval.
• override.

الهدف ليس تسجيل كل Token بلا حدود.

الهدف هو الاحتفاظ بما يسمح بإعادة بناء ما حدث.

10. Oversight — الإشراف

Human Oversight له أشكال مختلفة.

Human-in-the-Loop

الإنسان يوافق قبل الفعل.

Human-on-the-Loop

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

Human-over-the-System

إشراف أعلى على السياسات والحدود والأداء.

اختيار النموذج يعتمد على:

• impact.
• speed.
• reversibility.
• transaction value.
• vulnerability.
• error tolerance.

Human Oversight يجب أن تكون:

Meaningful.

ليس وجود اسم موظف في وثيقة.

11. Intervention — التدخل والإيقاف

كل Agent مرتفع الأثر يحتاج Intervention Design.

يمكن أن يشمل:

• pause.
• revoke token.
• disable tools.
• stop workflow.
• reduce permissions.
• switch to recommendation-only mode.
• isolate agent.
• full kill switch.

السؤال الحاسم:

Can we stop the agent faster than it can create unacceptable harm?

Kill Switch غير المختبرة ليست Control مكتملة.

12. Accountability — المساءلة

آخر السلسلة يعيدنا إلى الإنسان والمؤسسة.

يجب تحديد:

Who remains accountable for delegated authority?

قد يكون:

• Process Owner.
• Executive Owner.
• System Owner.
• regulated function owner.

لكن لا ينبغي أن تصبح Accountability موزعة لدرجة أن لا أحد يملكها.

يمكن توزيع المسؤوليات.

لكن يجب عدم تبخير المساءلة.

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

في Security يوجد Least Privilege.

في Agentic Governance نضيف:

Least Agency Principle.

المعنى:

لا تمنح النظام Autonomy أعلى مما يحتاجه لتحقيق الهدف.

إذا كانت Recommendation كافية، لا تعطِ Execution.

إذا كانت Execution بعد Approval كافية، لا تعطِ Autonomous Execution.

إذا كانت أداة واحدة كافية، لا تعطِ عشر أدوات.

إذا كان حد 1,000 كافيًا، لا تعطِ حد 100,000.

القاعدة:

Minimum autonomy necessary for legitimate business value.

الأنظمة متعددة الوكلاء

Multi-Agent Systems تضيف تعقيدًا جديدًا.

قد يوجد:

• planner agent.
• research agent.
• execution agent.
• approval agent.
• monitoring agent.

وهنا تظهر أسئلة:

• من يستطيع إنشاء Agent جديد؟
• هل Agent يستطيع تفويض Agent آخر؟
• هل تنتقل صلاحيات الأصل تلقائيًا؟
• كيف نمنع privilege propagation؟
• كيف نعرف من نفذ الفعل النهائي؟
• ماذا لو تفاعل وكلاء بأهداف متعارضة؟

Agent-to-Agent Delegation يجب ألا يكون طريقًا للالتفاف حول Governance.

الأمن وPrompt Injection

Agentic AI يجعل Prompt Injection أخطر.

في Chatbot قد تؤدي Injection إلى إجابة سيئة.

في Agent يمكن أن تؤدي إلى:

tool invocation.

مثلًا قد يحتوي:

• Email.
• webpage.
• document.
• ticket.
• retrieved content.

على تعليمات خبيثة تحاول دفع Agent إلى:

• كشف بيانات.
• استدعاء أداة.
• تغيير إعداد.
• إرسال رسالة.
• تنفيذ معاملة.

لذلك يجب فصل:

Data

عن:

Trusted Instructions.

واستخدام:

• tool allowlists.
• validation.
• scoped permissions.
• content isolation.
• approval thresholds.
• monitoring.

الوكلاء والموردون الخارجيون

قد يكون Agent:

• built internally.
• vendor SaaS.
• cloud agent.
• embedded inside enterprise software.
• powered by external foundation model.

يجب ألا نفحص اسم Vendor فقط.

بل Dependency Chain:

Enterprise

→ Agent Platform

→ Model

→ Cloud

→ API

→ Tools

→ External services.

ومن هنا تصبح Dependency Map مهمة.

يجب معرفة:

• من يملك كل طبقة؟
• أين توجد البيانات؟
• ما jurisdiction؟
• ماذا يحدث عند outage؟
• هل يمكن تغيير model؟
• ما تكلفة الخروج؟
• هل يوجد بديل؟

تصنيف وموافقات Agentic AI

يمكن بناء Agentic Risk Tier من عناصر مثل:

Autonomy

+ Authority

+ Access

+ Action impact

+ Transaction value

+ Data sensitivity

+ Human oversight

+ Reversibility

+ External dependency.

مثلًا:

Tier A

Read-only agent.

Tier B

Agent ينشئ drafts.

Tier C

Agent ينفذ أفعالًا قابلة للعكس ضمن حدود.

Tier D

Agent يتخذ قرارات أو معاملات عالية الأثر.

كل Tier يجب أن يرتبط بـControl Baseline مختلف.

المراقبة وإعادة التقييم

Agentic Monitoring لا يراقب accuracy فقط.

يجب مراقبة:

• actions.
• tool calls.
• failed calls.
• denied actions.
• escalations.
• overrides.
• transaction values.
• anomalies.
• permissions.
• incidents.
• human intervention rates.

ويجب إعادة التقييم عند:

• model change.
• prompt or policy change.
• new tool.
• expanded permission.
• new system access.
• higher transaction limit.
• new purpose.
• new jurisdiction.
• incident.
• change in vendor.

زيادة authority هي Material Change.

خارطة التطبيق المؤسسي

يمكن للمؤسسة تطبيق Agentic Governance بالترتيب التالي.

المرحلة 1 — Discover

أنشئ Agent Inventory.

المرحلة 2 — Define Objective

حدد الهدف والغرض.

المرحلة 3 — Establish Delegation

حدد صاحب التفويض.

المرحلة 4 — Map Authority

حدد ما يسمح وما يحظر.

المرحلة 5 — Create Identity

هوية منفصلة قابلة للتتبع.

المرحلة 6 — Scope Access

أقل صلاحيات ممكنة.

المرحلة 7 — Define Decision Rights

Recommend / approve / decide.

المرحلة 8 — Define Actions

Tool and action boundaries.

المرحلة 9 — Limit Transactions

Limits and approvals.

المرحلة 10 — Build Evidence

Logs and decision records.

المرحلة 11 — Design Oversight

Human control model.

المرحلة 12 — Test Intervention

Pause and kill mechanisms.

المرحلة 13 — Assign Accountability

Named accountable owner.

المرحلة 14 — Monitor

Continuous control monitoring.

أخطاء شائعة

معاملة Agent كـChatbot

يتجاهل Action Risk.

إعطاؤه حساب Admin

يكسر Least Privilege وAttribution.

منح كل الأدوات منذ البداية

يتعارض مع Least Agency.

عدم الفصل بين Recommend وExecute

هما سلطتان مختلفتان.

عدم وضع Transaction Limits

خطر مالي مباشر.

استخدام Shared Credentials

يضعف المساءلة.

Human Oversight دون وقت أو قدرة للتدخل

إشراف شكلي.

Kill Switch غير مختبرة

لا يمكن الاعتماد عليها.

السماح بإنشاء Sub-agents بحرية

قد يوسع السلطة بطريقة غير مرئية.

تسجيل المحادثة دون Actions

الدليل ناقص.

اعتبار Vendor Agent مسؤولية المورد

المؤسسة تبقى مسؤولة عن السلطة التي منحته إياها داخل عملياتها.

القول إن Siyada Agentic Authority Chain إطار حكومي إماراتي

غير صحيح.

هو نموذج تشغيلي من سيادة للاستفادة من مبادئ الحوكمة وتحويلها إلى Controls قابلة للتطبيق.

خلاصة سيادة

التحول الحقيقي مع Agentic AI ليس:

Chat → Better Chat.

بل:

Intelligence → Delegated Digital Authority.

ولهذا يجب ألا تبدأ الحوكمة من النموذج فقط.

بل من سلسلة السلطة كاملة:

Objective

→ Delegation

→ Authority

→ Identity

→ Access

→ Decision

→ Action

→ Transaction

→ Evidence

→ Oversight

→ Intervention

→ Accountability.

هذه هي:

Siyada Agentic Authority Chain™.

وتقود إلى مبدأ مؤسسي أساسي:

Never give an AI agent more authority, access, autonomy, or transaction power than is necessary for its approved objective.

ثم اسأل دائمًا:

Who delegated the authority?

Can we prove what the agent did?

Can a human intervene?

Can we stop it?

Who remains accountable when it acts?

إذا كانت المؤسسة لا تستطيع الإجابة عن هذه الأسئلة، فهي لا تحكم Agentic AI بعد.

هي فقط تشغله.