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

من المعرفة التنظيمية إلى قرار مؤسسي

امتلاك مكتبة من الأنظمة والأطر والإرشادات ليس حوكمة.

يمكن للمؤسسة أن تجمع عشرات الوثائق الصادرة عن سدايا والهيئة الوطنية للأمن السيبراني والجهات القطاعية، ومع ذلك تظل عاجزة عن الإجابة عن سؤال بسيط:

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

المشكلة ليست نقص المعلومات فقط.

المشكلة هي غياب السلسلة التي تحول المعلومات إلى قرار وتشغيل ومتابعة.

في السعودية، قد يتقاطع مشروع AI واحد مع عدة طبقات في الوقت نفسه، مثل:

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

لذلك لا يوجد سؤال واحد اسمه:

ما تنظيم الذكاء الاصطناعي الذي ينطبق علينا؟

السؤال الصحيح متعدد الأبعاد.

1. ابدأ بالـAI Inventory، لا بالسياسة

لا تستطيع المؤسسة حوكمة شيء لا تعرف بوجوده.

يجب أن يبدأ البرنامج بجرد الاستخدامات والأنظمة التي تحتوي قدرات AI، سواء كانت:

• مطورة داخليًا.
• مشتراة من مورد.
• خدمة SaaS تحتوي AI مدمجًا.
• نموذجًا يتم الوصول إليه عبر API.
• أداة Generative AI.
• Agentic AI.
• ميزة AI تم تفعيلها داخل منصة موجودة أصلًا.
• تجربة أو Proof of Concept.
• أداة يستخدمها الموظفون دون اعتماد رسمي.

ليس المطلوب فقط تسجيل اسم المنتج.

السجل المفيد يجب أن يجيب مثلًا عن:

الـInventory ليس سجل أصول IT تقليديًا.

إنه نقطة البداية لكل قرار حوكمة لاحق.

2. افصل Use Case عن Product

هذه نقطة غالبًا ما تُفقد.

يمكن للمنتج نفسه أن يكون منخفض المخاطر في استخدام، وعالي المخاطر في استخدام آخر.

مثلًا، نموذج توليدي واحد قد يستخدم لـ:

تلخيص محتوى عام

وفي مكان آخر لـ:

تحليل بيانات عملاء أو دعم قرار يؤثر عليهم.

تقنيًا قد يكون المنتج نفسه.

حوكميًا ليس النظام نفسه.

لذلك يجب أن يحتوي السجل على:

Product / Model + Use Case + Data + Decision Context + Users + Business Process

وليس Vendor + Product فقط.

3. نفذ Applicability قبل Compliance

بعد اكتشاف النظام يأتي السؤال:

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

لا تبدأ بتحويل كل وثيقة سعودية إلى Checklist.

ابدأ بالوقائع.

أسئلة الجهة

• هل المؤسسة حكومية أم خاصة أم غير ربحية؟
• ما القطاع؟
• هل تخضع لمتطلبات قطاعية خاصة؟
• هل تقع ضمن نطاق ضوابط سيبرانية محددة؟

أسئلة البيانات

• هل توجد بيانات شخصية؟
• هل توجد بيانات حساسة؟
• هل توجد بيانات مقيدة أو مصنفة؟
• هل يتم نقل البيانات أو مشاركتها؟
• أين تتم المعالجة؟

أسئلة التقنية

• هل النظام سحابي؟
• هل يوجد مورد خارجي؟
• هل تستخدم API خارجية؟
• هل يعتمد على نموذج طرف ثالث؟
• هل يستطيع تنفيذ Actions؟

أسئلة الأثر

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

ثم تربط الإجابات بالمصادر التنظيمية ذات الصلة.

4. لا تخلط بين Applicability وRisk

قد يكون هناك Requirement قابل للتطبيق على النظام مهما كان تقييم المخاطر الداخلي.

وفي الاتجاه الآخر، قد توجد مخاطرة مؤسسية مهمة حتى إن لم تكن هناك مادة تنظيمية محددة تسميها صراحة.

لذلك نحتاج مسارين:

Regulatory Applicability

و:

AI Risk Assessment

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

5. صنّف المخاطر ولكن لا تختزلها في رقم

