عامل‌های هوش مصنوعی و برنامه‌های دسکتاپ: چه بر سر نرم‌افزارهای قدیمی ویندوز می‌آید؟

عامل‌های هوش مصنوعی در حال شروع به تعامل با برنامه‌های دسکتاپ به همان شیوه‌ای هستند که کاربران انسانی انجام می‌دهند. برای تیم‌های IT، این سوال مهمی را مطرح می‌کند: آیا نرم‌افزارهای موجود ویندوز، از جمله برنامه‌هایی که APIهای مدرن ندارند، می‌توانند بدون اینکه ابتدا جایگزین یا بازسازی شوند، به جریان‌های کاری مبتنی بر هوش مصنوعی دسترسی پیدا کنند؟

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

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

جایگاه APIها؟

بیشتر اتوماسیون‌های شرکتی زمانی بهترین عملکرد را دارند که نرم‌افزار از طریق یک رابط برنامه‌نویسی کاربردی (API) ارتباط برقرار کند. APIها عملیات ساختاریافته و ورودی و خروجی‌های قابل پیش‌بینی را بدون نیاز به تفسیر یک رابط گرافیکی ارائه می‌دهند.

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

وارد کردن عوامل هوش مصنوعی

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

این دیگر تنها یک آزمایش نیست. خدمات وب آمازون (AWS) اکنون آمازون را در موقعیت قرار می‌دهد. فضاهای کاری برای عوامل هوش مصنوعی به عنوان یک محیط مدیریت شده که در آن عوامل می‌توانند برنامه‌های دسکتاپ را اجرا کنند، از جمله برنامه‌هایی که فاقد APIهای مدرن هستند. مایکروسافت به طور مشابه Windows 365 برای عوامل را به عنوان یک محیط اجرایی برای وظایفی که نیاز به تعامل با برنامه‌های دسکتاپ و وب دارند و فاقد APIهای قابل اعتماد هستند، توصیف می‌کند.

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

چگونه می‌توانند عوامل هوش مصنوعی واقعاً از برنامه‌های ویندوز استفاده کنند؟

انواع عوامل هوش مصنوعی برای انواع مختلف تعامل

نمایندگان هوش مصنوعی دسکتاپ همه به یک شکل با نرم‌افزار تعامل ندارند. سیستم‌های استفاده از کامپیوتر می‌توانند اسکرین‌شات‌ها را تحلیل کرده و کلیک‌های ماوس و ورودی‌های صفحه‌کلید تولید کنند و به‌طور مؤثر برخی از تعاملات انسانی با یک رابط کاربری گرافیکی را بازتولید کنند.

رویکردهای دیگر از کنترل‌های سیستم‌عامل، اطلاعات دسترسی یا تکنیک‌های اتوماسیون قطعی نزدیک به اتوماسیون فرآیند رباتیک (RPA) استفاده می‌کنند. معماری‌های هیبریدی می‌توانند این روش‌ها را با APIها یا ابزارهای پروتکل زمینه مدل (MCP) ترکیب کنند.

نمونه‌ها و مزایای بالقوه برای تیم‌های IT

AWS، به عنوان مثال، تعامل بصری دسکتاپ را با انتقال ابزار MCP ترکیب می‌کند و به وظایف مناسب اجازه می‌دهد تا از یک ابزار مستقیم به جای تعامل در سطح پیکسل استفاده کنند. مایکروسافت همچنین عوامل استفاده‌کننده از کامپیوتر را از RPA در معماری Windows 365 for Agents متمایز می‌کند.

برای تیم‌های IT، این تمایز مهم است. یک رابط ساختاریافته معمولاً باید ترجیح داده شود زمانی که قابلیت‌های مورد نیاز را به طور قابل اعتماد و ایمن ارائه می‌دهد. تعامل با GUI زمانی به ویژه جالب می‌شود که هیچ مسیر برنامه‌نویسی مناسبی وجود نداشته باشد.

اعطای دامنه عمل به هوش مصنوعی در زمینه‌های خاص

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

آیا هر عامل هوش مصنوعی به دسکتاپ خود نیاز دارد؟

زمانی که یک نماینده به یک برنامه گرافیکی نیاز دارد، تیم‌های IT باید تصمیم بگیرند که آن تعامل باید در کجا انجام شود.

دسترسی به دسکتاپ محلی

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

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

دسکتاپ‌های مجازی اختصاصی و DaaS

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

خدمات دسکتاپ به عنوان یک سرویس (DaaS) بنابراین به یکی از لایه‌های اجرایی ممکن برای عوامل هوش مصنوعی و همچنین کاربران انسانی تبدیل می‌شود.

تحویل برنامه از راه دور

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

این سوال معماری را از "میز کار عامل باید کجا باشد؟" به "این عامل در واقع به چه منابعی نیاز دارد؟" تغییر می‌دهد.

کجا و چه چیزی، به طور خلاصه:

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

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

آیا هوش مصنوعی می‌تواند در احیای برنامه‌های کاربردی ویندوز قدیمی شما مشارکت کند؟

نرم‌افزارهای قدیمی به طور سنتی انتخاب دشواری برای پروژه‌های اتوماسیون ارائه داده‌اند. اگر یک برنامه مهم دارای API نباشد، سازمان‌ها ممکن است به ادغام سفارشی، RPA یا نوسازی برنامه قبل از اتصال آن به جریان‌های کاری جدید نیاز داشته باشند.

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

