سيادة AI
مقالتنفيذي

42 خطرًا للذكاء الاصطناعي في البنوك: من التصنيف إلى سجل مخاطر قابل للتدقيق

نُشر 20 أكتوبر 2026

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

⚡ الخلاصة السريعة

هذه القائمة تصنيف تحليلي وليست معيارًا رسميًا أو قائمة امتثال ملزمة.

42 خطرًا للذكاء الاصطناعي في البنوك: من التصنيف إلى سجل مخاطر قابل للتدقيق

المصدر وحدود الاستخدام

تستعمل هذه المادة قائمة «42 AI Risks Banking Leaders Must Control» باعتبارها تصنيفًا تحليليًا إلى ست مجموعات، كل منها تضم سبعة عناصر. ليست هذه القائمة معيارًا رسميًا من OWASP ولا يجوز وصفها بأنها جميع مخاطر الذكاء الاصطناعي التي يجب على كل بنك تسجيلها. تركز قوائم OWASP الرسمية على أمن تطبيقات النماذج اللغوية وتطبيقات الوكلاء. أما البنك فيحتاج إضافة مخاطر نابعة من الأغراض الفعلية للأنظمة، والمنتجات المصرفية، وتكاملات البيانات، وحقوق العملاء، وسلطة تنفيذ المعاملات، والمتطلبات التنظيمية الخاصة بالاختصاص القضائي. العدد المتساوي في الجدول مفيد للتذكر، لكنه لا يدل على تساوي المخاطر في الشدة أو الاحتمالية أو كلفة الضبط. لا تُستعمل الخانات الـ42 كسجل امتثال ولا كمصفوفة أوزان جاهزة. الهدف تحويل كل مفهوم إلى سيناريو يمكن اختباره وربطه بضابط ومالك ودليل وقرار قبول خطر متبقٍ.

الوحدة الصحيحة لتقييم المخاطر

يبدأ التقييم من «نظام محدد يستخدم في عملية مصرفية محددة». يجب توثيق المعرف الثابت للنظام، والمهمة، والمستخدمين، وأصحاب القرار، والمزود، والنموذج وإصداره، والبيانات والسجلات الداخلة، وقناة النشر، والمخرجات والجهات التي تستقبلها، ونطاق وصول الأدوات وواجهات API، وما إذا كان النظام يوصي أو يقرر أو ينفذ إجراءً. استعمال نموذج واحد في تلخيص مراسلات عميل لا يعادل استعماله في اقتراح حد ائتماني أو توجيه تنبيه احتيال أو إجراء تغيير في حالة معاملة. يختلف أثر الخطأ بحسب درجة اعتماد الموظف على المخرجات وبحسب قدرة النظام على تحويلها إلى فعل. لا يمكن تقييم خطر Excessive Agency قبل معرفة الصلاحيات الفعلية وهوية الحساب التقني وحدود التنفيذ، ولا يكفي تحديدها من نص التعليمات داخل الـPrompt. لا تُعتمد درجة خطر واحدة لجميع استخدامات النموذج لمجرد أنها تشترك في المزود. ينبغي أن يسمح السجل بارتباط استخدامات عدة بخطر واحد وباشتراك ضوابط عدة في معالجة الخطر نفسه.

صياغة السيناريو بدلاً من العناوين