مبادئ أخلاقيات AI المنشورة من SDAIA تتناول مستويات للمخاطر وتربط إدارة المخاطر بدورة حياة النظام، بما في ذلك المراقبة والاختبار والضوابط.

لكن داخل المؤسسة، ليس الهدف إنتاج:

Risk Score = 73

ثم إخفاء كل شيء وراء الرقم.

الأفضل الاحتفاظ بأبعاد الخطر بصورة منفصلة، مثل:

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

يمكن استخدام Tier نهائي لتوجيه القرار.

لكن يجب أن تبقى أسباب التصنيف مرئية.

6. حدد Decision Rights قبل أول حالة خلاف

البرنامج الذي لا يحدد من يقرر سيتحول إلى اجتماعات.

يجب تحديد صلاحيات مثل:

• من يستطيع تسجيل حالة AI؟
• من يملك Business Use Case؟
• من يقيّم الخصوصية؟
• من يقيّم الأمن السيبراني؟
• من يراجع المورد؟
• من يصنف المخاطر؟
• من يعتمد الاستخدام؟
• متى يلزم تصعيد؟
• من يقبل Residual Risk؟
• من يستطيع فرض شروط؟
• من يستطيع إيقاف النظام؟

ليست كل القرارات بحاجة إلى لجنة.

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

7. اجعل الموافقة قرارًا موثقًا، لا بريدًا إلكترونيًا

نهاية التقييم يجب أن تنتج Decision Record واضحًا.

مثلًا:

Approved
Approved with Conditions
Pilot Only
Restricted
Rejected
Suspended
Retired

ويجب أن يسجل القرار على الأقل:

• النظام والاستخدام.
• مالك العمل.
• مستوى المخاطر.
• المصادر التنظيمية المطبقة.
• الاستثناءات.
• الضوابط المطلوبة.
• الأدلة المطلوبة.
• صاحب الموافقة.
• تاريخ القرار.
• مدة صلاحية الموافقة.
• أحداث إعادة التقييم.

بهذا يصبح القرار قابلًا للمراجعة لاحقًا.

8. Approval with Conditions أهم من نعم أو لا

كثير من حالات AI لا تحتاج:

Allow / Ban

فقط.

قد يكون الاستخدام مقبولًا بشرط:

• عدم إدخال أنواع محددة من البيانات.
• تعطيل خاصية معينة.
• استخدام حسابات مؤسسية فقط.
• فرض Human Review.
• الحد من الصلاحيات.
• الاحتفاظ بالسجلات.
• تنفيذ اختبار أمني.
• مراجعة المورد سنويًا.
• منع التنفيذ الآلي لبعض الإجراءات.
• اعتماد نموذج معين دون غيره.

وهنا تتحول الحوكمة من Gate جامد إلى Controlled Enablement.

9. البيانات يجب أن تسير مع Use Case

وجود PDPL يعني أن معالجة البيانات الشخصية تحتاج إلى تحليل وفق النظام ولوائحه، وليس فقط وفق سياسة AI داخلية.

لذلك يجب أن يعرف سجل النظام مثلًا:

• ما البيانات الداخلة؟
• لماذا تستخدم؟
• من مصدرها؟
• هل هي شخصية؟
• هل هي حساسة؟
• أين تخزن؟
• مع من تشارك؟
• أين يعالجها المورد؟
• كم تبقى؟
• هل تستخدم لتدريب النموذج؟
• هل يستطيع المورد إعادة استخدامها؟

المشكلة لا تنتهي عند:

نحن لا ندرب النموذج على بياناتكم.

فهذه إجابة عن متغير واحد فقط.

10. الأمن السيبراني ليس Appendix

ضوابط NCA الأساسية ECC 2-2024 تشكل طبقة سيبرانية قائمة بذاتها للجهات الواقعة ضمن نطاقها، بينما CCC 2-2024 تتناول متطلبات الحوسبة السحابية من منظور مقدم الخدمة والمشترك.

لذلك يجب أن يمر AI Security Review عبر الأسئلة التقنية الفعلية، وليس بند:

Cybersecurity reviewed = Yes.

مثلًا:

