تحديث أنظمة البنوك القديمة لتمكين ذكاء اصطناعي عملي بالبحرين

قبل أن نتحدث عن نماذج ذكاء اصطناعي ترد على العملاء أو تكشف الاحتيال في ثوانٍ، هناك حقيقة مزعجة كثيرًا ما يتم تجاهلها: الذكاء الاصطناعي لا يعمل على “الوعود”، بل يعمل على البيانات. والبيانات في معظم البنوك لا تعيش في تطبيقات حديثة فقط—بل ما زالت، في كثير من الحالات، مخزنة ومدارة داخل أنظمة قديمة بنيت منذ عقود، أشهرها أنظمة COBOL على الحواسيب المركزية (Mainframe).

هذه ليست مشكلة نظرية. في البحرين، حيث تتسارع مشاريع التحول الرقمي في البنوك وتزداد المنافسة مع شركات التكنولوجيا المالية (FinTech)، يصبح السؤال العملي: كيف نحصل على ذكاء اصطناعي “ينتج قيمة” إذا كانت بياناتنا موزعة بين أنظمة قديمة وجزر معلومات وإجراءات تشغيل مصممة لعصر مختلف؟

في هذه المقالة ضمن سلسلة «كيف يُحوّل الذكاء الاصطناعي قطاع الخدمات المالية والتكنولوجيا المالية في البحرين»، سأطرح زاوية واضحة: أنظمة COBOL ليست “عدوًا” للتحول الرقمي—هي قلب العمليات المصرفية—لكن يجب أن تتصل بالعالم الحديث بشكل صحيح.

لماذا ما زالت أنظمة COBOL قلبًا نابضًا في البنوك؟

الجواب المباشر: لأنها تشغّل الأشياء التي لا يمكن للبنك أن يخطئ فيها—الحسابات، التسويات، القيود المحاسبية، الرواتب، الحوالات، وإجراءات نهاية اليوم. كثير من هذه الأنظمة استمرت لأنها مستقرة، دقيقة، ومُجرّبة تحت ضغط ملايين المعاملات.

في الواقع، استمرار COBOL ليس “عنادًا تقنيًا”، بل قرار تشغيلي: البنوك تُدار بمنطق المخاطر. تغيير نظام أساسي يعالج أرصدة العملاء ليس مثل تحديث تطبيق للهواتف. أي خطأ صغير قد يتحول إلى أزمة ثقة.

ما الذي تغيّر في 2026؟

الذي تغيّر هو توقعات العملاء والجهات الرقابية وسرعة السوق. في البحرين—كمركز مالي إقليمي—أصبح معيار الخدمة أعلى:

• تجربة رقمية متكاملة (فتح حساب/اعرف عميلك/دعم فوري)
• رصد احتيال أسرع مع انخفاض الإنذارات الكاذبة
• تسعير ائتماني أدق، خصوصًا لشرائح الشركات الصغيرة والمتوسطة

هذه القدرات تعتمد على الذكاء الاصطناعي… والذكاء الاصطناعي يعتمد على تدفق بيانات موثوق من الأنظمة الأساسية، سواء كانت COBOL أو غيرها.

جملة قابلة للاقتباس: لا توجد “استراتيجية ذكاء اصطناعي” ناجحة في بنك بدون استراتيجية بيانات تربط الأنظمة الأساسية بالعالم الرقمي.

الذكاء الاصطناعي في البنوك: المشكلة ليست النموذج، بل البيانات

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

عندما تُبنى بيانات المعاملات التاريخية على بنية قديمة، تظهر تحديات عملية مثل:

• بيانات غير موحّدة: نفس العميل قد يظهر بأكثر من معرّف عبر أنظمة مختلفة.
• نقص السياق: السجل المالي موجود، لكن السبب/المنتج/القناة غير واضح.
• تأخر التحديث: بيانات تُحدّث بنهاية اليوم بدلًا من الزمن الحقيقي.
• صعوبة الاستخراج: البيانات موجودة لكنها مقفلة في ملفات وترميزات وإجراءات قديمة.

مثال بحريني واقعي (سيناريو عملي)

تخيل بنكًا في البحرين يريد إطلاق مساعد ذكي داخل التطبيق يجيب عن: “لماذا تم رفض بطاقتي؟” أو “كم متبقي من حدّي الائتماني؟”. إن كان قرار الرفض أو تحديث الحد يحدث داخل نظام أساسي قديم ويُرحَّل للتطبيق بعد ساعات، فالمساعد الذكي سيبدو “غبيًا” حتى لو كان النموذج اللغوي ممتازًا.

الذكاء الاصطناعي هنا لا يفشل لأنه لا يفهم اللغة، بل لأنه لا يملك البيانات الصحيحة في الوقت الصحيح.

تحديث الأنظمة القديمة: لا تُسقط القلب… ابنِ حوله

الجواب المباشر: أفضل نهج في البنوك ليس الاستبدال الشامل (Big Bang)، بل “التحديث التدريجي” الذي يحافظ على استقرار النظام الأساسي ويضيف طبقات حديثة حوله.

في بيئة حساسة مثل الخدمات المالية في البحرين، الاستبدال الكامل قد يرفع المخاطر والتكاليف ويُطيل الزمن. البديل الأكثر واقعية هو “تحديث دون كسر التشغيل”.

1) طبقة APIs فوق الأنظمة الأساسية

إنشاء واجهات برمجية (APIs) آمنة يتيح للتطبيقات الحديثة—ولأنظمة الذكاء الاصطناعي—الوصول المنضبط للبيانات والوظائف (مثل الاستعلام عن الرصيد، أو حالة معاملة) دون العبث بالنظام الأساسي.

ما الذي يكسبه البنك؟

• تقليل الاعتماد على تكاملات قديمة نقطية (Point-to-Point)
• تسريع بناء المنتجات الرقمية
• حوكمة أفضل للوصول للبيانات

2) بث الأحداث والبيانات شبه الفورية

بدل انتظار دفعات نهاية اليوم، يمكن اعتماد نمط Event Streaming لالتقاط “أحداث” المعاملات عند حدوثها (عملية سحب، تحويل، تغيير عنوان، إلخ). هذا يفتح الباب لتطبيقات ذكاء اصطناعي لحظية مثل:

• رصد الاحتيال في وقت العملية، لا بعدها
• توصيات مخصّصة أثناء رحلة العميل
• تنبيهات ذكية لإدارة التدفق النقدي

3) بحيرة بيانات/مستودع حديث مع حوكمة صارمة

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

• قاموس بيانات موحد (Data Dictionary)
• إدارة جودة البيانات (DQ rules)
• إدارة موافقات الوصول (Role-based access)

رأيي بصراحة: كثير من المؤسسات تبني “بحيرة بيانات” قبل أن تتفق داخليًا على تعريف “العميل النشط” أو “المعاملة المكتملة”. ثم تتفاجأ بأن التحليلات متضاربة.

كيف يترجم هذا إلى حالات استخدام ذكاء اصطناعي في البحرين؟

الجواب المباشر: عندما تُفتح بيانات الأنظمة الأساسية بشكل منضبط، يمكن للذكاء الاصطناعي تقديم قيمة واضحة في ثلاث جبهات: المخاطر، التجربة، والكفاءة.

1) رصد الاحتيال وخفض الإنذارات الكاذبة

بدل الاعتماد على قواعد ثابتة فقط، يمكن لنماذج تعلم الآلة تحليل أنماط إنفاق العميل وسلوكه عبر القنوات. القيمة هنا ليست “اكتشاف المزيد” فقط، بل تقليل الإنذارات الخاطئة التي ترهق فرق المخاطر وتزعج العملاء.

شرط النجاح: بيانات معاملات دقيقة وسياقية، وتغذية شبه فورية.

2) ائتمان أذكى للشركات الصغيرة والمتوسطة

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

• بناء نماذج مخاطر تعتمد على تدفق نقدي ومعاملات فعلية
• تسريع الموافقات مع ضوابط واضحة
• تسعير أكثر عدالة بحسب السلوك الحقيقي لا “الانطباع الورقي” فقط

شرط النجاح: ربط بيانات الحسابات/الفواتير/التحويلات عبر الأنظمة القديمة والحديثة.

3) خدمة عملاء آلية… لكن مرتبطة بالعمليات الأساسية

