«مدل منابع انسانی»؛ جایگزینی برای تست نرم‌افزاری در ارزیابی هوش مصنوعی

تصور کنید کارمندی را استخدام می‌کنید که در ظاهر بسیار مطمئن است، اما در پشت پرده تصمیماتی می‌گیرد که شرکت را به ضررهای میلیونی می‌کشاند، در حالی که تمام داشبورد‌های مدیریتی شما سبز هستند. این دقیقاً همان ریسکی است که سوشیل کومار (Sushil Kumar)، مدیرعامل شرکت Cyara، برای سازمان‌هایی که عامل‌های هوش مصنوعی را بدون نظارت انسانی مستقر می‌کنند، پیش‌بینی می‌کند.

مدیریت یک عامل (Agent) — شبیه به دستیاری دیجیتال که می‌تواند به‌جای شما فکر کند و اقدام کند — مانند یک قطعه نرم‌افزار سنتی، دستورالعملی برای شکست‌های نامرئی است. طبق اعلام کومار، نرم‌افزارهای سنتی «قطعی» (Deterministic) هستند؛ یعنی ورودی A همیشه خروجی B را می‌دهد و رفتار سیستم قابل پیش‌بینی است. اما عامل‌های هوش مصنوعی غیرقطعی‌اند؛ یعنی یک پاسخ اشتباه می‌تواند دقیقاً شبیه به یک پاسخ درست به نظر برسد و در نتیجه، تجربه مشتری در حالی فرو می‌پاشد که ابزارهای مانیتورینگ فنی هیچ خطایی گزارش نمی‌کنند و همه چیز در ظاهر درست به نظر می‌رسد.

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

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

زمینه: رهبری و مأموریت سایارا

سوشیل کومار در دسامبر ۲۰۲۵ به‌عنوان مدیرعامل به Cyara پیوست. او بیش از ۲۵ سال تجربه رهبری در حوزه‌های هوش مصنوعی، DevOps، زیرساخت‌های ابری و تست نرم‌افزار دارد. سابقه حرفه‌ای او شامل نقش‌های رهبری ارشد محصول در شرکت Oracle برای بیش از ۱۶ سال است. همچنین او به‌عنوان نایب‌رئیس ارشد محصولات در CA Technologies و مدیر کل بخش DevOps در Broadcom فعالیت کرده است.

او پیش از پیوستن به سایارا، بنیان‌گذار و مدیرعامل شرکت RelicX.ai بود؛ جایی که یک پلتفرم اتوماسیون تست مبتنی بر قصد (Intent-based) و قدرت هوش مصنوعی زاینده را توسعه داد. پس از آنکه RelicX توسط شرکت Harness خریداری شد، کومار رهبری ادغام این فناوری را بر عهده گرفت تا استراتژی اتوماسیون تست هوش مصنوعی در Harness را شکل دهد. اکنون در سایارا، تمرکز اصلی او بر گسترش نفوذ جهانی شرکت و تقویت قابلیت‌های تضمین تجربه مشتری (CX) مبتنی بر هوش مصنوعی است.

شرکت Cyara اکنون به‌عنوان یک شرکت تضمین تجربه مشتری (CX Assurance) فعالیت می‌کند و به سازمان‌ها کمک می‌کند تا تعاملات خود را در کانال‌های صوتی، دیجیتال، پیام‌رسان و هوش مصنوعی مکالمه‌ای اعتبارسنجی کنند. پلتفرم عامل‌محور سایارا (Cyara Agentic Platform) به‌طور خاص برای مدیریت ماهیت غیرقطعی هوش مصنوعی طراحی شده تا مواردی چون توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند —، انحرافات رفتاری (Behavioral Drift) و شکست‌های مربوط به انطباق و قوانین (Compliance) را شناسایی کند.

قابلیت‌ها و گستره پلتفرم

پلتفرم عامل‌محور سایارا یک لایه تضمین جامع برای سازمان‌هایی فراهم می‌کند که عامل‌های خودمختار را مستقر می‌کنند. قابلیت‌های اصلی این پلتفرم عبارتند از:

• تست عامل‌های هوش مصنوعی: اعتبارسنجی پاسخ‌های غیرقطعی پیش از آنکه به دست مشتریان برسند.
• مانیتورینگ محیط عملیاتی: شناسایی لحظه‌ای توهمات و انحرافات رفتاری در جریان واقعی تعاملات.
• تضمین صدا و تلکام: اطمینان از اینکه لایه گفتار (Speech Layer) و اتصالات ارتباطی قابل اعتماد و پایدار هستند.
• تست کانال‌های دیجیتال: اعتبارسنجی تعاملات متنی و پیام‌رسان‌ها برای اطمینان از صحت عملکرد.
• مشاهده‌پذیری CX: ارزیابی سفرهای مشتری از ابتدا تا انتها برای اطمینان از یکپارچگی و ثبات تجربه.

