دليل حوكمة الذكاء الاصطناعي للمؤسسات في دولة الإمارات

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

حوكمة الذكاء الاصطناعي في المؤسسة الإماراتية لا ينبغي أن تبدأ بسؤال:

أين قانون الذكاء الاصطناعي؟

السؤال الأصح هو:

ما النظام الذي نستخدمه، وما الذي يفعله، وما البيانات التي يعالجها، ومن يتأثر به، وأين نعمل، وما القواعد التي تنطبق علينا، ومن يملك سلطة السماح باستخدامه؟

مشهد الإمارات موزع بين:

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

لذلك لا يكفي إنشاء AI Policy.

المؤسسة تحتاج:

AI Governance Operating System.

أي نظام مؤسسي يربط:

Inventory → Applicability → Risk → Authority → Controls → Approval → Evidence → Deployment → Monitoring → Reassessment → Accountability.

كيف نفهم مشهد حوكمة AI في الإمارات؟

الإمارات تتبنى الذكاء الاصطناعي بصورة استراتيجية واسعة.

لكن التنظيم لا يعمل من خلال وثيقة واحدة تشمل كل نظام وكل قطاع.

قد تكون المؤسسة في الوقت نفسه مطالبة بالنظر إلى:

• Federal legislation.
• Personal data protection.
• Cybersecurity.
• sector regulation.
• contractual obligations.
• DIFC or ADGM rules when applicable.
• financial-sector requirements.
• professional or safety obligations.
• internal risk appetite.

وهذا يعني أن حوكمة AI يجب أن تتعامل مع Applicability قبل التعامل مع Compliance Checklist.

لماذا لا يبدأ البرنامج من قانون AI واحد؟

هناك خطأ شائع في بناء برامج AI Governance:

البحث أولًا عن تشريع يحمل اسم:

Artificial Intelligence Law

ثم بناء البرنامج حوله.

هذا الأسلوب غير مناسب.

قد يؤثر قانون حماية البيانات على AI حتى لو لم يكن قانون AI.

قد تؤثر قواعد حماية المستهلك على Automated Decision.

قد تؤثر متطلبات القطاع المالي على Model Governance.

قد تؤثر قوانين الطفل على Recommendation Systems وAge Estimation.

وقد تتغير الالتزامات بحسب:

• القطاع.
• المنطقة القانونية.
• نوع العميل.
• طبيعة البيانات.
• مستوى الأثر.
• استخدام النظام.

إذن:

AI Governance is applicability-driven, not label-driven.

نموذج الحوكمة المؤسسية

النموذج الفعال يحتاج ثلاثة مستويات.

المستوى الأول: Governance

من يضع القواعد؟

من يملك Risk Appetite؟

من يقرر؟

من يراقب؟

المستوى الثاني: Management

كيف يتم:

• التسجيل؟
• التقييم؟
• الموافقة؟
• التوثيق؟
• التصعيد؟
• إعادة التقييم؟

المستوى الثالث: Technical and Operational Controls

كيف يتم تطبيق:

• Access control.
• testing.
• logging.
• privacy.
• security.
• monitoring.
• human oversight.

الفشل يحدث عندما توجد لجنة في المستوى الأول ولا يوجد Workflow في المستوى الثاني أو Controls في المستوى الثالث.

المساءلة والملكية

كل AI System يجب أن تكون له مسؤولية بشرية واضحة.

على الأقل يجب تحديد:

Business Owner

يمتلك الغرض التجاري والنتيجة.

Technical Owner

يمتلك التكامل والتشغيل التقني.

Data Owner

يمتلك حوكمة البيانات حيث يلزم.

Risk or Control Owner

يمتلك الضوابط أو الرقابة ذات الصلة.

Approval Authority

صاحب صلاحية السماح بالتشغيل.

لا يجوز أن تكون الإجابة:

The AI decided.

النظام ليس كيان المساءلة النهائي.

سجل أنظمة واستخدامات AI

AI Inventory هو نقطة البداية العملية.

السجل يجب ألا يقتصر على النماذج التي طورتها المؤسسة.

بل يشمل:

• Internal models.
• SaaS AI.
• Generative AI.
• Copilots.
• embedded AI features.
• APIs.
• recommendation systems.
• scoring systems.
• AI agents.
• vendor-managed models.
• employee-use tools where relevant.

لكل سجل يجب حفظ معلومات مثل:

• system name.
• owner.
• purpose.
• vendor.
• model.
• deployment environment.
• affected users.
• data types.
• decisions supported.
• degree of autonomy.
• jurisdictions.
• current status.
• risk tier.

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

خريطة الاختصاص والانطباق

وجود Country Relation واحدة باسم UAE مفيد للمحتوى.

لكن في التطبيق المؤسسي يجب النزول إلى طبقة أعمق.

مثلًا:

• UAE Federal.
• Dubai.
• DIFC.
• Abu Dhabi.
• ADGM.
• CBUAE-regulated activity.
• DFSA-regulated activity.
• FSRA-regulated activity.
• healthcare.
• employment.
• children.
• other regulated sectors.

هذه هي Jurisdiction & Applicability Layer.

يجب أن يجيب كل System Record عن:

Where does this system operate and which regulatory perimeter applies?

تصنيف المخاطر والأهمية

ليست كل استخدامات AI متساوية.

يمكن أن يبدأ Enterprise Classification من عناصر مثل:

Impact

ما حجم الضرر إذا أخطأ النظام؟

Decision significance

هل يؤثر على قرار جوهري؟

Autonomy

هل يقترح أم ينفذ؟

Data sensitivity

هل يعالج Personal أو Sensitive Data؟

User vulnerability

هل يؤثر في أطفال أو مرضى أو فئات معرضة؟

Scale

كم شخصًا أو معاملة يتأثر؟

Reversibility

هل يمكن عكس النتيجة بسهولة؟

External dependency

كم يعتمد على مورد أو Model API خارجي؟

يمكن تحويل هذه العناصر إلى Risk Tier.

لكن الرقم وحده ليس الهدف.

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

What governance must happen next?

بوابات الموافقة قبل الاستخدام

ليس كل AI Use Case بحاجة إلى Board Approval.

لكن لا ينبغي أيضًا أن يستطيع كل فريق تشغيل ما يريد.

يمكن بناء Approval Tiers.

منخفض المخاطر

Self-service registration مع ضوابط أساسية.

متوسط المخاطر

مراجعة Privacy أو Security أو Risk بحسب الحالة.

مرتفع المخاطر

Cross-functional assessment وموافقة رسمية.

Critical

Executive approval وAssurance أقوى ومراقبة مستمرة.

المبدأ:

Approval intensity should follow impact and risk.

البيانات والخصوصية

كل AI Assessment يجب أن يسأل:

• هل توجد Personal Data؟
• هل توجد Sensitive Data؟
• من مصدرها؟
• ما الغرض؟
• هل تستخدم في training أو fine-tuning؟
• هل تنتقل إلى vendor؟
• هل توجد Profiling؟
• هل توجد Automated Decisions؟
• أين تتم المعالجة؟
• هل توجد Retention Rules؟
• هل يستطيع الفرد ممارسة حقوقه؟

Privacy Review لا ينبغي أن تكون ملفًا منفصلًا عن AI Assessment.

بل جزءًا من نفس Governance Record.

الأمن السيبراني للذكاء الاصطناعي

AI يضيف Attack Surface جديدة.

من المخاطر:

• Prompt Injection.
• data leakage.
• poisoned knowledge sources.
• insecure plugins.
• excessive permissions.
• credential exposure.
• model manipulation.
• malicious files.
• unsafe tool calls.
• supply-chain vulnerabilities.

ولهذا Security Review يجب أن يغطي أكثر من Network Security.

نحتاج:

AI Security by Design.

العدالة والشفافية وقابلية التفسير

عندما يؤثر النظام في البشر يجب تقييم:

