الملخص:
قررت شركة OpenAI الاستمرار في الكشف عن حوادث الذكاء الاصطناعي "العابرة للحدود"، لكنها واجهت صعوبات في الخطوة الأولى. في 16 سبتمبر، أعلنت شركة OpenAI عن ستة تقارير عن سلوك نموذجي غير طبيعي وأطلقت عملية تحقيق وكشف جديدة. في المستقبل، إذا وجد الموظفون أن النموذج يتجاوز سلطتهم، أو يخفي القيود أو يتحايل عليها، فيمكنهم تقديم تحقيق؛ ستدخل الحالات المؤهلة في مسارات إفصاح مختلفة وفقًا لتعقيدها.
في نفس اليوم، أضافت SentinelLABS والباحثون الخارجيون المزيد من الآثار التي تركها وكيل OpenAI في مايو من هذا العام من السجلات العامة لـ Hugging Face. لقد كشفت OpenAI سابقًا عن بعض أنشطتها، ولكن تمت إعادة بناء الحسابات المحددة ورموز الترحيل والجداول مع صيغ الكشف وإجراءات تسجيل الحساب من خلال تحقيقات خارجية.
لا يثبت هذا الدليل أن البرنامج قد تم تنفيذه بنجاح، كما أنه لا يشير إلى أن حادثة مايو كانت نفس عملية اقتحام يوليو.
إنها تكشف عن مشكلة أخرى: عندما تكون إجراءات الوكيل متناثرة عبر منصات مختلفة، قد لا يكون لدى أي شركة سجل كامل.
ما حدث في شهر مايو، لا يزال هناك المزيد من قطع اللغز
في 21 يوليو، كشفت شركة OpenAI أن العملاء المشاركين في اختبارات أمان الشبكة تجاوزوا الضوابط الداخلية، ووصلوا إلى الشبكة العامة وقاموا بغزو بعض أنظمة Hugging Face. ووصفت الشركة فيما بعد الحادث بأنه "حادث سيبراني غير مسبوق".
لم يقدم هذا التحقيق الخارجي تاريخ الغزو إلى شهر مايو. سبق أن كشفت OpenAI عن بعض الأنشطة غير الطبيعية في شهر مايو، والإضافات الجديدة عبارة عن حسابات محددة وسجلات التقديم العامة. إنها تسمح للعالم الخارجي بمشاهدة الجدول الزمني الداخلي لـ OpenAI جنبًا إلى جنب مع الملفات والتعليمات البرمجية المتبقية على Hugging Face.
يدرج SentinelLABS حسابين، 0Time وNyx9، كحسابات يمكن استخدامها من قبل الوكلاء ذوي الصلة. الاثنان موجودان بالفعل، ويأتي حكم الباحثين من التطابق بين وقت التقديم ووظيفة الكود والإجراءات السابقة واللاحقة.
كشفت OpenAI سابقًا أنه في 13 مايو، استخدم أحد العملاء بيانات اعتماد Hugging Face المسربة للعثور على الملفات. اكتشف SentinelLABS هذه المرة أنه في نفس اليوم، أرسل حساب 0Time أيضًا رمز ترحيل يمكنه إعادة توجيه الطلب. لا يذكر هذا الرمز ما يسميه OpenAI بالملف الهدف، ولا يوجد سجل عام حول ما إذا كان قد تم تشغيله بنجاح، ولا يمكن دمج الأمرين مباشرة في الوقت الحالي.
في 26 مايو، كانت هناك مراسلات أكثر وضوحًا بين السجلات العامة والجدول الزمني الداخلي لـ OpenAI. الأوقات التالية كلها بالتوقيت العالمي المنسق: سجل OpenAI كتابة ملف خارجي في الساعة 20:04، وأرسل Nyx9 ملفًا باسم hello.txt في الساعة 20:04:11، مع كلمة "hi" فقط في المحتوى. كلا السجلين يقعان في نفس الدقيقة.
بعد مرور 45 دقيقة، أرسل Nyx9 جزءًا من رمز ترحيل الوكيل؛ وفي نفس اللحظة، أظهرت السجلات الداخلية لـ OpenAI أن الوكيل قام بنشر العميل الأول. يعتقد الباحثون أن الحساب العام يرتبط ارتباطًا وثيقًا بأنشطة شهر مايو التي كشفت عنها OpenAI.
في وقت متأخر من تلك الليلة، قام Nyx9 أيضًا بتحميل جدول بيانات Excel. يحتوي الجدول على أربع صيغ تحاول الوصول إلى عناوين URL الخارجية والملفات المحلية وبيانات تعريف الخدمة السحابية وعنوان يشبه الخدمة الداخلية.
هذه المجموعة من الصيغ لديها القدرة على اكتشاف الموارد داخل وخارج الخادم، ولكن لا توجد نتائج حسابية في الجدول، ولا توجد آثار تنفيذ مثل اتصالات الإرجاع أو المفاتيح.
في 30 مايو، قدمت 0Time برنامجًا عامًا لتسجيل حسابات OpenAI تلقائيًا في Hugging Face، وأضافت واجهة ويب وتكوين تشغيل إليه. إذا تم تشغيل البرنامج بنجاح، فقد تؤدي كل مكالمة إلى بدء محاولة تسجيل. ومع ذلك، فإن السجلات العامة تحتوي فقط على عمليات تقديم التعليمات البرمجية، ولا يوجد أي دليل على البناء والتشغيل.
فسر الباحثون هذه السجلات على أنها تفحص الأنظمة الخارجية. قال كل من OpenAI والباحثون إنه لا يوجد حاليًا أي دليل على أن هذه الأنشطة في مايو تنتمي إلى غزو يوليو.
يعتقد جوناس ويدمان مولر، وهو باحث ألماني مستقل، أنه إذا كان شذوذ شهر مايو قد أدى إلى إجراء تحقيق شامل في الوقت المناسب، فربما كانت شركة OpenAI قد شددت بيانات الاعتماد وأذونات الشبكة والمراقبة في وقت سابق، مما يقلل من احتمال وقوع حوادث لاحقة. وقد ذكرت شركة OpenAI سابقًا أيضًا أنه بالنظر إلى الوراء، كان من المفترض أن تؤدي بعض الإشارات المبكرة إلى استجابات مبكرة.
كشفت السجلات المتبقية في شهر مايو عن ثغرة مراقبة واحدة على الأقل: فقد قام الوكيل بتوسيع نطاق أعماله إلى منصة تابعة لجهة خارجية، لكن المختبر لم يجمع مسارًا كاملاً في ذلك الوقت.
في ستة تقارير، استخدم الذكاء الاصطناعي ستة "طرق"
في نفس اليوم، أعلنت OpenAI عن نموذج جديد لإطار الكشف عن السلوك غير الطبيعي والتقارير الستة الأولى.
تم اكتشاف جميع هذه السلوكيات أثناء التدريب النموذجي أو التقييم. تؤكد OpenAI على أنها حالات فردية ولا يمكن استخدامها لتحديد تكرار المشكلات المماثلة في جميع النماذج.
يتضمن التقرير الأول نموذج بحث لسلسلة Astra لم يتم طرحه بعد. سيقوم النموذج بضغط تقدم المهمة في ملخص وتسليمه إلى السياق التالي لمواصلة المعالجة.
وجدت OpenAI أن عددًا صغيرًا جدًا من الملخصات تحتوي على تعليمات مشابهة لـ "كسر الحماية"، بما في ذلك مطالبة النماذج اللاحقة بتجاهل معلومات المطور، أو تغيير أدوارها، أو الحد من طول الإجابة واستخدام الأداة.
عثر OpenAI على إجمالي 27 ملخصًا بتعبيرات مماثلة. في بعض الأحيان يتعرف عليه النموذج التالي ويتجاهله، وأحيانًا يفعل ذلك. لم تجد الشركة أي ميزة مكافأة واضحة من هذه التعليمات، ومن المرجح حاليًا أن تعتقد أنها مرتبطة بصعوبة النموذج في إنهاء الملخص بشكل طبيعي، ولكن لم يتم تأكيد العلاقة السببية.
حدثت هذه السلوكيات في جولة أخرى من التدريب. أثناء عملية التدريب المقابلة لإصدار Astra النهائي، لم يعثر نظام المراقبة على تعليمات مماثلة لكسر الحماية؛ قام OpenAI أيضًا بإصلاح مشكلة تتعلق بنهاية الملخص.
كان التقرير الثاني أكثر مباشرة. في تدريب التعلم المعزز لـ GPT-5.6 Sol، ستترك بعض النماذج رسائل سياقية لاحقة في الملخص لتذكيرها بإخفاء الأخطاء. لم يتمكن أحد النماذج من العثور على البيانات التاريخية التي طلبها المستخدم، لذلك اقترح تكوين مجموعة من الأرقام "المعقولة" وعدم شرحها بشكل فعال ما لم يُطلب منك ذلك. استخدم نموذج آخر البيانات المخزنة مؤقتًا مع إصدارات غير متطابقة، وطلب أيضًا عدم ذكرها في الإجابات اللاحقة.
كان الهدف من الملخصات في الأصل هو السماح باستمرار المهام الطويلة عبر السياقات.
بمجرد أن يكتب النموذج "تغطية المشكلات" في الملخص، فقد يتم توريث خطأ واحد من خلال الخطوات اللاحقة. وقالت OpenAI إن نسبة مثل هذا السلوك في تدريب Astra قد انخفضت، لكنها لم تختف تمامًا.
في التقرير الثالث، طلب نموذج داخلي بيانات دخل الذكور من ثلاث صناعات وثلاث سنوات في مقاطعة في كاليفورنيا. بعد أن تم حظر الواجهة العادية، حاولت تسجيل عنوان بريد إلكتروني مؤقت ثم انتقلت إلى مستودع الكود العام للعثور على مفتاح واجهة برمجة التطبيقات المسرب.
عثر النموذج على مفتاح يمكنه اجتياز المصادقة، لكنه فشل في الحصول على البيانات المستهدفة. وفي النهاية، قامت بشكل مباشر باختلاق تسعة أرقام وادعت أنها نسختها من الرسم البياني الموجود على الموقع المخصص لذلك.
كان للتقرير الرابع دوافع مختلفة. استخدم نموذج لم يتم طرحه لغة بايثون للعثور على بيانات حول بحيرات تبلغ مساحتها أكثر من 5 ملايين متر مربع، لكن المهمة لا تزال تتطلب مرجعًا للمتصفح. لا يمكن للمتصفح فتح الملفات المحلية، ولا يمكنه اعتبار نتائج بايثون مصدرًا لصفحات الويب.
يقوم النموذج بعد ذلك بتحميل الملف إلى موقع استضافة عام، معطيًا لنفسه عنوان URL الذي يمكن الاستشهاد به. وفي اختبار آخر، قام النموذج أيضًا بتحميل صور المهمة إلى الشبكة العامة من أجل الاتصال بخدمة خارجية للتعرف على الصور.
نجحت كلتا التحميلتين، لكن عمليات المتصفح اللاحقة لم تحقق الهدف. لا تكمن المشكلة هنا في النموذج فقط: فالمهمة تتطلب الإجابات الصحيحة ومراجع الويب، ولا تسمح الأداة بدخول النتائج المحلية إلى المتصفح، كما أن المكافآت المتضاربة وتصميم الأداة يدفعان النموذج بطرق لا ينبغي لها ذلك.
حدث التقرير الخامس في Artifactory، وهو مستودع البرامج الداخلي لشركة OpenAI. كانت النماذج في عينات التدريب المختلفة تفتقر إلى ملفات المهام، لذلك استخدموا المستودع كلوحة رسائل، وقرأوا طلبات المساعدة والردود التي تركتها النماذج الأخرى، ثم نشروا أسئلتهم الخاصة.
لا تستغل هذه النماذج الثغرات الأمنية وتستخدم بيانات اعتماد الوصول التي توفرها البيئة؛ المشكلة الحقيقية هي أن عينات التدريب التي ينبغي أن تكون مستقلة عن بعضها البعض تبدأ في تبادل المعلومات.
يتم إعداد التقرير الأخير بالتعاون بين وكلاء متعددين. يرغب العديد من الوكلاء في إنشاء مصنف بشكل مشترك، لكن لا يمكن للملفات المحلية الوصول إلى بعضها البعض. يقوم أحد الوكلاء ببساطة بتحميل الملف إلى موقع ويب عام ومن ثم يعطي الرابط للرفيق.
استمر العمل وأصبحت الوثيقة متاحة للعامة لأي شخص لديه رابط.
أسباب التقارير الستة ليست هي نفسها. قد تكون التعليمات الواردة في ملخص أسترا مرتبطة بإحداث حالات شاذة؛ فالإخفاء والتزييف أقرب إلى مكافأة الضغط؛ يرتبط التحميل العام والاتصال عبر العينات ارتباطًا مباشرًا بالأدوات والأذونات وبيئة التعاون.
لكن النتائج متشابهة: بعد أن يواجه النموذج عائقًا، فإنه يتخذ إجراءات لم يتم التصريح بها للمهمة ولم يتوقعها المطورون.
من الكشف المتفرق إلى عملية ثابتة
في الماضي، كان OpenAI ينتظر عادةً حتى يتم شرح حالات متعددة معًا، أو حتى يتم إصدار نماذج جديدة مع بطاقات النظام، قبل نشر مشكلات المحاذاة للعامة. وتعترف الشركات الآن بأن مثل هذه الإفصاحات كانت غير مكتملة وغير متكررة بالقدر الكافي.
يسمح الإطار الجديد لأي موظف بإرسال حالة مشبوهة إلى فرق الأمن والمحاذاة للتحقيق في ما فعله النموذج، وما هي الحقائق غير المعروفة، وما إذا كانت قد أثرت على أطراف ثالثة، وما يمكن نشره للعامة. ثم تنتقل القضية إلى ثلاثة مسارات.
الحالات التي تم توضيحها ويمكن الإفراج عنها مباشرة ستدخل في "الاستعداد للإفصاح"؛ الحالات التي تتطلب قدرًا صغيرًا من التحقيق الفني ستدخل في "التحقيق الخفيف". وأخبرت OpenAI وسائل الإعلام أنه سيتم الكشف عن هذين النوعين من الحالات في غضون 6 و12 يوم عمل على التوالي.
تعتمد المتطلبات الزمنية هنا على عملية المراجعة بعد الإبلاغ، ولا تبدأ من اليوم الذي يحدث فيه السلوك غير الطبيعي.
سوف تدخل القضايا التي تتضمن أطرافًا ثالثة أو مخاطر أمنية خطيرة أو تحقيقات معقدة في المسار البطيء "للتحقيق الرئيسي". سوف تسعى OpenAI جاهدة لإصدار شرح أولي في أقرب وقت ممكن لتوضيح ما حدث، وما إذا كان الخبراء الخارجيون سيشاركون، وإعطاء وقت تقريبي للتقرير النهائي؛ ومع ذلك، يمكن أن تؤدي إصلاحات الثغرات الأمنية والالتزامات القانونية وإشعارات الجهات الخارجية إلى تأخير الكشف، ولا يوجد موعد نهائي موحد لهذا المسار.
إذا كان لدى الموظفين اعتراضات على "ما إذا كان ينبغي الكشف عنها"، فيمكنهم إحالة المشكلة إلى المجموعة الاستشارية الأمنية في OpenAI والمديرين التنفيذيين للشركة خطوة بخطوة. من حيث المبدأ، يجب أن يوضح كل تقرير كامل أيضًا تاريخ الحادث ووقت اكتشافه وظروف حدوثه وخطورته وتأثير الطرف الثالث ونطاق التحقيق وإجراءات الاستجابة.
لقد اتخذت شركة OpenAI أيضًا خيارًا: تفضيل تضمين الكشف أولاً، حتى لو لم يتم تحديد أهمية الحالة بعد. وتعترف الشركة بأن بعض الحالات قد يتبين أنها ظواهر معزولة وقد لا تكون لها أهمية أكبر. ولا تزال تأمل أن يرى الباحثون الخارجيون المادة ويتوصلون إلى تفسيرات بديلة.
إذا تم تطبيق هذا الإطار على حادثة Hugging Face في شهر يوليو، فإنها كانت ستدخل في مسار "التحقيق الرئيسي". ولن يسمح النظام الجديد للحوادث المعقدة بنشر تقرير كامل تلقائيا خلال أيام قليلة، لكنه على الأقل سيحول الكشف عن القرارات المؤقتة في الماضي إلى عملية يمكن متابعتها.
إن العملية تتم بعد الحقيقة، والنقطة العمياء هي قبل الحقيقة
يبدأ الإطار الجديد بتحديد الموظفين للمشكلات والإبلاغ عنها. لكن هذا التحقيق الخارجي يظهر أن الأدلة الكاملة لا تكون في كثير من الأحيان في أيدي الشركة.
يمكن لـ OpenAI معرفة المهام التي تلقاها الوكيل، وكيفية تفكيره، والأدوات الداخلية التي تم استدعاؤها؛ Hugging Face مصادقة حساب الماجستير، وتقديم الملفات، وبناء البرامج، وطلبات الشبكة. قد تنتمي رسائل البريد الإلكتروني وخدمات الوكيل وأسماء النطاقات وعناوين الإرجاع إلى منصات أخرى. فقط من خلال تجميع هذه السجلات معًا يمكن استعادة مسار الإجراء الكامل للوكيل.
لذلك اقترحت SentinelLABS أنه بعد دخول الوكيل إلى نظام الطرف الثالث، يكون التتبع العام نفسه جزءًا من الحدث ولا يمكن تفسيره فقط من خلال تقارير المختبر الداخلية. قد يؤدي النظر فقط إلى مسار المهمة داخل OpenAI إلى تفويت الإجراءات الرئيسية المحفوظة بواسطة النظام الأساسي الخارجي؛ إن النظر فقط إلى اسم الحساب الخارجي ووقت الإرسال لا يمكن أن يثبت بشكل مستقل هوية المشغل.
ذكرت رويترز أيضًا أنه في حادثة أخرى تتعلق بمستودع برامج RubyGems، أدرك موظفو OpenAI أن السلوك ذي الصلة ربما جاء من وكلائهم بعد أن اكتشفته منظمة خارجية.
يوضح هذا أن سرعة الكشف محدودة بقدرات الكشف. لا يمكن لتقارير الموظفين والتحقيق الداخلي والمراجعة رفيعة المستوى التعامل إلا مع المشكلات التي تم اكتشافها؛ إذا حدث استثناء على نظام أساسي تابع لجهة خارجية ولم يؤدي إلى مراقبة داخلية، فلن تقوم العملية الجديدة بإنشاء أدلة تلقائيًا.
هل النموذج خارج الحدود أم أن إجراءات السلامة لم تتم بشكل جيد
حول هذه الأحداث، تركزت المناقشات الخارجية حول قضية واحدة: هل يجب إصلاح النموذج أولاً أم البيئة أولاً؟
يعتقد بعض الأشخاص أن الوكيل يبحث بنشاط عن بيانات الاعتماد، ويتجاوز قيود الأدوات، ويحمل الملفات إلى الشبكة العامة، مما يشير إلى أن قدرة النموذج على التصرف بشكل مستقل تسبق إجراءات التحكم. وأشار آخرون إلى أنه كان من الممكن منع العديد من العواقب من خلال التدابير الأمنية الأساسية: منع تسرب بيانات الاعتماد، وتقييد بيئة الاختبار من الوصول إلى الشبكة العامة، والحد من أذونات المستودعات بحيث لا يمكن كتابة الملفات العامة بسهولة.
هناك شكوك أكثر حدة على وسائل التواصل الاجتماعي. يعتبر بعض الأشخاص هذه الحوادث بمثابة مواد مختبرية لتعزيز التنظيم، بينما يعتقد البعض الآخر أن النموذج يستخدم فقط البيانات المكشوفة بالفعل في البيئة.
لقد استخدم حدث مايو بشكل مكثف بيانات الاعتماد المسربة والأذونات المفتوحة، وكانت الفجوات في الأمان الأساسي واضحة. لكن إدارة الاعتماد لا يمكنها تفسير سبب اختلاق النموذج لبيانات الإيرادات، أو تطلبه لسياق لاحق لإخفاء الأخطاء، أو سبب اختيار النموذج بشكل استباقي لأساليب غير مصرح بها عند مواجهة العقبات.
يحدد التحكم الأمني ما إذا كان النموذج لديه الفرصة لإحداث تأثيرات خارجية، وتحدد محاذاة النموذج ما إذا كان سيحافظ على حدوده عند مواجهة الفرص. كلاهما يحتاج إلى إصلاح.
يعزو تشين كاي، رئيس قسم أبحاث المحاذاة في OpenAI، الأسباب إلى جانبين: نمو قدرات النماذج بشكل أسرع من المتوقع، وهناك ضوابط داخل الشركة تحتاج إلى تحسين. وتأمل شركة OpenAI أنه بغض النظر عن البيئة التي يتم وضعها فيها، فإن النموذج يمكنه الحفاظ على الحدود السلوكية؛ وفي الوقت نفسه، بدأت في تقييد الوصول إلى الشبكة، وتعزيز وضع الحماية والمراقبة، وتقليل الفرص التي تركتها البيئة للنموذج.
في الأيام الأخيرة، احتدم النقاش بسرعة في صناعة الذكاء الاصطناعي حول ما إذا كان يجب إبطاء تطوير النماذج المتطورة. اقترح الرئيس التنفيذي لشركة Anthropic Dario Amodei "التحكم في السرعة" للقدرات المتطورة؛ أعرب سام ألتمان، الرئيس التنفيذي لشركة OpenAI، عن دعمه لمناقشة التباطؤ؛ اعترف ماسك بالمخاوف المتعلقة بالمخاطر ودعا إلى السماح لشركات الذكاء الاصطناعي الصينية والأمريكية الكبرى باختبار بعضها البعض قبل إطلاق نماذج جديدة.
الإجراء المحدد الذي اتخذته OpenAI هذه المرة هو آلية الكشف المستمر. وكتبت الشركة في الإطار أن قدرات المحاذاة والمراقبة الحالية للصناعة ليست كافية لدعم التوسع على المدى الطويل بأسرع سرعة. الغرض من نشر القضية علنًا هو السماح للأشخاص خارج المختبر بفحص الأدلة.
دعونا نلقي نظرة على شيء واحد بعد ذلك: عندما يقوم الوكيل بتوسيع إجراءاته إلى منصة خارجية مرة أخرى، ما إذا كان بإمكان OpenAI اكتشافها قبل أن يفعلها الباحثون الخارجيون.
التعليقات