اگر مدیریت یک تیم فنی هستید که در حال استقرار عامل‌های هوشمند است، احتمالاً با حقیقتی تلخ رو‌به‌رو هستید: ابزارهای نظارتی شما برای دنیای دیروز ساخته شده‌اند. طبق اعلام مک‌کینزی (McKinsey) در نظرسنجی «بلوغ اعتماد در هوش مصنوعی ۲۰۲۶»، تنها ۳۰ درصد از سازمان‌ها به سطح بلوغ ۳ یا بالاتر در استراتژی، حاکمیت و کنترل‌های هوش مصنوعی عامل‌محور (Agentic AI) رسیده‌اند. در حالی که استقرار فنی عامل‌های هوش مصنوعی در حال شتاب گرفتن است، ساختارهای نظارتی لازم برای پاسخگو نگه داشتن آن‌ها عقب مانده‌اند. فاصله بین توانمندی فنی و حاکمیت سازمانی همچنان در حال گسترش است.
بسیاری از شرکت‌ها در حال حاضر بر چارچوب‌های حاکمیتی تکیه می‌کنند که برای ابزارهای نظارت‌شده (Supervised Tools) ساخته شده‌اند. این سیستم‌ها زمانی درست کار می‌کنند که یک هوش مصنوعی پیش‌نویسی می‌سازد و سپس منتظر می‌ماند تا انسانی آن را تأیید کند. در این مدل نظارت‌شده، انسان متن را می‌خواند، ویرایش می‌کند و تصمیم می‌گیرد که آیا اثر نهایی ارسال شود یا خیر. در نتیجه، تمامی کنترل‌ها و بازرسی‌ها حول محور لحظه تأیید نهایی متمرکز شده‌اند.
اما هوش مصنوعی عامل‌محور — شبیه به کارمندی که اجازه دارد خودش وارد اتاق‌های مختلف شود، پرونده‌ها را بخواند و ایمیل بزند، بدون اینکه هر لحظه منتظر دستور باشد — منتظر نمی‌ماند. این تغییر در ماهیت ابزارها باعث شده است که نقش توسعه‌دهندگان از کدنویسی صرف به مدیریت کارکنان دیجیتالی تغییر کند. این عامل‌ها زنجیره‌ای از اقدامات را در پایگاه‌های داده، سیستم‌های CRM و سیستم‌های ایمیل اجرا می‌کنند، پیش از آنکه انسانی متوجه نتیجه شود. مدل زیربنایی ممکن است دقیقاً مشابه یک ابزار نظارت‌شده باشد، اما مشکل نظارت در اینجا یک موجود کاملاً متفاوت است. طراحی نرده‌های ایمنیِ مدل‌های نظارت‌شده به محض اینکه یک عامل بدون حضور یک شخص در دروازه، شروع به فعالیت میان سیستم‌ها و حساب‌های مختلف می‌کند، کاملاً از هم می‌پاشد.
تصور کنید یک عامل پشتیبانی، تیکتی را می‌خواند، از پایگاه داده استعلام می‌گیرد، سوابق را به‌روز می‌کند و در عرض چند ثانیه سه ایمیل می‌فرستد. اگر عامل در اولین ورودی دچار اشتباه در خواندن شود، هر اقدام بعدی آن خطا را به ارث می‌برد. تا زمانی که انسان مداخله کند، اشتباه در لایه‌های عمیق یک زنجیره پیچیده از وقایع دفن شده است. در ابزارهای نظارت‌شده، خطا در یک نقطه واحد رخ می‌دهد؛ اما در عامل‌ها، خطا در امتداد یک مسیر پخش می‌شود.
شکاف کنترلی
بر اساس داده‌های مک‌کینزی، ریسک‌های مربوط به این توالی‌های خودکار اکنون تبدیل به سدهای اصلی برای مقیاس‌دهی شده‌اند:
- نزدیک به دو-سوم پاسخ‌دهندگان، نگرانی‌های امنیتی و ریسک را به عنوان مانع اصلی در مسیر مقیاس‌دهی هوش مصنوعی عامل‌محور ذکر کرده‌اند. این نگرانی‌ها به‌ویژه در مورد جایگاه داده‌های حساس کارکنان و نقاط کور امنیتی که توسط این عامل‌ها پردازش می‌شوند، شدت یافته است.
- نرخ حوادث مرتبط با هوش مصنوعی روی سطح تقریبی ۸ درصد ثابت مانده است.
- اعتماد به واکنش‌ها در حال سقوط است؛ نزدیک به ۶۰ درصد سازمان‌های آسیب‌دیده، پاسخ خود به حوادث را در سطحی ارزیابی کرده‌اند که بهتر از «رضایت‌بخش» نیست.
این اعداد نشان می‌دهند که عامل‌ها لزوماً دفعات بیشتری شکست نمی‌خورند، بلکه توانایی ما برای توضیح دادن (Explainability) و بازگرداندن اقدامات آن‌ها از پیچیدگی سیستم‌ها عقب مانده است. تیم‌ها اکنون نگران این هستند که چه اتفاقی می‌افتد وقتی یک عامل کاری را انجام دهد که هرگز صراحتاً به او دستور داده نشده است.
ضرورت ردیابی‌پذیری
وقتی یک عامل در سیستم‌های مختلف عمل می‌کند، ارزشمندترین دارایی، سوابق «چرا» و «چطور» است. این به معنای دانستن این است که کدام ورودی خاص باعث تحریک کدام اقدام شد و کدام تصمیم منجر به چه نتیجه‌ای گشت. بدون این ردپا، هر حادثه به یک تمرین جرم‌شناسی (Forensic) بدون هیچ مدرکی تبدیل می‌شود و تیم‌ها مجبورند درباره سیستمی حدس بزنند که مدت‌ها پیش از آن نقطه عبور کرده است.
ردیابی‌پذیری (Traceability) باید پیش از آنکه به یک مسئله «پذیرش قانونی» و تطبیقی تبدیل شود، به عنوان یک مسئله مهندسی پرداخت شود. این کار مستلزم موارد زیر است:
- ثبت استدلال‌ها و اقدامات عامل در قالبی که انسان بتواند آن را بازسازی کند.
- طراحی سیستم‌هایی که در آن‌ها هر تصمیم واحد را بتوان مستقیماً به محرک اولیه‌اش ردیابی کرد.
- گنجاندن ردپای حسابرسی (Audit Trail) در معماری سیستم، به جای اینکه پس از وقوع یک شکست به آن اضافه شود.
در نهایت، عامل‌هایی که نمی‌توانند عملکرد خود را توضیح دهند، عامل‌هایی هستند که نمی‌توان آن‌ها را مدیریت یا حاکم کرد.
مهندسی در برابر تطبیق قانونی
بسیاری از تیم‌ها منتظرند تا تقویم‌های رگولاتوری تعریف کنند که حاکمیت «خوب» چیست. برای مثال، قانون‌گذاران اتحادیه اروپا در می ۲۰۲۶ به یک توافق سیاسی رسیدند تا اکثر تعهدات پرخطر قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) را از تاریخ اولیه (آگوست ۲۰۲۶) به دسامبر ۲۰۲۷ موکول کنند. اگرچه قوانین مربوط به شفافیت همچنان در آگوست ۲۰۲۶ اجرایی می‌شوند، اما ضرب‌الاجل اصلی بیش از یک سال جابه‌جا شد.
اتکا به این تاریخ‌ها یک اشتباه است؛ زیرا مذاکرات سیاسی دیکته نمی‌کنند که یک عامل خاص در یک محیط عملیاتی (Production) چگونه شکست می‌خورد. یک تقویم قانونی هیچ چیز به شما درباره اینکه عامل‌های شما به چه چیزهایی دسترسی دارند یا وقتی از مسیر خارج می‌شوند (Drift)، چطور آن‌ها را بگیرید، نمی‌گوید. این‌ها سؤالات مهندسی هستند که فقط کسانی پاسخ می‌دهند که معماری سیستم را درک می‌کنند.
چارچوبی جدید برای نظارت
نیک تالوار (Nick Talwar)، CTO سابق مایکروسافت و مهندس هوش مصنوعی، پیشنهاد می‌کند برای گذار از حاکمیت نظارت‌شده به حاکمیت عامل‌محور، تمرکز را از «نقطه پایان» (Endpoint) به «توالی عملیات» (Sequence) تغییر دهیم. نظارت باید مسیر را ببیند، نه فقط خروجی نهایی را. این یعنی تعریف مرزهایی برای آنچه عامل مجاز به لمس آن است و تصمیم‌گیری پیش‌دستانه درباره اتفاقاتی که هنگام عملیات خارج از محدوده مورد نظر رخ می‌دهد.
تیم‌ها باید به جای نصب یک چک‌پوینت یا بررسی تک‌مرحله‌ای در انتهای خروجی، نقاط کنترل را مستقیماً در مسیر حرکت عامل بگذرانند. مهندسان باید بتوانند به سه سؤال کلیدی پاسخ دهند:
۱. این عامل به چه چیزهایی دسترسی دارد؟
۲. وقتی چیزی را اشتباه می‌گیرد، چه واکنشی نشان می‌دهد؟
۳. چگونه هر نتیجه را می‌توان به تصمیم اولیه بازگرداند؟
با تعریف دسترسی‌های محدود (Bounded Access) و گنجاندن ردپاهای حسابرسی در معماری, سازمان‌ها می‌توانند هم مشتریان سازمانی و هم رگولاتورهای آینده را راضی کنند. اگر تیمی بتواند به این سؤالات پاسخ دهد، در واقع عاملی را ساخته است که واکنشی تعریف شده به خطا دارد و ردپای حسابرسی آن قابل دنبال است. تنها حاکمیتی که واقعاً از شرکت محافظت می‌کند، همان چیزی است که در مهندسیِ خودِ عامل عجین شده باشد.
گام بعدی شما
- بررسی کنید آیا سیستم‌های فعلی شما فقط خروجی نهایی را چک می‌کنند یا مسیر تصمیم‌گیری عامل را ثبت می‌نمایند.
- برای هر عامل، یک «نقشه دسترسی» (Access Map) رسم کنید تا دقیقاً بدانید چه داده‌هایی در معرض ریسک هستند.
- معماری ثبت وقایع (Logging) خود را از حالت متنی ساده به حالت ساختاریافته تغییر دهید تا بازسازی حوادث سریع‌تر شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو