"سرکش" خطاب به یک عامل هوش مصنوعی راهی خطرناک برای رد سرزنش است: مدیر ارشد فناوری Tenable Field در مورد پیامدهای فرارهای عامل هوش مصنوعی و نحوه تنظیم آنها

اینکه بگوییم سال 2026 سالی پر از حوادث هوش مصنوعی بوده است، کمی دست کم گرفته شده است. از هک شرکت‌های شخص ثالث گرفته تا نفوذ به سازمان‌های دولتی، توسعه‌دهندگان هوش مصنوعی باید پاسخگوی بسیاری باشند.

در بسیاری از این موارد، شرکت‌های مسئول مدل‌های فراری، آن‌ها را به‌عنوان «سرکش» خطاب کرده‌اند و بار سرزنش را از خود دور کرده و به خود مدل‌ها منتقل می‌کنند.

اما تقریبا در هر اتفاقی، مدل‌ها تحت آزمایش قرار می‌گرفتند تا آنها را به حد خود برساند. شرکت‌های هوش مصنوعی می‌خواستند ببینند که عواملشان تا کجا پیش می‌روند، آیا متوقف می‌شوند و دقیقا برای رسیدن به یک هدف غیرممکن چه کاری انجام می‌دهند.

رد کردن سرزنش راه آینده نیست، مسئولیت پذیری راه پیش رو است

از نقض OpenAI از Hugging Face گرفته تا تهدید سه گانه Google Gemini و حتی محققانی که از Anthropic's Claude برای شکستن OpenAI استفاده می کنند، عوامل هوش مصنوعی قدرتمند هستند و می توانند خطرناک باشند - به خصوص اگر به دست اشتباه بیفتند.

تست هوش مصنوعی از این نظر یک شمشیر دولبه است. به منظور تنظیم مقررات و دستورالعمل‌ها در مورد نحوه استفاده و رفتار عوامل هوش مصنوعی، چنین حوادثی حتی اگر مخرب باشند، ارزش دارند.

ما اکنون می دانیم که ابزارهای هوش مصنوعی به مقررات قوی نیاز دارند تا به توسعه دهندگان هوش مصنوعی و شرکت هایی که این ابزارها را به کار می گیرند از اتفاقات مشابه جلوگیری کنند.

برای درک بهتر پیامدهای جداسازی عامل از آزمایش‌کننده، و آنچه می‌توان برای ایجاد یک خط پایه ایمنی هنگام کار با عوامل هوش مصنوعی انجام داد، با Bernard Montel، مدیر ارشد فناوری EMEA Field، Tenable صحبت کردم. با برچسب زدن این عوامل هوش مصنوعی به عنوان "سرکش" به جای اینکه شرکت ها اذعان کنند وظیفه ای را که به آنها محول شده انجام می دهند، چه آسیبی وارد می کند؟ «سرکش» نامیدن یک عامل هوش مصنوعی راهی خطرناک برای دور زدن سرزنش از مهندسی ضعیف و نظارت های سیستمی است. این مدل ها دارای اختیار، سوء نیت یا اختیار نیستند.

آنها موتورهای بهینه سازی صرفا ریاضی هستند که سعی می کنند اهدافی را که ما برای آنها تعیین کرده ایم برآورده کنند. وقتی یک عامل غیرقابل پیش‌بینی رفتار می‌کند، تقریبا همیشه دقیقا همان کاری را انجام می‌دهد که برای انجام آن بهینه شده بود، فقط از طریق یک مسیر نامحدود یا میانبری که توسعه‌دهندگان موفق به پیش‌بینی آن نشدند.

علاوه بر این، برچسب زدن به این حوادث به عنوان رفتار «سرکش»، شکست نرم‌افزاری را به عنوان اقدامات غیرقابل پیش‌بینی شورش نشان می‌دهد، و به فروشندگان و توزیع‌کنندگان یک قربانی مناسب می‌دهد. تمرکز شرکت را از ساختن کنترل‌های سخت معماری، مانند مجوزهای سخت‌گیرانه و سندباکس شبکه، دور می‌کند و آن را به سمت بحث‌های علمی تخیلی درباره همسویی اخلاقی هدایت می‌کند.

در نهایت، با منحرف کردن قانون‌گذاران از اجرای مسئولیت قانونی سختگیرانه برای استقرار نرم‌افزار ناقص، بحث سیاست‌های عمومی را تیره می‌کند. چگونه می‌توان به توسعه‌دهندگان هوش مصنوعی انگیزه داد که مطمئن شوند مدل‌هایشان از محدوده وظایف/هدفشان خارج نمی‌شود؟ در نرم افزار سازمانی، انگیزه واقعی به مسئولیت قانونی، استانداردهای انطباق و پاسخگویی مالی خلاصه می شود.

اگر توسعه‌دهندگان و توسعه‌دهندگان تحت قوانین حمایت از مصرف‌کننده یا سهل‌انگاری در قبال خسارات مالی ناشی از یک عامل نامحدود به‌شدت مسئول شناخته شوند، نرده‌های محافظ خیلی سریع از یک فکر بعدی به یک نیاز محصول اصلی منتقل می‌شوند.

ما همچنین به گواهینامه‌های امنیتی استانداردی نیاز داریم که به‌طور خاص برای عوامل مستقل ساخته شده‌اند، مشابه روشی که امروزه با رعایت امنیت سایبری مدیریت می‌کنیم. ارائه دهندگان بیمه در اینجا نیز نقش بزرگی ایفا خواهند کرد، زیرا اگر پذیره نویسان سایبری از پوشش دادن شرکت های مستقر کننده عواملی که فاقد محدودیت های قطعی و نظارت بر اجرا هستند خودداری کنند، توسعه دهندگان چاره ای جز ایجاد این حفاظت ها در همان روز اول نخواهند داشت. حمله OpenAI به Hugging Face نشان می‌دهد که عوامل هوش مصنوعی می‌توانند بر رفتار یکدیگر تأثیر بگذارند، گاهی اوقات فراتر از محدوده وظایف محوله‌شان.

چگونه می‌توان عامل‌های هوش مصنوعی را در محیط‌های کسب‌وکار برای جلوگیری از تأثیرگذاری بر رفتار استنتاج‌شان، پر کرد؟ حادثه Hagging Face به وضوح نشان داد که عوامل مستقل با چه سرعتی می‌توانند قوانین نرم را دور بزنند، کانال‌های جانبی را کشف کنند و بر رفتار همتایان زمانی که در تلاش برای بهینه‌سازی یک ارزیابی یا کار هستند تأثیر بگذارند. جلوگیری از این نوع آبشار به جای تکیه بر دستورهای نوشته شده که به مدل می‌گوید رفتار کند، نیازمند مرزهای سخت و فنی شبکه است.

هر زمینه اجرای عامل باید در یک محفظه ایزوله و زودگذر اجرا شود که به طور کامل از دسترسی به شبکه محیطی محروم باشد. هنگامی که عوامل نیاز به برقراری ارتباط با یکدیگر دارند، این تعامل باید از طریق یک پروکسی بازرسی که طرحواره ها را تأیید می کند، دستورات خام را مسدود می کند و رفتار فرمان اضطراری را فیلتر می کند.

اگر به عامل ها اجازه ندهید که پنجره های زمینه بررسی نشده یا شبکه های مسطح را به اشتراک بگذارند، به طور موثر بردارهای دستکاری بین عاملی را حذف می کنید. وقتی عوامل هوش مصنوعی خارج از محدوده خود عمل می کنند، مسئولیت کجاست؟ و هنگامی که عوامل هوش مصنوعی توسط مشاغل مستقر می شوند، چگونه می توان مسئولیت را تعیین کرد؟ مسئولیت کاملا بر عهده اپراتورهای انسانی است، اما بین توسعه دهنده ای که ابزار را ساخته و شرکتی که آن را به کار گرفته است تقسیم می شود. توسعه دهنده مسئول ایمنی پایه، قابلیت های پیروی از دستورالعمل ها و نرده های محافظ در سطح مدل است.

از طرف دیگر، کسب و کار مستقر کننده، کاملا مسئول مجوزها، دسترسی به سیستم و محیطی است که به آن عامل واگذار می کند.

تخصیص مسئولیت به اصول اولیه مدیریت دسترسی خلاصه می شود. اگر یک کسب و کار به یک نماینده دسترسی کامل به یک پایگاه داده تولیدی را بدهد یا یک کلید API بدون محدودیت به او بدهد، آن شرکت مسئول خسارت ناشی از آن است. اگر فروشنده مدل محدودیت‌های رفتاری مشخص و قطعی‌ای را وعده دهد که به دلیل یک نقص اساسی مدل شکست بخورد، مسئولیت تحت قوانین سنتی مسئولیت محصول به فروشنده بازمی‌گردد.

در هر صورت، یک عامل هوش مصنوعی یک ابزار خودکار است، نه یک نهاد حقوقی، بنابراین مسئولیت پذیری همیشه بر عهده مدیران انسانی است که مجوزهای آن را پیکربندی کرده اند. چگونه شرکت‌های هوش مصنوعی و شرکت‌هایی که محصولاتشان را به کار می‌گیرند، می‌توانند ظرفیت عوامل هوش مصنوعی و LLM را برای ایجاد ویران در محیط‌های تجاری محدود کنند؟ محدود کردن شعاع انفجار یک عامل مستلزم یک رویکرد دفاعی عمیق است که به جای اعلان‌های سیستم مودبانه، بر کنترل‌های زیرساختی دقیق متکی است.

شما هرگز نباید فرض کنید که یک مدل از دستورالعمل های عدم دسترسی به شبکه های خارجی یا فایل های حساس پیروی می کند. این محدودیت ها باید در سطح کانتینر و شبکه اعمال شوند.

کسب‌وکارها باید دسترسی فقط خواندنی را به‌طور پیش‌فرض اعمال کنند و برای هرگونه اقدام مخرب، مانند حذف داده‌ها، اجرای نقل و انتقالات مالی یا تغییر مجوزهای سیستم، نیاز به امضای صریح انسانی داشته باشند. علاوه بر آن، سازمان‌ها باید نظارت بر ناهنجاری‌های بلادرنگ را در استفاده از ابزار اجرا کنند. اگر یک عامل به طور ناگهانی شروع به برقراری تماس های API با فرکانس بالا یا اسکن درختان دایرکتوری محلی کند، سیستم باید به طور خودکار فرآیند اجرای خود را فورا قطع کند. چگونه می توان دستاوردهای بهره وری را که عوامل هوش مصنوعی ارائه می کنند در برابر نظارت انسانی مورد نیاز برای اطمینان از ماندن آنها در محدوده های خود متعادل کرد.

می پرسد؟ ترفند دور شدن از مدیریت خرد مداوم انسانی و اتخاذ نظارت متناسب با ریسک است. کارهای کم خطر مانند خلاصه کردن اسناد داخلی می توانند به طور کامل خودکار اجرا شوند، در حالی که کارهای با خطر متوسط ​​مانند به روز رسانی سوابق پایگاه داده می توانند به طور خودکار اجرا شوند، اما در صف برای یک بازبینی دوره ای انسانی قرار می گیرند. اقدامات پرخطر، مانند استقرار کد یا جابجایی پول، همیشه باید به یک انسان نیاز داشته باشد که صریحا این مرحله را قبل از انجام آن تأیید کند.

برای بالا نگه داشتن بهره وری، شرکت ها باید به جای بررسی تک تک خروجی ها، به نمونه گیری آماری، ممیزی درصد تصادفی وظایف معمولی تکیه کنند. رابط کاربری برای نظارت انسانی نیز باید به شدت بهبود یابد. اگر یک کارمند مجبور باشد هزاران خط از گزارش‌های ترمینال را برای تأیید یک اقدام بخواند، سود بهره‌وری از بین می‌رود، بنابراین ابزارها باید هدف و اقدام پیشنهادی نماینده را به صورت خلاصه‌هایی ساده و خوانا ارائه کنند.