ضمان وتقييم أنظمة الذكاء الاصطناعي في مصر: اختبار المخاطر والأثر وTEVV قبل النشر وبعده

ما معنى AI Assurance؟

AI Assurance هي مجموعة الأنشطة التي تمنح المؤسسة مستوى معقولاً من الثقة بأن نظام الذكاء الاصطناعي:

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

Assurance لا تعني أن النظام خالٍ من المخاطر.

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

لماذا أصبحت Assurance جزءاً من المشهد المصري؟

الاستراتيجية الوطنية للذكاء الاصطناعي والإطار الوطني والإرشادات الوطنية الموثوقة والمسؤولة تضع الحوكمة والتقييم والاختبار والمراقبة ضمن دورة حياة AI.

والأهم أن إرشادات 2026 تحدد مرحلة صريحة للتقييم قبل النشر باستخدام:

Testing, Evaluation, Verification and Validation — TEVV

وهذا ينقل Assurance من مفهوم اختياري إلى عنصر تشغيلي واضح داخل الحوكمة.

Pre-Deployment Assessment

قبل إطلاق النظام في بيئة التشغيل، يجب إجراء تقييم شامل يتناسب مع المخاطر.

السؤال ليس:

“هل النموذج يعمل؟”

بل:

• هل يعمل في الحالات العادية؟
• ماذا يحدث عند edge cases؟
• كيف يتصرف تحت الضغط؟
• هل توجد نتائج غير عادلة؟
• هل الضوابط تعمل؟
• هل النظام آمن؟
• هل البيانات مناسبة؟
• هل human oversight يعمل فعلياً؟

TEVV

TEVV يتكون من:

Testing اختبار السلوك والأداء.

Evaluation تقييم النتائج مقابل معايير محددة.

Verification التحقق من أن النظام يطابق المتطلبات والتصميم.

Validation التحقق من أن النظام مناسب للاستخدام المقصود في الواقع.

الخلط بين هذه المكونات يجعل التقييم أضعف.

Testing

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

ماذا يحدث إذا أدخلنا حالات مختلفة للنظام؟

يشمل ذلك:

• normal cases.
• boundary cases.
• edge cases.
• stress cases.
• adversarial cases.
• malformed inputs.

Evaluation

Evaluation لا يبحث فقط عن bugs.

بل يقيس النظام مقابل معايير.

مثلاً:

• accuracy.
• false-positive rate.
• robustness.
• fairness.
• latency.
• explainability.
• privacy.
• security.

Verification

Verification يسأل:

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

مثلاً إذا كان requirement يقول:

“لا يجوز للAgent تنفيذ transaction فوق حد معين دون موافقة بشرية”

فيجب التحقق تقنياً من وجود هذا control.

Validation

Validation يسأل:

هل هذا النظام مناسب فعلاً للسياق الذي سنستخدمه فيه؟

Model قد يكون ممتازاً في المختبر لكنه غير مناسب لـ:

• population مختلفة.
• language مختلفة.
• risk context مختلف.
• operational environment مختلف.

Intended Use

كل Assurance يبدأ بتحديد Intended Use.

إذا كان use case غامضاً، فلا يمكن تقييم النظام بدقة.

حدد:

• ماذا يفعل؟
• لمن؟
• في أي سياق؟
• ما القرار؟
• ما حدود دوره؟
• ما الذي لا يسمح له بفعله؟

Foreseeable Misuse

لا يكفي توثيق الاستخدام المقصود.

يجب التفكير في misuse المتوقع.

مثال:

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

هذا misuse متوقع ويجب تصميم controls له.

Impact Assessment

تقييم الأثر يسأل:

إذا أخطأ النظام، من سيتضرر وكيف؟

يمكن أن يشمل:

• أفراد.
• عملاء.
• موظفين.
• مؤسسة.
• سوق.
• مجتمع.
• حقوق.
• أمن.
• خصوصية.
• سمعة.

Impact ليست Probability

قد يكون الحدث نادرًا لكن أثره كارثيًا.

لذلك تقييم المخاطر يجب أن يفرق بين:

• likelihood.
• severity.
• detectability.
• reversibility.
• scale.

Risk Scoring

Risk Score يجب أن يساعد القرار وليس أن يصنع دقة زائفة.

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

يمكن استخدام dimensions مثل:

• Impact Severity.
• Likelihood.
• Autonomy.
• Data Sensitivity.
• Scale.
• Reversibility.
• Human Oversight.
• External Dependency.

High-Risk AI

لا ينبغي اعتبار “high risk” مجرد label.

يجب أن ينتج عنه controls إضافية، مثل:

• stronger validation.
• independent review.
• human oversight.
• monitoring.
• documentation.
• approval gates.
• incident planning.

Data Quality

النموذج لا يمكن أن يكون أكثر موثوقية من البيانات التي يعتمد عليها.

يجب اختبار:

• completeness.
• accuracy.
• relevance.
• representativeness.
• freshness.
• labeling quality.
• provenance.

Data Provenance

يجب أن نعرف:

• من أين جاءت البيانات؟
• متى؟
• بأي ترخيص؟
• من عدلها؟
• أي version استخدم؟
• ما transformations؟

