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

لماذا تحتاج قطر إلى AI Assurance كطبقة مستقلة؟

الإرشادات القطرية للتطوير والنشر الأخلاقي توفر مبادئ واضحة.

لكن المؤسسة تحتاج آلية تثبت أن هذه المبادئ تم تطبيقها فعليًا.

هنا يأتي دور AI Assurance.

ما هو AI Assurance؟

AI Assurance هو مجموعة عمليات وأدلة تهدف إلى بناء مستوى معقول من الثقة بأن النظام:

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

Assurance ليس Certification فقط

الضمان لا يساوي شهادة خارجية.

قد يشمل:

• internal validation.
• control testing.
• independent review.
• impact assessment.
• monitoring evidence.
• audit.

Assurance ≠ Compliance

قد يكون النظام compliant مع سياسة ما، لكنه ضعيف تقنيًا أو تشغيليًا.

وقد يكون قويًا تقنيًا لكنه يفتقر إلى governance.

Assurance يبدأ قبل التطوير

أول سؤال:

ما نوع الضرر الممكن؟

وليس:

هل النموذج دقيق؟

Impact Assessment

تقييم الأثر يساعد على فهم:

• من يتأثر؟
• ما نوع الضرر؟
• ما مدى reversibility؟
• ما البيانات؟
• ما مستوى autonomy؟
• ما أثر الخطأ؟

Scope of Impact

يمكن أن يشمل:

• individuals.
• groups.
• customers.
• employees.
• citizens.
• operations.
• security.
• reputation.

Severity

قيّم:

• magnitude.
• duration.
• reversibility.
• scale.

Likelihood

قيّم احتمال وقوع الأثر.

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

Risk = More Than Probability

في AI بعض المخاطر نادرة لكنها كارثية.

لذلك severity قد ترفع التصنيف حتى لو كان الاحتمال منخفضًا.

Use-Case Context

نفس model قد يكون منخفض الخطر في:

Drafting Assistant.

وعالي الخطر في:

Eligibility Decision.

Risk Classification

استخدم Risk Tier لتحديد عمق Assurance.

مثلاً:

Low Moderate High Critical.

Assurance Depth by Tier

Low: basic review.

Moderate: structured testing.

High: independent validation.

Critical: deep assurance + continuous oversight.

Responsible AI Principles as Assurance Domains

يمكن تحويل المبادئ المحلية إلى مجالات Assurance:

• Risk.
• Safety.
• Robustness.
• Security.
• Fairness.
• Privacy.
• Transparency.
• Human Accountability.

Governance Assurance

هل توجد:

• ownership.
• approval authority.
• risk appetite.
• escalation.
• exception process؟

Data Assurance

هل البيانات:

• مناسبة؟
• موثقة؟
• ذات جودة؟
• قابلة للتتبع؟
• محدثة؟

Data Provenance

يجب معرفة:

• source.
• version.
• transformations.
• labeling.
• ownership.

Data Quality Evidence

الادعاء بأن البيانات جيدة لا يكفي.

احتفظ بـ:

• validation results.
• completeness metrics.
• anomaly findings.
• remediation.

Bias Assurance

اختبر:

• performance differences.
• data imbalance.
• error distribution.
• subgroup impact.

Fairness Is Contextual

لا يوجد metric واحد صالح لكل use case.

Privacy Assurance

راجع:

• purpose.
• minimization.
• retention.
• cross-border flows.
• vendors.
• access.

Security Assurance

يشمل:

• threat modeling.
• access controls.
• API security.
• prompt injection testing.
• RAG authorization.
• agent permissions.

Robustness Assurance

اختبر performance عند:

• noisy inputs.
• incomplete inputs.
• edge cases.
• adversarial conditions.

Reliability

هل النظام يؤدي بصورة مستقرة ضمن operating range؟

Safety

هل يمكن أن تسبب المخرجات harm حتى إذا كانت تقنيًا صحيحة؟

Human Oversight Assurance

لا يكفي وجود human reviewer.

اختبر:

• هل يفهم؟
• هل يستطيع override؟
• هل يملك الوقت؟
• هل يتم توثيق intervention؟

Explainability Assurance

حدد مستوى الشرح المطلوب حسب الأثر.

Transparency Assurance

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

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

Model Validation

Model Validation يجب أن يجيب:

هل هذا النموذج مناسب لهذا الغرض؟

Technical Validation

قد تشمل:

• accuracy.
• precision.
• recall.
• calibration.
• latency.
• robustness.

Business Validation

قد تشمل:

• process fit.
• outcome quality.
• workflow impact.
• user acceptance.

Operational Validation

اختبر:

• availability.
• failure recovery.
• support.
• monitoring.
• fallback.

TEVV

Testing, Evaluation, Verification and Validation يمكن استخدامه كمنهجية عملية.

لكن:

ليس لدينا ما يثبت أنه متطلب قطري محدد بالاسم.

نستخدمه هنا كأفضل ممارسة دولية مساندة.

Testing

هل النظام يؤدي الوظيفة المطلوبة؟

Evaluation

هل الأداء مناسب للسياق؟

Verification

هل تم بناء النظام وفق المتطلبات المحددة؟

Validation

هل النظام النهائي مناسب للاستخدام المقصود؟

Acceptance Criteria

حددها قبل الاختبار.

Failure Criteria

حدد متى يجب وقف النشر.

Red Teaming

للأنظمة الحساسة اختبر:

• adversarial prompts.
• data extraction.
• unsafe actions.
• privilege abuse.
• policy bypass.

Scenario Testing

اختبر حالات:

• normal.
• stressed.
• degraded.
• malicious.

Edge Cases

الأخطاء غالبًا تظهر خارج average case.

Independent Review

في الأنظمة عالية الأثر، فصل reviewer عن builder يزيد مصداقية Assurance.

Conflict of Interest

الفريق الذي يريد إطلاق النظام قد يكون متحيزًا لقبول النتائج.

Assurance Owner

حدد جهة مسؤولة عن تنسيق Assurance.

قد تكون:

• Risk.
• Internal Control.
• AI Governance.
• Model Risk.
• Assurance Function.

Three Lines Model

يمكن توزيع المسؤوليات:

First Line: business and engineering.

Second Line: risk/compliance/governance.

Third Line: internal audit.

Evidence-Based Approval

لا تعتمد الموافقة على presentation.

يجب أن تعتمد على Evidence Pack.

Evidence Pack

قد يشمل:

• use case.
• risk classification.
• impact assessment.
• data review.
• model validation.
• security testing.
• privacy review.
• bias testing.
• human oversight test.
• approvals.
• monitoring plan.

Assurance Case

يمكن بناء Assurance Case يربط:

Claim → Evidence → Rationale.

مثال:

Claim: النظام مناسب للاستخدام.

Evidence: validation + stress test + monitoring plan.

Traceability

يجب أن تستطيع تتبع:

Requirement → Control → Test → Result → Approval.

ISO/IEC 42001

ISO/IEC 42001 يوفر إطار نظام إدارة للذكاء الاصطناعي.

يمكن استخدامه لتنظيم:

• governance.
• roles.
• policies.
• risk.
• monitoring.
• continuous improvement.

ISO/IEC 42005

ISO/IEC 42005 يوفر إطارًا منهجيًا لتقييم أثر AI systems.

مفيد جدًا لتصميم Impact Assessment.

ISO/IEC 23894

يوفر مبادئ لإدارة مخاطر AI.

NIST AI RMF

يمكن الاستفادة من:

Govern Map Measure Manage.

لا تحول المعايير الدولية إلى قانون محلي

هذه نقطة إلزامية في الصياغة.

ISO أو NIST لا تصبح متطلبات قطرية تلقائيًا.

Local + Global Assurance Model

النموذج الأفضل:

Qatar Ethical Guidelines → Local principles.

ISO/NIST → Operational assurance mechanics.

Assurance Before Go-Live

قبل النشر، تحقق من:

• risk classification.
• impact assessment.
• test results.
• approval.
• monitoring readiness.

Go-Live Gate

يجب أن يكون Decision Gate حقيقيًا.

Conditional Approval

قد يسمح بالنشر مع:

• limited users.
• limited data.
• limited scope.
• time-bound exception.

Exceptions

يجب أن تكون:

• documented.
• approved.
• time-bound.
• monitored.

Post-Deployment Assurance

Assurance لا ينتهي عند Go-Live.

Continuous Monitoring

راقب:

• model performance.
• data drift.
• incidents.
• complaints.
• overrides.
• vendor changes.

Model Drift

قد يتغير الأداء مع الزمن.

Data Drift

Input distribution قد تتغير.

Concept Drift

المعنى أو العلاقة بين input والنتيجة قد تتغير.

Monitoring Thresholds

حدد thresholds مسبقًا.

Trigger-Based Reassessment

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

• major incident.
• model change.
• new dataset.
• new population.
• increased autonomy.
• new vendor.

Vendor Assurance

إذا كان النظام SaaS، لا تنتقل المسؤولية إلى المورد.

Supplier Evidence

اطلب:

• security evidence.
• testing.
• documentation.
• incident history.
• data practices.

Third-Party Model Changes

Vendor قد يغير model دون deployment داخلي.

يجب أن يطلق ذلك review.

Cloud Assurance

راجع:

• availability.
• resilience.
• region.
• failover.
• access.
• exit.

Agentic AI Assurance

إذا كان Agent ينفذ actions، أضف:

• permission testing.
• tool restrictions.
• approval gates.
• kill switch.
• transaction limits.

Prompt Assurance

في GenAI، prompt templates نفسها artifacts مهمة.

RAG Assurance

اختبر:

• source quality.
• retrieval accuracy.
• authorization.
• poisoning.
• stale content.

