حوكمة الذكاء الاصطناعي في القطاع المالي البحريني: من مخاطر النماذج إلى الموردين والمرونة التشغيلية

لماذا القطاع المالي يحتاج حوكمة AI أكثر صرامة؟

المؤسسات المالية تعمل في بيئة تجمع بين:

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

لهذا السبب فإن AI Governance داخل القطاع المالي لا يمكن أن يكون مجرد امتداد لسياسة استخدام داخلية عامة.

لا يوجد CBB AI Framework عام مستقل مثبت

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

لذلك يجب تجنب صياغات مثل:

"وفق إطار CBB للذكاء الاصطناعي..."

ما لم يوجد مصدر محدد يدعمها.

ما الموجود فعليًا؟

الحوكمة تنشأ من تركيب عدة طبقات:

• Bahrain AI Policy 2025.
• Personal Data Protection Law.
• National Cybersecurity Strategy 2025–2028.
• Bahrain Open Banking Framework.
• القواعد والمتطلبات القطاعية لدى مصرف البحرين المركزي حيث تنطبق.
• Internal Model Risk.
• Third-Party Risk.
• Business Continuity.

Regulatory Stack

يمكن تمثيل البيئة هكذا:

Financial Regulation + Data Protection + Cybersecurity + Open Banking + AI Policy + Internal Governance

قوة هذا النموذج أنه لا ينتظر ظهور وثيقة تحمل كلمة AI في عنوانها حتى يبدأ ضبط المخاطر.

حالات الاستخدام المالية

يمكن أن يدخل AI في:

• Fraud Detection.
• AML Support.
• Customer Service.
• Credit Analytics.
• Collections.
• Transaction Monitoring.
• Personalization.
• Cybersecurity.
• Document Processing.
• Internal Copilots.
• Trading Support.
• Risk Analytics.

ولا يجب معاملتها كلها بنفس مستوى المخاطر.

AI Inventory

أول طبقة حوكمة هي الجرد.

لكل نظام سجل:

• business purpose.
• owner.
• model.
• provider.
• data.
• users.
• decision impact.
• autonomy.
• deployment status.
• validation status.

Model Inventory مقابل Application Inventory

قد يحتوي تطبيق واحد على عدة models.

وقد يستخدم model واحد في عدة تطبيقات.

لذلك يجب الربط بين:

Application ↔ Model ↔ Provider.

Model Risk

Model Risk قد يظهر على شكل:

• hallucination.
• drift.
• unstable output.
• weak calibration.
• bias.
• data sensitivity.
• unexpected behavior.

Materiality

ليس كل model جوهريًا.

حدد materiality وفق:

• financial exposure.
• customer impact.
• regulatory impact.
• transaction volume.
• business criticality.
• substitutability.

Risk Tiering

يمكن استخدام تصنيف داخلي:

Low Moderate High Critical

ويجب أن يغير شدة controls.

Model Validation

الأنظمة المؤثرة تحتاج Validation يشمل:

• design.
• assumptions.
• data.
• performance.
• limitations.
• stress cases.
• sensitivity.

Validation Independence

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

Generative AI

GenAI يمكن أن يدخل في:

• summarization.
• drafting.
• support.
• policy search.
• document analysis.
• coding.

هذه الاستخدامات قد تكون منخفضة أو متوسطة الأثر إذا بقي القرار النهائي بيد الإنسان.

Customer-Facing GenAI

عندما يواجه العميل النظام مباشرة، ترتفع المخاطر.

اختبر:

• hallucination.
• outdated information.
• incorrect product interpretation.
• disclosure.
• inappropriate guidance.
• failed escalation.

Financial Advice Risk

إذا كان output قد يُفهم كإرشاد مالي، يجب وضع boundaries واضحة.

مثلاً:

• disclaimer.
• escalation.
• human review.
• restricted domains.

Fraud Detection

AI قد يكون فعالًا في اكتشاف الاحتيال، لكنه قد يخلق False Positives.

هذا قد يؤدي إلى:

• تعطيل عميل شرعي.
• تجميد معاملة.
• تصعيد غير ضروري.
• عبء تشغيلي.

Fraud Model Metrics

راقب:

• precision.
• recall.
• false positive rate.
• false negative rate.
• investigation conversion.
• customer complaints.

AML Support

AI يمكن أن يساعد في:

• pattern detection.
• prioritization.
• document review.
• alert enrichment.

لكنه لا يلغي مسؤولية المؤسسة عن governance واتخاذ القرار.

Credit and Eligibility