• هل توجد فروقات أداء بين مجموعات؟
• هل البيانات مناسبة للسياق؟
• هل النتيجة قابلة للمراجعة؟
• هل يفهم المستخدم دور AI؟
• هل القرار قابل للاعتراض؟
• هل توجد مراجعة بشرية مناسبة؟

Explainability ليست مطلبًا واحدًا بنفس المستوى لكل نظام.

نظام داخلي لتلخيص اجتماع لا يحتاج مستوى تفسير نظام يستخدم لاتخاذ قرار يؤثر على شخص.

حوكمة AI للأطراف الثالثة

كثير من AI داخل المؤسسة ليس ملكًا لها.

قد تستخدم:

• Foundation model.
• SaaS product.
• AI API.
• embedded feature.
• cloud model.
• vendor agent.

وهنا يجب تقييم:

Vendor

من هو؟

Model

ما النموذج؟

Data

ماذا يحصل عليه؟

Jurisdiction

أين تتم المعالجة؟

Security

ما الضوابط؟

Change

هل يستطيع تغيير النموذج دون إشعار؟

Auditability

ما الأدلة المتاحة؟

Exit

كيف تخرج المؤسسة؟

Dependency

ماذا يحدث إذا تعطلت الخدمة أو تغير السعر أو أغلقت API؟

Vendor Risk يجب أن يتحول إلى Third-Party AI Governance.

Shadow AI واستخدامات الموظفين

أحد أكبر فجوات الحوكمة هو AI الذي لا يمر عبر Procurement أو IT.

قد يستخدم الموظف أداة عامة من أجل:

• تلخيص عقد.
• تحليل بيانات عميل.
• كتابة تقرير.
• إنتاج كود.
• ترجمة ملف.
• تحليل سيرة ذاتية.

إذا لم يكن هناك:

• Policy.
• approved tools.
• data rules.
• awareness.
• monitoring.
• exception process.

فسينمو Shadow AI تلقائيًا.

الحظر الكامل غالبًا لا يحل المشكلة.

الحل هو إنشاء مسار آمن وسهل للاستخدام المسموح.

الضمان والاختبار والتدقيق

AI Assurance يجيب عن سؤال:

ما الأدلة التي تجعلنا نثق بأن النظام مناسب للاستخدام المحدد؟

يمكن أن تشمل الأدلة:

• validation results.
• test cases.
• bias testing.
• security testing.
• privacy assessment.
• red-team testing.
• performance thresholds.
• vendor evidence.
• human oversight tests.
• incident simulation.

Assurance ليست Audit فقط.

والـAudit ليس Assurance بالكامل.

الـAssurance أوسع ويمكن أن يحدث قبل النشر وأثناء التشغيل.

الموافقة على النشر والتشغيل

قبل Production يجب التأكد من أن النظام:

• مسجل.
• مصنف.
• تمت مراجعة Applicability.
• تمت مراجعة Data.
• تمت مراجعة Security.
• استوفى الاختبارات.
• لديه Owner.
• لديه Monitoring Plan.
• لديه Incident Process.
• لديه Exit أو Suspension Plan عندما يلزم.

ثم يجب تسجيل:

Who approved production use and on what evidence?

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

AI system قد يكون جيدًا يوم الإطلاق ثم يصبح غير مناسب بعد أشهر.

أسباب التغير:

• model update.
• data drift.
• user behaviour.
• vendor change.
• new attack.
• new regulation.
• business-process change.
• new population.
• new feature.

Post-Deployment Monitoring يجب أن يكون جزءًا من Lifecycle وليس مرحلة اختيارية.

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

لا ينبغي الاعتماد فقط على Annual Review.

يجب تعريف Event-Triggered Review.

من المحفزات:

• تغيير النموذج.
• تغيير المورد.
• إضافة بيانات جديدة.
• تغيير الغرض.
• زيادة autonomy.
• إضافة integration.
• دخول سوق أو jurisdiction جديد.
• incident.
• regulatory change.
• significant performance deterioration.

المبدأ:

Material change → reassessment.

الحوادث والتعليق والإيقاف

