تصور کنید صدها عامل هوش مصنوعی دقیقاً همان کاری را انجام دهند که برایش ساخته شده‌اند؛ نتیجه اغلب سامانه‌ای است که هیچ‌کس آن را طراحی نکرده و هیچ‌کس نمی‌تواند کنترلش کند. به نقل از روری بلاندل (Rory Blundell)، مدیرعامل Gravitee، در گزارشی که در ۲۷ اوت ۲۰۲۶ منتشر شد، همین پیچیدگیِ انباشته‌شده دلیل اصلی توقف برنامه‌های هوش مصنوعی سازمانی در مرحله‌ی آزمایشی و عدم ورود آن‌ها به محیط عملیاتی است.
بیشتر شرکت‌ها تنها یک عامل را مستقر نمی‌کنند، بلکه ناوگانی از عامل‌ها را به کار می‌گیرند که در زنجیره‌های متوالی، APIها و عامل‌های دیگر را فراخوانی می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی شش کنترل زیرساختی لازم برای مدل‌های زبانی بزرگ اشاره کردیم، چالش فعلی از «قابلیت اطمینان تک‌مدل» به «سایه‌ی شومِ متصل‌بودن» تغییر کرده است. این وضعیت یادآور هشدارهای اخیر است که در آن سیستم‌های چندعاملی می‌توانند منجر به فروپاشی ساختاری و حتی جنگ قدرت بین عامل‌ها شوند. تصور کنید یک تیکت پشتیبانی که پیش‌تر تنها با یک سیستم در ارتباط بود، اکنون پیش از رسیدن به انسان، از چهار عامل مختلف عبور می‌کند — شبیه به کارمندانی که هر کدام تکه‌ای از پرونده را می‌خوانند و به نفر بعدی پاس می‌دهند. هر یک از این جابه‌جایی‌ها، یک نقطه‌ی تصمیم‌گیری است که هیچ انسانی آن را تأیید نکرده است.
ماهیت پیچیدگی انباشته‌شده
پیچیدگی با افزایش تعداد عامل‌ها به‌صورت خطی رشد نمی‌کند. اضافه کردن دهمین عامل، تنها ۱۰ اتصال جدید ایجاد نمی‌کند؛ بلکه پتانسیل ایجاد ده‌ها مسیر جدید را دارد، چون هر عامل ممکن است هر عامل دیگری را فراخوانی کند و هر یک از این فراخوانی‌ها می‌تواند به نوبه خود، فراخوانی‌های بیشتری را در نقاط دیگر فعال کند.
این وضعیت یک شکاف حاکمیتی ایجاد می‌کند که در آن تیم‌های امنیتی نمی‌توانند پاسخ دهند کدام عامل به کدام سیستم دسترسی دارد یا کدام عامل سه مرحله پیش، باعث اجرای یک دستور خاص در انتهای زنجیره شده است. طبق گزارش Gravitee، وقتی این پرسش‌ها مطرح می‌شوند، نتیجه اغلب سکوت است؛ زیرا هیچ‌کس در سازمان وظیفه ندارد گراف این تعاملات پیچیده را ترسیم کند.
حالت‌های شکست در ناوگان‌های عامل‌محور
شرکت Gravitee دو روش اصلی برای فروپاشی این سامانه‌ها شناسایی کرده است:
- توسعه‌ی خزنده دسترسی‌ها (Permissions Creep): عاملی که برای یک کار ساده مانند خلاصه‌سازی تیکت‌ها ساخته شده است، دسترسی‌های گسترده‌ای به APIها می‌گیرد، زیرا محدود کردن دقیق دسترسی‌های آن (Scoping) ممکن بود یک دوره توسعه (Sprint) دیگر زمان ببرد. شش ماه بعد، همین عامل مسیری مستندنشده به سیستم پرداخت‌ها پیدا می‌کند. هیچ‌کس به یاد نمی‌آورد که این دسترسی را تأیید کرده باشد، چون در واقع هیچ‌کس چنین کاری نکرده است.
- رقیق شدن مالکیت (Ownership Thinning): وقتی پنج عامل در یک گردش‌کار نقش دارند و در مرحله چهارم خطایی رخ می‌دهد، اغلب هیچ انسانی به نام مشخص وجود ندارد که مسئول آن لینک خاص از زنجیره باشد. نمودار سازمانی معمولاً در مرحله «استقرار عامل» متوقف می‌شود و هرگز به مرحله‌ای نمی‌رسد که انسانی تعیین شود تا پاسخگوی عملکرد و خطاهای آن باشد.
چارچوب حاکمیتی برای خروج از بن‌بست
حل این مشکل نیازمند عبور از چک‌لیست‌های تک‌مرحله‌ای است. بلاندل استدلال می‌کند که نگاه به حاکمیت به‌عنوان یک چک‌لیست — یعنی تأیید و ثبت یک‌باره‌ی عامل — غریزه و رویکردی اشتباه است. یک چک‌لیست تنها یک نقطه زمانی خاص را بررسی می‌کند، اما پیچیدگی در طول یک زنجیره جاری است. او این رویکرد را به رژیم غذایی تشبیه می‌کند؛ شما نمی‌توانید صرفاً به دلیل اینکه یک بار سبزیجات خورده‌اید، رژیم خود را موفق بنامید. این چالش‌ها را می‌توان در بررسی جامع‌تر حاکمیت لایه‌های کنترلی در برابر افزایش هوش مدل‌ها که پیش‌تر منتشر کردیم، دنبال کرد.
برای اصلاح این خوشه از عامل‌ها، حاکمیت باید به یک زنجیره مستمر از نظارت تبدیل شود:
- هویت متمرکز: هر عامل باید به‌عنوان یک موجودیت مستقل با نام مشخص در دفتر ثبت (Register) و با اختیارات محدود شده‌ی خود وجود داشته باشد. عامل نباید از یک دسترسی سایه‌ای (Shadow Permission) که از شخص مستقرکننده قرض گرفته شده، استفاده کند. هر عامل باید یک حامی انسانی (Human Sponsor) داشته باشد که پاسخگوی اقدامات آن باشد.
- شفافیت بلادرنگ: سازمان‌ها به نظارتی نیاز دارند که در کل زنجیره جاری باشد، نه فقط در تک‌تک حلقه‌ها. گزارش‌های فصلی ناکافی هستند؛ مدیران باید در لحظه ببینند یک عامل چه کرد، چه اتفاقاتی را در پایین‌دست رقم زد و این ردپا در نهایت کجا به پایان می‌رسد.
- اجرای فعال (Active Enforcement): سیستم باید از حالت «مانیتورینگ» به حالت «اجرا» تغییر وضعیت دهد. داشبوردی که نشان می‌دهد پنج دقیقه پیش نقضی رخ داده است، صرفاً یک ابزار نظارتی است. حاکمیت واقعی یعنی توانایی متوقف کردن یک فراخوانی خارج از سیاست‌ها (Out-of-policy call) پیش از آنکه اجرا شود، نه اینکه صرفاً آن را برای بررسی سه هفته بعد ثبت کند.
این چرخش به سمت «هماهنگی انسان و عامل»، اجازه می‌دهد مقیاس‌پذیری و پاسخگویی به‌جای تقابل و جایگزینی یکدیگر، در کنار هم رشد کنند. هدف، کند کردن سرعت مسابقه پذیرش هوش مصنوعی یا «ترمز گرفتن» نیست، بلکه ساختن دید لازم برای رشد ناوگان بدون از دست دادن توانایی پاسخ به این پرسش است: «این سیستم همین حالا چه می‌کند و چه کسی مسئول آن است؟»
برای کسانی که گردش‌کارهای عامل‌محور را مدیریت می‌کنند، گام حیاتی بعدی، ممیزی «مسیرهای پنهان» بین عامل‌های فعلی است تا شناسایی شود در کجا دسترسی‌ها فراتر از محدوده اولیه خود گسترش یافته‌اند.
گام بعدی شما
- تمام مسیرهای ارتباطی بین عامل‌های فعلی خود را ممیزی کنید تا دسترسی‌های غیرضروری را شناسایی کنید.
- برای هر عامل مستقر شده، یک «مالک انسانی» (Human Sponsor) تعیین کنید که مسئول خطاهای عملیاتی آن باشد.
- از ابزارهای مانیتورینگ ساده به سمت سیستم‌های Enforcement حرکت کنید که اجازه اجرای دستورات خارج از محدوده را نمی‌دهند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو