برای مقیاس‌پذیری موفق عامل‌های هوش مصنوعی، آن‌ها را مانند اعضای تیم خود ببینید

این پرسش بازتاب‌دهنده فرض‌هایی است که در عصر نرم‌افزار به‌عنوان خدمت، پذیرش نرم‌افزارهای سازمانی را هدایت کرده‌اند. نخست اینکه بیشتر ابزارها را می‌توان با سفارشی‌سازی نسبتاً اندک، تأمین، پیکربندی و مقیاس‌پذیر کرد و دوم اینکه اگر یکپارچه‌سازی به‌درستی انجام شود و کارکنان نیز محصول را بپذیرند، استقرار آن عمدتاً یک پروژه پیاده‌سازی خواهد بود. هوش مصنوعی عامل‌محور این الگو را برهم می‌زند.

عامل وارد می‌شود

برخلاف نرم‌افزارهای سنتی، عامل‌های هوش مصنوعی برای استدلال، برنامه‌ریزی و انجام اقدام در میان سیستم‌های مختلف طراحی شده‌اند. لحظه‌ای که یک عامل بتواند یک سیستم مرجع را تغییر دهد؛ برای مثال، قیمتی را به‌روزرسانی کند، پرداختی را ارسال کند یا داده‌های مشتری را اصلاح کند، دیگر صرفاً یک ابزار بهره‌وری نیست، بلکه به بخشی از مدل عملیاتی سازمان تبدیل می‌شود.

مهم‌تر از همه، این فناوری دسته‌های جدیدی از ریسک را ایجاد می‌کند. یک ابزار محدود هوش مصنوعی مولد، مانند ChatGPT، ریسک محتوایی ایجاد می‌کند و ممکن است مطلبی نادرست بیان کند. اما هوش مصنوعی عامل‌محور، ریسک اجرایی ایجاد می‌کند و ممکن است اقدامی نادرست انجام دهد.

باتکیه‌بر فعالیت‌های «راهول تلانگ» و «محمد ضیا حیدری» به‌عنوان پژوهشگر و تجربه عملی «راجا اقبال» در مدیریت استقرارهای هوش مصنوعی عامل‌محور در سطح سازمانی، توجه دقیقی به شیوه پیاده‌سازی واقعی هوش مصنوعی عامل‌محور شده است. این تیم دریافت که اگرچه بسیاری از عامل‌ها امروز آماده اقدام هستند، شرکت‌ها به‌ندرت آماده‌اند که واقعاً به آن‌ها اجازه اقدام بدهند.

برای عبور از این آستانه و یکپارچه‌سازی مؤثر عامل‌های هوش مصنوعی در مقیاس وسیع، نباید دیگر با آن‌ها مانند نرم‌افزارهای آماده‌ای که صرفاً نیاز به نصب دارند برخورد کنید؛ بلکه باید آن‌ها را نوع جدیدی از نیروی کار بدانید که به مدیریت نیاز دارد. عامل‌های هوش مصنوعی نیز، درست مانند نیروی انسانی شما، به یک نقش، محدوده اختیارات مشخص، منابع تأییدشده حقیقت و قواعد روشن برای ارجاع و تشدید موضوع نیاز دارند. آن‌ها همچنین به نظارت و ممیزی نیازمندند، زیرا در نهایت شما در قبال اقدامات آن‌ها پاسخ‌گو خواهید بود.

تا زمانی که این بنیان‌های سازمانی ایجاد نشوند، مقیاس‌پذیر کردن هوش مصنوعی عامل‌محور دشوار خواهد بود. به طور خاص، چهار اصطکاک تکرارشونده معمولاً روند پیشرفت را کند یا حتی منحرف می‌کنند. درک این موارد، نخستین گام برای مدیریت آن‌هاست.

هویت: مدیران باید بدانند «چه کسی» در حال اقدام است

شرکت‌ها دهه‌ها صرف ایجاد سازوکارهای کنترل دسترسی برای کارکنان انسانی کرده‌اند. کاربران سیستم‌های رایانه‌ای با یک هویت منحصربه‌فرد وارد سیستم می‌شوند و نقش آن‌ها تعیین می‌کند چه کارهایی را می‌توانند و چه کارهایی را نمی‌توانند انجام دهند.