هذه من أعلى حالات الاستخدام تأثيرًا.

تحتاج إلى:

• data quality.
• fairness review.
• explainability.
• override.
• auditability.
• monitoring.

Human Oversight

الإشراف البشري يجب أن يكون حقيقيًا.

اسأل:

• هل يستطيع الموظف رفض توصية model؟
• هل يفهم النتيجة؟
• هل يملك وقتًا؟
• هل توجد escalation؟
• هل يتم تسجيل التدخل؟

Rubber-Stamp Risk

إذا كان الموظف يوافق دائمًا على output دون مراجعة حقيقية، يصبح Human-in-the-loop عنصرًا شكليًا.

Override Monitoring

راقب:

• override rate.
• override reasons.
• repeated patterns.
• business unit differences.

قد تكشف هذه المؤشرات ضعف model أو سوء استخدامه.

Explainability

Explainability ليست requirement واحدة لجميع الأنظمة.

قد تحتاج إلى:

• feature-level explanation.
• reason code.
• business rationale.
• decision trace.

بحسب use case.

Data Governance

القطاع المالي يملك كميات كبيرة من البيانات.

لكن هذا يزيد مسؤولية الحوكمة.

حدد:

• ownership.
• source.
• quality.
• lineage.
• access.
• retention.
• permitted use.

Personal Data

قانون حماية البيانات الشخصية البحريني يبقى طبقة مستقلة.

AI لا يخلق إعفاء من حماية البيانات.

Financial Data

بعض البيانات المالية قد تكون حساسة جدًا حتى لو كان تصنيفها القانوني الدقيق يعتمد على السياق.

يجب معاملتها وفق مستوى المخاطر الفعلي.

Data Provenance

يجب معرفة أصل البيانات المستخدمة في:

• training.
• scoring.
• inference.
• recommendations.
• analytics.

Derived Data

AI قد ينتج:

• risk score.
• customer segment.
• behavioral profile.
• predicted propensity.

هذه المخرجات نفسها تحتاج governance.

Data Quality

Poor Data → Poor Model.

لكن في القطاع المالي قد يعني هذا:

• قرارًا خاطئًا.
• مخاطرة مالية.
• أثرًا على عميل.
• مخالفة داخلية.

Third-Party AI

المؤسسة قد تعتمد على:

• foundation model provider.
• fintech vendor.
• cloud provider.
• analytics vendor.
• identity provider.
• security provider.

Vendor Due Diligence

راجع:

• security.
• privacy.
• operational resilience.
• financial stability.
• data use.
• retention.
• subcontracting.
• incidents.
• portability.
• termination.

Model Provider Changes

مزود SaaS قد يغير model دون أن تقوم المؤسسة بعملية deployment جديدة.

هذا يعني أن change management يجب أن يشمل vendor-side changes.

Change Notification

العقد أو governance process يجب أن يحدد متى يصبح تغيير provider أو model حدثًا يتطلب مراجعة.

Third-Party Concentration Risk

إذا كان نفس provider يخدم:

• fraud.
• customer support.
• internal copilot.
• analytics.

فقد يصبح failure واحد ذا أثر واسع.

Cloud Dependency

الاعتماد على cloud يضيف مخاطر:

• region outage.
• latency.
• concentration.
• portability.
• support access.
• data location.

Operational Resilience

الخدمة المالية يجب أن تستمر أو تتدهور بصورة مسيطر عليها عند فشل AI.

Graceful Degradation

مثال:

إذا فشل model الخاص بالتوصيات، تبقى الخدمة الأساسية متاحة بدون توصية آلية.

Manual Fallback

في العمليات الحرجة يجب أن يوجد مسار بديل.

Business Continuity

AI يجب أن يدخل ضمن Business Continuity Planning إذا كان مؤثرًا في خدمة أساسية.

Cybersecurity

AI يتكامل مع:

• IAM.
• SOC.
• Incident Response.
• API Security.
• Third-Party Risk.
• Secure Development.

Prompt Injection

في الأنظمة المتصلة بأنظمة مالية، Prompt Injection قد يتجاوز محتوى المحادثة ويصل إلى action layer.

Agentic AI

Agentic AI في القطاع المالي يتطلب ضوابط أعلى.

قد يمتلك agent القدرة على:

• query.
• update.
• message.
• initiate.
• approve.
• execute.

Segregation of Duties

لا تمنح agent صلاحيات:

Create + Approve + Execute

داخل نفس العملية الحساسة.

Machine Identity

كل agent يحتاج:

• unique identity.
• least privilege.
• credential rotation.
• logging.
• revocation.

