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