• Authentication.
• Privileged access.
• API security.
• Secret management.
• Logging.
• Monitoring.
• Network exposure.
• Cloud architecture.
• Data protection.
• Model/API abuse.
• Prompt injection exposure.
• Third-party integrations.
• Incident response.
• Resilience.
• Backup/recovery حيث ينطبق.

وفي Agentic AI يجب إضافة:

• ما الأدوات التي يستطيع الوكيل الوصول إليها؟
• ما الأفعال التي يستطيع تنفيذها؟
• ما حدود الصلاحية؟
• أين توجد Human Approval Gates؟
• هل يمكن إيقاف التنفيذ؟
• هل يوجد أثر تدقيق للأفعال؟

11. المورد ليس dependency واحدة

في SaaS تقليدي قد يظهر المورد كعلاقة واضحة.

في AI، النظام قد يعتمد على سلسلة أطول:

Application → AI Vendor → Foundation Model → Cloud → API → Vector Store → Data Provider → Tool → Subprocessor

إذا فشل أحدها أو تغير، قد يتغير النظام كله.

لذلك Vendor Assessment وحده غير كافٍ.

يجب أن تفهم المؤسسة Dependency Chain.

12. اسأل سؤال الخروج قبل الشراء

واحد من أكثر الأسئلة التي يتم تجاهلها:

ماذا يحدث إذا أردنا ترك هذا النظام بعد سنتين؟

يجب تقييم:

• إمكانية استخراج البيانات.
• قابلية نقل الـworkflows.
• بدائل النموذج.
• بدائل المورد.
• اعتماد التطبيق على API خاصة.
• اعتماد المستخدمين على خصائص مغلقة.
• تكلفة إعادة البناء.
• الوقت اللازم للخروج.
• فقدان المعرفة.
• المهارات المطلوبة داخليًا.

قد يكون النظام ممتازًا وظيفيًا لكنه يخلق اعتمادًا يصعب عكسه.

وهذا ليس Vendor Risk تقليديًا فقط.

إنه سؤال سيادة مؤسسية.

13. لا تطلب Evidence لا تعرف لماذا تحتاجه

كل Requirement مهم يجب أن يمتلك Evidence Expectation مناسبًا.

مثلًا:

لكن يجب تجنب بناء Evidence Repository ضخم بلا نموذج تهديد واضح.

الأدلة المؤسسية قد تحتوي معلومات حساسة للغاية، لذلك تخزينها يحتاج إلى tenant isolation وRBAC والتشفير وسجلات تدقيق وسياسة احتفاظ وغيرها من الضمانات قبل تحويل Siyada إلى مستودع ملفات مؤسسي. هذه نقطة مقفلة أصلًا في معمارية المنتج.

14. لا تجعل الموافقة أبدية

AI يتغير بعد الموافقة.

قد يتغير:

• النموذج.
• المورد.
• شروط الاستخدام.
• سياسة الخصوصية.
• مكان الاستضافة.
• Subprocessor.
• طريقة الاحتفاظ بالبيانات.
• قدرات Agentic جديدة.
• API.
• تكامل جديد.
• الاستخدام نفسه.
• القانون أو الإرشادات التنظيمية.

لذلك يجب ربط كل نظام بـReassessment Triggers.

15. استخدم Event-Triggered Reassessment

بدل أن تعتمد فقط على:

Annual Review

اجعل أحداثًا معينة تفتح التقييم مجددًا.

مثلًا:

Model Changed
Vendor Changed
New Subprocessor
New Data Category
New Jurisdiction
Security Incident
Material Feature Enabled
Agentic Capability Added
Use Case Expanded
Regulatory Status Changed
Contract Renewed
Approval Expired

هذا يتسق مع منطق المراقبة المستمرة الذي بُني أيضًا في Third-Party AI & Shadow AI vertical المخطط للمنصة. دورة التشغيل المرجعية هناك هي Discovery → Intake → Triage → Due Diligence → Risk Assessment → Controls → Approval → Monitoring → Reassessment.

16. Shadow AI يجب أن يدخل في نفس النظام

إذا كان الـInventory يعتمد فقط على Procurement فلن يكون كاملًا.

قد تصل AI إلى المؤسسة عبر:

• موظف فتح حسابًا مجانيًا.
• إضافة Browser.
• AI feature أضافها المورد إلى SaaS قائم.
• API استخدمه فريق تطوير.
• أداة اشترتها إدارة بصورة مباشرة.
• Plugin.
• Embedded AI.
• تجربة غير رسمية.

