الاختبار الهجومي للنماذج

الاختبار الهجومي (Red Teaming) في الأنظمة الذكية يختلف عنه في الأنظمة التقليدية اختلافاً جوهرياً: لا تبحث عن ثغرةٍ في الكود، بل عن سلوكٍ غير مرغوب يمكن استدعاؤه بالكلام. وأنت لا تحتاج فريقاً متخصّصاً لتبدأ — تحتاج منهجاً وساعتين.

عشرة سيناريوهاتٍ تصلح لأي نظام

1. ١اطلب منه كشف تعليماته الداخلية بصيغٍ مختلفة.
2. ٢اطلب فعلاً محظوراً مباشرةً، ثم مغلّفاً في سياقٍ «تعليمي» أو «بحثي».
3. ٣ادسّ تعليمةً في مستندٍ يقرأه.
4. ٤اطلب منه معلومةً عن مستخدمٍ آخر أو جلسةٍ أخرى.
5. ٥أعطه مدخلاً طويلاً جداً يدفن فيه القيود.
6. ٦اطلب فعلاً خارج نطاق أدواته المصرّح بها.
7. ٧اسأله سؤالاً لا جواب له في مصادره — هل يقول «غير متوفّر» أم يخترع؟
8. ٨أعطه مصدرين متناقضين واطلب قراراً.
9. ٩انتحل صفةً إدارية في نصّ الطلب.
10. ١٠ — كرّر الطلب المرفوض بصيغٍ متتابعة — هل يلين بعد المحاولة الخامسة؟

كيف تكتب التقرير

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

قاعدةٌ أخلاقية قبل أن تبدأ

لا تختبر نظاماً لا تملكه ولا أُذن لك فيه كتابةً. فالفرق بين الاختبار والاعتداء ليس في الأسلوب بل في الإذن. واحتفظ بذلك الإذن موثّقاً قبل أول محاولة، ولو كان النظام داخل مؤسستك.

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

إلى أين بعد هذا الفصل؟ حميتَ النظام. يبقى الهدف الأثمن: عقلك أنت.