الإرشادات الوطنية المصرية للذكاء الاصطناعي الموثوق والمسؤول 2026: من المبادئ إلى التشغيل والتقييم

ما هي الإرشادات الوطنية للذكاء الاصطناعي الموثوق والمسؤول؟

صدرت النسخة النهائية 2.0 في مارس 2026 بعد دورة تطوير تضمنت إعداد المسودات والمراجعات والتشاور العام ودمج تعليقات جهات حكومية وخاصة ودولية.

الوثيقة مصممة لتكون Operational Manual ضمن منظومة الحوكمة الوطنية.

الفرق بين Framework وGuidelines

هذه من أهم النقاط.

الـGovernance Framework يحدد:

WHAT should be governed

بينما الإرشادات تحدد:

HOW to comply

هذا الفرق يمنع خطأ شائعاً: وجود سياسة أو Framework بدون أدوات تنفيذ.

من تشمل الإرشادات؟

الإرشادات ليست موجهة للحكومة فقط.

تشمل أدواراً مثل:

• Provider.
• Developer.
• Beneficiary.
• User.
• Government Entity.
• Enterprise.
• Research Institution.
• Individual.

وقد يكون الطرف نفسه في أكثر من دور.

شركة تشتري نموذجاً وتدمجه في منتجها قد تكون:

• user بالنسبة للمورد.
• deployer بالنسبة لعملائها.
• controller بالنسبة لبعض البيانات.

ما أنواع الأنظمة التي تغطيها؟

تشمل:

• standalone AI.
• AI components.
• GPAI.
• Generative AI.
• embedded AI.
• systems integrated into larger operational environments.

وهذا مهم لأن AI قد يكون داخل جهاز أو منصة أو خدمة ولا يظهر للمستخدم كنظام مستقل.

Institutional Governance

قبل تقييم النموذج يجب أن تكون المؤسسة نفسها جاهزة.

تشمل الجاهزية عناصر مثل:

• policy.
• ownership.
• accountability.
• roles.
• training.
• risk management.
• documentation.
• escalation.
• internal assurance.

المؤسسة التي لا تعرف من يملك القرار لا تستطيع إدارة AI بصورة مسؤولة مهما كان النموذج جيداً.

سياسة AI المؤسسية

[ممارسة تنفيذية]

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

• ما الأدوات المسموحة.
• ما الأدوات الممنوعة.
• ما البيانات التي لا يجوز إدخالها.
• متى يحتاج الاستخدام موافقة.
• من يملك النظام.
• كيف يتم تسجيل الحالات.
• متى يتم التقييم.
• كيف تدار الحوادث.

AI Lifecycle Governance

الحوكمة تغطي دورة الحياة كاملة.

التخطيط

تحديد الغرض والأثر والمستفيدين.

التصميم والتطوير

اختيار البيانات والنموذج والضوابط.

التقييم قبل النشر

اختبار الأداء والمخاطر.

النشر

اعتماد النظام وتحديد حدود التشغيل.

المراقبة

متابعة الأداء والسلوك.

التغيير

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

الإيقاف

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

البيانات

الحوكمة الجيدة للبيانات تشمل:

• provenance.
• quality.
• relevance.
• representativeness.
• bias.
• access.
• security.
• privacy.
• retention.

البيانات الرديئة قد تنتج نظاماً عالي الأداء ظاهرياً لكنه غير موثوق في بيئة التشغيل.

Pre-Deployment Assessment

قبل إطلاق النظام يجب أن يكون هناك تقييم يتناسب مع المخاطر.

قد يشمل:

• intended use.
• misuse.
• affected users.
• failure modes.
• safety.
• privacy.
• bias.
• security.
• human oversight.
• vendor dependencies.

TEVV

Testing, Evaluation, Verification and Validation ليست اختباراً واحداً.

Testing

كيف يتصرف النظام تحت سيناريوهات محددة؟

Evaluation

هل النتائج تحقق الأهداف والمعايير؟

Verification

هل بُني النظام كما هو محدد؟

Validation

هل النظام مناسب فعلياً للغرض والسياق؟

الاختبار العدائي

[ممارسة تنفيذية]

الأنظمة الحساسة قد تحتاج إلى:

• adversarial testing.
• red teaming.
• misuse scenarios.
• prompt injection testing.
• data leakage testing.
• access-control testing.

الغرض ليس إثبات أن النظام “غير قابل للاختراق”، بل فهم حدود مقاومته.

Human Oversight

الإشراف يجب تصميمه.

أسئلة الحوكمة تشمل:

