حوكمة الذكاء الاصطناعي في عُمان مقابل NIST AI RMF: خريطة تحليلية من المتطلبات إلى إدارة المخاطر

حوكمة الذكاء الاصطناعي في عُمان مقابل NIST AI RMF: خريطة تحليلية من المتطلبات إلى إدارة المخاطر

قبل المقارنة: هذه ليست مواءمة رسمية

هذا المقال هو تحليل من سيادة AI.

لا توجد هنا دعوى بأن سلطنة عُمان تبنت NIST AI Risk Management Framework، ولا أن وزارة النقل والاتصالات وتقنية المعلومات أو NIST أصدرا خريطة مواءمة رسمية بين السياسة العُمانية وAI RMF.

الهدف مختلف:

استخدام NIST AI RMF كعدسة تشغيلية تساعد المؤسسة على تنظيم إدارة المخاطر والأدلة حول توقعات الحوكمة العُمانية.

لذلك يجب قراءة كل علاقة في هذا المقال باعتبارها crosswalk تحليلياً وليست معادلة قانونية أو تنظيمية.

ما هي نقطة الانطلاق في عُمان؟

اعتمد مجلس الوزراء البرنامج الوطني للذكاء الاصطناعي والتقنيات الرقمية المتقدمة في 19 سبتمبر 2024، ويغطي البرنامج الفترة 2024–2026.

ويتضمن البرنامج محوراً لحوكمة تطبيقات الذكاء الاصطناعي برؤية تتمحور حول الإنسان، مع التركيز على بناء الأطر التشريعية والتنظيمية اللازمة للاستخدام الآمن والأخلاقي للذكاء الاصطناعي، وحماية خصوصية البيانات، وتعزيز الثقة.

وفي 2025 أصدرت وزارة النقل والاتصالات وتقنية المعلومات السياسة العامة للاستخدام الآمن والأخلاقي لأنظمة الذكاء الاصطناعي بوصفها مرجعاً وطنياً لحوكمة الاستخدام والتطوير المسؤول لأنظمة AI.

وتتناول السياسة مبادئ مثل:

• الشفافية.
• العدالة.
• المساءلة.
• الشمول.
• الخصوصية.
• الإشراف البشري.

كما تتعامل مع الحوكمة عبر دورة الحياة، والمخاطر المرتبطة بالبيانات والتحيز والمخرجات، وتقييم الأداء والتوثيق والمتابعة.

هذه البيئة هي «جانب عُمان» في المقارنة.

ما الذي يقدمه NIST AI RMF؟

NIST AI RMF هو إطار لإدارة مخاطر الذكاء الاصطناعي طوره المعهد الوطني الأمريكي للمعايير والتقنية.

AI RMF 1.0 صدر في 2023، ويقسم Core إلى أربع وظائف رئيسية:

GOVERN — MAP — MEASURE — MANAGE

ويوضح NIST أن GOVERN وظيفة عابرة لبقية الوظائف، وأن إدارة المخاطر يجب أن تكون مستمرة وعبر دورة حياة نظام AI.

كما يؤكد NIST أن إجراءات الـCore ليست checklist ولا سلسلة خطوات إلزامية مرتبة.

ويقدم AI RMF Playbook إجراءات مقترحة لتحقيق مخرجات الـCore، لكنه مورد طوعي وليس قائمة إلزامية يجب تنفيذها بالكامل.

ملاحظة إصدار مهمة

اعتباراً من 9 سبتمبر 2026، يوضح NIST رسمياً أن AI RMF 1.0 قيد المراجعة.

كما يوضح أن Playbook سيُحدّث بعد مراجعة AI RMF.

لذلك فإن هذه الخريطة مبنية على AI RMF 1.0 والمواد الرسمية المتاحة في تاريخ المراجعة، ويجب إعادة فحصها عندما يصدر الإصدار المنقح.

لماذا المقارنة مفيدة للمؤسسات في عُمان؟

السياسة أو التنظيم يحدد التوقعات والمبادئ والالتزامات ذات الصلة.

لكن المؤسسة تحتاج بعد ذلك إلى تشغيلها.

مثلاً، إذا كان المطلوب هو المساءلة، تظهر أسئلة مثل:

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

NIST AI RMF يوفر لغة تنظيمية مفيدة لهذه الأسئلة.

[ممارسة تنفيذية] يمكن استخدام النموذج:

المتطلب العُماني → NIST Function → Control → Evidence → Owner → Review Trigger

