)
)
عاملهای هوش مصنوعی در حال شروع به تعامل با برنامههای دسکتاپ به همان شیوهای هستند که کاربران انسانی انجام میدهند. برای تیمهای IT، این سوال مهمی را مطرح میکند: آیا نرمافزارهای موجود ویندوز، از جمله برنامههایی که APIهای مدرن ندارند، میتوانند بدون اینکه ابتدا جایگزین یا بازسازی شوند، به جریانهای کاری مبتنی بر هوش مصنوعی دسترسی پیدا کنند؟
این پاسخ پیامدهایی فراتر از اتوماسیون هوش مصنوعی دارد. این موضوع بر معماری دسکتاپ، تحویل برنامه، هویتها، مجوزها و امنیت سایبری تأثیر میگذارد، بهویژه زمانی که عوامل میتوانند اقداماتی انجام دهند نه اینکه فقط اطلاعات را بازیابی کنند.
چرا عوامل هوش مصنوعی به دسترسی به برنامههای دسکتاپ نیاز دارند؟
جایگاه APIها؟
بیشتر اتوماسیونهای شرکتی زمانی بهترین عملکرد را دارند که نرمافزار از طریق یک رابط برنامهنویسی کاربردی (API) ارتباط برقرار کند. APIها عملیات ساختاریافته و ورودی و خروجیهای قابل پیشبینی را بدون نیاز به تفسیر یک رابط گرافیکی ارائه میدهند.
مشکل این است که محیطهای شرکتی شامل برنامههایی هستند که هرگز بر اساس APIهای مدرن طراحی نشدهاند. برنامههای سفارشی ویندوز، مشتریان قدیمی ERP و نرمافزارهای اختصاصی خط کسبوکار میتوانند برای مدت طولانی پس از آنکه معماری اصلی آنها قدیمی شده است، ضروری باقی بمانند.
وارد کردن عوامل هوش مصنوعی
استفاده از کامپیوتر یک مسیر دیگر را ارائه میدهد. به جای اینکه هر برنامهای نیاز داشته باشد یک API را ارائه دهد، یک عامل هوش مصنوعی میتواند به طور بالقوه با همان رابطی که به یک کاربر انسانی ارائه شده است، تعامل داشته باشد.
این دیگر تنها یک آزمایش نیست. خدمات وب آمازون (AWS) اکنون Amazon WorkSpaces را برای عوامل هوش مصنوعی به عنوان یک محیط مدیریت شده معرفی میکند که در آن عوامل میتوانند برنامههای دسکتاپ را اجرا کنند، از جمله برنامههایی که بدون APIهای مدرن هستند. مایکروسافت به طور مشابه Windows 365 برای عوامل را به عنوان یک محیط اجرایی برای وظایفی که نیاز به تعامل با برنامههای دسکتاپ و وب دارند و فاقد APIهای قابل اعتماد هستند، توصیف میکند.
از آنجا که اینها پیشنهادات فروشنده هستند، فرض کنید که هر برنامه یا جریان کاری قدیمی برای عملکرد خودکار آماده نیست. هنگام برنامهریزی زیرساخت تولید، به این موضوع توجه داشته باشید.
چگونه میتوانند عوامل هوش مصنوعی واقعاً از برنامههای ویندوز استفاده کنند؟
نمایندگان هوش مصنوعی دسکتاپ همه به یک شکل با نرمافزار تعامل ندارند. سیستمهای استفاده از کامپیوتر میتوانند اسکرینشاتها را تحلیل کرده و کلیکهای ماوس و ورودیهای صفحهکلید تولید کنند و بهطور مؤثر برخی از تعاملات انسانی با یک رابط کاربری گرافیکی را بازتولید کنند.
رویکردهای دیگر از کنترلهای سیستمعامل، اطلاعات دسترسی یا تکنیکهای اتوماسیون قطعی نزدیک به اتوماسیون فرآیند رباتیک (RPA) استفاده میکنند. معماریهای هیبریدی میتوانند این روشها را با APIها یا ابزارهای پروتکل زمینه مدل (MCP) ترکیب کنند.
AWS، به عنوان مثال، تعامل بصری دسکتاپ را با انتقال ابزار MCP ترکیب میکند و به وظایف مناسب اجازه میدهد تا از یک ابزار مستقیم به جای تعامل در سطح پیکسل استفاده کنند. مایکروسافت همچنین عوامل استفادهکننده از کامپیوتر را از RPA در معماری Windows 365 for Agents متمایز میکند.
برای تیمهای IT، این تمایز مهم است. یک رابط ساختاریافته معمولاً باید ترجیح داده شود زمانی که قابلیتهای مورد نیاز را به طور قابل اعتماد و ایمن ارائه میدهد. تعامل با GUI زمانی به ویژه جالب میشود که هیچ مسیر برنامهنویسی مناسبی وجود نداشته باشد.
آیا هر عامل هوش مصنوعی به دسکتاپ خود نیاز دارد؟
زمانی که یک نماینده به یک برنامه گرافیکی نیاز دارد، تیمهای IT باید تصمیم بگیرند که آن تعامل باید در کجا انجام شود.
دسترسی به دسکتاپ محلی
یک عامل میتواند به طور بالقوه نرمافزاری را که بر روی یک ایستگاه کاری فیزیکی نصب شده است، اجرا کند. این دسترسی مستقیم به برنامهها، فایلها و زمینه کاربر موجود را فراهم میکند، اما همچنین خطر ترکیب فعالیتهای انسانی و خودکار را در یک محیط واحد به همراه دارد.
اجرای محلی همچنین نیاز به تعریف دقیق دارد. یک عامل ممکن است به صورت محلی اجرا شود در حالی که درخواستها، اسکرینشاتها یا دادههای برنامه را به یک مدل هوش مصنوعی میزبانی شده بهطور از راه دور ارسال میکند. جایی که دسکتاپ اجرا میشود و جایی که دادهها پردازش میشوند، سوالات معماری جداگانهای هستند.
دسکتاپهای مجازی اختصاصی و DaaS
یک دسکتاپ مجازی اختصاصی جدایی قویتری ایجاد میکند. AWS WorkSpaces برای عوامل هوش مصنوعی و Microsoft Windows 365 برای عوامل این مدل را نشان میدهند و بارهای کاری عوامل را با جلسات دسکتاپ مدیریتشده فراهم میکنند، به جای اینکه به آنها اجازه دهند مستقیماً بر روی یک ایستگاه کاری کارمند عمل کنند. مایکروسافت رایانههای شخصی ابری تجمیعشده با هویتهای مدیریتشده، وضعیت دستگاه و چرخههای حیات جلسه تحت نظارت را توصیف میکند.
خدمات دسکتاپ به عنوان یک سرویس (DaaS) بنابراین به یکی از لایههای اجرایی ممکن برای عوامل هوش مصنوعی و همچنین کاربران انسانی تبدیل میشود.
تحویل برنامه از راه دور
با این حال، ممکن است یک دسکتاپ مجازی کامل همیشه ضروری نباشد. اگر یک عامل فقط به یک یا دو برنامه ویندوز نیاز داشته باشد، تیمهای IT میتوانند در نظر بگیرند که آیا آن برنامهها باید بهطور مرکزی میزبانی و بهعنوان جلسات کنترلشده از راه دور ارائه شوند یا خیر.
این سوال معماری را از "میزکار عامل باید کجا باشد؟" به "این عامل در واقع به چه منابعی نیاز دارد؟" تغییر میدهد.
آیا هوش مصنوعی میتواند به برنامههای قدیمی ویندوز زندگی جدیدی ببخشد؟
نرمافزارهای قدیمی به طور سنتی انتخاب دشواری برای پروژههای اتوماسیون ارائه دادهاند. اگر یک برنامه مهم دارای API نباشد، سازمانها ممکن است به ادغام سفارشی، RPA یا نوسازی برنامه قبل از اتصال آن به جریانهای کاری جدید نیاز داشته باشند.
عاملهای هوش مصنوعی یک امکان دیگر اضافه میکنند. اگر نرمافزار بتواند رابط کاربری موجود را تفسیر و دستکاری کند، خود GUI میتواند به یک سطح ادغام تبدیل شود.
AWS بهطور صریح از اجتناب از نوسازی برنامه و یکپارچهسازی سفارشی بهعنوان یک مورد استفاده برای WorkSpaces عامل خود یاد میکند. مایکروسافت در حال توسعه دسترسی از رایانههای Cloud عامل به برنامههای خط کسبوکار محلی است و بهطور مشابه قابلیت را در اطراف خودکارسازی جریانهای کاری بدون نوسازی اولیه برنامههای قدیمی چارچوببندی میکند.
این به این معنا نیست که هر برنامه قدیمی برای اتوماسیون دسکتاپ هوش مصنوعی مناسب است. رابطها تغییر میکنند، تفسیر بصری ممکن است شکست بخورد، جلسات ممکن است به وضعیتهای غیرمنتظره برسند و مجوزها ممکن است نحوه استفاده از برنامهها را محدود کنند. یک جریان کاری که به طور فنی برای یک عامل قابل دسترسی است هنوز نیاز به آزمایش برای قابلیت اطمینان، پشتیبانی و ریسک تجاری دارد.
کدام سوالات جدید امنیتی و انطباقی توسط دسترسی عامل هوش مصنوعی ایجاد میشود؟
دسترسی یک عامل هوش مصنوعی به نرمافزارهای تجاری نقش آن را از دستیار اطلاعاتی به شرکتکننده فعال در سیستم تغییر میدهد. بنابراین، مدل امنیتی باید فرض کند که یک عامل ممکن است اشتباه کند، زمینه را درک نکند یا اقداماتی را انجام دهد که از نظر فنی مجاز هستند اما هرگز در نظر گرفته نشدهاند.
یک عامل هوش مصنوعی به یک هویت و مجوزهای تعریف شده نیاز دارد
دسترسی نماینده باید با حداقل امتیاز شروع شود. تیمهای IT باید تعیین کنند که یک نماینده از کدام حساب استفاده میکند، به کدام برنامهها و فایلها دسترسی دارد، به کدام منابع شبکه میتواند دسترسی پیدا کند و آیا میتواند عملیاتهای امتیازدار یا مخرب را اجرا کند یا خیر.
حادثه PocketOS نمونهای بهویژه واضح از اهمیت کنترلهای معماری را نشان میدهد. در آوریل ۲۰۲۶، یک عامل کدنویسی هوش مصنوعی که بر روی یک وظیفه آزمایشی کار میکرد، توکن API راهآهن را بهدست آورد و پایگاه داده تولید شرکت و نسخههای پشتیبان مرتبط را در یک عملیات API حذف کرد. حذف گزارششده نه ثانیه طول کشید.
درس فراتر از کدنویسی عوامل است. دستوراتی که به یک عامل میگویند که عملیاتی خطرناک را انجام ندهد معادل زیرساختی نیستند که آن عملیات را جلوگیری کند.
هوش مصنوعی محلی و هوش مصنوعی شخص ثالث مسیرهای داده متفاوتی ایجاد میکنند
سازمانها همچنین نیاز دارند تا مشخص کنند اطلاعات کجا سفر میکند. یک دسکتاپ ممکن است بهصورت محلی میزبانی شود در حالی که مدل تفسیرکننده محتوای آن بر روی زیرساخت شخص ثالث عمل میکند.
عکسهای صفحه میتوانند سوابق مشتری، اعتبارنامهها یا دادههای محرمانه برنامه را افشا کنند. درخواستها، گزارشها و اطلاعات زمینهای میتوانند جریانهای داده اضافی ایجاد کنند که مشمول الزامات نگهداری، اقامت و مقررات هستند.
قبل از استقرار، تیمهای IT باید مشخص کنند که عامل در کجا اجرا میشود، مدل AI در کجا اجرا میشود و دادههای برنامه در کجا پردازش یا نگهداری میشوند.
نیاز به تأیید انسانی یک مرز معنادار دارد
کنترلهای انسان در حلقه قبل از اقدامهای مهم، نه بعد از آنها، اهمیت بیشتری دارند. حذف دادهها، تغییر مجوزها، ارسال تراکنشهای مالی یا تغییر سیستمهای تولید ممکن است نیاز به تأیید صریح داشته باشد یا به سادگی خارج از دامنه مجاز عامل باشد.
خطر گستردهتر دیگر فرضی نیست. پایگاه داده حوادث هوش مصنوعی در دوره پردازش خود از مه تا ژوئیه ۲۰۲۶، ۱۴۸ شناسه حادثه اضافه کرد و در عین حال هشدار داد که این اضافات شامل رویدادهایی از تاریخهای مختلف است و نباید به عنوان اندازهگیری فراوانی حوادث تفسیر شود. با این حال، خلاصه آن به مشکلات مکرر مربوط به سیستمهای خودمختار، حریم خصوصی و فعالیتهای امنیت سایبری با کمک هوش مصنوعی اشاره دارد.
نفوذ هگینگ فیس در ژوئیه ۲۰۲۶ هشدار متفاوتی را ارائه میدهد: هگینگ فیس گزارش داد که نفوذی به بخشی از زیرساخت تولید خود بهطور کامل توسط یک سیستم عامل هوش مصنوعی خودمختار انجام شده است. این یک حمله بود نه یک عامل مجاز شرکتی که فراتر از وظایف خود عمل کند، اما نشان میدهد که چگونه نرمافزارهای خودمختار میتوانند به سرعت زیرساختهای قابل دسترسی را کاوش و عمل کنند.
لاگها زمانی اهمیت بیشتری پیدا میکنند که کاربر نرمافزار باشد
یک جلسه نماینده باید شواهد کافی برای بازسازی آنچه اتفاق افتاده است، به جا بگذارد. سوابق احراز هویت، فعالیت جلسه، لاگهای برنامه و اقدامات نماینده همه میتوانند به آن مسیر حسابرسی کمک کنند.
مدیران همچنین به روشی برای خاتمه سریع فعالیت نیاز دارند. AWS قابلیت مشاهده جلسه در زمان واقعی و لغو دسترسی را به WorkSpaces برای عوامل هوش مصنوعی اضافه کرده است، در حالی که مایکروسافت نظارت، کنترلهای جلسه و مداخله انسانی را به عنوان بخشی از معماری Cloud PC عامل خود توصیف میکند. این کنترلها سوالات عملیاتی را که تیمهای IT باید بپرسند، نشان میدهند، صرف نظر از پلتفرم.
قبل از اعطای دسترسی دسکتاپ به یک عامل هوش مصنوعی، IT باید چه تصمیماتی بگیرد؟
نقطه شروع مفیدی این است که یک عامل هوش مصنوعی را به عنوان یک کلاس جدید از کاربران دارای امتیاز در نظر بگیریم نه به عنوان یک اسکریپت خودکار با قابلیتهای غیرمعمول.
قبل از اجازه دادن به دسترسی به دسکتاپ، تعیین کنید که آیا تعامل با رابط کاربری واقعاً ضروری است و عامل را از منابعی که به آن نیاز ندارد جدا کنید. به آن یک هویت اختصاصی با مجوزهای حداقلی بدهید و مشخص کنید که کدام اقدامات نیاز به تأیید انسانی دارند یا نمیتوانند بهطور خودکار انجام شوند.
تیمهای IT همچنین باید اطمینان حاصل کنند که فعالیتها میتوانند ثبت، متوقف و بررسی شوند. در نهایت، شرایط شکست را به همان اندازه که جریانهای کاری موفق را آزمایش میکنید، به طور عمدی آزمایش کنید: رفتار یک عامل زمانی که یک برنامه یخ میزند، اعتبارنامهها ناموفق هستند یا اطلاعات غیرمنتظره ظاهر میشود، ممکن است بیشتر از رفتار آن در طول توالی ایدهآل اهمیت داشته باشد.
تحویل برنامههای کاربردی از راه دور در کجا قرار میگیرد؟
ورود عوامل هوش مصنوعی به طور خودکار به این معنا نیست که سازمانها به رایانههای شخصی ابری بیشتری نیاز دارند. برای محیطهایی که در حال حاضر برنامههای ویندوز را به صورت متمرکز میزبانی میکنند، تحویل برنامههای از راه دور یک امکان معماری دیگر را ارائه میدهد.
TSplus Remote Access دسترسی متمرکز به برنامههای ویندوز و دسترسی از راه دور را بدون نیاز به اینکه هر کاربر یک دسکتاپ کامل ابری را اجرا کند، فراهم میکند. هنگامی که سازمانها شروع به ارزیابی دسترسی عامل به برنامههای موجود میکنند، همان اصل یک امکان جالب را مطرح میکند: فراهم کردن دسترسی به دور برنامه و وظیفه به جای اینکه به طور خودکار به یک دسکتاپ کامل دسترسی داشته باشد.
این به این معنا نیست که TSplus Remote Access خود یک پلتفرم عامل هوش مصنوعی است. بلکه، عوامل هوش مصنوعی سوالات موجود در مورد انتشار برنامه، جداسازی جلسه، کنترل دسترسی و مالکیت زیرساخت را برای نوع جدیدی از مصرفکننده برنامه مرتبط میسازند.
عاملهای هوش مصنوعی قرار است رویکرد به برنامههای قدیمی را تغییر دهند
برنامههای کاربردی ویندوز قدیمی بر اساس نشستن افراد در پشت کیبورد طراحی شده بودند. عوامل استفادهکننده از کامپیوتر این فرض را با ایجاد رابطهای گرافیکی که بهطور بالقوه برای نرمافزار قابل دسترسی هستند، به چالش میکشند.
بنابراین، برای تیمهای IT، سوال مهم تنها این نیست که آیا یک عامل هوش مصنوعی میتواند از یک برنامه قدیمی ویندوز استفاده کند یا خیر. بلکه این است که چگونه تنها دسترسی مورد نیاز عامل را فراهم کنیم در حالی که کنترل بر هویتها، دادهها، جلسات و زیرساخت را حفظ کنیم. با تبدیل شدن عوامل هوش مصنوعی به کاربران برنامه، معماری دسترسی از راه دور مناسب احتمالاً به طور فزایندهای اهمیت خواهد داشت، نه کمتر.
)
)
)