AI Incident Process يجب أن يحدد:

• ما هو incident؟
• من يبلّغ؟
• من يحقق؟
• من يستطيع تعليق النظام؟
• ماذا يحدث للمستخدمين؟
• هل يجب إخطار جهة أخرى؟
• كيف تحفظ الأدلة؟
• متى يسمح بإعادة التشغيل؟

بعض الأنظمة تحتاج:

Kill or Suspension Capability.

لكن الإيقاف يجب أن يكون مصممًا ومختبرًا، لا مجرد نص في السياسة.

الأدلة وسجل القرار

حوكمة لا تنتج Evidence ليست حوكمة قابلة للإثبات.

يجب الاحتفاظ بما يكفي لإعادة بناء القرار:

What was proposed?

What was assessed?

What evidence existed?

What risks were identified?

What controls were required?

Who approved?

What conditions were imposed?

What changed later?

وهذا هو أساس Auditability.

مؤشرات مجلس الإدارة والإدارة التنفيذية

لا يحتاج مجلس الإدارة إلى قائمة بكل Prompt.

يحتاج مؤشرات مثل:

• عدد AI systems.
• توزيع Risk Tiers.
• critical systems.
• unapproved AI.
• overdue reviews.
• major incidents.
• high-risk vendors.
• unresolved exceptions.
• systems without owners.
• material regulatory gaps.
• concentration risk.
• remediation status.

الهدف هو Governance Visibility وليس Operational Noise.

خارطة تنفيذ عملية

يمكن للمؤسسة البدء على مراحل.

المرحلة 1 — Discover

• AI Inventory.
• Shadow AI discovery.
• vendor inventory.

المرحلة 2 — Classify

• use case.
• data.
• impact.
• risk.
• jurisdiction.

المرحلة 3 — Govern

• roles.
• policy.
• risk appetite.
• approval authorities.

المرحلة 4 — Control

• privacy.
• security.
• testing.
• human oversight.
• vendor controls.

المرحلة 5 — Evidence

• assessments.
• approvals.
• exceptions.
• logs.

المرحلة 6 — Monitor

• performance.
• incidents.
• changes.
• regulatory developments.

المرحلة 7 — Improve

• metrics.
• audit findings.
• lessons learned.
• maturity roadmap.

أخطاء شائعة

إنشاء AI Committee دون Operating Model

اللجنة وحدها لا تدير دورة الحياة.

إنشاء Policy دون Inventory

لا يمكنك تطبيق السياسة على ما لا تعرفه.

تطبيق Checklist واحدة على الجميع

المخاطر تختلف.

مساواة Vendor Approval بـAI Approval

المورد قد يكون مقبولًا لكن Use Case غير مقبول.

فصل Legal وPrivacy وSecurity وRisk

ينتج تقييمات متكررة ومتعارضة.

تجاهل Shadow AI

جزء مهم من المخاطر قد يكون خارج السجل الرسمي.

اعتبار Go-Live نهاية الحوكمة

هو بداية مرحلة المراقبة.

عدم تحديد Stop Authority

عند الأزمة لا يعرف أحد من يملك القرار.

خلاصة سيادة

حوكمة AI المؤسسية في الإمارات يجب ألا تتحول إلى عملية بحث عن قانون واحد.

النموذج الأكثر نضجًا هو:

Discover

→ Classify

→ Map Applicability

→ Assign Accountability

→ Assess Risk

→ Design Controls

→ Assure

→ Approve

→ Deploy

→ Monitor

→ Reassess

→ Suspend or Improve

→ Evidence Everything.

المعادلة الأساسية:

Governance = Authority + Process + Controls + Evidence + Accountability.

عندما تستطيع المؤسسة الإجابة عن:

ما أنظمة AI لدينا؟

أين تعمل؟

ما الذي ينطبق عليها؟

من يملكها؟

ما مخاطرها؟

من سمح بها؟

على أي أدلة؟

ومن يستطيع إيقافها؟

فهي لا تملك مجرد AI Policy.

بل تملك AI Governance Operating System.