مصطلحات «التهديد» و«الثغرة» و«الحدث» و«الأثر» ليست مترادفات. مثال: غياب فحص هوية المسترجع على مستوى المستند ثغرة في التصميم؛ محاولة استرجاع محتوى عميل آخر قد تكون مسار تهديد؛ تقديم المساعد بيانات غير مخوّل بها هو حدث خطر؛ وانكشاف معلومات مصرفية وخرق التزامات الخصوصية آثار محتملة. لا تسجّل المؤسسة أربعة صفوف غير مترابطة لمجرد أن لكل واحد اسمًا مختلفًا. الصياغة الأفضل: عندما يسترجع مساعد الامتثال وثيقة معدلة بواسطة جهة غير موثوقة ويعامل تعليماتها كمصدر أوامر، قد يستدعي أداة داخلية خارج المهمة المفوضة، مما قد يغيّر حالة المراجعة أو يكشف معلومات حساسة. هذه الصياغة تحدد المصدر والظرف والفعل والأثر فتجعل اختبار الضبط ممكنًا. أما كتابة «Prompt Injection / High» فلا تعطي المدقق طريقة للتحقق ولا صاحب النظام إجراءً واضحًا لتقليل الخطر. يجب تسجيل الافتراضات ودرجة الثقة في التقدير ومصدر بيانات احتمالية وقوع الحدث؛ لا تُختلق نسب مئوية دقيقة من دون أساس تجريبي.

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

تجمع الصورة جودة البيانات ونسب المصدر وتسميم البيانات والتعرض للخصوصية وقيود المتجهات والتضمين والانحراف والإفشاء الحساس. تدهور جودة البيانات قد يكون نتيجة نقص أو تأخير أو خطأ غير عدائي. أما التسميم فيتعلق بمحاولة التأثير الخبيث في المادة المستخدمة في التدريب أو الاسترجاع أو السياق. التمييز ضروري لأن الضوابط تختلف: تدقيق جودة المصدر وحفظ النسب وضبط صلاحيات التغيير ومراقبة بيانات الإدخال مقابل اكتشاف التعديلات غير المصرح بها وإثبات سلامة خطوط المعالجة. في نظام RAG يستخدم لتجهيز ردود مصرفية لا يكفي تحصين النموذج؛ يجب تقييد المستندات والمقاطع المسترجعة وفق هوية المستفيد وسياق المؤسسة على مستوى البحث والتجميع والإجابة. قد تكون المقتطفات صحيحة دلاليًا ولكنها تخص مستخدمًا آخر. تشمل الأدلة اختبارات عبور حدود الوصول، وسجلات الفهرسة، وتوثيق معالجة البيانات، ونتائج مراجعة التغييرات، ونتائج قياس انحراف الأنماط، مع مراعاة سرية سجلات العملاء. أي ادعاء بأن مخزن المتجهات «آمن» يحتاج إثباتًا لآلية تفويض كل استرجاع، لا مجرد وصف خصائص مزود الخدمة.

مخاطر النماذج: الهلوسة ليست المشكلة الوحيدة

تضم المجموعة الهلوسة والتحيز والانحراف وقصور التفسير والهشاشة وضعف التقييم وسوء معالجة المخرجات. تستطيع منظومة مصرفية تقديم نص لغوي واثق لكنه خاطئ أو متحيز، كما قد تنتج إجابة دقيقة ثم يحوّلها التطبيق إلى إجراء لا يتوافق مع سلطة المستخدم. لذلك يجب الفصل بين أداء النموذج وبين سلامة النظام الكامل. في تحليل ملفات الائتمان، لا تكفي نسبة صحة إجمالية؛ يلزم قياس الحالات الحدية وتحليل تغير البيانات وتوثيق النسخ والعتبات والحالات المستبعدة وحدود التعميم. يجب تحديد متى يكون المخرج معلومة للمساعدة ومتى يؤثر في القرار وما آلية مراجعة القرار والاعتراض عليه. تشمل الضوابط اختبارات ما قبل الإنتاج، والتقييم بعد تغير النموذج، والمراقبة المستمرة، والتوثيق الموجه لحالة الاستخدام، والتحقق من مخرجات الأوامر قبل تمريرها إلى أنظمة أخرى. الدليل المقبول يحتوي تاريخ التقييم وبيئة الاختبار والعينات والنتائج والإخفاقات والمعيار الذي اعتُمد في قبول إطلاق النظام. مجرد وجود «اختبار أداء» بلا تفاصيل لا يبرهن السيطرة على المخاطر.

مخاطر الوكلاء: من صحة الإجابة إلى سلطة الإجراء

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

المخاطر الأمنية وتكاملات الأطراف الخارجية

