هوش مصنوعی و اتوماسیون · · ۸ دقیقه
چطور اسناد داخلی شرکت را با دسترسی امن به دستیار هوش مصنوعی وصل کنیم؟
برای اتصال امن اسناد شرکت به دستیار هوش مصنوعی، باید هویت کاربر و مجوز هر سند تا لحظهٔ بازیابی حفظ شود. این راهنما از نقشه‌برداری دسترسی‌ها تا همگام‌سازی تغییر مجوز و آزمون نشت اطلاعات را توضیح می‌دهد.
پاسخ کوتاه: مجوز را پیش از بازیابی اعمال کنید، نه بعد از پاسخ مدل
اگر قرار است دستورالعمل‌ها و اسناد داخلی از طریق دستیار در دسترس باشند، راه امن این نیست که همهٔ فایل‌ها را در یک مخزن بریزیم و از مدل بخواهیم اطلاعات محرمانه را نشان ندهد. RAG یا «تولیدِ تقویت‌شده با بازیابی» روشی است که برای پاسخ‌دادن، بخش‌های مرتبط از منبع دانش را پیدا می‌کند و در اختیار مدل می‌گذارد. بنابراین نقطهٔ حساس پیش از تولید پاسخ است: سامانه باید بداند چه کسی سؤال می‌پرسد و فقط محتوایی را بازیابی کند که همان فرد طبق مجوزهای واقعی شرکت حق دیدنش را دارد. برای نمونه، کارشناس فروش می‌تواند راهنمای عمومی محصول را ببیند، اما پروندهٔ منابع انسانی یا قرارداد محرمانه نباید وارد زمینهٔ پاسخ او شود. مدل مسئول اجرای مجوز نیست؛ برنامهٔ دستیار باید هویت را از مسیر قابل‌اعتماد بگیرد، دسترسی را بررسی کند و سپس متن مجاز را به مدل بدهد. RAG مجوز تازه‌ای ایجاد نمی‌کند؛ باید همان مرزهای منبع اصلی را حفظ کند.
پیش از انتخاب ابزار، منابع و مرزهای دسترسی را فهرست کنید
یک فهرست ساده از منبع‌ها تهیه کنید: فضای فایل، سامانهٔ پشتیبانی، ویکی داخلی، سامانهٔ مدیریت ارتباط با مشتری (CRM) یا پوشه‌های پروژه. کنار هر منبع، مالک داده، نوع اطلاعات، سطح محرمانگی، سازوکار ورود کاربر و روش فعلی اعطای مجوز را ثبت کنید. دسترسی مستقیم و دسترسی ارث‌رسیده از پوشه یا گروه را از هم جدا کنید؛ همین‌طور استثناهایی مثل فایل‌هایی که فقط برای یک نفر یا یک پروژه قابل مشاهده‌اند. تفاوت مهمی هم میان هویتی که فایل‌ها را وارد شاخص جست‌وجو می‌کند و هویت کسی که سؤال می‌پرسد وجود دارد. حساب اتصال ممکن است مجوز خواندن گسترده داشته باشد تا فهرست اسناد را بسازد، اما نباید آن مجوز گسترده به همهٔ کاربران دستیار منتقل شود. برای شروع، یک مجموعهٔ کوچک و کم‌حساسیت با مالک مشخص انتخاب کنید و نقشهٔ دسترسی آن را با چند کاربر واقعی مرور کنید. اگر شرکت نتواند بگوید چه کسی مالک سند است یا تغییر مجوز را کجا ثبت می‌کند، اتصال آن منبع به دستیار را تا روشن‌شدن این مسئولیت عقب بیندازید.
مجوز سند را تا سطح قطعه‌های بازیابی‌شده نگه دارید
هنگام آماده‌سازی اسناد، شناسهٔ منبع، مالک، نسخه، سطح محرمانگی و اطلاعات لازم برای تشخیص کاربران یا گروه‌های مجاز را همراه محتوا ثبت کنید. اگر یک سند به چند قطعه تقسیم می‌شود، هر قطعه باید همان مرز دسترسی سند را به ارث ببرد؛ در غیر این صورت ممکن است یک پاراگراف جداشده از فایل اصلی بدون قاعدهٔ مجوز بازیابی شود. هنگام پرسش، هویت تأییدشدهٔ کاربر و عضویت فعلی او در گروه‌ها باید به جست‌وجو وصل شود و محدودیت‌ها پیش از آنکه متن وارد درخواست مدل شود اعمال شوند. پنهان‌کردن نتیجه فقط در رابط کاربری کافی نیست؛ متن خارج از مجوز نباید به زمینهٔ مدل، گزارش‌های قابل‌دسترسی یا ذخیره‌سازی موقت مشترک برسد. کنترل می‌تواند در موتور جست‌وجو یا لایهٔ سرور مورداعتماد انجام شود، به شرط آنکه پیش از ارسال متن به مدل نتیجه با هویت معتبر کنترل شده باشد. شناسهٔ کاربر را از پیام متنی او نپذیرید؛ آن را از نشست ورود یا لایهٔ سرور بگیرید. برای محیط چندمشتری نیز مرز سازمان را جداگانه کنترل کنید. اگر سرویس جست‌وجو فقط بر اساس شناسه‌ای که برنامه می‌فرستد نتیجه را محدود می‌کند، برنامه همچنان باید مطمئن شود آن شناسه از هویت معتبر آمده است.
چرخهٔ عمر سند و مجوز را با همگام‌سازی پوشش دهید
ایمن‌بودن فقط به روز اول ورود فایل بستگی ندارد. ممکن است سند حذف شود، نسخهٔ تازه‌ای پیدا کند، دسترسی گروهی لغو شود یا کارمندی از تیمی به تیم دیگر برود. برای هر منبع، زمان قابل‌قبول همگام‌سازی این تغییرها را تعیین کنید؛ تأخیری که برای یک راهنمای عمومی بی‌اهمیت است، برای پروندهٔ حقوقی یا منابع انسانی می‌تواند قابل‌قبول نباشد. حذف باید در شاخص و نسخه‌های ذخیره‌شده هم اثر کند، نه فقط در پوشهٔ اصلی. گروه‌ها را از مرجع هویت جاری بخوانید یا ذخیرهٔ موقت اطلاعات دسترسی را کوتاه و قابل ابطال نگه دارید. پاسخ‌های قبلی، نتیجه‌های جست‌وجوی ذخیره‌شده و گزارش‌های عیب‌یابی نیز ممکن است متن حساس داشته باشند، پس دورهٔ نگهداری و سطح دسترسی آن‌ها را تعریف کنید. یک آشتی‌سازی دوره‌ای میان منبع و شاخص کمک می‌کند اسناد جاافتاده یا مجوزهای قدیمی پیدا شوند. اگر سامانهٔ سازمانی تغییر دسترسی را فوری اعمال می‌کند اما شاخص شما تا روز بعد به‌روز می‌شود، این فاصله باید برای مالک داده روشن باشد و تا رفع آن، منبع حساس وارد اجرای آزمایشی نشود.
ورودی سند را قابل اعتماد فرض نکنید و پاسخ را به منبع مجاز محدود کنید
اسناد می‌توانند تکراری، قدیمی، ناقص یا دارای متن استخراج‌شدهٔ نادرست باشند؛ فایل‌های تصویری نیز ممکن است به بازشناسی نوری نویسه‌ها (OCR) نیاز داشته باشند. پیش از ورود، نسخه و مالک را نگه دارید، دادهٔ غیرضروری را حذف کنید و برچسب محرمانگی را با قواعد منبع اصلی هماهنگ کنید. متن سند، حتی اگر داخل ویکی داخلی باشد، دستور قابل‌اعتماد برای مدل محسوب نمی‌شود. ممکن است سند یا پیوست عبارتی داشته باشد که از دستیار بخواهد دستورهای قبلی را نادیده بگیرد یا اطلاعات دیگری را بیرون بکشد؛ آن متن باید همچنان دادهٔ مورد بررسی بماند، نه مجوز تغییر رفتار. دستیار را طوری تنظیم کنید که پاسخ را با ارجاع به سندهای مجاز بسازد، در نبود مدرک روشن حدس نزند و پرسش مبهم یا حساس را به کارشناس ارجاع دهد. اگر از سرویس بیرونی استفاده می‌کنید، پیش از ارسال محتوای داخلی، نحوهٔ نگهداری، دسترسی عملیاتی و استفادهٔ احتمالی ارائه‌دهنده از داده را بررسی کنید. کنترل دسترسی به مخزن، شیوهٔ انتقال داده و نگهداری درخواست‌ها باید با حساسیت همان اسناد متناسب باشد.
دسترسی را با سناریوهای مجاز و غیرمجاز آزمایش کنید
یک جدول آزمون بسازید که ردیف‌هایش نقش‌ها و ستون‌هایش نوع سند یا پرسش باشند. برای هر خانه مشخص کنید کاربر باید پاسخ مستند بگیرد، فقط بخشی از اطلاعات را ببیند یا اصلاً نتیجه‌ای دریافت نکند. علاوه بر نمونه‌های عادی، سناریوهایی را اضافه کنید که عضویت گروه همین امروز لغو شده، سند حذف یا جایگزین شده، کاربر نام پوشهٔ محرمانه را می‌داند، یا متن یک فایل به مدل فرمانی گمراه‌کننده می‌دهد. در گزارش آزمون، جداگانه بررسی کنید چه چیزی از جست‌وجو برگردانده شد، چه چیزی به مدل فرستاده شد و چه پاسخی به کاربر رسید؛ فقط خوب‌بودن متن نهایی را نسنجید. معیار امنیتی اصلی این است که هیچ محتوای خارج از مجوز به زمینهٔ مدل راه پیدا نکند. در کنار آن، کیفیت پیدا کردن اسناد مجاز، درستی ارجاع‌ها، نرخ پاسخ‌ندادن در نبود مدرک و تازگی نتیجه را بسنجید. گزارش‌ها را طوری تنظیم کنید که برای تحلیل خطا مفید باشند، اما خودشان به مخزن موازیِ متن محرمانه تبدیل نشوند؛ شناسه، زمان و نتیجهٔ کنترل اغلب از ثبت متن کامل پرسش و سند امن‌تر است.
اجرای آزمایشی را کوچک نگه دارید و مسئول هر مرز را مشخص کنید
برای نسخهٔ نخست، یک تیم، یک منبع و پرسش‌های خواندنی را انتخاب کنید؛ اجازهٔ ویرایش یا اقدام خودکار لازم نیست. اگر ابزار آماده اتصال بومی و همگام‌سازی مجوزهای همان منبع را دارد، بار ساخت کمتر می‌شود، اما باید دقیقاً روشن کنید چه سطحی از مجوز را پشتیبانی می‌کند و آیا قابلیت موردنیاز هنوز آزمایشی است. ساخت مسیر اختصاصی انعطاف بیشتری می‌دهد، ولی تیم شما مسئول صحت هویت، نگهداری شاخص، حذف سند و تغییر عضویت گروه خواهد بود. مالک داده، مسئول هویت و امنیت، تیم محصول و مالک عملیات باید پیش از شروع دربارهٔ تأخیر همگام‌سازی، رویدادهای ثبت‌شونده و شرط توقف توافق کنند. در اجرای آزمایشی با حساب‌های واقعیِ نقش‌های متفاوت آزمون کنید، دسترسی را فقط پس از بازبینی افزایش دهید و راه بازگشت به جست‌وجوی معمولی را آماده داشته باشید. دستیار اسنادی زمانی آمادهٔ گسترش است که کاربران مجاز پاسخ مفید بگیرند و کاربران نامجاز چیزی از منبع نبینند؛ اگر مرز منبع، هویت یا چرخهٔ حذف هنوز مبهم است، افزودن مدل قوی‌تر این ابهام را حل نمی‌کند. اگر برای یکی از منابع داخلی‌تان دربارهٔ نقشهٔ دسترسی، انتخاب معماری یا طراحی اجرای آزمایشی تصمیم دارید، یک جلسهٔ مشاورهٔ متمرکز می‌تواند همین مرزها و آزمون‌های لازم را مشخص کند.