بهذا يصبح الإطار الدولي وسيلة لتنظيم التنفيذ، لا بديلاً عن المصدر العُماني.

GOVERN: الحوكمة والمساءلة كأساس عابر

وظيفة GOVERN في NIST تهتم بالسياسات والعمليات والإجراءات والممارسات التي تمكّن المؤسسة من رسم المخاطر وقياسها وإدارتها بصورة فعالة.

ويضع NIST ضمن GOVERN فهماً وإدارة وتوثيق المتطلبات القانونية والتنظيمية ذات الصلة بالذكاء الاصطناعي.

هذا يجعل GOVERN أقرب نقطة بداية لعدد كبير من توقعات الحوكمة العُمانية.

Crosswalk تحليلي

هذه الخريطة [استنتاج تحليلي] وليست mapping رسمياً صادراً عن أي جهة عُمانية أو NIST.

MAP: فهم السياق قبل قياس الخطر

وظيفة MAP تركز على فهم السياق الذي يعمل فيه النظام والمخاطر المرتبطة بذلك السياق.

في حوكمة AI لا يمكن تقييم نظام بصورة صحيحة إذا لم نعرف:

• الغرض.
• المستخدمين.
• الأطراف المتأثرة.
• البيانات.
• البيئة التشغيلية.
• الموردين.
• الاعتماديات.
• نوع القرار أو المخرج.
• أثر الخطأ.

وهذا يتقاطع تحليلياً مع النهج العُماني الذي يركز على الاستخدام المسؤول، ومخاطر البيانات والمخرجات، والإشراف البشري.

[ممارسة تنفيذية] قبل اعتماد use case، يمكن بناء Context Record يتضمن:

Use Case → Purpose → Users → Affected Parties → Data → Model → Decision Role → Human Oversight → Dependencies → Applicable Requirements

هذه الوثيقة تساعد على منع تقييم النموذج بمعزل عن سياق استخدامه.

MEASURE: من المبادئ إلى الاختبار والأدلة

وظيفة MEASURE في NIST تتعامل مع اختيار طرق ومقاييس مناسبة لتقييم وتحليل وتتبع مخاطر AI.

ويشير NIST إلى أن خصائص AI تخلق أنماط فشل مختلفة عن البرمجيات التقليدية، بما في ذلك الاعتماد على بيانات التدريب وجودتها وتمثيلها.

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

[ممارسة تنفيذية] يمكن أن تشمل طبقة MEASURE:

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

المهم ألا تتحول «العدالة» أو «السلامة» إلى شعارات بلا طريقة تقييم.

MANAGE: ماذا نفعل بنتيجة التقييم؟

القياس وحده لا يدير الخطر.

وظيفة MANAGE تتعامل مع ترتيب المخاطر وتخصيص الموارد والتعامل معها ومراقبتها وتحسين الاستجابة بمرور الوقت.

وتشمل فلسفة NIST الاستجابة للأحداث والحوادث والتعافي منها والتواصل بشأنها، إضافة إلى التحسين المستمر.

في البيئة العُمانية يمكن أن تساعد هذه الوظيفة في تحويل نتائج التقييم إلى قرارات مثل:

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

[ممارسة تنفيذية] يجب أن ينتهي كل risk finding إلى Owner وقرار وتاريخ مراجعة، لا أن يبقى بنداً في تقرير.

أين نضع الإشراف البشري؟

الإشراف البشري مثال جيد على سبب عدم بناء crosswalk واحد-إلى-واحد.

يمكن ربطه بـ:

GOVERN لأن المؤسسة تحتاج إلى مسؤوليات وصلاحيات واضحة.

MAP لأنها تحتاج إلى تحديد أين يقع الإنسان في سير القرار ومن يتأثر.

MEASURE لأنها قد تحتاج إلى اختبار ما إذا كان التدخل البشري يعمل فعلاً.

MANAGE لأن الإنسان قد يوقف النظام أو يتجاوز المخرج أو يتعامل مع حالة عالية المخاطر.

لذلك:

Human Oversight ≠ NIST Function واحدة

بل هو control theme يمتد عبر دورة إدارة المخاطر.

أين نضع الشفافية والتوثيق؟

الشفافية في السياسة العُمانية لا تعني بالضرورة نشر كل التفاصيل التقنية للجميع.

وفي NIST، التوثيق يدعم إدارة المخاطر والشفافية والمساءلة عبر الوظائف.

[ممارسة تنفيذية] يمكن تقسيم التوثيق إلى:

• توثيق الغرض والسياق.
• توثيق البيانات.
• توثيق النموذج والإصدار.
• توثيق الاختبارات.
• توثيق القيود.
• توثيق القرار والمسؤولية.
• توثيق الحوادث والتغييرات.
• توثيق نتائج المراجعة.

ثم يحدد مستوى الإفصاح حسب الجمهور والمتطلب والسياق.

أين نضع الخصوصية وحوكمة البيانات؟

الخصوصية ليست «اختباراً» فقط.

تبدأ في GOVERN بفهم المتطلبات والسياسات والمسؤوليات.

ثم MAP لفهم أنواع البيانات ومصادرها والغرض والأطراف.

ثم MEASURE لتقييم مخاطر الخصوصية وجودة البيانات وممارسات المعالجة حيث يلزم.

ثم MANAGE لمعالجة المخاطر وتغيير التصميم أو الوصول أو المورد أو الاحتفاظ.

وفي عُمان يجب ربط ذلك أيضاً بقانون حماية البيانات الشخصية ولائحته التنفيذية عند انطباقهما.

NIST هنا لا يحل محل القانون.

أين نضع تقييم الأداء؟

السياسة العُمانية تتعامل مع متابعة أداء أنظمة AI ضمن الحوكمة التشغيلية.

NIST MEASURE هو الموضع الطبيعي تحليلياً لاختيار المقاييس وتنفيذ التقييم والتتبع.

لكن النتائج تنتقل إلى MANAGE عندما يجب اتخاذ إجراء.

[ممارسة تنفيذية] النموذج:

Metric → Threshold → Result → Risk Interpretation → Owner → Action → Evidence

يمنع وجود dashboard أداء لا يؤدي إلى قرار عند تجاوز الحدود.

من Risk Register إلى AI Risk Profile

قد تمتلك المؤسسة سجلاً عاماً للمخاطر، لكن AI RMF يسمح بالتفكير في المخاطر وفق سياق النظام.

[ممارسة تنفيذية] يمكن بناء AI Risk Profile يوضح:

• المخاطر الرئيسية.
• الأطراف المتأثرة.
• الضوابط الحالية.
• نتائج القياس.
• الخطر المتبقي.
• الأولويات.
• إجراءات المعالجة.
• المالك.
• حالة التنفيذ.

هذا لا يعني أن «AI RMF Profile» مطلب عُماني.

هو وسيلة طوعية لتنظيم صورة المخاطر بصورة قابلة للإدارة.

ربط دورة حياة AI بوظائف NIST

وظائف NIST ليست مراحل waterfall.

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

مثلاً:

هذا الجدول [ممارسة تنفيذية] وليس نموذجاً رسمياً من NIST أو عُمان.

كيف نتعامل مع الذكاء الاصطناعي التوليدي؟

أنظمة GenAI تضيف مخاطر مثل المخرجات غير الدقيقة أو غير الملائمة، وتسرب المعلومات، وسوء الاستخدام، والاعتماد على مزود خارجي.

NIST أصدر في 2024 ملفاً خاصاً بمخاطر الذكاء الاصطناعي التوليدي مرتبطاً بـAI RMF.

وفي عُمان تنطبق السياسة العامة للاستخدام الآمن والأخلاقي على أنظمة AI بما فيها الاستخدامات التوليدية وفق نطاقها.

[ممارسة تنفيذية] يمكن استخدام نفس GOVERN/MAP/MEASURE/MANAGE مع سيناريوهات قياس وإدارة مصممة لمخاطر GenAI بدلاً من إنشاء نظام حوكمة منفصل بالكامل.

الأدلة: النقطة التي تجعل الـcrosswalk قابلاً للتدقيق

أفضل crosswalk ليس جدولاً جميلاً؛ بل خريطة تقود إلى دليل.

مثال:

متطلب/توقع: الإشراف البشري → NIST: GOVERN + MAP + MANAGE → Control: صلاحية إيقاف/تجاوز → Evidence: إجراء + سجل اختبار + سجل تدخل → Owner: مالك الخدمة → Trigger: تغير الاستخدام أو حادث أو فشل

ومثال آخر:

متطلب/توقع: تقييم الأداء → NIST: MEASURE + MANAGE → Control: performance monitoring → Evidence: نتائج القياس + thresholds + actions → Owner: Model/System Owner → Trigger: drift أو تحديث نموذج

هنا يصبح crosswalk أداة تشغيل ومراجعة.

نموذج سيادة AI المقترح

[ممارسة تنفيذية] للمؤسسات التي تريد استخدام NIST مع متطلبات عُمان، نقترح ست طبقات:

1. Requirement

النص أو التوقع العُماني الفعلي ومصدره.

2. NIST Function

الوظيفة أو الوظائف التي تساعد على تشغيل الموضوع.

3. Control

الإجراء أو الضابط المؤسسي.

4. Evidence

ما يثبت أن الضابط موجود ويعمل.

5. Owner

من يملك القرار والتنفيذ.

6. Review Trigger

ما الذي يجبر المؤسسة على إعادة النظر.

الصيغة:

Requirement → NIST Function → Control → Evidence → Owner → Review Trigger

ما الذي لا يجب فعله؟

أولاً، كتابة «عُمان متوافقة مع NIST AI RMF» دون مصدر رسمي يثبت ذلك.

ثانياً، تحويل وظائف NIST إلى متطلبات قانونية عُمانية.

ثالثاً، استخدام NIST بدلاً من قراءة السياسة أو القانون المحلي.

رابعاً، التعامل مع AI RMF كـchecklist إلزامية، بينما NIST نفسه يوضح أن إجراءات Core ليست checklist وأن Playbook طوعي.

خامساً، افتراض أن GOVERN ثم MAP ثم MEASURE ثم MANAGE سلسلة زمنية جامدة.

سادساً، بناء crosswalk على AI RMF 1.0 ثم تجاهل أن NIST يراجعه حالياً.

سابعاً، إنشاء control بلا دليل أو owner.

ثامناً، ربط كل مبدأ بوظيفة واحدة فقط حتى عندما يكون عابراً لعدة وظائف.

درجات القوة في هذه الخريطة

للحفاظ على الفصل بين التنظيم والتحليل:

E1 — مصدر عُماني صريح: المبدأ أو التوقع وارد في سياسة أو برنامج أو تنظيم عُماني رسمي.

E2 — علاقة تحليلية قوية: توجد علاقة واضحة بين التوقع ووظيفة NIST، لكنها ليست mapping رسمياً.

E3 — ممارسة تنفيذية: control أو evidence أو owner أو trigger تقترحه سيادة AI لتشغيل المتطلب.

E4 — تعزيز عبر إطار طوعي: استخدام NIST أو Playbook لتطوير النضج بما يتجاوز الحد الأدنى المحلي.

معظم روابط «عُمان → NIST Function» في هذا المقال هي E2، وليست E1.

ماذا عن ISO/IEC 42001؟

لدى سيادة AI مقال منفصل يقارن السياسة العُمانية بـISO/IEC 42001.

الفرق العملي في الاستخدام:

• ISO/IEC 42001 يركز على نظام إدارة للذكاء الاصطناعي AIMS.
• NIST AI RMF يركز على إطار لإدارة مخاطر AI عبر GOVERN/MAP/MEASURE/MANAGE.

يمكن للمؤسسة استخدام الاثنين بصورة تكاملية، لكن لا ينبغي اعتبارهما متطابقين أو بديلين تلقائياً لبعضهما.

وهذه أيضاً قراءة تحليلية وليست تبنياً عُمانياً لأي منهما.

متى يجب تحديث هذا المقال؟

هناك ثلاثة محفزات رئيسية:

1. صدور نسخة منقحة من NIST AI RMF.
2. تعديل جوهري في السياسة أو البيئة التنظيمية العُمانية للذكاء الاصطناعي.
3. صدور متطلبات قطاعية عُمانية جديدة تغير طريقة إدارة مخاطر AI.

وبسبب أن NIST يعلن حالياً أن AI RMF 1.0 قيد المراجعة، فإن trigger الأول مهم بصورة خاصة.

الخلاصة

عُمان توفر الاتجاه والمتطلبات المحلية للاستخدام الآمن والأخلاقي والمسؤول للذكاء الاصطناعي.

NIST AI RMF يوفر لغة طوعية ومنهجاً عملياً لتنظيم مخاطر AI عبر:

GOVERN → MAP → MEASURE → MANAGE

القيمة لا تأتي من إعلان «التوافق»، بل من بناء traceability:

المصدر العُماني → موضوع الحوكمة → وظيفة NIST → الضابط → الدليل → المالك → محفز المراجعة

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

آخر مراجعة تنظيمية وإطارية للمحتوى: 9 سبتمبر 2026.