به عامل هوش مصنوعی چه دسترسی‌ای بدهیم؟ قواعد ساده برای کنترل ریسک
هوش مصنوعی دیگر فقط به پرسش‌ها جواب نمی‌دهد. عامل‌های هوش مصنوعی ایمیل می‌خوانند، فایل‌ها را جابه‌جا می‌کنند، به سیستم‌های سازمان وصل می‌شوند و کار را خودشان پیش می‌برند. برای مدیر کسب‌وکار، پرسش اصلی دیگر این نیست که کدام مدل بهتر است. پرسش این است که چه دسترسی‌ای به این عامل بدهیم و اگر اشتباه کرد، چه چیزی از دست می‌رود.
خطر اصلی هم لزوماً «هک شدن» به معنای قدیمی نیست. به نوشته‌ی BleepingComputer، یک ایمیل، وب‌سایت یا افزونه‌ی مخرب می‌تواند عامل را فریب بدهد تا دستور مهاجم را اجرا کند، داده بفرستد یا فایل پاک کند. عامل برای این کار از همان مجوزهای مشروعی استفاده می‌کند که خودمان به او داده‌ایم. مثل کارمند تازه‌ای که هر یادداشتی را روی میزش ببیند، دستور مدیر فرض می‌کند.
تصور اینکه «حتماً کسی دارد مراقب عامل است» هم اطمینان‌بخش نیست. The Register درباره‌ی گزارشی از یک آزمون تیم قرمز نوشته که نظارت بر عامل‌های OpenAI در جریان حمله‌ای به Hugging Face فقط ناقص بوده و به‌راحتی دور زده شده است. The Register در گزارشی دیگر از ابزاری حمله‌گر نوشته که طراحی شده بود تا ۱۰۰ هزار گام را بدون تأیید انسان پیش ببرد. درس این دو خبر برای ما روشن است: بدون نقطه‌ی توقف و نظارت واقعی، عامل با سرعت ماشین اشتباه را تکرار می‌کند.
قاعده‌ی اول، حداقل دسترسی است. عاملی که قرار است پیش‌نویس پاسخ به مشتری بنویسد، به صندوق ایمیل مدیرعامل و پوشه‌ی مالی نیازی ندارد. برای هر عامل یک حساب جدا بسازید، دسترسی را فقط‌خواندنی شروع کنید و فقط پوشه‌ها و سیستم‌های لازم را باز کنید. در بسیاری از شرکت‌های ما حساب اشتراکی یا رمز مدیریتی واحد رایج است. اگر عامل به چنین حسابی وصل شود، یک فریب ساده همه‌چیز را در معرض خطر می‌گذارد.
قاعده‌ی دوم، تأیید انسانی برای کارهای حساس است. فهرستی مشخص کنید از کارهایی که عامل بدون تأیید یک نفر حق انجامشان را ندارد: پرداخت و تغییر شماره‌حساب در فاکتور، ارسال فایل به بیرون از سازمان، حذف داده، تغییر مجوزها و امضای قرارداد. این تأیید باید روی خود اقدام باشد، نه فقط در ابتدای کار. هزینه‌ی چند دقیقه مکث، در برابر یک انتقال وجه اشتباه یا یک پوشه‌ی پاک‌شده ناچیز است.
قاعده‌ی سوم، ثبت لاگ است. باید بتوانید بعداً بگویید عامل چه چیزی خواند، چه ابزاری را صدا زد و چه تغییری داد. بدون این سابقه، در یک حادثه نمی‌توانید بفهمید مشکل از دستور مخرب بود، از خطای مدل یا از تنظیم اشتباه خودتان. لاگ‌ها را جدا از خود عامل نگه دارید تا خود او نتواند آن‌ها را تغییر بدهد. بخشی از آن‌ها را هم به‌طور منظم و با چشم انسان بازبینی کنید.
قاعده‌ی چهارم، آزمایش در محیط جدا پیش از استفاده‌ی واقعی است. عامل را اول با داده‌ی نمونه و حساب‌های آزمایشی امتحان کنید و عمداً ایمیل یا صفحه‌ای با دستور مشکوک جلویش بگذارید تا واکنشش را ببینید. افزونه‌ها و مهارت‌های اضافه‌شونده را هم فقط از منبع معتبر نصب کنید. شرکت Gen Digital با محصولی به نام Agent Trust Hub برای راستی‌آزمایی مهارت‌ها و کنترل رفتار عامل هنگام اجرا وارد این حوزه شده است، اما اصل کار سیاست داخلی شماست، نه یک محصول. در ایران، که استفاده از افزونه‌ها و ابزارهای نانوشته و غیررسمی رایج است، همین احتیاط ساده بیشترین اثر را دارد. پیش از اتصال هر عامل به داده‌ی مشتری هم مشخص کنید آن داده به کدام سرویس خارجی می‌رود.
اگر می‌خواهید از جایی شروع کنید، یک کار کوچک و کم‌ریسک انتخاب کنید، مثلاً خلاصه‌کردن ایمیل‌های پشتیبانی با دسترسی فقط‌خواندنی. چهار قاعده‌ی بالا را از همان ابتدا رعایت کنید و فقط وقتی دسترسی را گسترش دهید که لاگ‌ها و آزمایش‌ها اطمینان داده باشند. هر دسترسی تازه باید یک تصمیم آگاهانه باشد، نه پیش‌فرض ابزار. تیم فناوری یا شریک MSP شما می‌تواند در تعریف این مرزها و پیاده‌کردنشان کمک کند.
راهکارهای ارتباطی زی