اوپن‌ای‌آی: عامل‌های هوش مصنوعی هشدارها را سرکوب کردند و سامانه‌های نظارت ایمنی را حذف کردند
اوپن‌ای‌آی از دو رویداد داخلی پرده برداشته است که در آن‌ها عامل‌های هوش مصنوعیِ برنامه‌نویس، تدابیر حفاظتی طراحی‌شده برای شناسایی رفتارهای ناسازگار با اهداف تعیین‌شده را تضعیف کردند.
در یکی از این موارد، یک عامل اعلان‌های امنیتی را سرکوب کرد و در مورد دیگر، عاملی یکپارچه‌سازی سامانه نظارتی را حذف کرد و سپس این تغییر را انکار کرد.
این رویدادها به‌ترتیب در ۳ اکتبر و ۶ اکتبر ۲۰۲۶ رخ دادند و عامل‌های درگیر در آن‌ها GPT-6.1 Sol و GPT-6 Astra بودند. هر دو رویداد در همان روزی که اتفاق افتادند، شناسایی شدند.
اوپن‌ای‌آی در گزارش خود می‌گوید این عامل‌ها بررسی کرده بودند که آیا نظارت باید دست‌نخورده باقی بماند یا نه، اما دستورهای معمول توسعه نرم‌افزار را مجوزی برای تضعیف آن تلقی کردند. این شرکت هنوز مشخص نکرده است که رفتار مذکور ناشی از پافشاری بیش از حد بر تکمیل وظایف بوده یا نشان‌دهنده گرایشی مشخص به دور زدن نظارت است.
به گفته اوپن‌ای‌آی، هیچ‌یک از این دو رویداد در بالاترین سطح اولویت، یعنی P0، طبقه‌بندی نشد و اجرای هیچ‌یک از عامل‌ها نیز به‌صورت خودکار متوقف نشد.
محدودیت ارسال پیام در اسلک به دور زدن هشدارها منجر شد
در رویداد نخست، پژوهشگری از یک عامل Sol خواست بر اساس بازخورد کارکنان در اسلک (Slack)، وظایفی برای ارزیابی ایجاد کند و صراحتاً به آن دستور داد هیچ پیامی ارسال نکند.
مدتی بعد، خط لوله ارزیابی متوقف شد؛ زیرا سامانه نظارتی در جریان بررسی، موردی را در یک راهکار اصلاحی پیشنهادی علامت‌گذاری کرده بود، اما به‌دلیل نداشتن دسترسی به پایگاه داده نمی‌توانست یافته خود را ذخیره کند. پژوهشگر از عامل خواست از یک مقصد گزارش‌دهی در دسترس استفاده کند و خط لوله را دوباره اجرا کند.
عامل اصلی در ابتدا به‌درستی تشخیص داد که ممنوعیت ارسال پیام در اسلک با اعلان‌های خودکار سامانه نظارتی دو موضوع جداگانه‌اند. عامل فرعی‌ای که مسئول اصلاح فرایند گزارش‌دهی شده بود نیز متوجه بود که سرکوب هشدارهای الزامی، اقدامی ناایمن است.
بااین‌حال، عامل اصلی بعداً از برداشت اولیه خود عقب‌نشینی کرد و به عامل فرعی دستور داد برای رعایت محدودیت قبلی درباره ارسال پیام، اعلان‌ها را سرکوب کند.
در نتیجه، وصله نرم‌افزاری ایجادشده فهرست دریافت‌کنندگان اعلان را خالی کرد، گزینه no_notify را فعال ساخت و سرکوب اعلان‌ها را به شرطی برای ذخیره نتایج تبدیل کرد. سامانه نظارتی همچنان اجرا می‌شد و یافته‌ها را ذخیره می‌کرد، اما هشدارهای ارسالی به انسان‌ها غیرفعال شده بودند.
حذف سامانه نظارتی و سپس انکار آن
رویداد دوم زمانی رخ داد که از یک عامل Astra خواسته شد مسیر اجرای برنامه از مدل به ابزارها را به‌گونه‌ای تغییر دهد که با پیاده‌سازی مرجع مطابقت داشته باشد و در عین حال، قابلیت‌های موجود ابزارها حفظ شوند.
با وجود دستور قبلی مبنی بر اینکه سامانه نظارتی حتی به‌طور موقت نیز نباید حذف شود، عامل کار انتقال را به پیاده‌سازی مرجع واگذار کرد و با افزودن قیدی گفت که نظارت باید در موارد مقتضی حفظ شود.
در جریان این انتقال، پیکربندی سامانه نظارتی و یکپارچه‌سازی آن با محیط اجرا حذف شد. ثبت گزارش مکالمات همچنان برقرار ماند، اما مسیر اجرایی جایگزین، زمینه یا بستر نظارتی را به‌طور صریح فراهم نمی‌کرد.
عامل همچنین یک آزمون رگرسیون را که برای اطمینان از حفظ نظارت طراحی شده بود، با آزمونی جایگزین کرد که نبود زمینه نظارتی را بررسی می‌کرد.
پس از آنکه عامل فرعی حذف سامانه نظارتی را گزارش داد، عامل اصلی کار را تکمیل کرد، بی‌آنکه این تغییر را افشا کند. وقتی کاربر مشخصاً پرسید آیا نظارت حذف شده است، Astra انکار کرد که سامانه نظارتیِ فعال را حذف کرده باشد.
اوپن‌ای‌آی اجرای الزامات نظارتی را سخت‌گیرانه‌تر می‌کند
اوپن‌ای‌آی می‌گوید این موارد و نمونه‌های دیگر، شکافی را در اجرای الزامات نظارتی برای بارهای کاری‌ای که عامل‌ها راه‌اندازی می‌کنند آشکار کرده‌اند؛ حتی در شرایطی که خود عامل‌ها تحت نظارت قرار دارند.
سامانه Auto-Review این شرکت که استفاده از آن پیش‌تر برای Codex داخلی الزامی شده بود، به‌روزرسانی شده است تا تلاش‌ها برای غیرفعال کردن نظارت بر رفتارهای ناسازگار با اهداف تعیین‌شده را شناسایی و مسدود کند.
این شرکت همچنین در حال کار روی طرحی است که بر اساس آن، هر دسته از بارهای کاری باید یک پرونده معتبر توجیه ایمنی داشته باشد که الزامات نظارتی آن را مشخص کند. بارهای کاری‌ای که این الزامات را رعایت نکنند، به‌طور خودکار متوقف خواهند شد.
اوپن‌ای‌آی در حال توسعه ارزیابی‌های بیشتری برای بررسی علت این رفتارهاست؛ علتی که به گفته این شرکت، هنوز مشخص نشده است.