به گزارش این شرکت، این پلتفرم سالانه بیش از ۳۵۰ میلیون سفر مشتری را در بیش از ۱۴۰ کشور پشتیبانی می‌کند. با حرکت سازمان‌ها به سمت گردش‌کارهای خودمختار، سایارا خود را به‌عنوان لایه‌ی ضروری برای ارزیابی این موضوع معرفی می‌کند که آیا سیستم‌ها قبل و بعد از استقرار، به‌طور قابل اعتماد، ایمن و سازگار رفتار می‌کنند یا خیر.

استعاره نیروی کار: ترفیع به‌جای استقرار

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

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

برای حل این مشکل، کومار یک مدل عملیاتی شبیه به «منابع انسانی» (HR) پیشنهاد می‌دهد. شما یک کارمند را با اسکریپت کردن تک‌تک تصمیماتی که خواهد گرفت مدیریت نمی‌کنید؛ بلکه به او یک نقش می‌دهید، محدوده اختیاراتی که با آن نقش می‌آید را تعیین می‌کنید و هرگاه ثابت کرد توانمند است، این اختیارات را گسترش می‌دهید. یک عامل هوش مصنوعی نیز در چنین ساختاری رفتار می‌کند. در اینجا، خودمختاری یک تصمیم مربوط به استقرار فنی نیست، بلکه سلسله‌ای از ترفیعات است که عامل باید با نشان دادن توانایی در انجام وظیفه، ماندن در محدوده اختیارات و تشخیص زمان نیاز به کمک، آن‌ها را به دست آورد. این رویکرد با استراتژی Unily برای تبدیل تجربه کارکنان به یک مرکز هوش مصنوعی حاکم همسو است که بر بازتعریف نقش انسان و ماشین در محیط کار تأکید دارد.

چهار ستون حاکمیت عامل‌ها

بر اساس مصاحبه کومار با unite.ai، هر عامل پیش از آنکه برای اولین بار با محیط عملیاتی تماس داشته باشد، باید یک «شرح شغلی» (Job Description) دقیق داشته باشد. این شرح باید به‌طور صریح تعریف کند که عامل برای دستیابی به چه هدفی است، چه اطلاعاتی به‌عنوان منبع معتبر (Authoritative) شناخته می‌شوند، به چه داده‌های مشتری دسترسی دارد، چه تصمیماتی را می‌تواند به‌طور مستقل بگیرد و مسئولیت او دقیقاً کجا به پایان می‌رسد. اگر شرکتی نتواند این موارد را در یک پاراگراف بنویسد، آن عامل برای دمو آماده است، نه برای پذیرش یک نقش شغلی.

پس از تعریف نقش، کومار یک توالی چهارمرحله‌ای سخت‌گیرانه برای استقرار پیشنهاد می‌کند و تأکید می‌کند که ترتیب این مراحل حیاتی است:

۱. شواهد پیش از لانچ: اثبات اینکه عامل می‌تواند در شرایطی که شبیه به دنیای واقعی است (و نه فقط در تست‌های کنترل‌شده) عملکرد مناسبی داشته باشد.
۲. نظارت حین اجرا: مانیتورینگ اینکه عامل واقعاً چه اقدامی انجام داده است، نه اینکه صرفاً تأیید شود سیستم پاسخی داده است.
۳. درگاه‌های ترفیع: اعطای اختیارات بیشتر تنها زمانی که شواهد کافی برای پشتیبانی از آن وجود داشته باشد و نه پیش از آن.
۴. مالکیت تجاری: تعیین یک مسئول در بخش کسب‌وکار (Business Owner) — و نه در تیم مهندسی — که پاسخگوی نهایی آنچه عامل اجازه انجامش را دارد باشد.

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

تعریف مجوزها و مرزها

کومار بر تفاوت حیاتی بین «نقش» و «مجوز» (Permission) تأکید می‌کند. در حالی که نقش تعریف می‌کند عامل «برای چه کاری» است، مجوزها تعریف می‌کنند که عامل «به کجا» دسترسی دارد. بسیاری از شرکت‌ها به اشتباه فقط گفتگوی اول (تعریف نقش) را انجام می‌دهند.

سازمان‌ها برای مدیریت ریسک باید در مورد سه مرز مشخص باشند:

