تصور کنید یک عامل هوش مصنوعی با دسترسی کامل به ایمیل‌ها، به‌جای ارسال پیش‌نویس برای همکار شما، یک پیام اشتباه را برای ۱۰ هزار مشتری ارسال کند. این کابوس عملیاتی زمانی رخ می‌دهد که ما «دسترسی به ابزار» را با «تایید اجرای عملیات» اشتباه بگیریم. حتی اگر یک عامل هوش مصنوعی در محیط عملیاتی دارای اعتبارنامه‌های معتبر و یک مسیر مدل سالم باشد، همچنان می‌تواند اقدامی فاجعه‌بار انجام دهد، مگر اینکه انسانی به او بگوید: «الان نه».
طبق گزارشی که در ۱۰ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، اکثر محصولات فعلی هوش مصنوعی، دسترسی به ابزارها را به‌صورت یک تنظیم ساده «بله یا خیر» (Binary) می‌بینند، به‌جای آنکه آن را به عنوان یک نقطه تصمیم‌گیری پویا در نظر بگیرند. این رویکرد محدود، دقیقاً همان نقطه شکست عامل‌های هوش مصنوعی در مقیاس صنعتی است که پیش‌تر در تحلیل تأییدیه‌های بولی به آن پرداختیم. بسیاری از محصولات با دسترسی به ابزارها مانند یک سوییچ ساده برخورد می‌کنند: عامل می‌تواند ایمیل بفرستد، رکورد CRM را به‌روزرسانی کند، تیکت پشتیبانی ایجاد کند، استقرار (Deployment) را فعال کند یا وجهی را بازگرداند.
در حالی که ریسک یک اقدام، کاملاً به زمینه یا کانتکست آن بستگی دارد. به‌روزرسانی یک رکورد آزمایشی با تغییر اطلاعات یک حساب فعال در محیط عملیاتی، دو دنیای متفاوت هستند. خواندن یک سند با استخراج کل پایگاه داده مشتریان تفاوت بنیادین دارد. برای مثال، اگر عاملی اجازه ارسال ایمیل داشته باشد، ارسال یک پیش‌نویس برای یک هم‌تیمی ریسک پایینی دارد، اما ارسال ایمیل به ۱۰,۰۰۰ مشتری یک رویداد با ریسک بسیار بالاست. اکثر سیستم‌های فعلی، «مجوز» (Permission) — که می‌پرسد آیا ابزاری برای این عامل یا مسیر مدل در دسترس است یا خیر — را با «تایید» (Approval) — که می‌پرسد آیا یک اقدام خاص باید اکنون برای یک هدف مشخص با ورودی‌های دقیق اجرا شود — اشتباه می‌گیرند.
عامل (Agent) — شبیه به کارمندی است که ابزارهای لازم برای انجام کار را دارد، اما هنوز نمی‌داند چه زمانی باید برای تصمیمات حساس از مدیرش اجازه بگیرد. در بسیاری از سیستم‌ها، اگر مدل اجازه داشته باشد ایمیل بزند، هر ایمیلی را در هر زمان و برای هر کسی می‌فرستد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبودِ لایه‌های نظارتی بین «توانایی» و «اجرا»، بزرگ‌ترین نقطه ضعف سیستم‌های خودکار است. در همین راستا، برای تضمین کیفیت، باید از ارزیابی‌های خارجی استفاده کرد تا عامل‌ها به‌جای اصلاح خطا، صرفاً خروجی‌های خود را تأیید نکنند.
برای حل این مشکل، چارچوب VectorNode یک سامانه کنترل زمان-اجرا (Runtime Control) را پیشنهاد می‌دهد که قابلیت مدل را از اجرای عملیات جدا می‌کند. این رویکرد تضمین می‌کند که در حالی که مدل ممکن است اجازه فراخوانی ابزار «بازگشت وجه» را داشته باشد، هر بازگشتی بالاتر از یک حد نصاب مالی مشخص، به‌طور اجباری باعث فعال شدن بررسی انسانی شود. به همین ترتیب، مدل ممکن است اجازه به‌روزرسانی CRM را داشته باشد، اما تغییر مالکیت حساب نیاز به تایید داشته باشد. همچنین، استقرار در محیط عملیاتی نباید از همان سیاست‌های محیط Staging استفاده کند. این تفکیک محیط‌ها با مدل پیشنهادی Edilec برای تبدیل عامل‌ها به نرم‌افزارهای تجاری از طریق استقرارهای مرحله‌بندی شده هم‌سو است.
مدل ریسک طبقه‌بندی‌شده
برای جلوگیری از «خستگی تایید» (Confirmation Fatigue) — وضعیتی که کاربر از شدت زیادِ پیام‌های تایید، بدون خواندن آن‌ها را تایید می‌کند و محصول کند می‌شود — اقدامات به سه سطح ریسک تقسیم می‌شوند. گیت‌های تایید زمانی بهترین عملکرد را دارند که برای اقداماتی با تاثیرات معنادار به کار روند:
- ریسک پایین: اقداماتی که به‌طور خودکار مجاز هستند. مثال‌ها شامل بازیابی مستندات عمومی، خلاصه‌سازی یک تیکت داخلی، ایجاد پیش‌نویس پاسخ، برچسب‌گذاری یک آیتم یا به‌روزرسانی یک فیلد وضعیت غیرحساس است.
- ریسک متوسط: اقداماتی که نیاز به یک حد نصاب یا تایید سبک دارند. مثال‌ها شامل ارسال پیام به مشتری، ایجاد تیکتی با قابلیت مشاهده خارجی، تغییر مجموعه‌ای محدود از رکوردها یا اجرای یک Job دسته‌ای (Batch) پایین‌تر از حد مجاز حجم داده است.
- ریسک بالا: اقداماتی که تایید صریح، مستند و انسانی می‌طلبند. مثال‌ها شامل حذف داده‌های محیط عملیاتی، تغییر دسترسی‌ها، اقدامات مالی، ارتباطات خروجی در مقیاس بزرگ، استقرار در محیط عملیاتی و استخراج داده‌های حساس است.
سوابق تایید غنی از زمینه
یک درخواست تایید ساده که بگوید «عامل می‌خواهد از ابزار refund_customer استفاده کند»، عملاً بی‌فایده است. طبق استانداردهای VectorNode، یک رکورد تایید آماده برای محیط عملیاتی باید شامل جزئیاتی شبیه به JSON باشد که حاوی موارد زیر است: شناسه مشتری، مبلغ دقیق (مثلاً ۸۹۰ دلار آمریکا)، محیط اجرا (عملیاتی در مقابل آزمایشی) و دلیل دقیق اقدام (مثلاً «تشخیص پرداخت تکراری توسط گردش‌کار»).
ناظر باید بتواند قبل از کلیک روی دکمه تایید، تعیین کند که آیا این اقدام بازگشت‌پذیر است یا خیر و چه شواهدی مدل را به این پیشنهاد رسانده است. آن‌ها باید بپرسند: چه کسی تحت تاثیر قرار می‌گیرد؟ اگر درخواست رد شود چه اتفاقی می‌افتد؟ این تایید تا چه زمانی معتبر است؟
علاوه بر این، این تاییدها نباید دائمی باشند؛ آن‌ها باید منقضی شوند تا از تکرار غیرمجاز یک اقدام تاییدشده توسط عامل برای هدفی متفاوت در روز بعد جلوگیری شود. رکوردهای تایید مفید باید موارد زیر را ردیابی کنند: شناسه درخواست (Request ID)، نسخه سیاست (Policy Version)، نسخه مدل و پرامپت، برچسب زمانی تاییدکننده، زمان انقضا و نتیجه نهایی اجرا.
امنیت مدل‌های جایگزین (Fallback)
ریسک‌های امنیتی زمانی افزایش می‌یابند که سیستم به‌دلیل تأخیر، خطا، محدودیت‌های نرخ (Rate Limits) یا کاهش کیفیت خروجی، به یک مدل جایگزین یا Fallback سوییچ می‌کند. یک مدل جایگزین به‌طور خودکار اجازه انجام هر اقدامی که برای مسیر اصلی در دسترس است را ندارد.
یک مسیر پشتیبان با هزینه کمتر ممکن است برای خلاصه‌سازی یک تیکت یا بازیابی داده‌ها کافی باشد، اما نباید همان مجوزهای اجرای مدل اصلی را برای کارهای پرریسک مانند اجرای پرداخت، تغییر دسترسی‌ها یا ارسال پیام خارجی به ارث ببرد. وقتی مسیر استنتاج تغییر می‌کند، تصمیم درباره ریسک نیز ممکن است نیاز به تغییر داشته باشد.
این تغییر معماری به این معناست که دیگر نمی‌توان عامل‌های عملیاتی را صرفاً با پرامپت‌ها و کلیدهای API کنترل کرد. با ایجاد مرزهای روشن بین آنچه عامل «می‌بیند»، آنچه «پیشنهاد می‌دهد» و آنچه «اجرا می‌کند»، سرعت اتوماسیون بدون فدا کردن ایمنی عملیاتی حفظ می‌شود.
برای کسانی که در حال ساخت گردش‌کارهای عامل‌محور (Agentic Workflows) هستند، گام بعدی بازبینی مجوزهای فعلی ابزارهاست تا شناسایی شود کدام دسترسی‌های «باینری» باید به گیت‌های تایید طبقه‌بندی‌شده تبدیل شوند.
گام بعدی شما
- تمام دسترسی‌های فعلی ابزارهای AI خود را بازبینی کنید و دسترسی‌های «باینری» (بله/خیر) را شناسایی کنید.
- برای هر ابزار، یک ماتریس ریسک سه سطحی (پایین، متوسط، بالا) تعریف کنید.
- برای اقدامات سطح بالا، یک فرمت استاندارد برای «درخواست تایید» طراحی کنید که شامل دلیل و اثر اقدام باشد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو