الصيرفة المفتوحة والذكاء الاصطناعي في عُمان: حوكمة البيانات وواجهات API ومخاطر الطرف الثالث

الصيرفة المفتوحة والذكاء الاصطناعي في عُمان: حوكمة البيانات وواجهات API ومخاطر الطرف الثالث

ما الذي ينظمه إطار الصيرفة المفتوحة في عُمان؟

أصدر البنك المركزي العُماني القرار رقم 26/2025 بإصدار الإطار التنظيمي للصيرفة المفتوحة، ودخل القرار حيز النفاذ في 4 يونيو 2025.

ينص القرار على تطبيق الإطار المرفق على ترخيص وتشغيل الصيرفة المفتوحة.

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

كما يضع الإطار مبادئ الحوكمة السليمة والإدارة الفعالة والاعتبارات التشغيلية والرقابية كمبادئ عامة للتنفيذ.

هذه نقطة البداية القانونية والتنظيمية.

لكن من المهم عدم توسيعها بصورة غير دقيقة:

إطار الصيرفة المفتوحة ليس إطاراً لتنظيم الذكاء الاصطناعي.

في سيادة AI نصنفه باعتباره AI-Relevant Sectoral Regulation: تنظيم قطاعي تصبح له آثار مباشرة على حوكمة AI عندما تدخل بيانات Open Banking أو خدماتها أو مزودوها في دورة حياة نظام ذكاء اصطناعي.

أين يدخل الذكاء الاصطناعي في سلسلة Open Banking؟

يمكن أن تظهر تطبيقات AI فوق بيئة الصيرفة المفتوحة في صور متعددة، مثل:

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

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

لكنه يعني أن استخدام AI لا يلغي الالتزامات والقيود التي تحكم أصل البيانات والوصول إليها والعلاقة مع العميل ومقدم الخدمة.

لذلك تصبح حوكمة AI طبقة فوق مسار تنظيمي قائم، وليست بديلاً عنه.

ارسم سلسلة البيانات قبل تقييم النموذج

في Open Banking قد تمر البيانات عبر عدة أطراف وأنظمة قبل أن تصل إلى نموذج AI.

[ممارسة تنفيذية] يمكن تمثيل المسار بهذه الصورة:

العميل → الموافقة/التفويض → البنك أو المؤسسة المالية → API → مقدم خدمة Open Banking → معالجة البيانات → نظام AI → توصية/تصنيف/قرار → نتيجة للعميل أو المؤسسة

هذا الرسم البسيط يكشف أسئلة لا تظهر إذا بدأ الفريق مباشرة من النموذج:

• من هو مصدر البيانات؟
• بأي صلاحية تم الوصول إليها؟
• ما الغرض الذي تم من أجله الوصول؟
• أي طرف يحتفظ بنسخة؟
• هل تنتقل البيانات إلى مزود نموذج آخر؟
• هل يستخدم النموذج بيانات خاماً أم مشتقة؟
• هل تدخل البيانات في التدريب أو التحسين؟
• من يستطيع رؤية المدخلات والمخرجات؟
• أين يتم تسجيل النشاط؟
• ماذا يحدث عند انتهاء العلاقة أو التفويض؟

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

الموافقة ليست مربعاً واحداً في الواجهة

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

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

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

لذلك:

[ممارسة تنفيذية] يوصى بإنشاء Consent-to-Purpose Traceability يربط بين:

مصدر البيانات → أساس الوصول/الموافقة → الغرض المعلن → استخدام AI → المخرجات → الأطراف التي تصل إليها

الهدف ليس إنشاء نموذج ورقي جديد، بل منع انفصال استخدام AI عن الغرض الذي سمح بوصول البيانات في المقام الأول.

واجهة API ليست مجرد قناة تقنية

في Open Banking، API هي نقطة تنفيذ للحقوق والصلاحيات والتكامل بين الأطراف.

وعندما يستخدم AI البيانات المتدفقة من خلالها، تصبح واجهة API جزءاً من سطح الحوكمة والمخاطر.

[ممارسة تنفيذية] يجب فحص عناصر مثل:

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

هذه ليست قائمة حرفية لمتطلبات AI في إطار CBO، بل ترجمة تشغيلية لمبدأ أن نظام AI لا يمكن أن يكون محكوماً إذا كانت قناة وصوله إلى البيانات غير محكومة.