نمونه‌های AWS و مایکروسافت:

AWS به‌طور صریح از اجتناب از نوسازی برنامه و یکپارچه‌سازی سفارشی به‌عنوان یک مورد استفاده برای WorkSpaces عامل خود یاد می‌کند. مایکروسافت در حال توسعه دسترسی از رایانه‌های Cloud عامل به برنامه‌های خط کسب‌وکار محلی است و به‌طور مشابه قابلیت را در اطراف خودکارسازی جریان‌های کاری بدون نوسازی اولیه برنامه‌های قدیمی چارچوب‌بندی می‌کند.

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

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

کدام سوالات جدید امنیتی و انطباقی توسط دسترسی عامل هوش مصنوعی مطرح می‌شود؟

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

یک عامل هوش مصنوعی به یک هویت و مجوزهای تعریف شده نیاز دارد

حداقل امتیاز

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

حمایت از امنیت سایبری بیشتر، از جمله در مورد استفاده از هوش مصنوعی

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

نمونه‌ای از یک پیشینه امنیت سایبری

[The] [ترجمه] حادثه PocketOS یک تصویر به‌ویژه واضح از اهمیت کنترل‌های معماری ارائه می‌دهد. در آوریل ۲۰۲۶، یک عامل کدنویسی هوش مصنوعی که بر روی یک وظیفه آزمایشی کار می‌کرد، یک توکن API راه‌آهن به‌دست آورد و پایگاه داده تولید شرکت و نسخه‌های پشتیبان مرتبط را در یک عملیات API حذف کرد. حذف گزارش‌شده نه ثانیه طول کشید.

درس فراتر از کدنویسی عوامل است. دستوراتی که به یک عامل می‌گویند که عملیاتی خطرناک را انجام ندهد معادل زیرساختی نیستند که آن عملیات را جلوگیری کند.

هوش مصنوعی محلی و هوش مصنوعی شخص ثالث مسیرهای داده متفاوتی ایجاد می‌کنند

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

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

قبل از استقرار، تیم‌های IT باید مشخص کنند که عامل در کجا اجرا می‌شود، مدل AI در کجا اجرا می‌شود و داده‌های برنامه در کجا پردازش یا نگهداری می‌شوند.

نیاز به تأیید انسانی یک مرز معنادار دارد

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

خطر گسترده‌تر دیگر فرضی نیست. پایگاه داده حوادث هوش مصنوعی در دوره پردازش خود از مه تا ژوئیه ۲۰۲۶، ۱۴۸ شناسه حادثه اضافه کرد و در عین حال هشدار داد که این اضافات شامل رویدادهایی از تاریخ‌های مختلف است و نباید به عنوان اندازه‌گیری فراوانی حوادث تفسیر شود. با این حال، خلاصه آن به مشکلات مکرر مربوط به سیستم‌های خودمختار، حریم خصوصی و فعالیت‌های امنیت سایبری با کمک هوش مصنوعی اشاره دارد.

لاگ‌ها زمانی اهمیت بیشتری پیدا می‌کنند که کاربر نرم‌افزار باشد

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

مدیران همچنین به روشی برای خاتمه سریع فعالیت نیاز دارند. AWS قابلیت مشاهده جلسه در زمان واقعی و لغو دسترسی را به WorkSpaces برای عوامل هوش مصنوعی اضافه کرده است، در حالی که مایکروسافت نظارت، کنترل‌های جلسه و مداخله انسانی را به عنوان بخشی از معماری Cloud PC عامل خود توصیف می‌کند. این کنترل‌ها سوالات کلیدی عملیاتی را که تیم‌های IT باید بپرسند، صرف نظر از پلتفرم، برجسته می‌کند.

قبل از اعطای دسترسی دسکتاپ به یک عامل هوش مصنوعی، IT باید چه تصمیماتی بگیرد؟

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

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

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

در مورد نرم‌افزارهای قدیمی و انتشار برنامه‌ها، موارد زیر را در نظر خواهیم گرفت:

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

برای اطلاعات بیشتر در مورد هویت‌ها و مجوزها و مسائل امنیتی مشابه، مقاله امنیتی عوامل هوش مصنوعی ما خواندنی بعدی شماست.

تحویل برنامه‌های کاربردی از راه دور در کجا قرار می‌گیرد؟

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

TSplus Remote Access دسترسی متمرکز به برنامه‌های ویندوز و دسترسی از راه دور را بدون نیاز به اینکه هر کاربر یک دسکتاپ کامل ابری را اجرا کند، فراهم می‌کند. هنگامی که سازمان‌ها شروع به ارزیابی دسترسی عامل به برنامه‌های موجود می‌کنند، همان اصل یک امکان جالب را مطرح می‌کند: فراهم کردن دسترسی به دور برنامه و وظیفه به جای اینکه به طور خودکار به یک دسکتاپ کامل دسترسی داشته باشد.

این به این معنا نیست که TSplus دسترسی از راه دور این خود یک پلتفرم عامل هوش مصنوعی نیست. بلکه، عوامل هوش مصنوعی سوالات موجود درباره انتشار برنامه، جداسازی جلسه، کنترل دسترسی و مالکیت زیرساخت را برای نوع جدیدی از مصرف‌کننده برنامه مرتبط می‌سازند.

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

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

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