لذلك يجب أن يكون Discovery مصدرًا مستمرًا للسجل وليس خطوة onboarding واحدة.

ومن المصادر المحتملة:

• Self-declaration.
• Procurement.
• Security.
• DLP/CASB.
• Audit.
• Incident.
• SaaS discovery.
• Manual governance review.

17. افصل بين النظام، الخطر، القرار، والضابط

خطأ معماري شائع هو وضع كل شيء في سجل واحد.

الأفضل التفكير في كيانات مترابطة:

AI System / Use Case

له:

Applicable Requirements

وله:

Risks

وله:

Controls

وله:

Evidence

وله:

Decisions

وله:

Issues / Exceptions

وله:

Monitoring Events

بهذا يمكن تغيير أحدها دون فقد تاريخ البقية.

18. Executive Dashboard يجب أن يعرض القرارات لا النشاط

لوحة الإدارة العليا لا يجب أن تقول فقط:

• لدينا 83 نظام AI.
• أكملنا 54 تقييمًا.
• رفعنا 236 مستندًا.

هذه أرقام نشاط.

الإدارة تحتاج معرفة:

• كم نظامًا عالي المخاطر؟
• كم نظامًا بلا مالك؟
• كم استخدامًا غير معتمد؟
• أين يوجد Shadow AI؟
• أين لدينا residual risk مرتفع؟
• ما القرارات التي تحتاج Executive Acceptance؟
• ما الاعتمادات الحرجة على مورد واحد؟
• ما الأنظمة التي لا يمكن الخروج منها بسهولة؟
• ما التغييرات التنظيمية التي قد تغير وضعنا؟
• أين يوجد evidence gap؟
• ما الأنظمة المتأخرة عن reassessment؟

هذه Decision Metrics.

19. النموذج التشغيلي المقترح

ما يلي نموذج تحريري/تشغيلي تقترحه سيادة AI، وليس Workflow رسميًا مفروضًا من جهة سعودية.

يمكن تمثيل دورة الحوكمة المؤسسية هكذا:

Discover
↓
Register
↓
Determine Applicability
↓
Classify Risk
↓
Assess Data / Privacy / Cyber / AI / Vendor
↓
Define Controls
↓
Make Approval Decision
↓
Collect Evidence
↓
Deploy / Use
↓
Monitor
↓
Detect Change
↓
Reassess
↓
Continue / Restrict / Suspend / Retire

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

20. من Applicability Matrix إلى Applicability Engine

في البداية يمكن للمؤسسة استخدام Matrix يدوية.

لكن مع زيادة عدد:

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

يصبح العمل اليدوي هشًا.

وهنا تظهر الحاجة مستقبلًا إلى Applicability Engine.

وظيفته ليست إعطاء “رأي قانوني آلي”.

بل مساعدة الفريق على تحويل خصائص المؤسسة والنظام إلى قائمة أولية قابلة للمراجعة من:

• الأنظمة.
• الضوابط.
• السياسات.
• التقييمات.
• أصحاب القرار.
• الأدلة.
• triggers.

ثم يبقى القرار النهائي خاضعًا لأصحاب الصلاحية والخبرة.

21. من Vendor Register إلى Sovereign Dependency Graph™

هذا القسم يمثل تصور سيادة AI للمنتج وليس متطلبًا تنظيميًا سعوديًا.

الـVendor Register يجيب:

من موردنا؟

لكن السؤال الأهم مستقبلًا:

ما الذي تعتمد عليه قدرتنا على تشغيل هذا النظام والسيطرة عليه؟

لذلك يجب توسيع العلاقة إلى:

AI System / Use Case → Data Dependencies → Model Dependencies → Compute Dependencies → API Dependencies → Vendor Dependencies → Jurisdiction Dependencies → Talent Dependencies → Exit Constraints

وهذه المعمارية معتمدة بالفعل في خارطة طريق Siyada AI، حيث لا يُعامل Sovereign Dependency Graph™ كخريطة بصرية فقط، بل كمحرك تحليلي يربط الأنظمة والموردين والمخاطر والأدلة والضوابط والقرارات والمراقبة.

22. ماذا يجب أن يقيس Dependency Graph؟

ليس Score واحدًا.

بل أبعادًا مستقلة مثل:

Data Sovereignty

• أين توجد البيانات؟
• من يستطيع الوصول إليها؟
• هل يمكن إخراجها؟

Model Sovereignty

• من يملك النموذج؟
• هل يمكن تغييره؟
• هل توجد بدائل؟

Infrastructure Sovereignty

• أين يعمل النظام؟
• على أي cloud / compute يعتمد؟

Jurisdiction Sovereignty

• ما الاختصاصات القضائية المرتبطة بالسلسلة؟

Operational Sovereignty

• هل تستطيع المؤسسة تشغيل النظام دون المورد؟

Talent Sovereignty

• هل توجد المعرفة اللازمة داخليًا؟

Exit Readiness

• كم يكلف الخروج؟
• كم يستغرق؟
• ما الذي سيُفقد؟

الهدف ليس تحقيق “استقلال كامل”.

هذا غالبًا غير واقعي.

الهدف أن تعرف المؤسسة أين توجد تبعيتها، وهل هي مقبولة ومقصودة وقابلة للإدارة.

23. نموذج المؤسسة الناضجة

يمكن تلخيص النضج الحقيقي بخمس قدرات:

تعرف

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

تفهم

ما البيانات والمخاطر والمتطلبات والاعتمادات المرتبطة بها.

تقرر

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

تثبت

ما الأدلة التي تبرهن أن القرار والضوابط طُبقت.

تتكيف

تعيد التقييم عندما يتغير النظام أو المورد أو البيئة التنظيمية.

غياب أي واحدة منها يترك فجوة.

24. كيف يترجم هذا إلى Siyada AI؟

اليوم يستطيع Siyada Public أن يشرح:

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

لكن القيمة المؤسسية القادمة تبدأ عندما تنتقل المعرفة إلى:

Knowledge → Applicability → Assessment → Decision → Action → Evidence → Assurance → Executive Reporting

وهذه السلسلة ليست فكرة جديدة أضيفت لهذا المقال؛ هي السلسلة المعتمدة أصلًا في معمارية Institutional Workspace في Siyada AI.

25. كيف ترتبط طبقات المنتج؟

يمكن أن تتطور التجربة بالشكل التالي:

Siyada AI Public

يشرح:

• ما المصدر؟
• ماذا يعني؟
• ما حالته؟
• متى قد ينطبق؟
• ما المفاهيم المرتبطة؟

Professional Workspace

يسمح للفرد ببناء:

• Assessment.
• Applicability output.
• Risk triage.
• Decision-rights map.
• Action plan.
• Dependency assessment.

Institutional Workspace

يحول ذلك إلى سجل مؤسسي حي:

• AI Inventory.
• Use Cases.
• Vendors.
• Risks.
• Controls.
• Decisions.
• Evidence.
• Issues.
• Monitoring.
• Reassessment.

CAIO Workspace

يرفع البيانات إلى مستوى القرار التنفيذي:

• Enterprise AI posture.
• Material risks.
• Exceptions.
• Concentration.
• Regulatory change.
• Strategic dependencies.
• Sovereignty posture.
• Executive decisions.

وهنا يصبح المحتوى العام هو الطبقة المعرفية لنظام تشغيل حوكمي أوسع، لا منتجًا منفصلًا عنه.

الخلاصة

الحوكمة المؤسسية للذكاء الاصطناعي في السعودية لا يمكن اختزالها في سياسة AI واحدة أو Checklist واحدة.

المنهج العملي هو:

اعرف النظام → افهم استخدامه وبياناته واعتماداته → حدد ما ينطبق → قيّم المخاطر → حدد أصحاب القرار → ضع الضوابط → اتخذ قرارًا موثقًا → اربطه بالأدلة → راقب التغيير → أعد التقييم عند الحاجة.

ثم أضف السؤال الذي يُهمل غالبًا:

إذا تغير المورد أو النموذج أو البنية أو الاختصاص القضائي، هل ما زلنا نملك السيطرة العملية على هذا النظام؟

عندها تنتقل المؤسسة من AI Compliance إلى AI Governance.

ومن AI Governance إلى AI Sovereignty.