فراخوان ۱۰ میلیون دلاری Google DeepMind برای مهار ریسکهای هوش مصنوعی چندعاملی
Google DeepMind با مشارکت چند مؤسسه علمی و حمایت Google.org، فراخوانی با بودجه حداکثر ۱۰ میلیون دلار برای پژوهش درباره ایمنی سیستمهای هوش مصنوعی چندعاملی منتشر کرده است. این برنامه بهدنبال حل یکی از چالشهای مهم نسل بعدی هوش مصنوعی است: چگونه میتوان رفتار میلیونها AI Agent مستقل را هنگام ارتباط، مذاکره و انجام تراکنش، ایمن، قابلکنترل و پیشبینیپذیر نگه داشت؟
مهلت ارسال درخواست برای این فراخوان ۱۷ مرداد ۱۴۰۵ اعلام شده و قرار است برگزیدگان در پاییز همان سال معرفی شوند.
چرا ایمنی هوش مصنوعی چندعاملی به یک مسئله جدی تبدیل شده است؟
نسل کنونی ارزیابیهای ایمنی هوش مصنوعی عمدتاً روی یک مدل یا یک عامل منفرد تمرکز دارد. در این ارزیابیها بررسی میشود که آیا مدل پاسخ زیانبار تولید میکند، اطلاعات حساس را افشا میکند، دستور غیرمجاز اجرا میکند یا در برابر حملات Prompt Injection مقاوم است.
این رویکرد برای یک مدل مستقل لازم است، اما برای آیندهای متشکل از میلیونها عامل متعامل کافی نخواهد بود.
در سیستمهای چندعاملی، ریسک فقط از رفتار یک Agent به وجود نمیآید. حتی اگر هر عامل بهتنهایی رفتار قابلقبولی داشته باشد، تعامل تعداد زیادی از عاملها ممکن است به پیامدهایی منجر شود که طراحان هیچیک از آنها پیشبینی نکردهاند.
نمونه این پیامدها عبارتاند از:
- تشکیل الگوهای هماهنگی ناخواسته میان عاملها
- انتشار آبشاری اطلاعات غلط یا مخرب
- دستکاری سیستمهای اعتبار و شهرت
- انجام تراکنشهای غیرمنتظره با سرعت بالا
- سوءاستفاده از اعتماد بین عاملها
- حرکت جانبی عامل آلوده در یک شبکه
- شکلگیری تبانی یا رفتار جمعی مخرب
- افزایش نوسان در بازارهای خودکار
- انتقال خطای یک Agent به کل زنجیره تصمیمگیری
- ناتوانی اپراتور انسانی در تشخیص منشأ یک تصمیم
این همان شکافی است که فراخوان جدید Google DeepMind قصد دارد به حل آن کمک کند.
رفتار نوظهور در سیستمهای چندعاملی چیست؟
رفتار نوظهور یا Emergent Behavior به رفتاری گفته میشود که از تعامل اجزای یک سیستم پدید میآید، اما نمیتوان آن را صرفاً با بررسی جداگانه هر جزء پیشبینی کرد.
برای مثال، ممکن است چند عامل خریدوفروش بهصورت مستقل طراحی شده باشند و هیچکدام دستور ایجاد نوسان در بازار را نداشته باشند. بااینحال، واکنش سریع آنها به خروجی یکدیگر میتواند موجی از خریدوفروش خودکار ایجاد کند.
در محیط سازمانی نیز چند عامل ممکن است برای تحلیل اسناد، تأیید درخواست، مدیریت پرداخت و بهروزرسانی سوابق به یکدیگر متصل باشند. خطای عامل تحلیل یا جعل هویت یکی از Agentها ممکن است کل گردشکار را تحت تأثیر قرار دهد.
بنابراین، ایمنی یک سیستم چندعاملی فقط حاصل جمع ایمنی تکتک عاملها نیست. معماری ارتباطات، پروتکل اعتماد، حافظه مشترک، مجوز ابزارها، ترتیب تصمیمها و روش کنترل رفتار جمعی نیز باید ارزیابی شوند.
چهار مسئلهای که فراخوان Google DeepMind برای حل آنها طراحی شده است
۱. نبود محیط آزمایش استاندارد و تکرارپذیر
یکی از مشکلات اصلی پژوهشگران، نبود Testbedهای استاندارد برای مقایسه روشهای ایمنی چندعاملی است. اگر هر تیم از محیط، معیار و سناریوی متفاوتی استفاده کند، مقایسه نتایج دشوار خواهد شد.
فراخوان جدید از طراحی محیطهایی حمایت میکند که بتوان در آنها تعامل تعداد زیادی عامل را بهصورت کنترلشده آزمایش کرد. این محیطها میتوانند شامل بازارهای مجازی، زنجیرههای تأمین شبیهسازیشده، گردشکارهای چندسازمانی و شبکههای خدمات دیجیتال باشند.
راهکار عملی برای تیمها
یک Testbed مناسب باید حداقل این قابلیتها را داشته باشد:
- اجرای تکرارپذیر سناریوها
- ثبت کامل رویدادها و Tool Callها
- امکان تغییر تعداد و نقش عاملها
- تزریق خطا و رفتار خصمانه
- بازپخش یا Replay یک رخداد
- تعیین Seed و تنظیمات مدل
- اندازهگیری رفتار در سطح عامل و شبکه
- توقف اضطراری و بازیابی وضعیت
- مقایسه چند سیاست کنترلی
۲. نبود معیار برای سنجش ریسک جمعی
معیارهایی مانند Accuracy و Task Completion Rate نمیتوانند بهتنهایی ایمنی یک شبکه عامل را نشان دهند. ممکن است سیستم از نظر تکمیل وظیفه موفق باشد، اما همزمان اطلاعات حساس را بین عاملها منتشر کند یا تصمیمهای تبعیضآمیز بگیرد.
معیارهای پیشنهادی
تیمهای پژوهشی و صنعتی میتوانند معیارهای زیر را به ارزیابی خود اضافه کنند:
- نرخ انتشار خطا بین عاملها
- زمان تشخیص رفتار غیرعادی
- گستره اثر یک عامل آلوده
- تعداد ارتباطات خارج از Allow-list
- نرخ پذیرش هویت جعلی
- میزان نقض اصل Least Privilege
- قابلیت انتساب هر تصمیم به عامل و شواهد آن
- نرخ موفقیت تبانی یا Manipulation
- زمان مهار حادثه
- هزینه بازگشت سیستم به وضعیت امن
- درصد تصمیمهای حساس دارای تأیید انسانی
۳. ضعف زیرساخت هویت، اعتبار و تعهد عاملها
در یک اکوسیستم باز، هر Agent باید بتواند هویت طرف مقابل، مجوزهای آن و اعتبار پیام یا درخواست را بررسی کند. اعتماد ضمنی به یک عامل صرفاً به این دلیل که در شبکه داخلی قرار دارد، با اصول Zero Trust سازگار نیست.
راهکارهای معماری پیشنهادی
- اختصاص هویت مستقل به هر Agent
- استفاده از اعتبارنامههای کوتاهعمر
- اعمال Least Privilege برای ابزارها و منابع
- امضای درخواستها و خروجیهای حساس
- ثبت منشأ داده و تصمیم یا Data Provenance
- استفاده از Default-Deny در ارتباطات شبکه
- تعریف Allow-list صریح برای Agent-to-Agent Communication
- جداسازی محیط اجرا و حافظه عاملها
- محدودسازی نرخ درخواست و سقف تراکنش
- اعتبارسنجی Schema و Contract Testing
- ابطال سریع هویت عامل مشکوک یا آلوده
استفاده از یک Managed Identity مشترک برای همه عاملها، سطح حمله را افزایش میدهد؛ زیرا در صورت نفوذ به یک Agent، مهاجم ممکن است به منابع سایر عاملها نیز دسترسی پیدا کند.
۴. دشواری نظارت و کنترل جمعیت عاملها
ثبت Log برای هر Agent لازم است، اما کافی نیست. رفتار خطرناک ممکن است فقط در سطح گراف ارتباطی قابلمشاهده باشد؛ برای مثال، عاملی که معمولاً فقط با Orchestrator ارتباط دارد، ناگهان تلاش میکند مستقیماً به Agent ذخیرهسازی یا پرداخت متصل شود.
اقدامات عملی برای Observability
- استفاده از Distributed Tracing برای تمام فراخوانیها
- تخصیص Correlation ID سراسری به هر مأموریت
- ثبت Agent ID، Model Version و Prompt Version
- ثبت ورودی و خروجی ابزارها با رعایت حریم خصوصی
- مانیتورینگ گراف ارتباطات عاملها
- تشخیص ناهنجاری در الگوی فراخوانی
- تعریف Circuit Breaker برای Agentهای ناپایدار
- اعمال Timeout و Retry محدود با Backoff
- ایجاد Kill Switch در سطح Agent و کل شبکه
- نگهداری Audit Trail تغییرناپذیر
- تعریف Human-in-the-Loop برای تصمیمهای پرریسک
پژوهشگران چگونه یک پروپوزال قوی آماده کنند؟
یک پیشنهاد پژوهشی موفق نباید صرفاً به توصیف کلی خطرهای AI Agentها محدود شود. پروپوزال باید مسئلهای قابلاندازهگیری، روش آزمایش تکرارپذیر و معیار موفقیت مشخص داشته باشد.
ساختار پیشنهادی پروپوزال
تعریف دقیق مسئله
مشخص کنید چه نوع رفتار جمعی یا آسیبپذیری را بررسی میکنید؛ مانند تبانی عاملها، جعل هویت، انتشار خطا، نوسان شبکه یا شکست هماهنگی.
مدل تهدید
توضیح دهید مهاجم چه تواناییهایی دارد، کدام Agent ممکن است آلوده شود، چه منابعی در معرض خطر هستند و بدترین پیامد چیست.
محیط آزمایشی
تعداد عاملها، نقش آنها، توپولوژی شبکه، ابزارهای در دسترس و شرایط عادی یا خصمانه را تعریف کنید.
فرضیه قابلآزمون
بهجای بیان کلی «روش ما ایمنی را افزایش میدهد»، یک فرضیه کمّی ارائه کنید؛ برای نمونه: «سیاست ارتباطی پیشنهادی، شعاع انتشار خطا را دستکم ۴۰ درصد کاهش میدهد.»
Baseline
روش پیشنهادی را با حداقل یک یا چند روش موجود مقایسه کنید.
معیارهای ایمنی
شاخصهایی مانند زمان تشخیص، نرخ مهار، هزینه عملیاتی، False Positive و گستره آسیب را اندازهگیری کنید.
بازتولیدپذیری
کد، پیکربندی، Seed، نسخه مدل و دادههای قابلانتشار را مستند کنید تا آزمایش توسط پژوهشگران دیگر تکرارپذیر باشد.
انتشار مسئولانه
اگر پژوهش به کشف آسیبپذیری منجر میشود، برنامهای برای Responsible Disclosure و جلوگیری از سوءاستفاده ارائه کنید.
چکلیست ایمنی برای تیمهای سازنده سیستمهای چندعاملی
حتی تیمهایی که قصد شرکت در این فراخوان را ندارند، میتوانند از این موضوع برای ارزیابی معماری خود استفاده کنند:
- آیا هر Agent هویت و مجوز مستقل دارد؟
- آیا ارتباطات بین عاملها بر اساس Default-Deny کنترل میشود؟
- آیا Tool Callها بهصورت ساختاری اعتبارسنجی میشوند؟
- آیا ورودی سایر عاملها بهعنوان داده غیرقابلاعتماد در نظر گرفته میشود؟
- آیا نسخه مدل، Prompt، ابزار و Schema ثبت میشود؟
- آیا تصمیمهای حساس نیازمند تأیید انسان هستند؟
- آیا برای هزینه، تعداد تکرار و مدت اجرا سقف وجود دارد؟
- آیا Circuit Breaker و Fallback تعریف شده است؟
- آیا میتوان یک حادثه را بهصورت قطعی Replay کرد؟
- آیا Rollback جزئی با Contract Testing ارزیابی میشود؟
- آیا رفتار کل شبکه، نهفقط Agentهای منفرد، مانیتور میشود؟
- آیا Kill Switch و برنامه Incident Response آزمایش شده است؟
چرا این فراخوان برای آینده Agentic AI مهم است؟
بسیاری از سازمانها در حال عبور از چتباتهای ساده به سیستمهای Agentic AI هستند؛ سیستمهایی که میتوانند برنامهریزی کنند، ابزار اجرا کنند، با عاملهای دیگر ارتباط برقرار کنند و بر سامانههای واقعی اثر بگذارند.
با افزایش استقلال عملیاتی، دامنه خطا نیز بزرگتر میشود. یک پاسخ نادرست در چتبات ممکن است فقط یک کاربر را تحت تأثیر قرار دهد، اما تصمیم اشتباه در یک شبکه عامل میتواند در چندین سرویس، سازمان یا بازار منتشر شود.
فراخوان Google DeepMind بر این اصل تأکید دارد که طراحی ایمنی باید پیش از فراگیرشدن شبکههای عامل انجام شود، نه بعد از وقوع بحرانهای گسترده. این رویکرد میتواند به شکلگیری استانداردهای باز، محیطهای آزمایشی مشترک و پروتکلهای قابلاعتماد برای تعامل عاملها کمک کند.
جمعبندی
Google DeepMind و شرکای علمی آن، فراخوانی با بودجه حداکثر ۱۰ میلیون دلار برای توسعه پژوهشهای ایمنی هوش مصنوعی چندعاملی اعلام کردهاند. این برنامه چهار حوزه محیطهای آزمایشی، علم شبکههای عامل، زیرساخت امن و نظارت و کنترل را پوشش میدهد.
مسئله اصلی این است که ایمنی یک مدل منفرد، ایمنی کل اکوسیستم را تضمین نمیکند. رفتارهای نوظهور، انتشار آبشاری خطا، جعل هویت، تبانی و ضعف کنترل دسترسی از مهمترین ریسکهای شبکههای AI Agent محسوب میشوند.
پژوهشگران علاقهمند باید تا ۱۷ مرداد ۱۴۰۵ درخواست خود را مطابق الزامات پرتال رسمی فراخوان ارسال کنند. تیمهای صنعتی نیز بهتر است از هماکنون هویت مستقل عاملها، معماری Zero Trust، مشاهدهپذیری سراسری، Contract Testing، کنترل انسانی و سازوکارهای توقف اضطراری را وارد معماری سیستمهای چندعاملی خود کنند.
پرسشهای متداول
فراخوان Google DeepMind برای ایمنی هوش مصنوعی چندعاملی چیست؟
این فراخوان یک برنامه تأمین مالی پژوهشی با بودجه حداکثر ۱۰ میلیون دلار برای مطالعه ریسکهای جمعی AI Agentها، توسعه محیطهای آزمایشی، تقویت زیرساخت عاملها و ایجاد روشهای نظارت و کنترل است.
مهلت درخواست چه زمانی است؟
مهلت اعلامشده ۸ اوت ۲۰۲۶، برابر با ۱۷ مرداد ۱۴۰۵ است. این تاریخ نسبت به زمان انتشار فعلی، هنوز فرا نرسیده است.
چه کسانی میتوانند درخواست دهند؟
بر اساس متن اعلامشده، پژوهشگران دانشگاهی و مستقل از سراسر جهان مخاطب فراخوان هستند؛ بااینحال، جزئیات دقیق احراز صلاحیت باید در پرتال رسمی بررسی شود.
ایمنی چندعاملی چه تفاوتی با ایمنی یک مدل دارد؟
ایمنی مدل منفرد، رفتار یک مدل را بررسی میکند؛ اما ایمنی چندعاملی بر پیامدهای حاصل از تعامل تعداد زیادی Agent، از جمله رفتار نوظهور، تبانی، انتشار خطا و بیثباتی شبکه تمرکز دارد.
AI Agent Trap چیست؟
AI Agent Trap به شرایط یا محیط خصمانهای گفته میشود که عامل هوش مصنوعی را به تصمیم اشتباه، افشای اطلاعات، اجرای ابزار نامطمئن یا نقض سیاستهای عملیاتی سوق میدهد.