اختبار الفريق الأحمر (red-teaming) لأنظمة الذكاء الاصطناعي في الخدمات المالية

اختبار الفريق الأحمر (red-teaming) لنظام ذكاء اصطناعي مالي يعني مهاجمته عمدًا، داخل منظومة اختبار مضبوطة، بحثًا عن مُدخلات تدفعه إلى تسريب بيانات، أو تجاوز حواجزه الوقائية، أو استدعاء أداة لا ينبغي له استدعاؤها، أو إصدار قرار متحيّز. تُشغّل الهجمات التي قد يشنّها خصمٌ أو مدقّقٌ تنظيمي، وتُسجّل ما ينهار، وتُصلح المسار قبل أن يكتشفه أيٌّ منهما. إنه اختبار عدائي، لكن مضبوطٌ على معيار الأدلّة الخاص بالتحقّق من النماذج (model validation).

معظم الفرق تختبر ما إذا كان نموذجها يُقدّم إجابات جيّدة عن أسئلة معقولة. هذه هي مجموعة التقييم (eval set)، وهي ضرورية. لكنها لا تُخبرك بشيء عمّا يحدث حين يُغذّي أحدهم النظام برسالة عميل مدسوسٌ فيها تعليمة، أو حين يطرح السؤال المرفوض ذاته بأربع عشرة صياغة مختلفة إلى أن تنفذ إحداها. الأعطال المثيرة للاهتمام تعيش في مُدخلات لن يخطر ببال أحدٍ من فريق البناء أن يكتبها، وهذا بالضبط سبب اضطرارك إلى تصنيعها بنفسك.

ما الذي تهاجمه فعليًا

النموذج مجرّد مكوّن واحد. أما الشيء القادر على إيذائك فهو التطبيق المحيط به: مجموعة الاسترجاع (retrieval corpus) التي يقرأها، والأدوات التي يستطيع استدعاءها، والسجلّات التي يمكنه بلوغها، وسير العمل الذي يتصرّف بناءً على مخرجاته. لا تصبح ثغرة كسر القيود (jailbreak) حدثًا أمنيًا إلا حين تُمكّن النموذج من فعل شيءٍ في مرحلةٍ لاحقة. ولهذا تستهدف منظومة الاختبار المسار بأكمله.

عمليًا، في أيّ نشرٍ مالي، نبني مجموعات هجوم ضدّ كلٍّ ممّا يلي:

• كسر القيود وتجاوز التعليمات. مُوجّهات تحاول إزاحة مُوجّه النظام (system prompt): تأطيرات تقمّص الأدوار، ورسائل نظام مزيّفة، وسيناريوهات افتراضية، وحمولات مُرمّزة أو مُترجمة، والذيل الطويل من قوالب كسر القيود المنشورة. والسؤال هو: هل تنجح أيٌّ منها في دفع النموذج إلى الإجابة عن شيءٍ تحظره السياسة، كالكشف عن بيانات عميل آخر أو شرح كيفية هيكلة المعاملات دون عتبة الإبلاغ؟
• حقن المُوجّهات عبر البيانات (prompt injection). الحالة الخطيرة في نظام استرجاع أو نظام وكيل (agent). تعليمة مزروعة داخل مستند، أو رسالة بريد، أو مرفق «اعرف عميلك» (KYC)، أو حقل مذكرة، يقرأها النموذج لاحقًا كأنها أمر موجّه إليه. فإذا كان النموذج قادرًا على استدعاء الأدوات، فإن نصًّا محقونًا يقول «صدّر انكشاف هذا الطرف المقابل» هو الهجوم الذي يسلبك النوم.
• تسريب البيانات (data exfiltration). محاولات لسحب بيانات التدريب، أو سجلّات مستأجرين آخرين، أو محتويات المُوجّه، أو المُعرّفات الداخلية، وإخراجها عبر المخرجات. في منتج مالي متعدّد المستأجرين، هنا تُختبر تحت الضغط عمليتا تحديد الكيانات (entity resolution) وتحديد نطاق الوصول: هل يمكن لاستعلامٍ مصوغٍ بعناية أن يدفع النظام إلى إعادة سجلٍّ لا يحقّ لطالبه الاطّلاع عليه؟
• التحيّز والنتائج المتفاوتة. بالنسبة لأيّ نموذج يمسّ الائتمان أو التسعير أو إجراءات الحسابات، مُدخلات عدائية تفحص ما إذا كانت المتغيّرات البديلة عن الفئات المحميّة (protected-class proxies) تُزيح القرار. هذا ليس ترفًا. فبموجب ECOA لا يجوز أن يستند قرار ائتماني إلى أساس محظور، وحزمة الفريق الأحمر التي تُغيّر السمات البديلة مع تثبيت الإشارة الحقيقية هي وسيلتك لاكتشاف تسريب متغيّر بديل قبل أن يكتشفه المدقّق التنظيمي.