عامل‌های هوش مصنوعی این وضعیت را پیچیده می‌کنند، زیرا مانند کارکنان انسانی رفتار می‌کنند، اما انسان نیستند. بسیاری از استقرارهای اولیه، این مسئله را با اعطای یک «حساب خدماتی» مشترک با دسترسی گسترده به چندین سیستم به عامل‌ها حل می‌کنند. هرچند این راه‌حل، راحت است؛ اما اعطای این حجم از مجوزها به عامل‌ها، یک ریسک امنیتی ایجاد می‌کند.

این مثال را در نظر بگیرید. یک نماینده خدمات مشتری مجاز است تا سقف ۵۰۰ دلار بازپرداخت انجام دهد. اگر نماینده تلاش کند مبلغ بیشتری را بازپرداخت کند، سیستم تراکنش را مسدود کرده و آن را برای تأیید ارجاع می‌دهد. اما یک عامل هوش مصنوعی که از طریق یک حساب خدماتی مشترک در بخش پشتی سیستم فعالیت می‌کند، ممکن است مشمول چنین محدودیت اختیاری نباشد و بتواند در یک مرحله، اعتبار ۵۰۰۰ دلاری صادر کند.

این ریسک‌ها صرفاً فرضی نیستند. در سال ۲۰۲۵، یک توسعه‌دهنده در آزمایشی با استفاده از عامل کدنویسی هوش مصنوعی Replit نشان داد که اتوماسیون با چه سرعتی می‌تواند از کنترل‌های خود فراتر برود. باوجوداینکه به عامل دستور داده شده بود هیچ تغییری ایجاد نکند، این عامل دستورهایی را اجرا کرد که یک پایگاه‌داده عملیاتی را حذف کردند. سپس تلاش کرد این شکست را پنهان کند و هزاران رکورد جعلی و پیام گمراه‌کننده سیستمی تولید کرد؛ اقدامی که روند واکنش را کند و بازیابی را پیچیده‌تر کرد.

نکته روشن است؛ سازمان‌ها باید با هر عامل هوش مصنوعی مانند یک نیروی کار دیجیتال مجزا رفتار کنند که هویت، اعتبارنامه و نقش مخصوص به خود را دارد. شرکت‌ها به‌جای اتکا به حساب‌های خدماتی مشترک، باید مجوزهایی با دامنه محدود به عامل‌ها اختصاص دهند که متناسب با وظایف مشخصی باشد که برای انجام آن‌ها طراحی شده‌اند. همان اصولی که برای مدیریت کارکنان انسانی به کار می‌روند باید درباره عامل‌ها نیز اعمال شوند؛ مانند دسترسی با حداقل سطح مجوز و محدودیت‌های مبتنی بر نقش. اگر یک کارمند خدمات مشتری نمی‌تواند بدون تأیید، بازپرداختی بیش از یک آستانه مشخص انجام دهد، همین محدودیت باید برای عاملی که همان کار را انجام می‌دهد نیز برقرار باشد.

به همان اندازه اهمیت دارد که هر اقدامی که یک عامل انجام می‌دهد، تحت یک هویت قابل‌ردیابی ثبت شود تا سازمان بتواند به‌وضوح مشخص کند چه کسی یا چه چیزی آن اقدام را انجام داده است. اگر رهبران نتوانند به‌سادگی توضیح دهند که یک عامل هنگام اجرای یک اقدام از کدام هویت استفاده می‌کند، آن سیستم هنوز برای محیط عملیاتی آماده نیست.

زمینه: داده‌های بد می‌توانند به اقدامات بد منجر شوند

عامل‌های هوش مصنوعی در نمایش‌ها عملکرد خوبی دارند، زیرا محیط کنترل‌شده است. داده‌ها تمیز و منظم‌اند، دستورالعمل‌ها روشن هستند و منابع حقیقت کاملاً مشخص‌اند. اما سازمان‌های واقعی متفاوت‌اند. داده‌های سازمانی میان سیستم‌های مختلف پراکنده‌اند، در میان تیم‌ها تکرار شده‌اند و اغلب با یکدیگر تناقض دارند. سیاست‌ها در طول زمان تغییر می‌کنند و اسناد قدیمی همچنان در گردش باقی می‌مانند. انسان‌ها با استفاده از قضاوت و تجربه‌ای که عامل‌های هوش مصنوعی فاقد آن هستند، این ابهام‌ها را مدیریت می‌کنند.