تشمل إساءة استخدام واجهات API وسرقة الرموز والتعرض للأسرار وسلسلة التوريد واستخراج النموذج وتسرب System Prompt وانعدام أمن الاتصالات بين الوكلاء. لا ينبغي وضع كلمات مرور أو مفاتيح سرية داخل التعليمات باعتبارها منطقة سرية يضمن النموذج عدم الكشف عنها. الفصل بين إدارة الأسرار والسياقات اللغوية وفرض الصلاحيات عند واجهات التنفيذ وتحديد حدود استخدام الرموز وتدويرها أساسات تشغيلية. تزداد أهمية سلسلة التوريد عندما يعتمد التطبيق على مكتبات وخوادم أدوات وموصلات بيانات ونماذج خارجية ومزودين فرعيين. يجب فحص هوية كل مكوّن، وإصداره، وحقوق الوصول، والتغييرات المسموح بها، وكيفية إيقافه أو استبداله. يمكن أن تشمل أدلة الضبط اختبارات إساءة استعمال الرمز المقيّد، وسجلات رفض التفويض، وآثار فحص المكونات، وإثبات إخفاء الأسرار، ونتائج اختبارات الاتصال بين الوكلاء. يجب ألا تتحول سجلات الاختبار أو التحليل إلى مستودع يجمع بيانات عملاء أو رموزًا حقيقية قابلة للاستغلال.

المخاطر التشغيلية والاعتمادية

تتضمن المجموعة مخاطر التأخر والاستهلاك غير المحدود وفجوات المراقبة والتتبع والفشل المتسلسل وصعوبة التراجع والتركيز لدى الموردين. قد يكون النموذج دقيقًا وآمنًا عند الاستخدام المعتاد لكنه يفشل عندما يضاعف أحد التدفقات عدد استدعاءات API أو يعلق عند انقطاع خدمة خارجية أو يعيد تنفيذ معاملة غير قابلة للتكرار. يجب تصميم حدود زمنية وتكلفة ومعدلات استدعاء وآليات محكومة لإعادة المحاولة وربط جميع الخطوات بمعرف تتبع. في سلسلة وكلاء مصرفية، قد يستلم وكيل ثانٍ نتيجة أول خاطئة ويعاملها كحقيقة ثم ينقلها إلى مرحلة التنفيذ. نقطة التحقق الفاصلة قبل الإجراء أهم من اعتماد كل وكيل على الثقة بالآخر. لا تكون جميع العمليات قابلة للتراجع؛ بعضها يحتاج تعويضًا تشغيليًا أو إيقافًا وقائيًا وتصعيدًا. الاعتماد على مزود واحد للنموذج أو الحوسبة أو الخدمة الوسيطة قد يكون نقطة فشل مركزة حتى مع وجود التزام تعاقدي بالتوافر. تُختبر القدرة على العمل في وضع التدهور وخطط الاستعادة وتوثيق الزمن الفعلي للانقطاع، وليس الاكتفاء بخطة مكتوبة أو مؤشرات تشغيلية مأخوذة من بيئة تطوير.

الحوكمة والإشراف والمساءلة

تضم المجموعة ملكية القرار والرقابة البشرية والامتثال وفجوة التدقيق والملكية الفكرية وانحراف السياسة وShadow AI. الملكية لا تتحقق بإضافة اسم إلى جدول المسؤوليات فقط؛ يجب معرفة من يملك اعتماد حالة الاستخدام وحدود السلطة وقبول الخطر المتبقي وإيقاف نظام خرج عن حدود التفويض. المراجعة البشرية لا تصبح فعالة بمجرد مطالبة الموظف بالضغط على «موافق». يحتاج المراجع إلى معلومات عن أساس التوصية وقيود النظام وإمكانية الاعتراض ووقت كافٍ وصلاحية حقيقية لإيقاف القرار أو طلب التحقق. يجب فحص أثر ضغط العمل وتحيز الأتمتة وتوثيق أسباب التدخل والتجاوز. كذلك تحتاج المؤسسة إلى جرد استخدامات الذكاء الاصطناعي المصرح بها وغير المسجلة، بما فيها مزايا AI المضمنة في منتجات موردي البرمجيات. لا يجوز أن يصبح عدم التسجيل وسيلة لتجنب التقييم، ولا أن تصبح عملية الموافقة معقدة لدرجة تشجيع الاستخدام الخفي. تربط الحوكمة بين جرد الأنظمة ومراجعة الموردين والامتثال والتدقيق والحوادث والدروس المستفادة، مع فصل المسؤولية التشغيلية عن المراجعة المستقلة في خطوط الدفاع.

سجل المخاطر والضوابط والأدلة

الحد الأدنى للسجل المؤسسي هو: معرف السيناريو؛ النظام والاستخدام؛ العملية المصرفية؛ الدولة والالتزامات ذات العلاقة؛ البيانات والأدوات؛ وصف السبب والحدث والأثر؛ المالك الفعلي؛ المخاطر المتأصلة؛ الضوابط الوقائية والكاشفة والتصحيحية؛ مالك كل ضابط؛ اختبار الضبط؛ الدليل ومصدره وتاريخه؛ حدود صلاحية الاختبار؛ القصور المفتوح؛ مستوى الخطر المتبقي؛ قرار المعالجة والجهة التي أجازته؛ موعد إعادة التقييم. لا يصح تخفيض الخطر المتبقي لأن الوثيقة تقول «الضابط مطبق». يجب التمييز بين الضابط المصمم والمطبق والمختبر والفعال ضمن نطاق معلوم. عند الارتباط بقرار مصرفي حساس قد يكون وجود صلاحية تنفيذ غير مأذون بها شرط إيقاف بغض النظر عن مجموع نقاط الخطر. كما لا يصح توزيع الاحتمالية بالتساوي بين البيانات والنماذج والوكلاء والأمن والتشغيل والحوكمة. تُعد الأولوية من شدة الأثر وحجم التعرض وإمكانية التنفيذ وفعالية الكشف وقابلية التراجع وأهمية العملية، مع إعلان ما لا يمكن قياسه بثقة. لهذا لا يُنشأ «مؤشر نضج 42/42» بوصفه نتيجة ضمان معتمدة دون منهج تقييم متحقق.

أمثلة الاختبار والتتبع

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

المراجع والالتزامات التنظيمية

يوفر NIST AI RMF بنية تفسيرية لوظائف GOVERN وMAP وMEASURE وMANAGE، ويمثل ISO/IEC 42001 مرجعًا لنظام الإدارة، بينما يدعم ISO/IEC 23894 سياق إدارة مخاطر الذكاء الاصطناعي. تتناول OWASP Top 10 for LLM Applications 2025 وOWASP Top 10 for Agentic Applications 2026 فئات أمنية متخصصة، لكنها لا تجعل التصنيف المتداول المؤلف من 42 بندًا التزامًا رسميًا. لا يجوز إسناد أي بند إلى بنك مركزي عربي دون التحقق من نص المصدر وتاريخ نفاذه والجهات الخاضعة ونطاق الاستخدام. تختلف متطلبات المؤسسات المالية بين البلدان والأنشطة، وقد تكون توصية دولية جيدة من دون أن تصبح التزامًا محليًا ملزمًا. ينبغي فصل «تحليل سيادة» و«ربط تفسيري» و«متطلب رسمي مؤكد». يراجع الفريق مصادره عند تحديث المعايير، ويعيد فحص العلاقات قبل إعادة نشر الادعاءات. الهدف إنشاء مرجع يُحدّث ويُدقّق، لا تثبيت قائمة دعائية قد تفقد سياقها بعد أشهر.

انضم لمجتمع سيادة AI التفاعلي على واتساب

كن جزءًا من مجتمع المهتمين بحوكمة الذكاء الاصطناعي وسيادته، وتابع النقاشات والمستجدات.

انضم الآن