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

لماذا يحتاج القطاع المصرفي إلى حوكمة AI مختلفة؟

استخدام الذكاء الاصطناعي داخل مصرف ليس مكافئًا لاستخدام أداة إنتاجية عادية داخل مؤسسة.

النظام قد يؤثر في كشف الاحتيال، تقييم المخاطر، خدمة العملاء، تحليل المعاملات، مراقبة العمليات أو دعم قرارات الائتمان.

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

في العراق، لا يوجد حتى الآن تنظيم مصرفي مستقل شامل مخصص للذكاء الاصطناعي، لكن هذا لا يعني وجود فراغ رقابي.

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

🔴 حالة الاستراتيجية الوطنية للذكاء الاصطناعي

الاستراتيجية الوطنية العراقية للذكاء الاصطناعي وتكامل البيانات الضخمة ما تزال مسودة / Draft وقيد التطوير.

لذلك يمكن استخدامها لفهم الاتجاه الوطني، لكنها ليست مصدرًا لالتزامات مصرفية نهائية.

المتطلبات النافذة في البيئة المصرفية يجب تمييزها عن الاتجاهات المقترحة في الاستراتيجية.

البنك المركزي والبيئة الرقمية المصرفية

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

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

هو يعتمد على:

الأنظمة الأساسية للمصرف.

قواعد البيانات.

واجهات الدفع.

الخدمات الإلكترونية.

الموردين.

الحوسبة.

الشبكات.

والصلاحيات.

لذلك فإن مخاطر AI تصبح جزءًا من المخاطر التقنية والتشغيلية والرقابية الموجودة أصلًا.

ضوابط الصمود السيبراني

ضوابط الصمود السيبراني للقطاع المالي والمصرفي الصادرة عن البنك المركزي العراقي توفر طبقة مهمة لفهم البيئة التي يجب تشغيل AI داخلها.

الصمود السيبراني يتجاوز منع الاختراق.

المؤسسة تحتاج إلى القدرة على الاستمرار، والاستجابة للحادث، واستعادة الخدمة، ومعرفة الأصول الحرجة والاعتماديات.

إذا أصبح AI جزءًا من وظيفة مصرفية مهمة، فيجب أن يدخل في هذا النموذج.

ما الذي يتغير عندما يدخل AI؟

النظام التقليدي ينفذ منطقًا محددًا نسبيًا.

أما AI فقد يعتمد على نموذج احتمالي أو متغير الأداء.

هذا يضيف مخاطر مثل:

تدهور الدقة.

الانحراف.

نتائج غير متوقعة.

تأثير تغير البيانات.

اعتماد كبير على مورد خارجي.

صعوبة تفسير بعض المخرجات.

والتغير المستمر في النموذج المستضاف خارجيًا.

لذلك يجب ألا يُعامل AI كبرنامج ثابت بعد دخوله الإنتاج.

سجل الأنظمة والنماذج

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

السجل يجب أن يشمل أكثر من النماذج المطورة داخليًا.

يجب أن يشمل:

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

إذا لم يعرف المصرف أن النظام يحتوي AI، فلن يستطيع إخضاعه للحوكمة.

تصنيف الاستخدام حسب الأثر

لا تحتاج كل الأنظمة إلى المستوى نفسه من الرقابة.

مساعد يختصر مذكرة داخلية يختلف عن نظام يوصي برفض طلب تمويل.

يمكن تصنيف الاستخدامات إلى مستويات وفق:

أثر القرار.

حساسية البيانات.

حجم المستخدمين المتأثرين.

إمكانية الضرر المالي.

صعوبة اكتشاف الخطأ.

ودرجة الاعتماد على الأتمتة.

كلما ارتفع الأثر، ارتفعت متطلبات الاختبار والموافقة والمراقبة.

مخاطر النماذج

مخاطر النموذج لا تعني فقط أن النموذج يمكن أن يكون "غير دقيق".

قد يكون النموذج صحيحًا إحصائيًا لكنه غير مناسب للغرض.

وقد يكون التدريب قائمًا على بيانات لا تمثل الفئة التي سيطبق عليها.

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

وقد يُستخدم النظام في قرار لم يُصمم له أصلًا.

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

الائتمان والقرارات المالية