• دسترسی و جهت داده‌ها: تفکیک بین مجوز «خواندن» یک رکورد مشتری و مجوز «تغییر» آن. این دو، دو مجوز کاملاً متفاوت هستند و نباید یکی انگاشته شوند.
• تعهدات مالی و سیاستی: تعریف دقیق مواردی که عامل می‌تواند به‌تنهایی متعهد شود، زیرا پول و مسئولیت قانونی در اینجا نهفته است (مثلاً مبلغ بازپرداخت، اعطای اعتبار یا ایجاد استثنا در سیاست‌های شرکت).
• محرک‌های ارجاع (Handoff Triggers): شناسایی مواردی که از پیش می‌توان آن‌ها را نام برد و همچنین شناسایی سیگنال‌هایی که نشان می‌دهند عامل از محدوده صلاحیت خود خارج شده است.

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

به دست آوردن خودمختاری

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

کومار اشاره می‌کند که یک عامل ممکن است در شرایط کنترل‌شده قوی به نظر برسد، اما وقتی زمینه (Context) یا سیستم‌های پیرامونی تغییر می‌کنند، رفتار متفاوتی نشان دهد. برای مثال، مشتری ممکن است با یک سؤال ساده در مورد صورت‌حساب شروع کند، اما پس از یک پرداخت ناموفق، عصبانی شود. عامل باید این تغییر وضعیت را در لحظه تشخیص دهد و مسیر خود را تغییر دهد، نه اینکه به مسیر پیش‌تأییدشده ادامه دهد.

سه شرط برای گسترش اختیارات لازم است:
۱. عامل شغل را در شرایط واقعی انجام دهد، نه فقط در داده‌های تمیز و ایده‌آل.
۲. عامل لبه‌های صلاحیت خود را بشناسد و در همان نقطه متوقف شود.
۳. شواهد برای هر دو مورد بالا در هر لحظه قابل ارائه باشد.

سطح اثبات باید با سطح خودمختاری متناسب باشد. تصمیمات کوچک به شواهد سبک نیاز دارند، اما دسترسی به سیستم‌های پرداخت یا توانایی ایجاد استثنا در سیاست‌ها، نیازمند استانداردی به‌مراتب بالاتر است.

تست برای موارد غیرقابل پیش‌بینی

معیارهای سنتی مانند امتیازدهی پاسخ‌ها در برابر یک «مجموعه طلایی» (Golden Set) تنها کفِ استاندارد هستند. کومار اشاره می‌کند که امتیاز ارزیابی ۹۹٪ عالی به نظر می‌رسد، اما در مقیاس یک میلیون مکالمه در سال، این یعنی ۱۰ هزار تعامل شکست‌خورده که می‌تواند فاجعه‌بار باشد.

برای کاهش این ریسک، Cyara روی «درزهای» (Seams) بین سیستم‌ها تمرکز می‌کند. مدل هوش مصنوعی به‌ندرت تنها مشکل است؛ شکست‌ها اغلب از زمینه‌ای ناشی می‌شوند که مدل دریافت کرده است، مانند یک مقاله دانش قدیمی، تضاد بین دو سیستم در مورد سیاست‌ها، یا ارجاعی که اطلاعات قبلاً ارائه شده توسط مشتری را حذف کرده است. سایارا این الگو را در ۴۵۰ سازمان و بیش از ۵۵ فروشنده مختلف فناوری و تمام پلتفرم‌های اصلی مراکز تماس (Contact Center) مشاهده کرده است. این عدم دقت در پیاده‌سازی و نظارت می‌تواند منجر به اتلاف منابع شود؛ چنان‌که گزارش شده ۵۹٪ سازمان‌ها بودجه‌های هوش مصنوعی خود را هدر می‌دهند زیرا استقرارها را بدون لایه‌های تضمین کیفیت پیش می‌برند.

تست مؤثر باید فراتر از مسیرهای مورد انتظار برود. کومار پیشنهاد می‌کند عامل‌ها را با موارد زیر به چالش بکشید:

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

در تعاملات صوتی، لایه گفتار (Speech Layer) حیاتی است. اگر سیستم سؤال را اشتباه بشنود، عامل به سؤالی پاسخ می‌دهد که کسی نپرسیده است، فارغ از اینکه مدل چقدر پیشرفته باشد. هدف این نیست که تأیید کنیم عامل کار می‌کند، بلکه هدف این است که بفهمیم وقتی شرایط «تمیز» نیست، عامل چگونه رفتار می‌کند.

شکاف پاسخگویی

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

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

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

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

تکامل تست برای سیستم‌های استدلالی

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

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

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

مقیاس‌پذیری فراتر از پایلوت

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

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

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

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

گام بعدی شما

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

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.