من API إلى Model: نقطة خروج بيانات جديدة

قد يلتزم التكامل بين البنك ومقدم خدمة Open Banking بضوابط واضحة، ثم تنتقل البيانات بعد ذلك إلى مزود نموذج أو خدمة تحليل خارجية.

هنا تظهر Data Egress Point جديدة.

مثلاً:

Bank → Open Banking API → Service Provider → External AI API

إذا لم توثق المؤسسة الخطوة الأخيرة، فقد تكون خريطة Open Banking سليمة بينما خريطة AI ناقصة.

[ممارسة تنفيذية] يجب توثيق كل نقطة تغادر فيها البيانات البيئة الأصلية إلى مزود أو خدمة أخرى، مع تحديد:

• نوع البيانات.
• سبب الإرسال.
• الحد الأدنى المطلوب.
• موقع المعالجة إن كان معروفاً ومهماً.
• سياسة الاحتفاظ.
• ما إذا كان المورد يستخدم البيانات للتدريب أو تحسين الخدمة.
• subprocessors.
• طريقة الحذف أو الإرجاع.
• السجلات المتاحة للمؤسسة.

هذا الربط مهم بصورة خاصة عندما يكون مزود AI مختلفاً عن مقدم خدمة Open Banking.

مخاطر الطرف الثالث قد تصبح سلسلة من الأطراف

الصيرفة المفتوحة بطبيعتها بيئة مترابطة.

ومع AI قد تصبح السلسلة أطول:

مؤسسة مالية → Open Banking provider → Cloud → AI provider → Subprocessor

كل طبقة يمكن أن تضيف اعتماداً أو معالجة أو نقطة فشل أو تعرضاً للبيانات.

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

[ممارسة تنفيذية] يمكن للعناية الواجبة لموردي AI في هذا السياق أن تشمل:

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

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

ماذا لو استُخدمت البيانات لتدريب نموذج؟

هذه من أكثر النقاط حساسية.

هناك فرق بين:

1. إرسال بيانات إلى نموذج لتنفيذ inference لخدمة محددة.
2. الاحتفاظ بهذه البيانات لأغراض تشغيلية.
3. استخدامها لاحقاً لتحسين خدمة.
4. استخدامها لتدريب نموذج أو ضبطه.
5. دمجها مع بيانات أخرى لبناء ملف أوسع عن العميل.

هذه الأغراض ليست متطابقة.

[ممارسة تنفيذية] يجب ألا تعتمد المؤسسة على وصف عام مثل «نستخدم البيانات لتحسين الخدمة» عندما يكون الاستخدام الفعلي أكثر تحديداً.

يجب أن تعرف:

• هل التدريب يحدث؟
• من يقوم به؟
• على أي بيانات؟
• هل البيانات قابلة لإعادة التعرف؟
• هل يوجد خيار يمنع التدريب؟
• هل يبقى الاستخدام ضمن الغرض المعتمد؟
• ما أثر انتهاء الموافقة أو العلاقة؟

هذا أيضاً موضع تقاطع مباشر مع قانون حماية البيانات الشخصية ولائحته التنفيذية عندما تكون البيانات شخصية.

القرار أو التوصية الآلية تحتاج مسار مساءلة

قد تستخدم المؤسسة AI لإنتاج:

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

لا ينبغي وصف كل مخرج آلي بأنه «قرار آلي قانوني» دون أساس.

لكن كلما زاد أثر المخرج على العميل أو الخدمة، زادت الحاجة إلى معرفة من يملك القرار وكيف يمكن تفسيره ومراجعته والتدخل فيه.

[ممارسة تنفيذية] يمكن توثيق:

AI output → business rule → human/system decision → customer impact → review path

وبذلك لا تختفي المسؤولية بين API ومقدم الخدمة والنموذج والنظام النهائي.

الحد الأدنى من البيانات مهم أيضاً في AI

نماذج AI قد تشجع الفرق على إرسال أكبر كمية ممكنة من البيانات «لتحسين النتيجة».

لكن من منظور الحوكمة، السؤال الأفضل هو:

ما أقل مجموعة بيانات لازمة فعلاً لتحقيق الغرض؟

[ممارسة تنفيذية] يمكن تطبيق data minimization عملياً عبر:

• حذف الحقول غير الضرورية قبل إرسالها للنموذج.
• استخدام معرفات بديلة عندما لا تكون الهوية مطلوبة.
• فصل بيانات التعريف عن البيانات التحليلية.
• منع prompt أو payload من احتواء حقول لا يحتاجها الاستخدام.
• تحديد schemas مسموحة لكل use case.
• مراقبة تغير payload بعد تحديث المنتج.

هذه الممارسات تساعد على تقليل مساحة التعرض إذا وقع خطأ أو اختراق أو سوء استخدام.

السجلات يجب أن تربط الوصول بالاستخدام

في نظام تقليدي قد يسجل API أن مستخدماً أو خدمة طلبت بيانات.

لكن في نظام AI نحتاج أحياناً إلى طبقة إضافية من التتبع.

[ممارسة تنفيذية] سجل قابل للتدقيق يمكن أن يربط:

• الطلب.
• الهوية أو الخدمة التي نفذته.
• نطاق البيانات.
• الغرض أو use case.
• إصدار التكامل.
• النظام أو النموذج الذي استهلك البيانات.
• نتيجة المعالجة.
• الإجراء اللاحق عند الحاجة.

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

الأمن السيبراني لا ينتهي عند API Gateway

حتى لو كانت واجهة Open Banking مؤمنة، يمكن أن تظهر مخاطر جديدة في طبقة AI.

مثلاً:

• تخزين payload في logs غير مناسبة.
• إرسال البيانات إلى أداة AI غير معتمدة.
• تسرب البيانات عبر prompt أو output.
• صلاحيات واسعة لحساب خدمة.
• مفتاح API مكشوف.
• دمج خدمة خارجية دون مراجعة.
• احتفاظ المورد بالبيانات أكثر من المتوقع.

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

ماذا يحدث عند انتهاء الموافقة أو العلاقة؟

هذه نقطة مهمة في تصميم دورة الحياة.

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

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

• هل يتوقف جمع البيانات الجديدة؟
• ماذا يحدث للبيانات الموجودة؟
• هل تبقى features مشتقة منها؟
• هل دخلت في dataset تدريب؟
• هل توجد نسخ لدى طرف ثالث؟
• ما الذي يجب حذفه أو الاحتفاظ به؟
• هل يستطيع النظام مواصلة تقديم توصية اعتماداً على بيانات قديمة؟
• كيف تُحدث الصلاحيات والـtokens؟

هذا هو الفرق بين إدارة اتصال API وإدارة دورة حياة البيانات.

إدارة التغيير في Open Banking + AI

يمكن أن يتغير أي من العناصر التالية:

• إصدار API.
• schema البيانات.
• مقدم الخدمة.
• النموذج.
• prompt.
• قواعد القرار.
• طريقة حساب feature.
• مصدر البيانات.
• سياسة الاحتفاظ.
• subprocessor.
• غرض الاستخدام.

قد يكون كل تغيير صغيراً منفرداً، لكن تراكمه يغير المخاطر.

[ممارسة تنفيذية] يوصى باستخدام trigger-based review عند تغييرات مثل:

• إضافة مصدر بيانات جديد.
• استخدام البيانات لغرض AI جديد.
• الانتقال إلى مزود نموذج جديد.
• إدخال تدريب أو fine-tuning.
• إضافة طرف ثالث جديد.
• تغير جوهري في API أو schema.
• ارتفاع أثر القرار على العميل.

الهدف أن تبقى الموافقة والغرض والمخاطر متوافقة مع النظام الفعلي لا مع التصميم القديم.

حزمة الأدلة المقترحة

لإثبات أن المؤسسة تحكم استخدام AI فوق بيئة Open Banking بصورة عملية، يمكن بناء حزمة أدلة تشمل:

1. وصف use case.
2. مخطط تدفق البيانات.
3. مصدر البيانات وأساس الوصول.
4. الغرض من الاستخدام.
5. خريطة APIs والتكاملات.
6. قائمة الأطراف الثالثة وsubprocessors ذوي الصلة.
7. تقييم مخاطر AI.
8. تقييم المورد.
9. ضوابط الوصول والصلاحيات.
10. سياسة الاحتفاظ والحذف ذات الصلة.
11. سجل التغييرات.
12. أثر تدقيق مناسب.
13. مسار التعامل مع الحوادث.
14. مسؤوليات القرار والمراجعة.
15. دليل مراجعة دورية أو عند حدوث تغيير جوهري.

[ممارسة تنفيذية] هذه ليست قائمة رسمية صادرة عن CBO، وإنما نموذج أدلة تقترحه سيادة AI لترجمة المتطلبات التنظيمية والمخاطر التقنية إلى عناصر قابلة للمراجعة.

نموذج رقابي مختصر

يمكن تلخيص الحوكمة في السلسلة التالية:

Requirement → Data Flow → Purpose → API Control → AI Use → Third Party → Decision/Output → Evidence → Owner → Review Trigger

هذا النموذج يمنع انفصال ثلاث طبقات عن بعضها:

التنظيم المالي، وحوكمة البيانات، وحوكمة الذكاء الاصطناعي.

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

أخطاء يجب تجنبها

أولاً، وصف إطار الصيرفة المفتوحة العُماني بأنه «قانون أو إطار لتنظيم AI».

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

ثالثاً، توثيق البنك وOpen Banking provider مع تجاهل مزود AI أو subprocessors.

رابعاً، اعتبار API قناة تقنية فقط دون ربطها بالصلاحية والغرض والبيانات.

خامساً، إرسال كامل dataset إلى النموذج عندما يحتاج الاستخدام إلى جزء محدود منها.

سادساً، عدم معرفة ما إذا كان مزود AI يحتفظ بالبيانات أو يستخدمها للتدريب.

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

ثامناً، عرض الضوابط التنفيذية المقترحة هنا على أنها متطلبات حرفية للبنك المركزي العُماني.

كيف نقرأ القوة التنظيمية؟

للحفاظ على الدقة:

E1 — صريح: ما يرد فعلاً في قرار CBO رقم 26/2025 والإطار التنظيمي، مثل نطاق الترخيص والتشغيل، حقوق والتزامات الأطراف، الترتيبات المرتبطة بالوصول إلى بيانات العملاء، ومبادئ الحوكمة والإدارة والاعتبارات التشغيلية والرقابية.

E2 — مستنتج بقوة: استمرار أهمية تلك الالتزامات عندما تُستخدم البيانات أو الخدمات ذاتها كمدخل لنظام AI.

E3 — ممارسة تنفيذية: مثل AI use-case register، API-to-model data-flow map، consent-to-purpose traceability، تقييم مورد AI، أو trigger-based review.

E4 — تعزيز عبر أطر أخرى: استخدام أطر AI أو الأمن أو إدارة المخاطر لتحسين النضج، دون تقديمها باعتبارها متطلبات صادرة عن CBO.

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

العلاقة مع قانون حماية البيانات الشخصية

عندما تتضمن بيئة Open Banking بيانات شخصية، لا ينبغي قراءة إطار CBO بمعزل عن قانون حماية البيانات الشخصية العُماني واللائحة التنفيذية حيث تنطبق أحكامهما.

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

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

كما يجب الانتباه إلى أن قانون حماية البيانات الشخصية شهد تعديلاً بالمرسوم السلطاني 68/2026. ولن يفترض هذا المقال تفاصيل أثر ذلك التعديل قبل تحليل نصه الرسمي بصورة مستقلة.

الخلاصة

الإطار التنظيمي للصيرفة المفتوحة في سلطنة عُمان يضع بيئة منظمة لترخيص وتشغيل خدمات Open Banking والوصول إلى بيانات العملاء والعلاقات بين الأطراف.

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

أين تذهب البيانات؟ ما الغرض؟ من يستطيع استخدامها؟ هل تصل إلى مزود AI آخر؟ هل تُستخدم للتدريب؟ كيف تُسجل العمليات؟ ماذا يحدث عند تغير الموافقة أو المورد أو النموذج؟

الإجابة المؤسسية الجيدة لا تبدأ بإضافة «AI Policy» عامة، بل ببناء traceability من العميل والبيانات والغرض إلى الـAPI والنموذج والطرف الثالث والمخرج والدليل.

آخر مراجعة تنظيمية للمحتوى: 9 سبتمبر 2026.