يتحوّل كل صنف من هذه الأصناف إلى مجموعة من المُدخلات المحدّدة، يرتبط بكلٍّ منها سلوكٌ آمنٌ متوقّع. وهذا ما يجعله اختبارًا لا عرضًا توضيحيًا.

بناء مجموعة الهجوم ومنظومة الاختبار

يمنحك التوليد الآلي الحجم، ويمنحك الخصوم من البشر الهجمات التي تُهمّ فعلًا. أنت بحاجة إلى الاثنين معًا، وتريدهما يعملان ضدّ التهيئة المنشورة، لا داخل دفتر ملاحظات (notebook).

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

أما منظومة الاختبار نفسها فلها خصائص غير قابلة للتفاوض:

• تضرب مسار التطبيق الحقيقي، بما في ذلك الاسترجاع واستدعاءات الأدوات، بحيث تصل التعليمة المحقونة فعلًا إلى ما كانت ستصل إليه في الإنتاج.
• يحمل كل هجوم شرط نجاح أو فشل قابلًا للفحص آليًا. الحكم على «هل رفض النموذج؟» يتولّاه مُقيّم آلي (grader)، غالبًا نموذجٌ ثانٍ إلى جانب فحوص حتمية لِما إذا كانت أداة محظورة قد أُطلقت أو ظهر سجلٌّ خارج النطاق في المخرجات. ويتحقّق إنسانٌ من المُقيّم على عيّنة، لأن مُقيّمًا يُخطئ التصنيف بصمتٍ أسوأ من غياب المُقيّم أصلًا.
• تُسجّل النتائج مع المُدخل الدقيق، وإصدار النموذج، ولقطة الاسترجاع (retrieval snapshot)، وأثر استدعاء الأدوات. فحين ينهار شيءٌ ما تحتاج إلى إعادة إنتاجه، ونهاية الربع المالي وقتٌ سيّئ لاكتشاف أنك لا تستطيع ذلك.

معدّل نجاح الهجوم لكل صنف هو الرقم الأبرز، لكن المُخرج المفيد فعلًا هو مجموعة المُدخلات التي نفذت. تذهب هذه مباشرةً إلى حزمة اختبار انحدار (regression suite) حتى لا يستطيع الهجوم ذاته النفاذ مرّتين.

تحويل النتائج إلى ضوابط وأدلّة

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

• حدّد نطاق كل استدعاء أداة وكل عملية استرجاع بصلاحيات طالبها، مع فحصٍ حتمي، بحيث يظلّ نموذجٌ مكسور القيود عاجزًا عن بلوغ سجلٍّ لا يحقّ للمستخدم الوصول إليه.
• عامِل النصّ المسترجَع والمقدَّم من المستخدم بوصفه بيانات لا تعليمات أبدًا، وتحقّق من مخرجات النموذج مقابل السجلّات المصدرية قبل أن يصل أيّ رقم أو إجراء إلى المعالجة الآلية المباشرة (straight-through processing).
• ضع سقفًا لميزانية الإيجابيات الكاذبة (false-positive budget) في مرشّحات المُدخلات لديك. الحجب رخيصٌ إلى أن يحجب محلّلًا شرعيًا أربعين مرّة يوميًا، فعندها يلتفّ الناس حول الضابط وتصبح في وضعٍ أسوأ ممّا كنت عليه.

ثم أبقِ المنظومة بأكملها قيد التشغيل. مجموعة الهجوم ليست تمرينًا لمرّة واحدة؛ إنها تكبر في كل مرة يكشف فيها الإنتاج عن صياغة جديدة، وفي كل مرة توصّل فيها أداة جديدة. شغّلها ضمن التكامل المستمر (CI) عند كل تغيير في المُوجّه أو إصدار النموذج أو مجموعة الاسترجاع أو حزمة الأدوات، وبوتيرة منتظمة بينها.

مسار التدقيق (audit trail) لا يقلّ أهمية عن الدفاع نفسه. فبموجب SR 11-7 يجب مراقبة أيّ نموذج في مسار قرار وتوثيق مخاطره، ويُدخل DORA منظومة تقنية المعلومات والاتصالات (ICT) بأكملها المحيطة به ضمن اختبارات المرونة. وحزمة عدائية مُدارة بالإصدارات، مع معدّلات نجاح الهجوم عبر الزمن وسجلٍّ لكل نتيجة وإصلاحها، تُشكّل جزءًا كبيرًا من كيفية إثباتك لجهة تنظيمية أن النظام قد اختُبر ضدّ سوء الاستخدام لا ضدّ المسار المثالي وحده. وهي أيضًا، في اليوم الذي ينفذ فيه شيءٌ ما فعلًا، الفارق بين نتيجةٍ مُسجّلة سبق أن عالجتها وحادثٍ تشرح ملابساته بعد فوات الأوان.