روبوت محادثة لا يستطيع تنفيذ “تجميد بطاقة” أو تتبع “حوالة محلية/دولية” ليس مساعدًا—هو واجهة أسئلة شائعة. عندما تتوفر APIs على الأنظمة الأساسية، يصبح بإمكان المساعد الذكي:

• تنفيذ إجراءات محددة مع تحقق أمني
• تلخيص سبب مشكلة العميل من سجلات متعددة
• تصعيد ذكي لموظف مع “ملف سياقي” يقلل زمن المكالمة

خارطة طريق عملية (90 يومًا) للبنوك وشركات الفنتك

الجواب المباشر: ابدأوا بمسح البيانات والواجهات، ثم نفّذوا حالة استخدام واحدة تُقاس، وبعدها وسّعوا التكامل تدريجيًا.

إليك خطة مختصرة قابلة للتنفيذ خلال 90 يومًا (بدون وعود غير واقعية):

1. الأسبوع 1–2: جرد الأنظمة والبيانات

   • ما مصادر بيانات المعاملات؟ أين يوجد “مصدر الحقيقة”؟
   • ما الحقول الحساسة؟ ومن يملكها؟

2. الأسبوع 3–4: اختيار حالة استخدام واحدة ذات عائد واضح

   • مثال: تنبيه احتيال لحظي لقناة واحدة، أو مساعد دعم لعملية محددة (تتبع حوالة).

3. الأسبوع 5–8: بناء طبقة تكامل آمنة

   • API/بوابة وصول + سجلات تدقيق + سياسات صلاحيات.

4. الأسبوع 9–12: تشغيل تجريبي وقياس

   • مؤشرات مقترحة:
     • زمن الاستجابة (Latency)
     • نسبة الأخطاء في البيانات
     • خفض الإنذارات الكاذبة
     • رضا العملاء عن الخدمة الرقمية

مقياس واقعي أحبّه: “هل أصبح قرارنا أسرع وأدق وقابلًا للتفسير؟” إذا لا، فالمشكلة غالبًا في البيانات أو التكامل، لا في الذكاء الاصطناعي.

أسئلة شائعة يطرحها التنفيذيون (وإجابات مختصرة)

هل يجب التخلص من COBOL لكي نستخدم الذكاء الاصطناعي؟

لا. الأولوية هي فتح قنوات وصول حديثة وآمنة للبيانات والوظائف، ثم تحديث ما يلزم تدريجيًا.

ما أكبر مخاطرة عند ربط الأنظمة القديمة بالذكاء الاصطناعي؟

الحوكمة والخصوصية: إذا توسّع الوصول للبيانات دون ضوابط، ستزيد مخاطر التسريب وسوء الاستخدام. الحل: صلاحيات دقيقة، سجلات تدقيق، وتقليل البيانات المتاحة للنموذج إلى الحد الضروري.

ما الخطأ الأكثر شيوعًا في مشاريع الذكاء الاصطناعي المصرفية؟

بناء نموذج “جميل” في بيئة معملية دون أن يكون هناك خط إنتاج بيانات (Data Pipeline) قابل للاعتماد داخل التشغيل اليومي.

أين تتجه البحرين في 2026؟

الجواب المباشر: البنوك التي ستربح ليست التي تتحدث عن الذكاء الاصطناعي أكثر، بل التي تنظّم بياناتها وتُحدّث تكاملها مع الأنظمة الأساسية بأقل مخاطرة وأعلى انضباط.

البحرين لديها عناصر قوة واضحة: منظومة مالية نشطة، حضور قوي للتكنولوجيا المالية، واهتمام متزايد بتجارب رقمية متقدمة. لكن الذكاء الاصطناعي في الخدمات المالية لن يصبح “تشغيليًا” على نطاق واسع إلا عندما تُحل العقدة الخلفية: ربط الأنظمة القديمة—بذكاء—بالطبقات الحديثة.

إذا كنت تقود مبادرة ذكاء اصطناعي في بنك أو شركة فنتك في البحرين، ابدأ من سؤال بسيط لكنه حاسم: هل بياناتنا قابلة للاستهلاك الآمن وفي الوقت المناسب؟ الإجابة على هذا السؤال هي التي تحدد إن كان الذكاء الاصطناعي سيبقى عرضًا تجريبيًا… أو يتحول إلى قيمة يومية يشعر بها العميل.