• متى يتدخل الإنسان؟
• ماذا يرى؟
• هل يفهم حدود النظام؟
• هل يمكنه إلغاء القرار؟
• متى يصعّد الحالة؟
• هل يتم تسجيل التدخل؟

Monitoring بعد النشر

الإطلاق ليس نهاية عملية التقييم.

يجب مراقبة:

• accuracy.
• drift.
• incidents.
• anomalies.
• complaints.
• bias.
• security events.
• user behavior.
• changes in operating context.

AI System Audit

التدقيق يبحث في:

• design.
• data.
• controls.
• logs.
• approvals.
• incidents.
• testing.
• monitoring.
• responsibilities.

والتدقيق يختلف عن مجرد technical penetration test.

Stakeholder Engagement

بعض الأنظمة تؤثر في أشخاص لا يشاركون في تصميمها.

لذلك قد يلزم فهم:

• affected groups.
• users.
• domain experts.
• regulators.
• employees.
• vulnerable communities.

Society & Sustainability

تتوسع الإرشادات خارج الأداء التقني لتشمل:

• societal impact.
• environmental impact.
• responsible resource use.
• inclusion.
• long-term sustainability.

Enterprise Readiness Assessment

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

السؤال ليس:

“هل لدينا AI؟”

بل:

“هل لدينا القدرة المؤسسية على إدارة AI؟”

تقييم الجاهزية يساعد في كشف فجوات مثل:

• governance.
• roles.
• policies.
• skills.
• data.
• controls.
• monitoring.

AI System Readiness Assessment

هناك أيضاً تقييم على مستوى النظام نفسه.

النظام قد يكون تقنياً جاهزاً لكنه غير جاهز من زاوية:

• governance.
• documentation.
• safety.
• privacy.
• explainability.
• monitoring.

الاستعداد للتنظيم المستقبلي

من النقاط المهمة أن الإرشادات تساعد المؤسسات على الاستعداد للامتثال في حال إصدار قانون أو مرسوم AI مستقبلاً.

🔴 FUTURE AI LAW READINESS ≠ CURRENT AI LAW وجود هذه الاستعدادات لا يعني أن قانوناً شاملاً أصبح نافذاً.

Evidence-Based Governance

[ممارسة تنفيذية]

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

لا تقل فقط إنك تطبق الحوكمة.

احتفظ بالأدلة.

مثل:

• inventory.
• risk assessment.
• test reports.
• approvals.
• model documentation.
• vendor review.
• human oversight procedures.
• incident records.
• monitoring reports.

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

الإرشادات تربط البيئة الوطنية بممارسات ومعايير دولية عديدة.

هذا يسمح للمؤسسات التي تستخدم ISO/IEC 42001 أو NIST AI RMF أو معايير تقنية أخرى ببناء Mapping بين نظامها الداخلي والمتطلبات الوطنية.

لكن:

international standard ≠ Egyptian law

هو أداة دعم وتوافق ما لم ينص التنظيم على غير ذلك.

الخلاصة

القيمة الحقيقية للإرشادات أنها تنقل Responsible AI من المبادئ إلى التشغيل.

وهي لذلك من أهم الأدوات التي تحتاجها أي مؤسسة تريد بناء AI Governance Program قابل للتقييم والمراجعة في مصر.

إدارة الأطراف الثالثة وسلسلة توريد الذكاء الاصطناعي

أحد أكثر أجزاء الحوكمة المؤسسية أهمية هو إدراك أن المؤسسة قد تكون مسؤولة عن نظام لا تملك النموذج الأساسي الذي يعمل داخله.

قد تعتمد المنظومة على:

• نموذج أساسي من مزود خارجي.
• خدمة SaaS.
• API تجارية.
• منصة سحابية.
• مكتبات مفتوحة المصدر.
• بيانات من طرف ثالث.
• مزود يقوم بالـfine-tuning.
• شركة أخرى تنفذ المراقبة أو الاختبار.

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

[ممارسة تنفيذية]

يجب أن يتضمن Vendor AI Due Diligence أسئلة مثل:

• من طور النموذج؟
• أين تتم المعالجة؟
• هل يحتفظ المزود بالمدخلات؟
• هل يستخدمها للتدريب؟
• ما آلية الإبلاغ عن الحوادث؟
• كيف يتعامل المزود مع تحديث النموذج؟
• هل يمكن للمؤسسة معرفة model version؟
• ما مستوى الدعم عند ظهور خلل؟
• هل يوجد sub-processors؟
• كيف يتم حذف البيانات عند انتهاء التعاقد؟
• ما خطة الخروج من المورد؟

