ServiceNow: مهار عامل‌های هوش مصنوعی باید با زمینه کسب‌وکار سنجیده شود

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

Pitre این دیدگاه را در گفت‌وگویی با رسانه theCUBE در رویداد Oktane شرکت Okta مطرح کرد؛ گفت‌وگویی که SiliconANGLE آن را در ۲۸ سپتامبر ۲۰۲۶ منتشر کرد. ServiceNow طی سال جاری خود را به‌عنوان مرکزی برای کنترل هوش مصنوعی سازمانی معرفی کرده است و می‌خواهد دامنه این نقش را به نظارت بر عامل‌ها پس از استقرار نیز گسترش دهد. محور اصلی اظهارات این شرکت آن است که مهار عامل، صرفاً یک اقدام فنی نیست: سازمان باید بداند چه چیزی را متوقف می‌کند، چرا این کار را انجام می‌دهد و پیامد آن برای عملیات چیست.

چرا «کلید قطع» پاسخ یکسانی برای همه موقعیت‌ها نیست

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

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

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

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

چارچوب پنج‌مرحله‌ای برای حاکمیت عامل‌ها

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

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

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

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

امنیت عامل‌ها به همکاری چند شرکت وابسته است

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

ServiceNow برای بخشی از این کار با Okta همکاری می‌کند. Pitre گفت این همکاری بر ایمن‌سازی توکن‌های نشست عامل و هویت عامل‌ها متمرکز است. توکن نشست، به‌طور کلی، داده‌ای است که برای شناسایی یا مجازکردن یک نشست در سامانه به کار می‌رود؛ هویت عامل نیز مشخص می‌کند کدام عامل در حال فعالیت است و چه دسترسی‌هایی دارد. در محیطی که چند ابزار و لایه امنیتی دخیل‌اند، مدیریت این مؤلفه‌ها می‌تواند به روشن‌ترشدن این‌که چه عاملی با چه مجوزی عمل می‌کند کمک کند.

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

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

از توقف اضطراری تا تصمیم‌گیری متناسب با خطر

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

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

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

این خبر برای چه کسانی اهمیت دارد

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

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