Hallucination Testing

قِس hallucination ضمن use case المحدد، لا كمؤشر عام فقط.

Safety Testing

اختبر harmful outputs حيث تكون ذات صلة.

Abuse Testing

افترض أن المستخدم قد يحاول إساءة الاستخدام.

User Testing

اختبر مع المستخدمين الفعليين.

Human Factors

الفشل قد يكون بسبب interface وليس model.

Automation Bias

المستخدم قد يثق بـAI أكثر من اللازم.

Over-Reliance Testing

اختبر هل المستخدمون يراجعون output فعلًا.

Explainability Testing

اسأل المستخدم أو reviewer:

هل يستطيع فهم سبب النتيجة بما يكفي لاتخاذ قرار؟

Control Testing

راجع هل controls تعمل فعليًا.

Design Effectiveness

هل control مصمم بشكل مناسب؟

Operating Effectiveness

هل يتم تطبيقه باستمرار؟

Residual Risk

بعد controls، ما المخاطر المتبقية؟

Risk Acceptance

من يملك صلاحية قبول residual risk؟

Senior Management Visibility

الأنظمة عالية الأثر تحتاج visibility أعلى.

Board Visibility

لا يحتاج مجلس الإدارة كل test result.

لكن يحتاج:

• major risks.
• critical systems.
• incidents.
• exceptions.

Internal Audit

يمكن للتدقيق اختبار Assurance Framework نفسها.

Regulatory Auditability

حتى في غياب AI law شامل، المؤسسات الناضجة يجب أن تكون قادرة على شرح:

• ما النظام؟
• لماذا اعتمد؟
• ما المخاطر؟
• كيف اختبر؟
• من وافق؟

Government AI

في القطاع الحكومي، impact assessment مهم بسبب:

• citizen impact.
• public services.
• public accountability.

Financial AI

في القطاع المالي ترتفع أهمية:

• model risk.
• resilience.
• explainability.
• oversight.

Healthcare AI

إذا استخدم في الصحة، ترتفع أهمية:

• safety.
• clinical validation.
• human oversight.

لكن هذا المقال لا يدعي وجود إطار صحي قطري مستقل للـAI.

Procurement

Vendor assessment يجب أن يسبق الشراء النهائي.

Contractual Assurance

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

• incident notification.
• change notification.
• data terms.
• audit evidence.
• exit.

Assurance Metrics

يمكن قياس:

• % high-risk systems validated.
• % controls tested.
• overdue reviews.
• open critical findings.
• monitoring coverage.

Assurance KRIs

مثل:

• high-risk system without impact assessment.
• unresolved red-team finding.
• vendor model change without revalidation.

Assurance Dashboard

قد يعرض:

• risk tier.
• assurance status.
• last review.
• findings.
• next reassessment.

Assurance Maturity

Level 1: Ad Hoc.

Level 2: Documented.

Level 3: Standardized.

Level 4: Measured.

Level 5: Continuously Improved.

Common Anti-Pattern: Checklist Assurance

وجود 50 سؤالًا answered نعم/لا ليس ضمانًا حقيقيًا.

Common Anti-Pattern: Accuracy-Only

High accuracy لا تعني low risk.

Common Anti-Pattern: One-Time Testing

النظام المتغير يحتاج Assurance مستمرة.

Common Anti-Pattern: Vendor Trust

لا تعتمد على vendor marketing claims.

Common Anti-Pattern: Policy-Only

السياسة دون testing وevidence ضعيفة.

Retirement Assurance

عند إيقاف النظام:

• close access.
• handle data.
• archive evidence.
• update inventory.

Continuous Improvement

كل incident أو failure يجب أن يحسن Assurance process.

Draft National AI Policy

تبقى Draft.

لا نستخدمها كمصدر نهائي.

Current vs Proposed

Ethical Guidelines → Final guidance.

National AI Strategy → Final strategy.

Draft National AI Policy → Proposed.

Pre-Go-Live Assurance Gate

قبل Go-Live:

1. هل risk tier محدد؟
2. هل impact assessment مكتمل؟
3. هل data validated؟
4. هل security tested؟
5. هل privacy reviewed؟
6. هل model validated؟
7. هل human oversight اختبر؟
8. هل residual risk مقبول؟
9. هل monitoring جاهز؟
10. هل approval موثق؟

الخلاصة

AI Assurance في قطر لا يحتاج انتظار قانون شامل جديد.

المبادئ المحلية موجودة، ويمكن تحويلها إلى منظومة ضمان عملية عبر التقييم والاختبار والتحقق والمساءلة والمراقبة.

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

Local Principles + Operational Assurance + Evidence + Continuous Reassessment.

وهكذا يصبح السؤال ليس:

هل نثق بالـAI؟

بل:

ما الأدلة التي تبرر هذه الثقة، ومن قبل المخاطر المتبقية، ومتى نعيد التقييم؟