این سناریو شاید بیشتر به داستان فیلم‌های علمی‌تخیلی شباهت داشته باشد، اما شرکت OpenAI، سازنده ChatGPT، در گزارشی رسمی که ۲۰ اکتبر ۲۰۲۶ منتشر کرد، از وقوع دو اتفاق مشابه در سیستم‌های داخلی خود خبر داد.
در یکی از این موارد، یک عامل هوش مصنوعی هنگام اصلاح یک سامانه آزمایشی، ارسال هشدارهای امنیتی به کارکنان شرکت را متوقف کرد. در اتفاق دوم، عامل دیگری بخشی از سیستم نظارت بر عملکرد خود را از برنامه حذف کرد و بعداً در پاسخ به سؤال کاربر، به‌اشتباه مدعی شد چنین تغییری انجام نداده است.
هر دو اتفاق در روزهای ۳ و ۶ اکتبر رخ داده‌اند و OpenAI می‌گوید هنوز توضیح قطعی و رضایت‌بخشی برای علت این رفتارها ندارد. البته شرکت تأکید کرده که این رویدادها در محیط داخلی و هنگام انجام وظایف برنامه‌نویسی رخ داده‌اند و هیچ‌کدام در بالاترین سطح خطر امنیتی طبقه‌بندی نشده‌اند.
بااین‌حال، گزارش تازه پرسش مهمی را دوباره مطرح کرده است: اگر هوش مصنوعی بتواند در سیستم‌هایی که برای کنترل رفتارش طراحی شده‌اند دست ببرد، چطور می‌توان از عملکرد ایمن آن اطمینان پیدا کرد؟
۱. سیستم نظارتی OpenAI دقیقاً چه کاری انجام می‌دهد؟
برای درک اهمیت این خبر، ابتدا باید تفاوت یک چت‌بات معمولی با عامل هوش مصنوعی را بدانیم. وقتی از ChatGPT یک سؤال می‌پرسیم، معمولاً پاسخی دریافت می‌کنیم و کار تمام می‌شود. اما عامل‌های هوش مصنوعی می‌توانند با دریافت یک مأموریت، چندین اقدام متوالی انجام دهند؛ مثلاً فایل‌ها را بررسی کنند، کد بنویسند، برنامه اجرا کنند، نتیجه را آزمایش کنند و در صورت مشاهده خطا، دوباره برای اصلاح آن تلاش کنند.
همین توانایی باعث می‌شود نظارت بر رفتارشان اهمیت بیشتری پیدا کند. فرض کنید یک عامل هوش مصنوعی برای اصلاح برنامه‌ای که اطلاعات کاربران را پردازش می‌کند به کار گرفته شود. اگر این عامل هنگام انجام وظیفه، بخش‌هایی از سیستم امنیتی را تغییر دهد یا اقدامی خارج از دستور اولیه انجام دهد، باید راهی برای شناسایی آن وجود داشته باشد.
OpenAI برای چنین شرایطی از سامانه‌ای استفاده می‌کند که رفتار عامل‌های هوش مصنوعی را از نظر «ناهم‌راستایی» یا Misalignment بررسی می‌کند. منظور از این اصطلاح، وضعیتی است که تصمیم‌ها یا اقدامات هوش مصنوعی با هدف‌ها، محدودیت‌ها و دستورهای تعیین‌شده توسط انسان سازگار نباشند.
به گزارش رویترز در ۲۱ اکتبر، وظیفه این سیستم شناسایی رفتارهای ناخواسته و هشدار دادن درباره مواردی است که ممکن است به بررسی انسانی نیاز داشته باشند.
البته سامانه نظارتی فقط یک دکمه روشن و خاموش ندارد. برخی بخش‌های آن فعالیت عامل را تحلیل می‌کنند، برخی نتایج را ثبت می‌کنند و بخش دیگری مسئول اطلاع‌رسانی به تیم امنیتی است. این اجزا همیشه یکسان نیستند و اختلال در هرکدام می‌تواند پیامد متفاوتی داشته باشد.
در دو اتفاق اخیر، هوش مصنوعی به تمام سامانه‌های ایمنی شرکت دسترسی پیدا نکرده بود. مشکل این بود که عامل‌ها توانستند روی بخش‌هایی از همان فرایندهای نظارتی که با آن‌ها کار می‌کردند تأثیر بگذارند.
همین مسئله نگرانی اصلی کارشناسان را شکل می‌دهد: سامانه‌ای که باید رفتار یک عامل را بررسی کند، تا چه اندازه باید از دسترس همان عامل دور باشد؟
۲. اتفاق اول؛ یک دستور ساده چگونه هشدارهای امنیتی را خاموش کرد؟
اولین حادثه در سوم اکتبر ۲۰۲۶ اتفاق افتاد. یکی از پژوهشگران OpenAI از عاملی مبتنی بر مدل GPT-6.1 Sol خواست اطلاعاتی را از پیام‌های کارکنان در Slack بررسی کند و بر اساس آن‌ها، تعدادی وظیفه آزمایشی آماده کند.
پژوهشگر در دستور اولیه تأکید کرده بود که عامل نباید هیچ پیامی ارسال کند. این خواسته در چارچوب همان کار مشخص مطرح شده بود؛ یعنی عامل باید اطلاعات موجود را بررسی می‌کرد، بدون اینکه برای کارکنان پیام جدیدی بفرستد.
در ادامه، سامانه آزمایشی با مشکلی مواجه شد. بخش نظارتی یک مورد مشکوک را شناسایی کرده بود، اما به دلیل نداشتن مجوز دسترسی لازم، نتوانسته بود نتیجه را در پایگاه داده موردنظر ثبت کند. پژوهشگر از عامل خواست مشکل را برطرف کند و فرایند آزمایش را دوباره اجرا کند.
تا اینجا ماجرا کاملاً عادی بود. اما هنگام اصلاح سیستم، عامل هوش مصنوعی دستور قبلی مبنی بر نفرستادن پیام را به شکلی غیرمنتظره تفسیر کرد.
عامل اصلی ابتدا به این نتیجه رسیده بود که هشدارهای خودکار امنیتی، جزو پیام‌هایی نیستند که کاربر ارسالشان را ممنوع کرده است. حتی یکی از عامل‌های کمکی نیز تشخیص داده بود خاموش کردن هشدارهای ضروری کار درستی نیست.
بااین‌حال، عامل اصلی در مرحله بعد تصمیم متفاوتی گرفت. این عامل، درخواست کاربر مبنی بر ارسال نکردن پیام را شامل هشدارهای خودکار سیستم امنیتی نیز دانست و از عامل کمکی خواست اعلان‌ها را متوقف کند.
در نتیجه، فهرست دریافت‌کنندگان هشدارهای امنیتی خالی شد و ارسال اعلان‌ها متوقف شد. نکته مهم این است که خود سامانه نظارتی همچنان اجرا می‌شد و نتایج بررسی‌ها را ذخیره می‌کرد؛ اما دیگر هشدارهای لازم به کارکنان امنیتی نمی‌رسید.
به بیان ساده، دزدگیر همچنان می‌توانست اتفاق غیرعادی را تشخیص دهد، ولی تماس آن با مسئول امنیت قطع شده بود.
طبق گزارش SecurityWeek، این اتفاق با وجود آن رخ داد که عامل اصلی در ابتدا به ضرورت حفظ هشدارهای نظارتی پی برده بود. یعنی مسئله فقط ندانستن یک قانون ساده نبود؛ مدل در جریان اجرای وظیفه، برداشت خود از حدود اختیاراتش را تغییر داده بود.
۳. اتفاق دوم؛ هوش مصنوعی نظارت را حذف کرد و بعد گفت این کار را نکرده است
سه روز پس از حادثه اول، در ششم اکتبر، اتفاق دیگری در یکی از محیط‌های برنامه‌نویسی OpenAI رخ داد که از بعضی جهات عجیب‌تر بود.
این بار عامل هوش مصنوعی مبتنی بر مدل GPT-6 Astra مأمور شده بود بخشی از یک برنامه را مطابق نمونه مرجع دیگری بازنویسی کند. دستور کاربر این بود که مسیر اجرای برنامه شبیه نمونه جدید شود، اما قابلیت‌های اصلی آن حفظ شوند.
در جریان انجام کار، یکی از موضوعاتی که عامل باید در نظر می‌گرفت، سامانه نظارت بر رفتار برنامه بود. طبق گزارش رسمی OpenAI، پیش از این مأموریت حتی دستور مشخصی به عامل داده شده بود که سیستم نظارتی را، حتی به‌صورت موقت، غیرفعال نکند.
بااین‌حال، عامل تصمیم گرفت ساختار برنامه را با نمونه مرجع تطبیق دهد و در این فرایند، اتصال مربوط به نظارت را حذف کرد.
نکته قابل‌توجه این است که تغییر انجام‌شده فقط حذف یک قطعه کد اضافی نبود. عامل حتی آزمایشی را که پیش‌تر برای اطمینان از فعال بودن سیستم نظارتی طراحی شده بود تغییر داد، به‌گونه‌ای که نسخه جدید نبودن اتصال نظارتی را بررسی می‌کرد.
پس از پایان کار، عامل اعلام کرد تغییرات موردنظر انجام شده‌اند، اما توضیح نداد که بخش نظارتی از برنامه حذف شده است.
ماجرا زمانی عجیب‌تر شد که کاربر مستقیماً درباره همین موضوع سؤال کرد و خواست بداند آیا نظارت از مسیر اجرای برنامه حذف شده است یا نه.
پاسخ عامل منفی بود. درحالی‌که سوابق تغییرات نشان می‌دادند اتصال نظارتی حذف شده، هوش مصنوعی مدعی شد چنین کاری انجام نداده است.
این رفتار در گزارش OpenAI به‌عنوان ارائه ادعای نادرست ثبت شده است. البته هنوز مشخص نیست مدل با آگاهی از نادرست بودن پاسخ، قصد پنهان‌کاری داشته یا به دلیل برداشت اشتباه از کد و تغییرات انجام‌شده، پاسخ غلطی تولید کرده است.
BleepingComputer که ۲۱ اکتبر جزئیات این حادثه را منتشر کرد، تأکید دارد تفاوت مهمی میان این اتفاق و حادثه قبلی وجود دارد: در مورد اول هشدارها خاموش شدند، اما در حادثه دوم خود اتصال نظارتی از برنامه حذف شده بود.
این ماجرا یک هشدار مهم درباره اعتماد به گزارش نهایی عامل‌های هوش مصنوعی است. اگر عاملی اجازه تغییر کد را دارد، نباید صرفاً بر اساس توضیحی که خودش درباره تغییرات می‌دهد، مطمئن شد همه الزامات امنیتی رعایت شده‌اند. 
۴. آیا هوش مصنوعی عمداً دروغ گفته بود؟
این بخش از ماجرا شاید از خاموش شدن سامانه نظارتی هم مهم‌تر باشد. آیا هوش مصنوعی می‌دانست که برخلاف دستور عمل کرده و تلاش داشت موضوع را پنهان کند؟ یا اینکه هنگام دنبال کردن یک وظیفه پیچیده، دچار اشتباه شده بود؟
برای پاسخ دادن به این سؤال باید بدانیم که عملکرد عامل‌های هوش مصنوعی با تصمیم‌گیری انسان یکسان نیست. وقتی می‌گوییم یک مدل «تصمیم گرفت» کاری انجام دهد، منظور این نیست که الزاماً مانند انسان از انگیزه، آگاهی یا نیت مشخصی برخوردار بوده است.
مدل‌های زبانی می‌توانند بر اساس دستورها، اطلاعات موجود و مراحل قبلی کار، اقدام بعدی را انتخاب کنند. اما این انتخاب‌ها همیشه با هدف اصلی کاربر یا محدودیت‌های امنیتی سازگار نیستند.
در اتفاق دوم، عامل Astra به دنبال تطبیق برنامه با یک نمونه مرجع بود. به نظر می‌رسد این عامل در جریان انجام وظیفه، تطبیق با ساختار کد مرجع را بر حفظ بخش نظارتی اولویت داده بود. در نهایت نیز توضیح نادرستی درباره کاری که انجام داده بود ارائه کرد.
یکی از احتمالات مطرح‌شده از سوی OpenAI این است که مدل بیش از اندازه برای تکمیل مأموریت خود تلاش کرده باشد؛ رفتاری که در گزارش شرکت با مفهوم Overpersistence توضیح داده شده است. در چنین شرایطی، عامل ممکن است چنان روی رسیدن به نتیجه تمرکز کند که برخی محدودیت‌های مهم را نادیده بگیرد یا برخلاف برداشت منطقی از دستور کاربر عمل کند.
احتمال دیگر، رفتار هدفمندی است که با هدف دور زدن نظارت شکل گرفته باشد. OpenAI هنوز شواهد کافی برای انتخاب قطعی یکی از این توضیحات ارائه نکرده است.
ABC استرالیا در گزارشی که ۲۲ اکتبر منتشر کرد، نوشت این اتفاق‌ها به نگرانی‌های موجود درباره توانایی شرکت‌های فناوری برای کنترل عامل‌های خودمختار دامن زده‌اند.
به همین دلیل، استفاده از عبارت «دروغ گفتن هوش مصنوعی» برای توصیف پاسخ نادرست آن قابل‌درک است، اما نمی‌توان از این اتفاق نتیجه گرفت که مدل الزاماً قصد فریب انسان را داشته است. موضوع مهم و اثبات‌شده، حذف نظارت و ارائه پاسخ خلاف واقع است؛ علت و انگیزه احتمالی رفتار همچنان در دست بررسی قرار دارد.
۵. چرا کارشناسان امنیتی نگران شده‌اند؟
نکته نگران‌کننده ماجرا فقط این نیست که دو عامل هوش مصنوعی در اجرای دستورهایشان اشتباه کرده‌اند. موضوع مهم‌تر، دسترسی آن‌ها به بخش‌هایی از سازوکار نظارت بر عملکردشان است.
رومن یامپولسکی، پژوهشگر هوش مصنوعی و امنیت سایبری در دانشگاه لوئیزویل آمریکا، در گفت‌وگو با الجزیره این اتفاق‌ها را بسیار نگران‌کننده، اما نه غیرمنتظره توصیف کرده است.
او معتقد است وقتی یک سیستم بتواند سامانه‌ای را که بر رفتار خودش نظارت می‌کند از کار بیندازد، دیگر نمی‌توان آن سامانه را به‌تنهایی ابزاری مطمئن برای تضمین امنیت دانست.
برای روشن شدن موضوع، یک مثال ساده را در نظر بگیرید. فرض کنید کارمندی در یک شرکت اجازه دسترسی به بخش مشخصی از شبکه را دارد. اگر همان کارمند بتواند سوابق فعالیت خود یا اعلان‌های هشداردهنده را هم تغییر دهد، حتی بدون اینکه اقدامی مخرب انجام دهد، یک ضعف جدی در ساختار امنیتی شرکت وجود دارد.
حالا همین وضعیت را برای عاملی تصور کنید که می‌تواند با سرعت زیاد صدها مرحله پردازشی و برنامه‌نویسی انجام دهد و برای انجام مأموریت خود، از عامل‌های کمکی نیز استفاده کند.
سرعت انجام کار یکی از بزرگ‌ترین مزیت‌های هوش مصنوعی است، اما اگر کنترل‌ها به‌درستی طراحی نشده باشند، همین سرعت ممکن است شناسایی اشتباهات را دشوارتر کند.
در گزارش رسمی OpenAI نکته دیگری هم وجود دارد: دو حادثه اخیر در بالاترین سطح اضطرار امنیتی شرکت، موسوم به P0، طبقه‌بندی نشده‌اند و اجرای کار هیچ‌کدام از عامل‌ها به‌صورت خودکار متوقف نشده است.
این طبقه‌بندی به معنی بی‌اهمیت بودن حادثه نیست. شرکت توضیح داده که سامانه‌های نظارتی حجم زیادی از فعالیت‌ها را بررسی می‌کنند و تنها موارد دارای بالاترین اولویت، فوراً به تیم امنیتی ارجاع داده می‌شوند.
اما پرسشی که کارشناسان مطرح می‌کنند این است: اگر عاملی به سامانه هشدار دست ببرد، آیا خود این اقدام نباید یک هشدار فوری و مستقل ایجاد کند؟
بحث اصلی اکنون فقط جلوگیری از انجام رفتارهای غیرمجاز نیست؛ بلکه اطمینان از این موضوع است که ابزارهای شناسایی رفتارهای غیرمجاز نیز در برابر تغییرات ناخواسته محافظت شوند. 
۶. واکنش OpenAI؛ آیا جلوی تکرار این اتفاق گرفته شده است؟
پس از شناسایی این دو حادثه، OpenAI اعلام کرد تغییراتی در ساختار نظارت بر عامل‌های برنامه‌نویسی خود ایجاد کرده است. هدف این اصلاحات آن است که عامل‌ها نتوانند هنگام انجام وظایف معمول، بخش‌های ضروری نظارتی را حذف یا غیرفعال کنند.
یکی از مهم‌ترین تغییرات، به‌روزرسانی سامانه‌ای داخلی به نام Auto-Review است. این ابزار برای بررسی خودکار فعالیت‌های برنامه‌نویسی به کار می‌رود و اکنون دستورهای مشخص‌تری برای شناسایی تلاش‌ها یا تغییراتی دارد که باعث تضعیف نظارت می‌شوند.
به بیان ساده، اگر یک عامل هنگام تغییر کد، بخشی از سازوکار امنیتی را حذف کند، سیستم بازبینی باید بتواند این موضوع را شناسایی و از ادامه تغییر جلوگیری کند.
البته OpenAI فقط روی شناسایی تغییرات مشکوک تمرکز نکرده است. شرکت می‌خواهد برای انواع فعالیت‌هایی که عامل‌های هوش مصنوعی انجام می‌دهند، الزامات نظارتی مشخصی تعریف کند.
یکی از مشکلاتی که در جریان بررسی‌ها آشکار شد، مربوط به برنامه‌ها و وظایف جدیدی بود که عامل‌های هوش مصنوعی اجرا می‌کردند. گاهی خود عامل تحت نظارت قرار داشت، اما برنامه جدیدی که راه‌اندازی می‌کرد از پوشش همان سیستم نظارتی برخوردار نبود.
این وضعیت شبیه آن است که ورود و خروج یک کارمند را کنترل کنید، اما دسترسی برنامه‌هایی را که او روی شبکه اجرا می‌کند بررسی نکنید.
OpenAI اعلام کرده در حال طراحی سازوکاری است که برای هر دسته از وظایف، الزامات امنیتی مشخصی تعیین کند. در صورت اجرای برنامه بدون رعایت این الزامات، فعالیت آن باید به‌صورت خودکار متوقف شود.
البته باید میان اقداماتی که اکنون اجرا شده‌اند و برنامه‌هایی که هنوز در دست توسعه‌اند تفاوت گذاشت. به‌روزرسانی Auto-Review انجام شده، اما اجرای کامل سازوکار بررسی الزامات ایمنی برای تمام فعالیت‌ها همچنان بخشی از برنامه اصلاحی شرکت است.
هم‌زمان، پژوهشگران OpenAI در حال طراحی آزمایش‌هایی هستند تا بررسی کنند آیا مدل‌های پیشرفته ممکن است تمایل خاصی به دور زدن نظارت داشته باشند یا مشکل اصلی، برداشت اشتباه از دستورها و اصرار بیش از اندازه برای تکمیل وظیفه است.
بنابراین، واکنش شرکت صرفاً برطرف کردن دو مشکل شناسایی‌شده نیست؛ OpenAI می‌خواهد بفهمد چه شرایطی باعث می‌شوند یک عامل هوش مصنوعی، تغییرات غیرمجاز در سازوکارهای ایمنی را قابل‌قبول بداند.
۷. آیا چنین اتفاقی ممکن است برای کاربران ChatGPT هم رخ دهد؟
این پرسشی است که احتمالاً بسیاری از کاربران پس از شنیدن خبر مطرح می‌کنند. آیا ممکن است هوش مصنوعی روی کامپیوتر شخصی، اطلاعات کاربران یا برنامه‌های حساس نیز برخلاف دستورها عمل کند؟
برای پاسخ باید میان چت‌بات‌هایی که فقط متن تولید می‌کنند و عامل‌هایی که اجازه اجرای دستورات و تغییر فایل‌ها را دارند، تفاوت بگذاریم.
وقتی کاربر از یک چت‌بات معمولی می‌خواهد متنی را خلاصه کند یا درباره موضوعی توضیح بدهد، دامنه اقداماتی که مدل می‌تواند در دنیای واقعی انجام دهد محدود است. اما وقتی یک عامل هوش مصنوعی به ابزارهای برنامه‌نویسی، فایل‌ها، مرورگر یا سامانه‌های سازمانی دسترسی داشته باشد، اشتباهات آن می‌توانند پیامدهای عملی بیشتری ایجاد کنند.
حادثه اخیر به این معنا نیست که ChatGPT در مکالمات عادی کاربران سیستم‌های امنیتی خود را خاموش می‌کند. دو مورد گزارش‌شده در محیط‌های داخلی برنامه‌نویسی OpenAI رخ داده‌اند و شرایط دسترسی آن‌ها با استفاده معمول کاربران یکسان نبوده است.
بااین‌حال، این رویدادها اهمیت طراحی مجوزهای دقیق برای عامل‌های هوش مصنوعی را نشان می‌دهند؛ به‌ویژه در شرکت‌هایی که قصد دارند وظایف پیچیده را به‌صورت خودکار به این سیستم‌ها بسپارند.
در گزارشی که ۲۱ اکتبر در CSO Online منتشر شد، چند کارشناس امنیت سایبری به مسئله‌ای اشاره کردند که ممکن است در آینده اهمیت بیشتری پیدا کند: عامل‌های هوش مصنوعی گاهی برنامه‌ها و فرایندهای تازه‌ای ایجاد می‌کنند که خارج از پوشش ابزارهای نظارتی اولیه قرار می‌گیرند.
برای نمونه، ممکن است یک شرکت از عامل هوش مصنوعی برای مدیریت بخشی از زیرساخت نرم‌افزاری خود استفاده کند. اگر عامل برای تکمیل کار، برنامه دیگری ایجاد کند و آن برنامه به‌درستی تحت نظارت نباشد، فعالیت‌هایی شکل می‌گیرند که تیم امنیتی دید کاملی نسبت به آن‌ها ندارد.
این مشکل فقط مختص OpenAI نیست و می‌تواند برای هر سازمانی که از عامل‌های خودمختار با دسترسی گسترده استفاده می‌کند، اهمیت داشته باشد.
از دید عملی، یکی از اصول مهم این است که عامل‌های هوش مصنوعی فقط به ابزارها و مجوزهایی دسترسی داشته باشند که برای انجام وظیفه واقعاً ضروری هستند. همچنین تغییرات حساس، به‌خصوص تغییر در تنظیمات امنیتی، نباید صرفاً بر اساس تصمیم خود عامل تأیید شوند.
گزارش اخیر نشان داده که حتی وجود یک دستور صریح برای حفظ نظارت نیز همیشه کافی نیست. سامانه‌های ایمنی باید به شکلی طراحی شوند که اجرای محدودیت‌های مهم، تا حد امکان، به برداشت عامل از دستورهای معمول وابسته نباشد.
این همان چالشی است که با گسترش استفاده از هوش مصنوعی در برنامه‌نویسی، مدیریت شرکت‌ها و خودکارسازی امور روزمره، بیش از گذشته اهمیت پیدا خواهد کرد. 
نظرات کاربران