بدون provenance يصعب إعادة إنتاج التقييم.

Bias Testing

اختبار العدالة لا يعني فقط البحث عن متغير حساس مباشر.

قد توجد proxies.

مثلاً:

• location.
• income patterns.
• device.
• language.
• education.

قد ينتج عنها أثر غير متوازن.

Fairness Context

لا يوجد fairness metric واحد صحيح لكل الحالات.

المقياس يعتمد على:

• use case.
• population.
• harm model.
• legal context.

لذلك لا تستخدم metric محفوظة دون تفسير.

Robustness

Robustness تختبر استقرار النظام أمام:

• تغيرات صغيرة.
• بيانات غير مثالية.
• edge cases.
• noise.
• unexpected sequences.
• distribution shift.

Stress Testing

النظام قد يعمل جيداً في الظروف الطبيعية لكنه يفشل عند:

• high volume.
• latency.
• API failure.
• partial data.
• upstream outage.
• conflicting inputs.

Security Testing

AI security يجب أن تشمل:

• prompt injection.
• data leakage.
• malicious files.
• model endpoint abuse.
• tool misuse.
• privilege escalation.
• insecure plugins.
• poisoned retrieval.

Adversarial Testing

الهدف هو مهاجمة assumptions النظام قبل أن يفعل ذلك طرف خارجي.

قد يشمل:

• jailbreak attempts.
• evasion.
• manipulation.
• injection.
• unauthorized action sequences.

Privacy Testing

اسأل:

• هل يعرض النظام بيانات شخص آخر؟
• هل يمكن استخراج training data؟
• هل prompts تظهر في logs؟
• هل RAG يعزل المستخدمين؟
• هل retention فعلي؟

Explainability Testing

لا يكفي وجود تفسير.

يجب اختبار هل التفسير:

• صحيح.
• مستقر.
• مفيد.
• مناسب للمستخدم.

Human Oversight Testing

اختبر human oversight كـcontrol.

مثلاً:

• هل الموظف يرى المعلومات المطلوبة؟
• هل يستطيع الرفض؟
• هل يفهم recommendation؟
• هل يوجد وقت للمراجعة؟
• هل يتم تسجيل override؟

Override Testing

يجب اختبار override عملياً، لا توثيقه فقط.

الأسئلة:

• هل يعمل؟
• من يملكه؟
• هل يسجل؟
• هل يمكن إيقاف النظام؟
• هل هناك fallback؟

Kill Switch

بعض الأنظمة عالية الاستقلالية تحتاج وسيلة توقف واضحة.

Kill Switch يجب أن يكون:

• معروفاً.
• مجرباً.
• مصرحاً به.
• قابلاً للتدقيق.

Acceptance Criteria

قبل الاختبار يجب تحديد ما معنى النجاح.

مثلاً:

• minimum accuracy.
• maximum false-positive rate.
• fairness threshold.
• maximum latency.
• security findings threshold.

إذا حددنا criteria بعد الاختبار، يمكن تعديلها لتناسب النتيجة.

Risk Tolerance

ليست كل المخاطر بحاجة إلى صفر.

المؤسسة تحتاج إلى تحديد:

• ما المقبول؟
• ما يحتاج mitigation؟
• ما يمنع deployment؟

Residual Risk

بعد controls يبقى Residual Risk.

يجب تسجيل:

• ماهيته.
• لماذا قُبل.
• من قبله.
• متى يعاد تقييمه.

Independent Review

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

السبب:

Developer bias قد يجعل الفريق أقل قدرة على رؤية ضعف النظام الذي بناه.

Supplier TEVV

عندما يكون model من مورد خارجي، لا يجوز الاكتفاء بعبارة:

“Vendor tested it.”

اطلب evidence مناسباً.

Vendor Evidence

قد يشمل:

• testing reports.
• model card.
• security assessment.
• incident history.
• performance metrics.
• limitations.
• change notices.

Model Card

Model Card يجب أن تساعد على فهم:

• purpose.
• limitations.
• training context.
• performance.
• risks.
• intended users.

وليست مجرد وثيقة تسويق.

System Card

النظام الكامل أهم من model وحده.

System Card قد تشمل:

• architecture.
• model.
• data.
• integrations.
• controls.
• human oversight.
• monitoring.
• dependencies.

Versioning

يجب ربط كل Assurance بنتيجة محددة لـ:

• model version.
• dataset version.
• prompt version.
• policy version.
• configuration version.

Reproducibility

إذا لم تستطع إعادة إنتاج الاختبار، فإن evidence ضعيف.

سجل:

• environment.
• parameters.
• datasets.
• code.
• version.
• time.

Approval Decision

بعد الاختبار، القرار لا يجب أن يكون آلياً بالضرورة.

النتائج يجب أن تصل إلى accountable owner.

القرار يمكن أن يكون:

• Approved.
• Approved with Conditions.
• Rework Required.
• Rejected.

Approval Conditions

مثال:

“يسمح بالنشر بشرط بقاء human review إلزامياً.”

إذا تغير الشرط لاحقاً، يجب إعادة التقييم.

