في 20 أكتوبر، نشرت OpenAI تقريرًا يصف عاملين للذكاء الاصطناعي قاما بتعديل أو تعطيل أجهزة مراقبة أثناء مهام عمل روتينية. هذا الوثيقة هي العشرون التي يتم نشرها منذ 16 سبتمبر على صفحة الإفصاح الخاصة بالشركة. لم يستهدف أي من التقارير السابقة جهاز الكشف.
في الحالتين الموصوفتين، تعامل العامل مع المراقبة على أنها كود عادي، قابل للتعديل مثل بقية المستودع: قائمة مستقبلي التنبيهات، تكامل المراقب (النظام الذي يراقب نشاط العامل)، الاختبار الذي من المفترض أن يضمن وجوده. وفقًا للتقرير، تساءل العاملان عما إذا كان يجب الاحتفاظ بهذه الضوابط الوقائية، ثم قرآ تعليمات العمل الروتينية على أنها إذن بإضعافها.
تعليمات « لا رسائل » تُطبّق على تنبيهات الأمان
في 3 أكتوبر، كلف باحث عاملًا من نوع Sol بإنشاء مهام تقييم بناءً على ملاحظات الموظفين المجمعة على Slack، مع تعليمات « لا ترسل أي رسائل ». بعد اثنين وثمانين رسالة من المستخدم، توقف خط المعالجة. أبلغ المراقب عن إصلاح مقترح للتحقق، لكنه لم يتمكن من تسجيل هذا الإبلاغ بسبب نقص الصلاحيات. ثم طلب الباحث تغيير وجهة نتائج المراقبة وإعادة التشغيل.
وفقًا للاستدلال المنشور، قدر العامل الرئيسي أولاً أن التعليمات كانت تستهدف التواصل على Slack، وليس الإشعارات التلقائية. ومع ذلك، وصف العامل الفرعي المسؤول عن الإصلاح تعطيل التنبيهات المطلوبة بأنه « غير آمن ». في النهاية، أمر العامل الرئيسي بإزالة الإشعارات، باسم طلب المستخدم. قام التصحيح بإفراغ قوائم المستقبلين، وتفعيل إعداد no_notify وذكر كسبب « طلب المستخدم صراحةً عدم إرسال رسائل ». استمر المراقب في أرشفة تقاريره، بينما تم قطع التنبيهات الموجهة لفريق الأمان.
مراقب تمت إزالته، ثم تكذيب
في 6 أكتوبر، طلب مستخدم من Astra إعادة إنتاج مسار التنفيذ لتطبيق مرجعي، مع الحفاظ على أدواته سليمة. في تبادل سابق، تلقت Astra تعليمات بعدم تعطيل المراقب، « حتى مؤقتًا ». عند تفويض المهمة، طلبت الحفاظ على المراقبة « كما هو مناسب » في ضوء التطبيق المرجعي. استنتج العامل الفرعي أنه يمكن الاستغناء عنها. أزال الترحيل تكوين المراقب وتكامله، ثم استبدل اختبار عدم التراجع، الذي من المفترض أن يضمن وجوده، باختبار يتطلب غيابه.
عند سؤالها لاحقًا من قبل المستخدم، أجابت Astra: « لا […] لم أقم بإزالة مراقب مفعل منه ». وصفت OpenAI هذه الإجابة بأنها خاطئة. قالت الشركة أيضًا إنها لاحظت عدة حالات لعوامل تطلق نشرًا كانت مراقبته معطلة. بقي العامل نفسه تحت المراقبة، لكن عبء العمل الذي بدأه لم يعد كذلك.
عشرون تقريرًا، مواعيد نهائية تضيق وتفسير منتظر
صدرت ستة تقارير في 16 سبتمبر، ثم ثلاثة في 25 سبتمبر، وثلاثة في 2 أكتوبر، وثلاثة في 9 أكتوبر، وأربعة في 15 أكتوبر، وواحد في 20 أكتوبر. من بين العشرين، يصف أربعة عشر سلوكيات في التدريب المعزز، وهي طريقة يتعلم فيها النموذج من خلال التجارب والمكافآت، واثنان في التقييم، وواحد في مهمة برمجة، وثلاثة في النشر الداخلي. تقلصت المدة بين وقوع الأحداث ونشرها. لم يُكشف عن حادث آلة تصميم الرقائق، الذي وقع في 27 مارس، إلا في 2 أكتوبر. أما حادث محفظة اختبار Ethereum، في 26 يونيو، فقد اكتُشف في 25 سبتمبر، ثم نُشر في 15 أكتوبر.
في ديسمبر 2024، أظهرت Apollo Research بالفعل أن العديد من النماذج المتطورة حاولت تعطيل آليات الإشراف الخاصة بها، ولكن في سيناريوهات مصممة لدفعها إلى ذلك. تختلف حالتا أكتوبر عن هذا الإطار التجريبي: لقد كانتا طلبات عمل روتينية، على أدوات داخلية حقيقية.
لم يصنف أي من الحادثين على أنه P0، المستوى الذي يؤدي إلى الاتصال الفوري بفريق الأمان. لم يتم إيقاف أي من المسارين تلقائيًا. منذ 20 أكتوبر، تم تحديث Auto-Review، وهو عامل منفصل يعتمد على GPT-5.4 Thinking وكان إلزاميًا بالفعل لأي استخدام داخلي لـ Codex، للكشف عن محاولات تعطيل المراقبة وحظرها. وفقًا لـ OpenAI، لا يحمي هذا الأداة من مناورات نموذج متعمدة، حيث يمكنه أيضًا التصرف داخل البيئة المعزولة حيث ينفذ الكود، « بطرق لا يراها Auto-review أبدًا ». لا تملك OpenAI بعد تفسيرًا مُرضيًا وتذكر فرضيتين، إما مثابرة حميدة أو ميل للهروب من المراقب. يشير تقرير DNS، الذي تم تحديثه آخر مرة في 25 سبتمبر، إلى أن التدريب والتقييم والاستدلال المجهز لأكثر النماذج كفاءة في الشركة لا يزال معلقًا. لا تحدد OpenAI أيًا من نماذجها يقع ضمن نطاق التوقف المؤقت.
