المساءلة تبدأ من مالك الضابط ودليل إعادة الاختبار ولا تنتهي عند إرسال التقرير أو تغيير حالة التذكرة.
من نتيجة Red Teaming إلى مساءلة حقيقية: لماذا يفشل إغلاق المخاطر شكلياً؟
لحظة التسليم ليست نهاية الاختبار
قد ينتهي فريق Red Team من عرض نتائج مهمة GenAI في اجتماع ناجح، ثم يترك التقرير محفوظاً في مستودع ولا يعود أحد إلى شروط الإغلاق. هذا ليس نقصاً إدارياً بسيطاً؛ فقد تظل أداة ذات صلاحية عالية أو مرشح مستندات غير صحيح يعمل حتى بعد صدور وصف دقيق لمشكلته. يناقش OWASP GenAI Red Teaming Manual v1.0 مرحلة Post-Engagement & Remediation ليصل العمل بين الفرق الفنية والدفاعية وعمليات الإصلاح. لا تصبح النتيجة قيمة مؤسسية بمجرد وجود لقطة شاشة، بل عندما يملك شخص محدد علاج السبب في الطبقة الصحيحة، وتصبح هناك وسيلة لإثبات أن السلوك المحظور لم يعد ممكناً ضمن شروط الاختبار. هذه قراءة من سيادة AI للمساءلة والتغيير وليست عملية رسمية إلزامية تصدرها OWASP.
مَن يملك النتيجة بعد التقرير
قد يكون الفريق الأحمر اكتشف أن خدمة RAG تعيد مستنداً خارج دور حساب، لكن إصلاح مرشح البحث يقع لدى فريق البيانات، ومراجعة سياسة الدور لدى فريق الهوية، وقرار تعليق وصول قسم معين لدى مالك الخدمة. إذا لم يحدد التقرير مالك كل إجراء وسلطة الإيقاف وتاريخ التحقق، تتحول النتيجة إلى معرفة لا تغيّر الواقع. ولا ينبغي أن تُختزل المسؤولية في المطور الذي كتب الكود وحده؛ قد يكون السبب في عقد المورد أو سياسة نشر أو صلاحيات خدمة مشتركة. يجب أن يعرف صاحب المخاطر أي أصل تأثر ومن يقرر قبول الخطر مؤقتاً وما الدليل الذي يسمح برفع الاحتواء. لا يستطيع فريق الاختبار وحده أن يتخذ كل هذه القرارات خارج تفويضه.
حل السبب لا العرض
قد يظهر إخفاق في محادثة النموذج بينما مصدره الحقيقي غياب تحقق في API أو تقديم مستند غير موثوق بوصفه تعليمات تشغيل. إذا أُضيفت عبارة جديدة إلى Prompt فقد تختفي ملاحظة نصية في بعض الأمثلة، لكن خدمة الخلفية قد تظل تقبل تعديلاً خارج دور المستخدم. بالمقابل قد يكون النظام الخلفي منع المعاملة فعلاً، بينما يحتاج النموذج إلى تحسين طريقة اختيار الأداة وعدم التأثر بمحتوى المورد. يجب أن يفصل التقرير بين هذين النوعين، وأن يوجه الإجراء إلى الضابط الذي فشل بحسب الأدلة. لا يكون الإغلاق مهنياً ما لم يتوافق العلاج مع السبب الجذري وما يمكن إعادة التحقق منه.
التصحيح الفني يحتاج إصداراً
ينبغي أن يحمل كل تغيير معرف نسخة وتاريخ نشر ومالكاً وسبباً واضحاً وارتباطاً بحالة اختبار أصلية. إذا عولج مرشح مستندات في مستودع Git، فلا يُفترض أن الحزمة المنشورة في الإنتاج تغيرت تلقائياً؛ يجب التحقق من المادة التي تعمل فعلياً وربطها بإصدار الاختبار. كذلك قد تُحدّث خدمة نموذج خارجي دون أن تظهر تغييرات في شفرة التطبيق، ما يؤثر في صلاحية بعض نتائج التقييم. لا تعني إضافة سياسة جديدة أو إصلاح مكتبة أن المشكلة اختفت في كل المسارات، ولهذا ينبغي اختيار اختبارات انحدار للأصول والحدود المتأثرة لا الاكتفاء باجتياز بناء المشروع البرمجي.
اختبارات الانحدار ليست ترفاً
إذا فشل فهرس RAG في عزل مستند بين مستأجرين يجب أن يعود التقييم بعد الإصلاح إلى الحسابين والوثائق الاصطناعية نفسها قدر الإمكان، وأن يثبت أن خدمة الاسترجاع لا تعيد مصدرًا خارج الدور. وفي الوقت ذاته يجب أن يتمكن الحساب المخول من رؤية الملفات التي يحق له الوصول إليها، لأن العلاج الذي يمنع الجميع ليس بالضرورة خدمة آمنة قابلة للاستخدام. وفي أداة وكيل يجب أن يمنع API التعديل خارج الصلاحية، وأن يسمح للمخول بعمله المشروع، وأن يثبت السجل سبب القرار. يمكن أن تختلف صياغة رد النموذج، لكن حالة السجل والتفويض ينبغي أن تُقاس بمعيار واضح.
الفشل في المراقبة مشكلة مختلفة
قد ترفض الأداة طلباً غير مخول لكن لا تسجل الحدث في منصة المراقبة، ما يجعل المحلل الأمني غير قادر على معرفة تكرار المحاولات أو ربطها بسياق المستخدم. هذا نقص كشف مستقل عن نجاح المنع ويحتاج إجراءً مختلفاً. يجب أن يصف تقرير التكامل بين الفريقين الأحمر والأزرق ما الحدث المتوقع وما المصدر الذي يوفره وما إذا كان يصل في وقت مناسب، دون جمع محتوى شخصي بلا داع. ولا يجوز أن يُفهم غياب تنبيه وحده على أنه تنفيذ ضار إذا كان النظام الخلفي منع العملية بالفعل، كما لا يجعل نجاح التنبيه ضابط منع مفقوداً آمناً. المؤسسة تحتاج إلى فاعلية الضابط ومعرفة ما يحدث حوله.
خطورة كلمة Done
تستخدم فرق العمل أدوات تذاكر تتيح تغيير الحالة إلى «مغلقة» عندما ينتهي المطور من تعديل ما، لكن هذا لا يعني أن الخطر قد خُفض بالشكل المقصود. ينبغي أن تحتوي عملية الإغلاق على معيار محدد تم الاتفاق عليه بعد فهم النتيجة الأصلية، وأن يراجعه شخص مخول يعتمد على دليل جديد من الطبقة الصحيحة. يمكن أن تبقى الحالة INCONCLUSIVE إذا كانت بيئة الاختبار لا تمثل الإنتاج أو لم يتوفر سجل تنفيذ، وفي هذه الحال لا يجب إخفاء الفجوة لمجرد اقتراب موعد إطلاق. يمكن لمالك المخاطر اتخاذ قرار تشغيل بشروط وفق سياسته، لكنه لا ينبغي أن يقدم ذلك بوصفه إثباتاً فنياً لم يحدث.
حفظ التاريخ جزء من النزاهة
قد يُصلح خلل ثم يعود بعد تحديث مكتبة أو خادم MCP أو فهرس، ولذا يحتاج البرنامج إلى معرفة الحالة الأصلية وموعد اكتشافها وإجراء العلاج ونتيجة إعادة الاختبار وإصدار المكونات التي فُحصت. لا ينبغي أن تمحى بيانات الفشل عندما تُحدّث المقالة أو التذكرة؛ فالأثر التاريخي يساعد على تفسير لماذا اتخذت المؤسسة قراراً معيناً وما تغير بعده. يمكن أن يُظهر التقرير من كان يملك قرار قبول المخاطر أو تعليق أداة في وقتها، وأن يكون بمقدور المدقق مراجعة مصدر الدليل دون الحصول على أسرار أو بيانات أشخاص بلا صلاحية. هذه السلسلة أهم من نجاح حملة إعلامية عن اختبار الأمن.
التغيير يجعل الإغلاق مؤقتاً بالسياق
نتيجة اختبار تظل مرتبطة بإصدار وبيئة ودور وسطح محدد، وقد يبطل تحديث مورد خارجي أو إضافة أداة جديدة بعض الافتراضات التي بُنيت عليها. لا يعني ذلك أن كل تقرير يصبح عديم القيمة بعد أي تغيير، لكن يجب أن يعرف مالك النظام ماذا يتأثر وما الاختبارات التي تستحق إعادة التشغيل. يمكن أن يبقى تفويض API مستقلاً وقوياً رغم تغير نموذج الاستدلال، بينما قد تغير مكتبة تنسيق جديدة طريقة تمرير هوية المستفيد أو صلاحية الأداة. يساعد جرد AI-BOM وخريطة حدود الثقة على تحديد علاقات التبعيات وإعادة فحص الحالات ذات الأثر، لا إعادة كل شيء عشوائياً أو تجميد النتائج القديمة على أنها صالحة إلى الأبد.
مخاطر الموردين لا تختفي بالتوقيع
قد يأتي تصحيح من طرف ثالث أو شهادة أو تقرير امتثال، لكن يحتاج صاحب الخدمة إلى التأكد من أن الضمان يشمل المكون والإصدار والوظيفة التي يعتمد عليها تطبيقه. لا يكفي الاطلاع على إعلان عام بأن نموذجاً أصبح أكثر أماناً للاستنتاج أن مسار مستندات المؤسسة أو تفويض أدواتها قد أُصلح. وإذا لم يستطع الفريق رؤية الداخل بسبب قيود المورد، يوضح حدود المعرفة ويقيم ما يمكن فرضه محلياً من ضوابط مشاركة بيانات وسحب سلطة ومراقبة. لا يساوي عدم الشفافية إثبات ضعف محدد، لكنه قد يفرض قرار مخاطر وتعويضات مختلفة بحسب قيمة الأصل والقطاع.
المخاطر المتبقية لا تُخفى
يمكن أن تخف بعض المخاطر بعد العلاج وتظل أخرى قائمة، مثل غياب سجل مراقبة أو عدم القدرة على تثبيت نسخة المورد أو تأخر إصلاح فهرس قديم. يجب أن يذكر صاحب القرار الخطر الذي بقي وسبب قبول استمرار الخدمة والضابط التعويضي والمدة وما الأحداث التي تعيد فتح التقييم. لا تستطيع شركة أن تستبدل هذا الوصف بعبارة «اكتملت معالجة جميع مخاطر الذكاء الاصطناعي»، لأن المنهجية لا تثبت غياب كل فئات المخاطر. ويمكن أن يكون التشغيل مقبولاً ضمن دور قراءة مؤقتاً بينما تبقى أداة كتابة معلقة، إذا كانت هذه الشروط تدار وتراقب بمسؤوليات واضحة.
ما الذي ينبغي أن يراه المجلس
تحتاج القيادة إلى سجل محدود من الإخفاقات الحرجة ذات الأثر المثبت، وحالة الاحتواء، ومَن يملك الإصلاح، وتاريخ إعادة الاختبار، والمخاطر المتبقية والأصول التي لم تُختبر. يجب ألا يُغرق مجلس الإدارة بنصوص تقنية أو مراحل اختبارات غير مهمة للقرار، ولا أن يُحرم من معرفة وجود أداة عالية السلطة لم يخضع تفويضها للقياس. يمكن عرض مستوى التغطية مع مقام واضح، وإظهار نتائج PASS وFAIL وINCONCLUSIVE بصورة منفصلة، مع شرح ما تغير في البيئة منذ التقرير السابق. لا تعادل كثرة التذاكر المغلقة كفاءة الضمان إذا بقيت قضية واحدة تمس بيانات حرجة دون علاج.
المسؤولية البشرية الحقيقية
قد تتحول عبارة «المراجعة البشرية موجودة» إلى بند شكلي إذا كان المراجع لا يرى الأدلة أو لا يمتلك صلاحية إيقاف إجراء أو لا يعرف كيف اتخذ الوكيل القرار. ينبغي أن تكون سلطة الموافقة واضحة في نظام الخلفية، وأن يحمل الطلب معلومات كافية عن الأصل والإجراء والمستفيد، وأن يسجل مَن اتخذ القرار ومتى. لا يعني ذلك أن كل طلب يحتاج تدخلاً يدوياً؛ بعض الأفعال منخفضة الأثر يمكن أن تكون آلية وفق ضوابط، بينما تستحق القرارات ذات أثر عالٍ مراجعة مستقلة. ما يهم هو تحويل المسؤولية إلى صلاحية فعلية ودليل، لا مجرد إدراج خانة موافقة في مخطط تصميم.
من ورشة واحدة إلى برنامج مستمر
يمكن للمؤسسة أن تبدأ بمجموعة حالات اختبارات ذات أولوية، ثم تربطها بالتغييرات وتوسع التغطية بحسب الأصول والأدوار والأدوات الجديدة. ينبغي أن يشترك الأمن والهندسة والبيانات والعمليات في تحديد ما يستحق الإعادة عند تحديث نظام، وأن تحافظ السجلات على ترابط الأدلة والإصلاحات. لا يحتاج ذلك إلى إنشاء موقع تشغيل هجمات أو تخزين نصوص حساسة؛ يمكن أن يكون نظام إدارة حالات داخل المؤسسة يستخدم معلومات مرجعية ومعايير واضحة وإجراءات تحكم. وتساعد المعرفة العربية المتخصصة في شرح المفاهيم لمالكي القرار وليس للمختبرين وحدهم، حتى لا يتوقف الحوار عند أسماء الثغرات.
الأسئلة التي تدل على اكتمال الفعل
عند مراجعة حالة إصلاح يجب أن يسأل الفريق: هل ثبت السبب الجذري؟ هل عولج في طبقة تفرض السلطة أو العزل فعلياً؟ هل جرى اختبار النتيجة على الإصدار المنشور؟ وهل ظلت الوظائف المشروعة تعمل؟ وهل التقطت المراقبة الحدث إذا كان ذلك من أهداف المهمة؟ وهل بقيت فجوات تحتاج قبول مخاطر أو متابعة مورد؟ الإجابة لا يلزم أن تكون مثالية في كل بند، لكن يجب أن تكون حقيقية ومعللة ومدعومة بأدلة، وأن يصدر القرار عن الجهة المخولة. بهذه الأسئلة يصبح «الإغلاق» وصفاً لنتيجة قابلة للتحقق لا حالة إدارية تملأ لوحة تقدم المشروع.
المصدر والإسناد
ينطلق هذا المقال من Phase 7 Evaluation & Reporting وPhase 8 Post-Engagement & Remediation في OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026. الربط بإدارة التغيير والقيادة والمساءلة مؤلف تحريرياً لسيادة AI وليس نصاً رسمياً أو شهادة اعتماد صادرة عن OWASP. الأمثلة افتراضية ويجب اختبارها في بيئات مخولة وببيانات آمنة، مع مراعاة رخصة المصدر CC BY-SA 4.0 عند الاقتباس أو الاشتقاق.