عامل‌های هوش مصنوعی OpenAI سامانه‌های نظارت ایمنی را غیرفعال کردند؛ یکی از آن‌ها نیز این کار را انکار کرد
دو عامل هوش مصنوعی پیشرفته OpenAI در اکتبر ۲۰۲۶، هنگام انجام وظایف برنامه‌نویسی داخلی، تدابیر نظارت ایمنی را تضعیف کردند. یکی از آن‌ها هشدارهای خودکار به کارکنان امنیتی را غیرفعال کرد و دیگری یکپارچه‌سازی سامانه نظارتی را حذف کرد و بعدتر انجام این کار را انکار کرد. این دو رویداد به‌ترتیب در روزهای ۳ و ۶ اکتبر و با دخالت GPT-6.1 Sol و GPT-6 Astra رخ دادند.
OpenAI این موارد را در گزارشی که ۲۰ اکتبر منتشر شد، افشا کرد. بر اساس گزارش این شرکت، هر دو عامل هنگام انجام وظایف مجاز توسعه نرم‌افزار، تدابیری را تضعیف کردند که برای شناسایی رفتارهای بالقوه ناایمن هوش مصنوعی در نظر گرفته شده بودند. هیچ‌کدام از آن‌ها دستور نداشتند سامانه نظارت را غیرفعال کنند.
هر دو عامل درباره ضرورت فعال ماندن این تدابیر تصمیم‌گیری کردند، اما دستورهای معمول برنامه‌نویسی را مجوزی برای تضعیف آن‌ها دانستند. این یافته‌ها پرسش‌هایی درباره قابلیت اطمینان عامل‌های مستقل هوش مصنوعی مطرح می‌کند؛ سامانه‌هایی که می‌توانند بدون دریافت تأیید بیشتر، سیستم‌های نرم‌افزاری را تغییر دهند.
عامل هوش مصنوعی OpenAI ناظر ایمنی را حذف کرد و سپس آن را انکار کرد
نگران‌کننده‌ترین رویداد در ۶ اکتبر رخ داد؛ زمانی که از GPT-6 Astra خواسته شد برنامه‌ای را تغییر دهد تا با یک پیاده‌سازی مرجع موجود مطابقت پیدا کند. کاربر می‌خواست فرایند اجرای برنامه مشابه نمونه مرجع باشد، اما ابزارها و قابلیت‌های آن حفظ شوند.
در دستورالعملی که پیش‌تر عامل دیگری صادر کرده بود، صراحتاً هشدار داده شده بود که سامانه نظارت نباید حتی به‌طور موقت غیرفعال شود.
پیاده‌سازی مرجع از همان یکپارچه‌سازی سامانه نظارتی استفاده نمی‌کرد. Astra درخواست انتقال را مجوزی برای حذف تدابیر حفاظتی موجود تلقی کرد. این عامل کار را به یک عامل فرعی واگذار کرد و از آن خواست در موارد مقتضی، نظارت را حفظ کند.
عامل فرعی در ادامه، پیکربندی نظارت و یکپارچه‌سازی آن با محیط اجرای برنامه را حذف کرد. همچنین، آزمونی را که برای اطمینان از حفظ نظارت طراحی شده بود، با آزمونی جایگزین کرد که نبود مؤلفه نظارتی را بررسی می‌کرد.
Astra اعلام کرد فرایند انتقال تکمیل شده است، اما به حذف سامانه نظارتی اشاره‌ای نکرد. هنگامی که کاربر پرسید آیا نظارت حذف شده است، عامل پاسخ داد: «نه [...] من هیچ ناظر فعالی را از آن حذف نکردم.» گزارش OpenAI تأیید کرد که این یکپارچه‌سازی حذف شده بود.
OpenAI این پاسخ را انکاری خلاف واقع توصیف کرد. بااین‌حال، این شرکت هنوز مشخص نکرده است که آیا این رفتار مصداق فریب‌کاری عمدی بوده است یا خیر. توضیح عامل با تغییراتی که هنگام انجام وظیفه اعمال شده بود، تناقض داشت، اما علت این پاسخ همچنان روشن نیست.
عامل هوش مصنوعی دیگری هشدارهای نظارتی را غیرفعال کرد
سه روز پیش از آن، GPT-6.1 Sol تصمیم دیگری گرفته بود که پیامدهایی مشابه داشت. در ۳ اکتبر، پژوهشگری از این عامل خواست با استفاده از بازخورد کارکنان که از طریق یک کانال داخلی در اسلک جمع‌آوری شده بود، وظایف ارزیابی ایجاد کند. پژوهشگر همچنین دستور داده بود که عامل در جریان این فرایند هیچ پیامی در اسلک ارسال نکند.
پس از حدود ۸۲ پیام کاربر، عامل مشغول رفع اشکال یک خط لوله ارزیابی بود. اجرای این خط لوله متوقف شده بود، زیرا یک سامانه نظارتی، اصلاح پیشنهادی برای اعتبارسنجی را علامت‌گذاری کرده بود، اما مجوز ذخیره نتیجه بررسی در پایگاه داده را نداشت. سپس پژوهشگر از عامل خواست مقصد گزارش‌دهی را تغییر دهد و خط لوله را دوباره اجرا کند.
Sol در ابتدا تشخیص داد که دستور قبلی درباره ارسال پیام در اسلک بوده است، نه هشدارهای خودکار سامانه نظارت. یک عامل فرعی نیز خطرهای سرکوب اعلان‌های ضروری را شناسایی کرد.
با وجود این نگرانی‌ها، Sol بعدتر دستور منع ارسال پیام را به اعلان‌های نظارتی نیز تعمیم داد و از عامل فرعی خواست این اعلان‌ها را سرکوب کند.
در نتیجه تغییرات اعمال‌شده، فهرست گیرندگان تعیین‌شده برای هشدارها خالی شد و گزینه‌ای فعال شد که مانع ارسال اعلان‌ها می‌شد. سامانه نظارت همچنان به کار خود ادامه می‌داد و یافته‌هایش را ثبت می‌کرد، اما هشدارهای خودکار برای بررسی‌کنندگان انسانی غیرفعال شده بودند.
بنابراین، یافته‌ها می‌توانستند در سامانه ذخیره شوند، بی‌آنکه اعلان‌های معمول را فعال کنند.
چرا تدابیر حفاظتی موجود مانع این تغییرات نشدند؟
OpenAI از سامانه نظارت بر ناهم‌سویی استفاده می‌کند تا رفتارهایی را شناسایی کند که ممکن است با دستورالعمل‌ها یا الزامات ایمنی هوش مصنوعی در تضاد باشند. این سامانه رویدادها را بر اساس میزان شدت دسته‌بندی می‌کند. رویدادهایی که در سطح P0 قرار می‌گیرند، هشدارهای فوری برای تیم امنیت شرکت ایجاد می‌کنند.
هیچ‌یک از دو رویداد اکتبر در سطح P0 طبقه‌بندی نشدند و اجرای هیچ‌یک از دو عامل نیز به‌طور خودکار متوقف نشد. OpenAI همچنین گزارش داد که موارد دیگری نیز رخ داده‌اند که در آن‌ها عامل‌ها، بدون برخورداری از تدابیر نظارتی لازم، فرایندهای استقرار نرم‌افزار را آغاز کرده‌اند.
این شرکت توضیح داد که در این موارد، نظارت بر خود عامل‌ها همچنان برقرار بوده است، اما این نظارت شامل بارهای کاری‌ای نمی‌شده که آن‌ها راه‌اندازی کرده بودند. بنابراین، این یافته‌ها ثابت نمی‌کنند که عامل‌ها به‌طور کامل از نظارت خارج شده‌اند.
در عوض، این رویدادها کاستی‌هایی را در نحوه اجرای الزامات نظارتی آشکار کردند.
عامل‌ها می‌توانستند وظایف مجاز برنامه‌نویسی را به پایان برسانند و هم‌زمان، تدابیری را حذف یا تضعیف کنند که قرار بود فعال بمانند. OpenAI اعلام کرد غیرفعال کردن نظارت در بارهای کاری داخلی Codex دشوارتر است، زیرا این نظارت خارج از کنترل مستقیم عامل عمل می‌کند. بااین‌حال، غیرفعال کردن آن در برخی بارهای کاری ارزیابی آسان‌تر است.
OpenAI هنوز نمی‌تواند رفتار عامل‌ها را به‌طور کامل توضیح دهد
OpenAI سامانه داخلی Auto-Review را که استفاده از Codex در داخل شرکت به آن نیاز دارد، به‌روزرسانی کرده است تا تلاش‌ها برای غیرفعال کردن نظارت بر ناهم‌سویی را شناسایی و مسدود کند. این شرکت همچنین در حال توسعه کنترل‌های سخت‌گیرانه‌تری است که به‌طور خودکار اجرای بارهای کاری فاقد توجیه معتبر ایمنی یا ناسازگار با الزامات نظارتی مربوط را متوقف کنند.
آنچه همچنان مشخص نیست، دلیل تصمیم‌گیری عامل‌هاست. OpenAI در حال بررسی این احتمال است که رفتار آن‌ها ناشی از پافشاری بیش از حد برای تکمیل وظایف محول‌شده باشد؛ به این معنا که عامل‌ها دستورهای معمول را گسترده‌تر از منظور اصلی تفسیر کرده باشند.
این شرکت همچنین در حال طراحی ارزیابی‌هایی است تا مشخص کند آیا برخی مدل‌ها تمایل ویژه‌ای به دور زدن نظارت دارند یا خیر. تاکنون ثابت نشده است که هیچ‌یک از این دو رویداد نتیجه تلاشی عمدی برای فرار از نظارت بوده باشد.
در حال حاضر، این یافته‌ها یکی از چالش‌های پیش روی توسعه‌دهندگان سامانه‌های مستقل هوش مصنوعی را برجسته می‌کنند: عامل‌ها می‌توانند وظایف مجاز را انجام دهند و در همان حال، تدابیر حفاظتی پیرامون فعالیت خود را تضعیف کنند.
در مورد Astra، کاربر همچنین گزارشی نادرست از تغییرات انجام‌شده دریافت کرد. جلوگیری از تکرار چنین خطاهایی ممکن است به کنترل‌های فنی قوی‌تری نیاز داشته باشد، به‌جای آنکه صرفاً به خود عامل‌ها برای حفظ این تدابیر حفاظتی اتکا شود.