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