كلما كان النظام أعلى خطورة، أصبح الاعتماد على تصريح تسويقي من المورد أقل قبولاً.

المشتريات ليست عملية تجارية فقط

AI Procurement جزء من الحوكمة.

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

[ممارسة تنفيذية]

من البنود التي قد تحتاج المؤسسة إلى تضمينها حسب المخاطر:

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

المؤسسة لا تنقل مسؤوليتها تلقائياً إلى المورد بمجرد شراء الخدمة.

إدارة التغيير في أنظمة AI

نظام AI ليس منتجاً ثابتاً.

قد يتغير بسبب:

• إعادة التدريب.
• fine-tuning.
• تبديل النموذج.
• تحديث المورد.
• تغيير مصدر البيانات.
• إضافة أداة.
• تغيير prompt أو system instruction.
• تغيير المستخدمين.
• نقل النظام إلى سياق جديد.

بعض هذه التغييرات قد يكون مادياً بما يكفي لإعادة التقييم.

[ممارسة تنفيذية]

يمكن للمؤسسة تحديد Material Change Triggers مثل:

• تغيير model family.
• توسيع صلاحيات النظام.
• إدخال بيانات حساسة جديدة.
• استخدام النظام لاتخاذ قرار أكثر تأثيراً.
• إضافة مجموعة مستخدمين جديدة.
• تغير كبير في مؤشرات الأداء.
• حدوث incident جوهري.

عند تحقق Trigger يجب ألا يُعامل النظام وكأنه هو نفسه الذي سبق اعتماده.

التوثيق كجزء من الحوكمة

الوثائق ليست عبئاً إدارياً منفصلاً عن AI governance.

في الأنظمة ذات المخاطر الأعلى، التوثيق هو ما يسمح لاحقاً بالإجابة عن:

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

الحد الأدنى المفيد من الأدلة قد يشمل:

• Use Case Record.
• Risk Classification.
• Impact Assessment.
• Data Documentation.
• Model/System Documentation.
• Test Evidence.
• Approval Record.
• Vendor Assessment.
• Monitoring Record.
• Incident Record.
• Change Log.

مؤشرات الأداء مقابل مؤشرات المخاطر

من الأخطاء الشائعة مراقبة Accuracy أو latency فقط.

النظام قد يحقق أداءً جيداً تجارياً بينما ترتفع مخاطر أخرى.

[ممارسة تنفيذية]

يمكن الفصل بين:

Performance Indicators

مثل:

• accuracy.
• precision.
• recall.
• response time.
• availability.

و:

Risk Indicators

مثل:

• harmful output rate.
• override rate.
• complaint volume.
• bias indicators.
• privacy incidents.
• security events.
• abnormal model behavior.
• human escalation frequency.

الهدف هو عدم اختزال نجاح النظام في KPI تجاري واحد.

متى يجب إيقاف النظام؟

الحوكمة الناضجة لا تفترض أن كل مشكلة تعالج بتحديث بسيط.

يجب وجود Exit Criteria أو Suspension Criteria.

قد تشمل:

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

[ممارسة تنفيذية]

وجود آلية Decommissioning أو Suspension ليس دليلاً على فشل برنامج AI؛ بل على نضجه.

دور الإدارة العليا ومجلس الإدارة

كلما توسع استخدام AI، يصبح ترك الحوكمة بالكامل داخل فريق البيانات أو تقنية المعلومات خطأً هيكلياً.

الإدارة العليا تحتاج إلى رؤية مجمعة حول:

• عدد الأنظمة.
• توزيع المخاطر.
• الحوادث.
• الأنظمة عالية المخاطر.
• الموردين الرئيسيين.
• الفجوات.
• خطط المعالجة.
• الاستثناءات.
• الأنظمة التي تم إيقافها.

[ممارسة تنفيذية]

يمكن أن يصبح AI Governance Reporting جزءاً من Enterprise Risk Reporting بدلاً من إنشاء قناة معزولة لا تصل لصناع القرار.

العلاقة بين الجاهزية والنضج

الجاهزية لا تعني أن المؤسسة وصلت إلى مستوى ناضج نهائي.

قد تكون المؤسسة جاهزة لبدء استخدام AI، لكنها ما تزال تحتاج إلى تحسين:

• جودة البيانات.
• قدرات الاختبار.
• التدقيق.
• مهارات المخاطر.
• إدارة الموردين.
• مراقبة النماذج.
• إدارة الحوادث.

لذلك الأفضل التعامل مع Responsible AI باعتباره Capability مستمرة التطور وليس مشروع امتثال لمرة واحدة.