Evidence Pack

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

AI Assurance Evidence Pack قد يتضمن:

1. System description.
2. Intended use.
3. Misuse scenarios.
4. Impact assessment.
5. Risk assessment.
6. Data assessment.
7. TEVV plan.
8. Test results.
9. Bias testing.
10. Robustness testing.
11. Security testing.
12. Privacy testing.
13. Human oversight testing.
14. Residual risk.
15. Approval.
16. Versions.
17. Monitoring plan.

Go-Live Gate

لا يتم Go-Live فقط لأن engineering انتهى.

Gate يجب أن يثبت:

• tests passed.
• critical risks mitigated.
• owners assigned.
• monitoring ready.
• incident process ready.
• rollback ready.

Post-Deployment Monitoring

Assurance لا تنتهي بعد النشر.

راقب:

• performance.
• drift.
• anomalies.
• overrides.
• complaints.
• incidents.
• fairness.
• vendor changes.

Drift

Drift قد يكون:

• data drift.
• concept drift.
• behavior drift.
• operational drift.

كل نوع يحتاج مؤشرات مختلفة.

Event-Triggered Review

لا تنتظر المراجعة السنوية فقط.

أعد التقييم عند:

• model change.
• dataset change.
• new population.
• new integration.
• increased autonomy.
• security incident.
• serious complaint.
• material performance drop.

Suspension

الحوكمة الجيدة يجب أن تسمح بتعليق النظام.

أسباب محتملة:

• severe incident.
• failed control.
• unexpected harm.
• critical drift.
• security compromise.

Deactivation

بعض الأنظمة يجب إيقافها نهائياً إذا لم تعد المخاطر قابلة للإدارة.

وجود Deactivation Path جزء من lifecycle governance.

ISO/IEC 42005

ISO/IEC 42005 يقدم إطاراً متخصصاً لتقييم أثر أنظمة الذكاء الاصطناعي.

قيمته هنا أنه يساعد على تنظيم impact assessment بصورة منهجية.

لكنه ليس قانوناً مصرياً.

ISO/IEC 23894

ISO/IEC 23894 يركز على إدارة مخاطر الذكاء الاصطناعي.

يمكن استخدامه كمرجع تكميلي لتطوير risk methodology.

لكنه ليس بديلاً عن المتطلبات المصرية.

العلاقة مع الإرشادات المصرية

الإرشادات المصرية توفر context وexpectations وطنية.

المعايير الدولية توفر أدوات ومنهجيات إضافية.

المنهج الصحيح ليس استبدال أحدهما بالآخر.

Auditability

النظام الذي لا يترك evidence يصعب تدقيقه.

يجب تسجيل:

• inputs ذات الصلة.
• outputs.
• decisions.
• actions.
• overrides.
• versions.
• incidents.

مع مراعاة الخصوصية والاحتفاظ.

Assurance vs Certification

AI Assurance لا تساوي Certification.

قد تنفذ المؤسسة assurance داخلياً بدون شهادة خارجية.

وقد توجد certification لكنها لا تغطي كامل use case.

Assurance vs Audit

Audit يقيم evidence وضوابط وفق نطاق معين.

Assurance أوسع ويمكن أن يشمل:

• testing.
• validation.
• monitoring.
• governance.
• audit.

Minimum Viable Assurance

للأنظمة منخفضة المخاطر لا تحتاج نفس مستوى الاختبار لنظام حرج.

لكن يجب على الأقل وجود:

• owner.
• use case.
• basic risk assessment.
• test.
• data check.
• monitoring proportionate to risk.

Proportionality

المبدأ الصحيح:

Assurance effort should scale with risk.

ليس كل chatbot يحتاج adversarial lab كامل.

لكن النظام الذي ينفذ قرارات عالية الأثر يحتاج مستوى أعلى بكثير.

Assurance Operating Model

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

يمكن تصميم workflow:

Use Case → Risk Classification → Impact Assessment → TEVV Plan → Testing → Findings → Mitigation → Retest → Approval → Deployment → Monitoring → Triggered Review

فصل المطور عن المعتمد

لا تجعل الشخص نفسه:

• يبني النظام.
• يختبره.
• يقرر المخاطر.
• يوافق على النشر.

في الأنظمة العالية يجب وجود separation of duties مناسب.

ما الذي يجب أن تسأل عنه الإدارة؟

الإدارة لا تحتاج 300 test result.

تحتاج إجابات:

• ما أكبر خطر؟
• ما الذي فشل؟
• ما residual risk؟
• من قبله؟
• هل هناك شرط للنشر؟
• هل يمكن إيقاف النظام؟
• ما trigger لإعادة التقييم؟

الخلاصة

إطار الحوكمة المصري في 2026 انتقل بحوكمة AI من مستوى المبادئ فقط إلى مستوى lifecycle controls أكثر وضوحاً.

TEVV قبل النشر، Impact Assessment، Risk Assessment، testing، human oversight، monitoring، evidence، وإعادة التقييم تشكل معاً أساساً عملياً لـAI Assurance.

المؤسسة الناضجة لا تسأل:

“هل اختبرنا النموذج؟”

بل:

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