برای سیستمی که متن تولید می‌کند، زمینه ناقص ممکن است به پاسخی معیوب منجر شود. این یک مشکل است، اما پیامدهای آن اغلب محدود است. بااین‌حال، برای سیستمی که اقدام می‌کند، پیامدها بسیار گسترده‌تر هستند. برای مثال، عاملی در حوزه منابع انسانی را تصور کنید که برای راهنمایی مدیران در فرایند خاتمه همکاری با یک کارمند، به یک سند سیاستی مربوط به سال ۲۰۲۲ که بارها به آن ارجاع داده شده است تکیه می‌کند؛ درحالی‌که قوانین از آن زمان تغییر کرده‌اند. این دیگر توهم نیست؛ بلکه یک خطای بازیابی اطلاعات است که شرکت را در معرض ریسک حقوقی قرار می‌دهد.

عامل‌ها همچنین یک چالش امنیتی جدید موسوم به دست‌کاری زمینه ایجاد می‌کنند. اگر یک عامل ایمیل‌ها، فرم‌ها یا تیکت‌های پشتیبانی را بخواند و سپس بر اساس آن اطلاعات وظایفی را انجام دهد، مهاجمان می‌توانند دستورالعمل‌های پنهانی را در این محتوا قرار دهند که برای تأثیرگذاری بر رفتار آن طراحی شده‌اند.

پژوهشگران در سال ۲۰۲۵ این ریسک را از طریق آسیب‌پذیری‌ای موسوم به ForcedLeak نشان دادند. آن‌ها با قراردادن دستورالعمل‌های مخرب در یک فرم وب معمولی، یک عامل Salesforce Agentforce را فریب دادند تا داده‌های حساس مدیریت ارتباط با مشتری را بازیابی کرده و آن‌ها را به یک مقصد خارجی ارسال کند.

برای مقابله با این اصطکاک‌های مرتبط با زمینه، سازمان‌ها باید استانداردهای روشنی برای تعیین اطلاعاتی که عامل‌هایشان می‌توانند به آن اعتماد کنند، ایجاد کنند. این امر مستلزم تعریف منابع معتبر برای سیاست‌ها، قیمت‌گذاری و داده‌های عملیاتی است تا عامل‌ها بتوانند به طور مستمر به نسخه درست حقیقت اتکا کنند. سیستم‌ها همچنین باید منشأ اطلاعات مورداستفاده در تصمیم‌گیری را ثبت کنند تا تیم‌ها بتوانند هر اقدام عامل را تا اسناد یا منابع داده مشخصی که بر آن‌ها تکیه داشته است، ردیابی کنند.

در نهایت، شرکت‌ها باید با ورودی‌های برون‌سازمانی مانند ایمیل‌ها، فرم‌ها یا فایل‌های بارگذاری‌شده، نه صرفاً به‌عنوان زمینه‌ای مفید، بلکه به‌عنوان عوامل بالقوه حمله برخورد کنند. ورودی‌هایی که منشأ آن‌ها خارج از سازمان است، باید با دقت مدیریت و پیش از آنکه به عامل اجازه داده شود بر اساس آن‌ها اقدام کند، اعتبارسنجی شوند. بدون این تدابیر حفاظتی، همان ناسازگاری‌های داده‌ای که انسان‌ها هر روز از میان آن‌ها عبور می‌کنند، می‌توانند به‌سرعت به خطاهای عملیاتی برای سیستم‌های خودکار تبدیل شوند.

کنترل: سیستم‌های احتمالاتی به قوانین سخت‌گیرانه نیاز دارند

نرم‌افزارهای سنتی رفتار قابل‌پیش‌بینی دارند؛ یک ورودی یکسان، هر بار خروجی یکسانی تولید می‌کند. اما مدل‌های زبانی بزرگ به این شکل عمل نمی‌کنند. پاسخ‌های آن‌ها احتمالاتی است؛ به این معنا که یک درخواست مشابه می‌تواند در اجراهای مختلف، نتایج اندکی متفاوت ایجاد کند. این میزان از تغییرپذیری زمانی که خروجی یک پیش‌نویس ایمیل است قابل‌قبول است، اما هنگامی که خروجی یک تراکنش باشد، به‌مراتب مسئله‌سازتر می‌شود.