استخدام AI في الائتمان من أكثر الحالات حساسية.

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

لكن يجب تجنب أن يتحول الدعم الخوارزمي إلى قرار غير قابل للفهم.

المصرف يحتاج إلى معرفة المتغيرات المهمة، وحدود النموذج، ومتى يجب إحالة الحالة لمراجعة بشرية.

كما يجب مراقبة ما إذا كان النظام ينتج فروقات غير مبررة بين مجموعات العملاء.

كشف الاحتيال

AI مفيد في تحليل الأنماط غير الطبيعية وكشف المعاملات المشبوهة.

لكن نظام كشف الاحتيال يواجه معضلتين:

False Positive: إيقاف معاملة سليمة.

False Negative: تمرير معاملة احتيالية.

لذلك لا يوجد رقم واحد يحدد جودة النظام.

يجب موازنة الحساسية والدقة والأثر على العميل والتكلفة التشغيلية.

البيانات المصرفية

النماذج المصرفية تعتمد على بيانات شديدة الحساسية.

قد تشمل:

الهوية.

الحسابات.

المعاملات.

السلوك.

الموقع.

تاريخ السداد.

التواصل مع المصرف.

والمعلومات التجارية.

أي مشروع AI يحتاج إلى تعريف واضح لما يمكن استخدامه ولماذا.

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

جودة البيانات

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

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

لذلك يجب أن تدخل جودة البيانات ضمن اعتماد النموذج.

مصدرية البيانات

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

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

هذا مهم عند ظهور اعتراض أو حادث أو نتيجة غير متوقعة.

الإشراف البشري

عبارة "يوجد إنسان في الحلقة" ليست كافية.

الإشراف الحقيقي يتطلب أن يملك الشخص:

صلاحية تعديل القرار.

المعلومات اللازمة للمراجعة.

وقتًا مناسبًا.

تدريبًا.

وآلية واضحة للتصعيد.

إذا كان الموظف يوافق تلقائيًا على مخرجات النموذج، فالإشراف شكلي.

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

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

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

هذه الممارسة قد تنقل بيانات إلى بيئة لم يوافق عليها المصرف.

لذلك يجب وضع سياسة واضحة لاستخدام Generative AI تشمل الأدوات المسموحة والبيانات المحظورة ومتطلبات التحقق.

مخاطر الموردين

المصارف تعتمد على موردين وتقنيات خارجية بصورة واسعة.

مع AI يصبح السؤال أكثر تعقيدًا.

يجب معرفة:

من يملك النموذج؟

أين يعمل؟

هل يتغير دون إشعار؟

هل يستخدم بيانات المصرف للتدريب؟

من هم المعالجون الفرعيون؟

كيف يتم الإبلاغ عن الحوادث؟

هل يستطيع المصرف إجراء تحقيق؟

وما الذي يحدث عند إنهاء العقد؟

الاعتماد على السحابة والخدمات الخارجية

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

إذا اعتمدت وظائف عديدة على المورد نفسه، فإن حادثًا واحدًا يمكن أن يؤثر في أكثر من خدمة.

يجب أن تعرف المؤسسة نقاط الاعتماد الحرجة وتضع خططًا للتعامل مع الانقطاع.

الأمن الخاص بالنماذج

AI يضيف أنماط تهديد جديدة.

مثل:

التلاعب بالمدخلات.

Prompt Injection.

استخراج المعلومات.

إساءة استخدام واجهات API.

التلاعب ببيانات التدريب أو الاسترجاع.

وسرقة مكونات النموذج.

هذه المخاطر يجب أن تدخل في الاختبارات الأمنية.

إدارة الصلاحيات

القاعدة الأساسية هي الحد الأدنى من الصلاحيات.

إذا كان النظام يحتاج إلى ثلاثة حقول من قاعدة بيانات العملاء، فلا مبرر لإعطائه صلاحية على كامل السجل.

فصل الصلاحيات يقلل أثر الاختراق والخطأ.

الاستجابة للحوادث

حادث AI قد لا يبدو مثل حادث تقني تقليدي.

قد يكون الحادث:

ارتفاعًا مفاجئًا في الأخطاء.

تسريب معلومات داخل المخرجات.