Transaction Limits

ضع حدودًا بحسب:

• amount.
• frequency.
• customer type.
• risk level.

Step-Up Authentication

الإجراءات الحساسة تحتاج تحققًا أقوى.

Explicit Confirmation

بعض الإجراءات يجب أن تحتاج تأكيدًا صريحًا من المستخدم أو الموظف.

Open Banking

إذا كان AI يعمل داخل Open Banking ecosystem، أضف:

• API scope.
• consent.
• TPP governance.
• data-sharing controls.
• API resilience.

API + Model Risk

قد يكون model متاحًا لكن API متوقف.

أو العكس.

يجب اختبار failure combinations.

Privacy

راجع:

• purpose.
• retention.
• logs.
• vendors.
• subprocessors.
• cross-border processing.

Customer Transparency

حدد متى يحتاج العميل أن يعرف أن AI يؤدي دورًا جوهريًا في الخدمة أو القرار.

Complaints

الشكاوى مؤشر مهم.

قد تكشف:

• inaccurate outputs.
• unfair treatment.
• poor escalation.
• misunderstood automation.

Monitoring

راقب:

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

Model Drift

قد يتغير performance مع تغير:

• customer behavior.
• fraud patterns.
• market conditions.
• input distribution.

Incident Classification

AI incident قد يسبب:

• financial loss.
• customer harm.
• privacy issue.
• cyber issue.
• service outage.
• reputation damage.

Incident Escalation

حدد مسبقًا:

• owner.
• severity.
• notification path.
• containment.
• recovery.

Board and Senior Management

ليس مطلوبًا أن تراجع الإدارة العليا كل model.

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

• critical AI systems.
• material risks.
• incidents.
• concentration.
• exceptions.

AI Risk Appetite

يمكن للمؤسسة تحديد مواقف واضحة.

مثال:

عدم السماح بقرار مالي نهائي fully autonomous في حالات معينة.

Policies

اربط AI Governance بـ:

• Model Risk Policy.
• Cybersecurity Policy.
• Data Protection.
• Third-Party Risk.
• Business Continuity.
• Internal Control.

AI Committee

إنشاء لجنة جديدة ليس هدفًا بحد ذاته.

إذا كانت البنية الحالية تستطيع إدارة AI بوضوح، قد يكون دمجه أفضل.

Internal Audit

يمكن للتدقيق اختبار:

• inventory completeness.
• risk classification.
• validation.
• approvals.
• vendor governance.
• monitoring.
• incident handling.

AI Assurance

الأنظمة عالية الأثر قد تحتاج:

• independent testing.
• scenario analysis.
• control testing.
• red teaming.
• model validation.
• operational resilience testing.

Evidence Pack

لكل نظام مادي:

• business case.
• owner.
• risk assessment.
• model documentation.
• data documentation.
• validation.
• security review.
• privacy review.
• vendor review.
• approval.
• monitoring.
• incidents.
• change history.

Lifecycle

Idea → Assessment → Validation → Approval → Deployment → Monitoring → Change → Retirement

Retirement

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

• revoke credentials.
• remove integrations.
• close vendor access.
• handle retained data.
• archive evidence.
• update inventory.

No-Regret Controls

حتى بدون Framework مصرفي مستقل باسم AI، يمكن تطبيق:

• inventory.
• classification.
• validation.
• human oversight.
• vendor governance.
• monitoring.
• incident management.
• assurance.

Attribution Discipline

لا تنسب للمصرف المركزي متطلبات لم يصدرها.

الصياغة الصحيحة تكون مثل:

هذه الممارسة مناسبة لإدارة مخاطر AI في ضوء الطبقات التنظيمية والتشغيلية القائمة.

وليس:

"مصرف البحرين المركزي يفرض هذا المتطلب"

دون مصدر مباشر.

Pre-Go-Live Gate

قبل نشر نظام مالي مؤثر:

1. هل use case مسجل؟
2. هل risk tier محدد؟
3. هل data موثقة؟
4. هل model validated؟
5. هل vendor assessed؟
6. هل security reviewed؟
7. هل privacy reviewed؟
8. هل human oversight مختبر؟
9. هل fallback موجود؟
10. هل monitoring جاهز؟

الخلاصة

القطاع المالي البحريني لا يحتاج إلى انتظار وثيقة مستقلة تحمل اسم AI Regulation حتى يبدأ حوكمة الذكاء الاصطناعي.

المخاطر والالتزامات موجودة بالفعل عبر طبقات مالية وبيانية وسيبرانية وتشغيلية.

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