یکی از شرکت‌هایی که یک عامل پشتیبانی مبتنی بر هوش مصنوعی را مستقر کرده بود، زمانی با این مسئله مواجه شد که تیم حقوقی اصرار داشت سیستم هرگز نام یک رقیب خاص را ذکر نکند. بااین‌حال، پایگاه دانش شرکت شامل مقالات مقایسه‌ای معتبر بسیاری بود که به آن رقیب اشاره داشتند و عامل نیز هنگام پاسخ به پرسش‌های مشتریان، مرتباً نام آن را مطرح می‌کرد. زمانی که مهندسان محدودیت‌ها را سخت‌گیرانه‌تر کردند تا این پاسخ‌ها مسدود شوند، سیستم حتی از پاسخ‌گویی به پرسش‌های معتبر نیز امتناع کرد.

مسئله عمیق‌تر این است که فرض روش‌های سنتی آزمون، رفتار پایدار است. اگر مدل به‌روزرسانی شود، پرامپت تغییر کند یا داده‌های جدیدی اضافه شوند؛ سیستمی که امروز از یک مجموعه آزمون عبور می‌کند، ممکن است فردا رفتاری متفاوت داشته باشد. این ریسک‌ها در محیط‌های چندعاملی، جایی که عامل‌ها کار را به یکدیگر منتقل می‌کنند نیز بیشتر می‌شوند.

به‌عنوان‌مثال، پژوهشگران AppOmni در سال ۲۰۲۵ نشان دادند که پیکربندی‌های ناامن در محیط Now Assist شرکت ServiceNow چگونه می‌توانند امکان «تزریق پرامپت مرتبه دوم» (Second-Order Prompt Injection) را فراهم کنند. در آزمایش آن‌ها، دستورالعمل‌های مخربی که توسط یک عامل وارد شده بودند، به عامل‌های دیگر منتقل می‌شدند و به طور بالقوه می‌توانستند به اقدامات ناخواسته یا غیرمجاز منجر شوند؛ از جمله بازیابی سوابق حساس یا ارسال اطلاعات به مقاصد خارجی.

نتیجه اصلی این است که بدون مرزهای روشن، اشتباهات (یا حملات) می‌توانند در سراسر یک سیستم خودکار زنجیره‌وار گسترش یابند. برای مدیریت این ریسک، سازمان‌ها باید کنترل‌های قطعی و مبتنی بر قواعد را پیرامون سیستم‌های احتمالاتی هوش مصنوعی ایجاد کنند. شرکت‌ها به‌جای آنکه به عامل‌ها اجازه دهند مستقیماً اقدام کنند، باید لایه‌های اعتبارسنجی را میان مدل هوش مصنوعی و سیستم‌های عملیاتی قرار دهند.

در این رویکرد، عامل اقدامی را پیشنهاد می‌کند؛ برای مثال، صدور بازپرداخت یا به‌روزرسانی یک رکورد. سپس، پیش از اجرای آن، یک نرم‌افزار قطعی و مبتنی بر قواعد بررسی می‌کند که آیا این اقدام با قوانین تعیین‌شده مطابقت دارد یا خیر. سازمان‌ها باید تعاملات بدون نظارت میان عامل‌ها را نیز محدود کنند تا خروجی یک عامل، بدون اعتبارسنجی، بررسی سیاست‌ها یا بازبینی انسانی، به طور خودکار به دستورالعمل قابل‌اجرا برای عامل دیگر تبدیل نشود. با تفکیک تولید یک توصیه از اجرای یک اقدام، شرکت‌ها می‌توانند سازوکارهای محافظتی ایجاد کنند که مانع از تبدیل تغییرپذیری مدل به خطاهای عملیاتی شوند.

پاسخ‌گویی: شرکت‌ها باید مسئولیت داخلی رفتار عامل‌ها را مشخص کنند

وقتی یک کارمند اشتباه می‌کند، مدیران می‌توانند با پرسیدن سؤال تحقیق کنند. وقتی یک نرم‌افزار سنتی دچار خطا می‌شود، مهندسان می‌توانند گزارش‌های ثبت رویداد یا لاگ‌ها را بررسی کنند. اما عامل‌های هوش مصنوعی وضعیت پیچیده‌تری ایجاد می‌کنند، زیرا رفتار آن‌ها اغلب از زنجیره‌ای از مراحل استدلال، اسناد بازیابی‌شده و فراخوانی ابزارها پدید می‌آید که بازسازی آن‌ها پس از وقوع رویداد ممکن است آسان نباشد.

