تصور کنید در محیطی کار میکنید که هر ثانیه دهها تغییر حیاتی در زیرساختهای نرمافزاری شما رخ میدهد و شما تنها سد دفاعی برای تأیید آنها هستید. در این وضعیت، دکمهی «تأیید» دیگر یک ابزار امنیتی نیست، بلکه به یک عادت مکانیکی تبدیل میشود که هر لحظه میتواند منجر به یک فاجعهی فنی شود.
طبق گزارشهای اخیر آنتروپیک (Anthropic) و سایر آزمایشگاههای هوش مصنوعی، خط لولهی سنتی تحویل نرمافزار در حال فروپاشی است؛ زیرا گلوگاه تولید نرمافزار از مرحلهی «نوشتن کد» به مرحلهی «بازبینی انسانی» منتقل شده است. وقتی توسعهدهندگان میتوانند تغییرات را در چند ثانیه تولید کنند، گام تأیید انسانی به جای آنکه یک کنترل امنیتی باشد، به یک مهر تأیید صوری تبدیل میشود. این فشار زمانی بر بازبینیها به قدری زیاد شده است که حتی پلتفرمهای بزرگی مانند استک اورفلو تلاش کردهاند زمان بازبینی هوش مصنوعی را به شدت کاهش دهند تا از توقف جریان توسعه جلوگیری کنند.
برای دههها، چرخه حیات توسعه نرمافزار (SDLC) بر این فرض استوار بود که انسان واحد مقیاسپذیر برای حاکمیت است. در این مدل، یک برنامهنویس کد را مینوشت، یک همکار آن را بازبینی میکرد و یک مدیر استقرار را تأیید مینمود. این فرآیند خطی برای تضمین ثبات سیستم عالی بود، اما در برابر خروجی نمایی مدلهای زاینده هوش مصنوعی توان مقیاسپذیری ندارد.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اتکای بیش از حد به نظارت انسانی در محیطهای سریع، ریسکهای سیستمی را افزایش میدهد. اکنون صنعت در حال ورود به فازی است که در آن هوش مصنوعی تنها پیشنهاد نمیدهد، بلکه بهصورت عاملمحور (Agentic) اقدام میکند. این تغییر شتابان است و پیشبینی میشود تا سال ۲۰۲۵، عاملهای خودمختار از محیطهای آزمایشگاهی و کنجکاویهای فنی به اولویتهای استراتژیک در سطح هیئتمدیره شرکتها تبدیل شوند.
فروپاشی نظارت انسانی
دادههای منتشر شده توسط آنتروپیک نشاندهندهی یک شکست بحرانی در مدل «انسان در حلقه» (Human-in-the-loop) است. این شرکت گزارش داده که کاربران کلود کد (Claude Code) تقریباً ۹۳٪ از درخواستهای دسترسی (Permission Prompts) را تأیید میکنند. این نرخ بسیار بالا ثابت میکند که انسانها دیگر قوه تشخیص خود را به کار نمیگیرند، بلکه دچار «خستگی از تأیید» (Approval Fatigue) شدهاند.
وقتی فردی تقریباً هر بار روی تأیید کلیک میکند، او دیگر یک مکانیسم ایمنی نیست، بلکه صرفاً یک مرحلهی اداری در جریان کاری است. اگر کسی ۹۳٪ مواقع دکمه تأیید را میزند، افزودن یک لایه تأیید دیگر در واقع کنترل را افزایش نمیدهد؛ بلکه صرفاً یک گام دیگر به جریان کاری اضافه میکند بدون آنکه امنیت واقعی ایجاد شود.
به همین دلیل، آنتروپیک شروع به پیادهسازی طبقهبندیکنندههای خودکار (Automated Classifiers) کرده است تا بهجای تکیه بر کلیک انسان، اقدامات خطرناک را بهطور سیستمی متوقف کند. این اقدام اعترافی صریح به این حقیقت است که توجه انسان یک منبع محدود است و نمیتواند با حجم خروجیهای تولید شده توسط هوش مصنوعی رقابت کند.
مسئلهی حجم خروجی
موج اول هوش مصنوعی زاینده بر کمک به توسعهدهندگان برای سریعتر نوشتن کد تمرکز داشت. اگرچه این امر بهرهوری را افزایش میدهد، اما بهطور بنیادین ماهیت تحویل نرمافزار را تغییر داده است. کدهای بیشتر به معنای جهشی در تعداد تغییرات اپلیکیشن، اصلاحات زیرساختی و بهروزرسانیهای پایگاهداده است.
تمام این تغییرات همچنان باید از فیلترهای تست، امنیت، بازبینی، استقرار و محیط عملیاتی عبور کنند. مشکل لزوماً این نیست که هوش مصنوعی تغییرات بدتری ایجاد میکند، بلکه مشکل این است که تغییرات «بیشتری» را با سرعتی «بیشتر» تولید میکند. اگر تنها کنترل برای این خروجی، بازبینی خطبهخط توسط انسان باشد، ریاضیات این فرآیند در نهایت شکست میخورد و سیستم متوقف میشود.
از دستیاران کدنویسی تا عاملهای خودمختار
هوش مصنوعی از دستیاران ساده به عاملهایی (Agents) تبدیل شده که قادرند در کل چرخه SDLC مشارکت کنند. برخلاف یک دستیار کدنویسی، یک عامل میتواند هدفی سطح بالا را دریافت کند، تصمیم بگیرد چگونه آن را به سرانجام برساند، از ابزارها استفاده کند، نتایج را مشاهده کند و گامهای بعدی خود را بر اساس مشاهدات اصلاح نماید.
در مهندسی نرمافزار، این عاملها میتوانند:
- اهداف سطح بالا را دریافت و مراحل اجرای عملیاتی را برنامهریزی کنند.
- فایلها را تغییر داده و دستورات ترمینال را اجرا کنند.
- با مخازن کد (Repositories) تعامل داشته و APIها را فراخوانی کنند.
- کدها را تست کرده و زیرساختهای ابری را مدیریت کنند.
این خودمختاری همین حالا توسط کاربران حرفهای پذیرفته شده است. آنتروپیک دریافت که کاربران باتجربهی کلود کد در بیش از ۴۰٪ جلسات خود از حالت «تأیید خودکار کامل» (Full Auto-approval) استفاده میکنند؛ رقمی که تقریباً دو برابر نرخ کاربران تازهوارد است. در این مسیر، مدلهای پیشرفتهتر از ابزارهای تکنفره فاصله گرفتهاند و استفاده از سوارمهای هماهنگ در توسعه نرمافزار نشان داده است که میتوان بهرهوری تیمها را به شکل چشمگیری افزایش داد.
اگرچه عاملهای خودمختار هنوز تمام محیطهای عملیاتی را اداره نمیکنند، اما پیشنمایشی از آینده هستند. در نهایت، عاملها تغییرات را ایجاد، اعتبارسنجی، استقرار، مشاهده و اصلاح میکنند و در هر مرحله، یک نقطهی کنترل انسانی سنتی حذف میشود.
خطر «عاملیت بیش از حد»
تفاوت بنیادینی میان «اجازه» (Permission) و «اختیار» (Authority) وجود دارد. یک عامل برای مفید بودن به اجازه دسترسی به پایگاهداده، سیستم CI/CD یا محیط ابری نیاز دارد، اما نباید اختیار اجرای هر اقدام ممکنی را در آن سیستم داشته باشد.
سلب دسترسی، کاربرد عامل را از بین میبرد. با این حال، کنترلهای دسترسی سنتی فقط به ما میگویند که آیا یک عامل «میتواند» به سیستم برسد یا خیر؛ آنها تعیین نمیکنند که آیا یک اقدام «خاص» در آن لحظه باید رخ دهد یا خیر. این موضوع زمانی حیاتی میشود که هوش مصنوعی وظیفهای را متفاوت از کاربر تفسیر کند، با مانعی مواجه شود و مسیری برنامهریزینشده را انتخاب کند، یا از یک ابزار مشروع به روشی پیشبینینشده استفاده نماید.
سازمان اوواسپ (OWASP) این ریسک را «عاملیت بیش از حد» (Excessive Agency) مینامد و سه علت اصلی برای اقدامات آسیبزا برمیشمارد:
- قابلیتهای بیش از حد (Excessive functionality)
- مجوزهای بسیار گسترده (Over-broad permissions)
- خودمختاری مفرط (Too much autonomy)
برای کاهش این ریسک، اوواسپ توصیه میکند که اقدامات با اثرگذاری بالا (High-impact actions)، حتماً نیازمند تأیید مستقل باشند.
ایمنی معماری
شرکت انویدیا (NVIDIA) با معرفی پلتفرم ایمنی عاملهای باز (Open Agent Safety Platform) در حال حل این مشکل در سطح معماری است. این پلتفرم، اجرای سیاستها (Policy Enforcement) را به خارج از محیط عامل منتقل میکند. فرض اصلی ساده است: نمیتوان از یک عامل انتظار داشت که رفتار خود را بهطور کامل مدیریت و حاکم کند.
هوش مصنوعی بر اساس احتمالات تصمیم میگیرد. بنابراین، سازمانها نباید اجازه دهند هر تصمیم احتمالی بهطور خودکار به یک اقدام در سیستمهای حیاتی تبدیل شود. یک عامل ممکن است اجازه دسترسی به سیستم استقرار را داشته باشد، اما نباید خودش تصمیم بگیرد که هر تغییری که میخواهد اعمال کند، لزوماً ایمن است.
بازتعریف مدل حاکمیت
برای حفظ کنترل بدون ایجاد گلوگاه، سازمانها باید از تأییدهای دستی برای هر اقدام فاصله بگیرند. اشتباه بزرگ این است که «انسان در حلقه» را پاسخ جهانی برای هر تصمیم بدانیم. اگر هر اقدام نیاز به یک کلیک داشته باشد، همان گلوگاهی که هوش مصنوعی قرار بود حذف کند، دوباره بازسازی میشود.
مدل پیشنهادی، تقسیم کار را به سه سطح میبرد:
- تصمیمات هوش مصنوعی: مدیریت وظایف فوری و منطق داخلی در محدوده شغلی تعیینشده.
- تصمیمات سیاستی: خودکارسازی قوانین تکرارپذیر. برای مثال، یک تغییر کمریسک که استانداردهای امنیتی را رعایت کرده، باید بدون نیاز به نظارت انسانی تأیید شود.
- تصمیمات انسانی: مداخله تنها برای استثنائاتی که نیاز به قضاوت واقعی تجاری، امنیتی یا عملیاتی دارند. تغییری که سیاستها را نقض کند باید بهطور خودکار متوقف شود، در حالی که استثناهای پیچیده نیازمند تصمیمگیری یک انسان است. این رویکرد در واقع بازتابی از تغییر پارادایم رهبری سازمانی به سمت همکاری انسان و ماشین است که در آن نقش انسان از کنترلگر ریزبین به مدیر استثنائات تبدیل میشود.
ادغام کنترل در خط لوله (Pipeline)
حاکمیت باید به «اقدام» نزدیکتر باشد تا به «کنشگر». سازمانها روی یک مدل واحد استاندارد نخواهند شد؛ توسعهدهندگان از کوپایلتهای مختلف استفاده میکنند، تیمها مدلهای متفاوتی را آزمایش میکنند و هوش مصنوعی در محصولات امنیتی و پلتفرمهای داده جاسازی میشود.
سعی برای ساخت یک فرآیند حاکمیتی مجزا برای هر ابزار AI مقیاسپذیر نیست. در عوض، کنترل باید در مسیری که هوش مصنوعی طی میکند ادغام شود:
- اگر یک تغییر تولیدشده توسط AI وارد خط لوله استقرار میشود، باید با همان سیاستهایی مواجه شود که یک تغییر انسانی با آنها مواجه است.
- اگر عاملی پایگاهداده عملیاتی را تغییر میدهد، کنترلهای آن سیستم باید فارغ از اینکه کنشگر کیست، پابرجا بمانند.
منبع تغییر، ریسک را تعیین نمیکند، بلکه خودِ تغییر است که ریسک را میسازد. این رویکرد اجازه میدهد تکنولوژی تکامل یابد — مدلها تغییر کنند و عاملها توانمندتر شوند — بدون آنکه شرکتها مجبور شوند حاکمیت خود را از ابتدا بازسازی کنند.
این رویکرد با چارچوب مدیریت ریسک AI سازمان نیست (NIST) همسو است. نیست حاکمیت را به جای یک تأیید دستی در انتهای زنجیره، فرآیندی میبیند که در کل چرخه حیات AI عمل میکند.
شکاف شواهد و مستندات
حذف انسان از حلقه، یک بحران در انطباق (Compliance) ایجاد میکند. در سیستمهای دستی، ردپای حسابرسی (Audit Trails) پس از وقوع حادثه از طریق تیکتها، تأییدها، لاگهای خط لوله، اسکرینشاتها و گفتگوها بازسازی میشود. این روش وقتی ماشینها بهطور مداوم تغییرات را اجرا میکنند، غیرواقعبینانه است.
با حذف شخص، کسی که ثابت کند بازبینی رخ داده است نیز حذف میشود. برای شرکتهایی با الزامات امنیتی و حسابرسی سختگیرانه، این یک مسئله جدی است. آنها همچنان باید ثابت کنند:
- چه چیزی تغییر کرد و چه کسی یا چه عاملی آن را آغاز کرد.
- کدام سیاست اعمال شد و آیا تأیید شد یا خیر.
- چه کسی استثنا را تأیید کرد.
- تغییر در کجا اجرا شد و نتیجه چه بود.
نمیتوان تغییر را خودکار کرد و مستندات را دستی گذاشت. شواهد باید محصول جانبی فرآیند تحویل باشند. تصمیمات سیاستی و نتایج باید بهصورت سوابق دیجیتال در لحظه وقوع کار ایجاد شوند.
تقسیم کار جدید
این غریزه وجود دارد که کنترل را با تعداد دفعات دخالت انسان بسنجیم. بازبینیهای بیشتر، حس امنیت بیشتری میدهند. اما هوش مصنوعی این فرض را به چالش میکشد. تلاش برای بازبینی هر تغییر، یا سرعت AI را میگیرد یا نظارت انسانی را به یک مهر تأیید صوری تبدیل میکند.
چرخه SDLC در عصر هوش مصنوعی نیازمند تقسیم کار جدیدی است: هوش مصنوعی کار را انجام میدهد، سیاستها تصمیمات تکرارپذیر را حاکم میکنند و انسانها استثناهای مبتنی بر قضاوت را مدیریت میکنند.
ما به هوش مصنوعی دسترسی و خودمختاری بیشتری خواهیم داد چون تنها راه رسیدن به اهرم رشد است. چالش اصلی این است که این دسترسی بهطور خاموش به «اختیار نامحدود» تبدیل نشود. هدف، کنترل کمتر نیست، بلکه مدلی از کنترل است که به وابستگی به انسان برای هر تصمیم کوچک متکی نباشد. ما باید کنترلهایی بسازیم که به ما اجازه دهد بدون از دست دادن مدیریت، فشار دست خود را شل کنیم.
گام بعدی شما
- بازبینی مجدد دسترسیهای API عاملهای AI در سازمان خود و جایگزینی تأییدهای دستی با سیاستهای سختگیرانه (Policy-based).
- مطالعه مستندات Open Agent Safety Platform انویدیا برای جداسازی لایه سیاستگذاری از لایه اجرا.
- پیادهسازی سیستمهای ثبت خودکار شواهد (Automated Evidence) برای جایگزینی لاگهای دستی در فرآیندهای انطباق.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو