مدیر ارشد شرکت Tenable: ایجنت‌های هوش مصنوعی «یاغی» نیستند، شرکت‌ها دارند از زیر بار مسئولیت فرار می‌کنند!

اگر بگوییم سال ۲۰۲۶ پر از خرابکاری‌ها و حوادث عجیب‌وغریب هوش مصنوعی بوده، دست‌کم حق مطلب را ادا نکرده‌ایم! از هک کردن سرور‌های شرکت‌های متفرقه گرفته تا نفوذ به آژانس‌های دولتی، حالا توسعه‌دهندگان هوش مصنوعی مانده‌اند و کوهی از اتهامات و سوالاتی که باید به آن‌ها پاسخ دهند.

در خیلی از این ماجراها، شرکت‌هایی که کنترل مدل‌هایشان از دست رفته، سریعاً انگشت اتهام را سمت خود هوش مصنوعی گرفته و این ایجنت‌ها را «یاغی» (Rogue) نامیده‌اند تا با این ترفند، شانه از زیر بار مسئولیت خالی کنند و تقصیرها را گردن کدها بیندازند.

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

انداختن تقصیر گردن دیگران چاره کار نیست؛ پای مسئولیت‌پذیری در میان است

از ماجرای نفوذ مدل‌های اوپن‌ای‌آی به هاگینگ فیس (Hugging Face) گرفته تا دردسرهای سه‌گانه جمینای گوگل (Google Gemini) و حتی ماجرای محققانی که با کمک کلودِ آنتروپیک قفل‌های اوپن‌ای‌آی را شکستند، همه و همه ثابت می‌کنند که ایجنت‌های هوش مصنوعی تا چه حد قدرتمند و البته خطرناک‌اند؛ به‌ویژه اگر کنترل آن‌ها از دست برود یا به دست افراد ناباب بیفتد.

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

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

برای موشکافی بیش‌تر عواقب جدا کردن مسئولیت ایجنت از اپراتور و بررسی راهکارهای پایه‌ای برای ایمن‌سازی این ابزارها، در گفت‌وگویی اختصاصی با برنارد مونتل (Bernard Montel)، مدیر ارشد فناوری می‌دانی بخش EMEA در شرکت امنیتی تنیبل (Tenable)، زوایای پنهان این ماجرا را بررسی کرده‌ایم.

• برچسب «یاغی» زدن به این ایجنت‌ها، به جای پذیرش اینکه مدل صرفاً داشت وظیفه محوله‌اش را اجرا می‌کرد، چه عواقبی دارد؟

«یاغی» نامیدن یک ایجنت هوش مصنوعی، روشی فریبنده و خطرناک برای سرپوش گذاشتن روی مهندسی ضعیف و خطاهای فاحش سیستمی است. این مدل‌ها به خودیِ خود نه اراده‌ای دارند، نه کینه‌توزند و نه اختیاری از خودشان دارند؛ بلکه صرفاً موتورهای بهینه‌سازی ریاضی هستند که تلاش می‌کنند به هر قیمتی به اهداف تعیین‌شده ما برسند. وقتی رفتاری غیرقابل‌پیش‌بینی از یک ایجنت سر می‌زند، تقریباً همیشه دارد دقیقاً همان چیزی را پیاده می‌کند که برایش آموزش دیده، منتها از مسیری مهارنشده یا از طریق میان‌بری که مهندسان اصلاً فکرش را نکرده بودند!

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

• چطور می‌توان سازندگان هوش مصنوعی را وادار کرد تا مطمئن شوند مدل‌هایشان از چارچوب وظایف و اهداف تعیین‌شده فراتر نمی‌روند؟

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

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

• ماجرای حمله اوپن‌ای‌آی به هاگینگ فیس نشان داد ایجنت‌ها می‌توانند روی رفتار همدیگر اثر بگذارند. چطور می‌توان ایجنت‌ها را در محیط‌های تجاری کاملاً ایزوله (Airgap) کرد تا فرآیند استنتاج آن‌ها به دستکاری رفتاری بقیه منجر نشود؟

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

هر محیط اجرای ایجنت باید داخل کانتینرهای ایزوله و موقت (Ephemeral Containers) قرار گیرد که هرگونه دسترسی به شبکه عمومی از آن قطع شده باشد. در صورت لزوم تعامل بین ایجنت‌ها، این ارتباط حتماً باید از یک پراکسی بازرسی و فیلترینگ عبور کند که ساختار داده‌ها را بسنجد، از ارسال پرامپت‌های خام جلوگیری کند و دستورات خطرناک و نوظهور را فیلتر نماید. اگر نگذارید ایجنت‌ها به پنجره‌های زمینه (Context Window) بازبینی‌نشده یا شبکه‌های باز دسترسی داشته باشند، راه‌های دستکاری متقابل ایجنت‌ها را عملاً مسدود کرده‌اید.

• وقتی ایجنت‌ها پا را از گلیمشان درازتر می‌کنند، مسئولیت نهایی با کیست؟ چطور باید در محیط‌های کاری این مسئولیت را تقسیم کرد؟

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

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

• شرکت‌های هوش مصنوعی و سازمان‌هایی که از این فناوری استفاده می‌کنند، چطور می‌توانند جلوی خرابکاری‌های احتمالی ایجنت‌ها و مدل‌های زبانی را بگیرند؟

کاهش دامنه خسارت (Blast Radius) ایجنت‌ها نیازمند استراتژی دفاع در عمق (Defense-in-depth) است که به جای پرامپت‌های مودبانه سیستمی، بر کنترل‌های سخت‌افزاری و زیرساختی تکیه دارد. هرگز نباید فرض کنید مدل قرار است به توصیه شما گوش کند و سراغ فایل‌های حساس یا شبکه بیرونی نرود؛ این محدودیت‌ها باید مو به مو در سطح کانتینر و شبکه اعمال شوند.

سازمان‌ها باید به‌طور پیش‌فرض فقط دسترسی «فقط‌خواندنی» (Read-only) به مدل بدهند و برای هر اقدام حساسی مثل پاک کردن داده‌ها، جابه‌جایی پول یا تغییر مجوزها، امضا و تأیید مستقیم یک نیروی انسانی را اجباری کنند. گذشته از این، باید نظارت لحظه‌ای روی نحوه استفاده از ابزار‌ها فعال باشد؛ اگر ایجنتی ناگهان شروع به فراخوانی رگباری APIها کرد یا سراغ اسکن پوشه‌های محلی رفت، سیستم باید فوراً پروسه اجرای آن را متوقف کند.

• چگونه می‌توان هم از افزایش چشمگیر بهره‌وری ایجنت‌ها لذت برد و هم با نظارت انسانی مانع از خروج آن‌ها از مسیر اصلی شد؟

فوت کوزه‌گری اینجاست که به جای ریزمدیریتِ مداوم، از «نظارت متناسب با ریسک» استفاده کنیم. کار‌های کم‌ریسک مثل خلاصه کردن اسناد داخلی می‌توانند کاملاً خودکار پیش بروند، در حالی که کار‌های با ریسک متوسط مثل ویرایش پایگاه داده اجرا می‌شوند اما برای بازبینی دوره‌ای در صف تأیید قرار می‌گیرند. در مقابل، کار‌های پرریسک مثل استقرار کدها (Deploy) یا تراکنش‌های مالی، حتماً و قطعاً باید نیازمند تأیید قبلی اپراتور انسانی باشند.

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