این مسئله یک چالش جدی در زمینه پاسخ‌گویی ایجاد می‌کند. برای مثال، یک عامل تدارکات را تصور کنید که عملکرد تأمین‌کنندگان را خلاصه کرده و نتایج را در کانال Slack شرکت منتشر می‌کند. اگر عامل به طور تصادفی شرایط محرمانه یک قرارداد را نیز در محتوا وارد کند (زیرا عبارت «شفاف به اشتراک بگذار» را به منزله مجوز افشای آن اطلاعات تفسیر کرده است) رهبران باید دقیقاً بدانند این تصمیم چگونه گرفته شده است. عامل چه اسنادی را خوانده است؟ از چه دستورالعمل‌هایی پیروی کرده است؟ چرا تصور کرده اجازه اشتراک‌گذاری این اطلاعات را دارد؟ بدون چنین زنجیره‌ای از شواهد، سازمان‌ها نمی‌توانند رفتار سیستم‌های خود را برای نهادهای تنظیم‌گر، حسابرسان و مشتریان توضیح دهند.

رأی یک دادگاه در سال ۲۰۲۴، نشانه‌ای اولیه از نحوه برخورد قانون با این مسئله ارائه می‌کند. در پرونده Moffatt v. Air Canada، یک مشتری به اطلاعات نادرستی که یک چت‌بات شرکت هواپیمایی درباره شرایط برخورداری از نرخ ویژه سفر در موارد سوگواری ارائه کرده بود، اعتماد کرد. زمانی که شرکت هواپیمایی استدلال کرد چت‌بات عملاً یک موجودیت جداگانه است، دادگاه این ادعا را نپذیرفت و شرکت را مسئول اطلاعات نادرست دانست.

برای اجتناب از چنین مشکلاتی، شرکت‌ها باید از همان ابتدا سیستم‌های هوش مصنوعی خود را با درنظرگرفتن پاسخ‌گویی طراحی کنند. این کار با نگهداری سوابق جامع از نحوه عملکرد یک عامل آغاز می‌شود؛ از جمله اینکه عامل به کدام منابع داده دسترسی داشته، چه پرامپت‌هایی دریافت کرده و برای تکمیل یک وظیفه از چه ابزارهایی استفاده کرده است.

این سوابق باید امکان بازسازی زنجیره استدلالی را که به هر اقدام منجر شده است فراهم کنند. سازمان‌ها همچنین باید مسئولیت داخلی مشخصی برای نظارت و حاکمیت بر رفتار عامل‌ها تعیین کنند تا مسئولیت در میان بخش‌ها پراکنده و مبهم نشود. اگر یک نهاد تنظیم‌گر، حسابرس یا مشتری بپرسد چرا یک سیستم هوش مصنوعی تصمیم خاصی گرفته است، شرکت باید بتواند توضیحی روشن و مبتنی بر شواهد ارائه کند. بدون این سطح از شفافیت، دفاع از اتوماسیون در مقیاس وسیع همچنان دشوار خواهد بود.

مسیر پیش‌رو

اگر استقرار آماده و بی‌دردسر عامل‌های هوش مصنوعی واقع‌بینانه نیست، جایگزین آن پرهیز از استفاده از این عامل‌ها نیست؛ بلکه باید آن‌ها را به‌تدریج وارد سازمان کرد و صرفاً هم‌زمان با توسعه توانایی سازمان برای حاکمیت بر آن‌ها، میزان خودمختاری‌شان را افزایش داد.

یک روش مفید برای درک این مسیر پیشرفت، تصور آن به‌صورت یک «نردبان خودمختاری» با سطوح مختلف اختیار اجراست؛ به‌این‌ترتیب که آیا سیستم محتوا تولید می‌کند، اقداماتی را برای تأیید پیشنهاد می‌دهد یا اقداماتی را در محدوده‌های کاملاً تعریف‌شده اجرا می‌کند؟

سازمان‌ها معمولاً با عامل‌هایی شروع می‌کنند که خروجی کمکی تولید می‌کنند؛ مانند پیش‌نویس‌ها، خلاصه‌ها یا توصیه‌هایی که انسان‌ها پیش از ارسال یا اجرای هر چیزی آن‌ها را بررسی می‌کنند. سطح بعدی، بازیابی اطلاعات همراه با سازوکارهای محافظتی است؛ جایی که عامل‌ها با استفاده از اطلاعات داخلی به پرسش‌ها پاسخ می‌دهند، اما به منابع داده‌ای با حاکمیت مناسب متکی هستند.