قرارًا آليًا خاطئًا على نطاق واسع.

تغيرًا غير مصرح به في النموذج.

أو اعتمادًا على بيانات فاسدة.

لذلك تحتاج خطة الحوادث إلى تعريف واضح لما يعتبر حادث AI.

المرونة التشغيلية

إذا أصبح النموذج جزءًا من عملية مصرفية حرجة، يجب وجود خطة عند تعطله.

هل يمكن العودة إلى عملية يدوية؟

هل توجد خدمة بديلة؟

ما الحد الأقصى للتوقف المقبول؟

هل فقد النموذج يؤثر على قنوات متعددة؟

هذه الأسئلة يجب اختبارها قبل وقوع المشكلة.

مراقبة الأداء بعد النشر

نجاح الاختبار قبل الإنتاج لا يضمن الأداء المستقبلي.

البيانات تتغير.

العملاء يتغيرون.

أنماط الاحتيال تتغير.

المورد قد يحدث النموذج.

لذلك يجب تحديد مؤشرات مراقبة وعتبات تستدعي التحقيق أو إيقاف النظام.

أثر التدقيق

يجب أن يستطيع المصرف لاحقًا معرفة:

ما النظام الذي استخدم؟

أي إصدار؟

أي بيانات؟

متى؟

من طلب القرار؟

ما النتيجة؟

هل عدلها موظف؟

من وافق على الاستثناء؟

هذه القدرة مهمة للمراجعة الداخلية وإدارة الحوادث والمساءلة.

التدقيق الداخلي

التدقيق في AI لا يقتصر على قراءة السياسة.

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

هل التقييم موجود؟

هل اختُبر النظام؟

هل تمت مراجعة المورد؟

هل توجد سجلات مراقبة؟

هل الاستثناءات موثقة؟

الفرق بين الحوكمة الورقية والحوكمة الفعلية يظهر هنا.

العلاقة مع المصارف الرقمية

المصارف الرقمية تمثل حالة خاصة داخل القطاع، لأن اعتمادها على الأنظمة الرقمية أعلى منذ البداية.

معايير المصارف الرقمية الصادرة في 2026 تستحق تحليلًا مستقلًا، لذلك لا يحاول هذا المقال استبدال القراءة الخاصة بها.

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

ما الذي لا ينبغي استنتاجه؟

لا ينبغي القول إن البنك المركزي العراقي أصدر "AI Regulation" خاصًا بالبنوك ما لم توجد وثيقة تحمل ذلك المعنى رسميًا.

وضوابط الصمود السيبراني ليست Model Risk Framework للذكاء الاصطناعي.

ومعايير المصارف الرقمية ليست قانون AI.

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

نموذج حوكمة عملي للمصرف

يمكن بناء دورة حوكمة داخلية تبدأ من اقتراح الاستخدام.

ثم:

تحديد المالك.

تصنيف المخاطر.

مراجعة البيانات.

مراجعة المورد.

الاختبار.

الموافقة.

النشر.

المراقبة.

إدارة التغيير.

الاستجابة للحوادث.

والإيقاف.

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

ما الذي يجب أن يفعله المصرف الآن؟

لا يحتاج المصرف إلى انتظار صدور تنظيم AI مستقل حتى يبدأ.

يمكنه الآن:

معرفة استخداماته.

تصنيفها.

تحديد أصحاب المسؤولية.

ربطها بإدارة المخاطر.

إدخال الأمن والموردين والبيانات في بوابة الموافقة.

اختبار الأنظمة المؤثرة.

ومراقبتها بعد النشر.

هذه الإجراءات تتكامل مع البيئة الرقابية القائمة بدل أن تنافسها.

الخلاصة التنفيذية

القطاع المصرفي العراقي يمتلك بالفعل بيئة تنظيمية وتقنية تجعل حوكمة AI ضرورة عملية.

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

التحدي للمصارف ليس انتظار وثيقة تحمل اسم AI Regulation.

التحدي هو دمج مخاطر النماذج والبيانات والموردين والأتمتة ضمن منظومة المخاطر والأمن والرقابة الموجودة أصلًا.

عندما يصبح AI جزءًا من الخدمة المصرفية، يجب أن يصبح أيضًا جزءًا من الحوكمة المصرفية.