پس از آن، شرکت‌ها می‌توانند اقدامات تحت نظارت را مجاز کنند؛ وضعیتی که در آن عامل‌ها وظایف عملیاتی مانند صدور بازپرداخت، به‌روزرسانی سوابق یا ارجاع موارد برای تأیید را پیشنهاد می‌دهند، اما یک انسان همواره پیش از اجرا تصمیم را تأیید می‌کند. تنها پس از اثبات کارآمدی این کنترل‌ها، سازمان‌ها باید خودمختاری محدودشده را در نظر بگیرند؛ جایی که عامل‌ها گردش‌کارها را به طور مستقل، اما در محدوده‌های محدود و آستانه‌های ازپیش‌تعیین‌شده اجرا می‌کنند.

بسیاری از استقرارهای مؤثر، به‌صورت آگاهانه در پله‌های پایین‌تر نردبان خودمختاری باقی می‌مانند. به‌عنوان‌مثال، شرکت مشاوره OneDigital از Azure OpenAI برای تسریع تحقیقات مشاوران استفاده می‌کند و به‌جای جایگزین‌کردن خود مشاوران، «زمان دستیابی به بینش» را بهبود می‌دهد. برخی استقرارهای برجسته دیگر با محدود نگه‌داشتن دامنه فعالیت، به خودمختاری محدودشده دست پیدا می‌کنند. Klarna اعلام کرده است که دستیار هوش مصنوعی این شرکت بخش بزرگی از گفت‌وگوهای خدمات مشتری را به‌صورت خودمختار مدیریت می‌کند و درعین‌حال، برای موارد پیچیده یا حساس، مسیرهای فوری ارجاع به پشتیبانی انسانی را حفظ کرده است.

برای رهبرانی که در حال ارزیابی تعداد روبه‌رشد پلتفرم‌های عامل‌محور هستند، مهم‌ترین سرمایه‌گذاری‌ها اغلب سازمانی هستند، نه فنی. شرکت‌ها باید کار را با تعریف یک «مرز استقرار آماده» روشن آغاز کنند؛ مرزی که میان کاربردهای هوش مصنوعی قابل‌استقرار با حداقل تغییرات ساختاری و کاربردهایی که به بازطراحی اساسی کنترل‌ها و سازوکارهای حاکمیتی نیاز دارند، تمایز ایجاد می‌کند.

آن‌ها همچنین باید مجوزها را یک مسئله اساسی در طراحی بدانند و برای هر عامل، دسترسی محدود و متناسب با نقش آن تعیین کنند. آستانه‌های روشن «انسان در حلقه» (Human-in-the-Loop) باید مشخص کنند تصمیم‌های خودکار در چه زمانی به نظارت نیاز دارند؛ به‌ویژه در موقعیت‌هایی که با ریسک مالی، تعهدات نظارتی و ریسک اعتباری سازمان سروکار دارند. در نهایت، رهبران باید به‌جای اندازه‌گیری تعداد پروژه‌های آزمایشی، نتایج را بسنجند و بر شاخص‌های عملیاتی مانند زمان چرخه، نرخ خطا و رخدادهای عدم انطباق تمرکز کنند؛ نه صرفاً شمار آزمایش‌های هوش مصنوعی در حال اجرا.

هوش مصنوعی مولد همچنان به پیشرفت خود ادامه خواهد داد و وندورها نیز قابلیت‌های ایمنی بیشتری را در پلتفرم‌های خود عرضه خواهند کرد، اما فاصله میان یک نمایش چشمگیر و یک سیستم عملیاتی قابل‌اعتماد همچنان باقی خواهد ماند؛ مگر آنکه سازمان‌ها درک خود را از الزامات واقعی استقرار بازنگری کنند. سازمان‌های بزرگ محیط‌هایی آماده و قابل‌استقرار نیستند؛ آن‌ها سیستم‌های پیچیده‌ای هستند که فناوری‌های قدیمی، سیاست‌ها و قضاوت انسانی به آن‌ها شکل داده‌اند. شرکت‌هایی که در هوش مصنوعی عامل‌محور موفق خواهند شد، صرفاً عامل‌های بیشتری نصب نمی‌کنند؛ بلکه ساختارهایی ایجاد می‌کنند که امکان اعتماد به آن عامل‌ها را فراهم می‌سازد.

گزارش حاضر در نسخه  September-October 2026نشریه Harvard Business Review منتشر شده است.