
محرمانهماندن اسناد شرکت هنگام استفاده از هوش مصنوعی به نوع داده، محصول و حساب کاربری، مسیر پردازش و دسترسی افراد بستگی دارد. پیش از بارگذاری یک قرارداد یا گزارش داخلی باید بدانید چه اطلاعاتی از شرکت خارج میشود، کجا نگهداری میشود و چه کسانی میتوانند به فایل و پاسخهای آن دسترسی داشته باشند.
خلاصهکردن یک قرارداد با هوش مصنوعی چند دقیقه زمان میبرد؛ اما همان فایل ممکن است نام مشتری، قیمت توافقشده و شرایط پرداخت را کنار هم داشته باشد. در این راهنما، معیارهای انتخاب ابزار و کنترلهای لازم برای استفاده از اسناد سازمانی را بررسی میکنیم.
وقتی سندی را در هوش مصنوعی بارگذاری میکنیم، چه اتفاقی میافتد؟
در یک سرویس ابری، فایل برای پردازش به زیرساخت ارائهدهنده ارسال میشود. ممکن است متن آن استخراج شود، بخشهایی از آن همراه پرسش به مدل برسد و فایل یا سابقهٔ گفتوگو برای استفادهٔ بعدی ذخیره شود. اگر ابزار به سامانهٔ دیگری متصل باشد، بخشی از پردازش میتواند در همان سرویس متصل انجام شود.
بنابراین بررسی امنیت باید کل مسیر را در بر بگیرد: فایل اصلی، متن استخراجشده، اطلاعات ارسالشده به مدل، پاسخ، گزارشهای فعالیت و نسخههای پشتیبان. حذف فایل از صفحهٔ گفتوگو نیز لزوماً به معنی حذف فوری همهٔ نسخهها از تمام این بخشها نیست؛ دامنه و زمان حذف را باید در مستندات همان سرویس بررسی کرد.
استفادهنکردن برای آموزش مدل با ذخیرهنکردن داده چه تفاوتی دارد؟
این دو موضوع جداگانهاند. سیاست آموزش مشخص میکند آیا ارائهدهنده میتواند از ورودی و خروجی شما برای بهبود مدل استفاده کند. سیاست نگهداری دربارهٔ ذخیرهٔ فایل، تاریخچه، گزارشهای امنیتی و زمان حذف آنهاست.
برای نمونه، مستندات تجاری Anthropic میان نگهداری ورودی و خروجی API، فایلها و تاریخچهٔ محصولات گفتوگویی تفاوت قائل میشود و استثناهایی هم دارد. مستندات Microsoft نیز استفاده از داده برای آموزش را جدا از ذخیرهسازی برخی قابلیتها توضیح میدهد. پس هنگام ارزیابی ابزار، نام دقیق محصول، طرح حساب و قابلیت مورد استفاده را ثبت کنید؛ شرایط یک API را نمیتوان به همهٔ حسابهای همان برند تعمیم داد.
کدام اسناد شرکت به بررسی بیشتری نیاز دارند؟
بهتر است سازمان برای اسنادش سطح دسترسی مشخص داشته باشد. جدول زیر نقطهٔ شروعی برای تصمیمگیری است؛ مجازبودن ارسال هر فایل را مالک اطلاعات و سیاست شرکت تعیین میکنند.
| نوع داده | نمونه در کسبوکار | اقدام پیش از استفاده |
|---|---|---|
| منتشرشده و عمومی | کاتالوگ یا متن سایت | بررسی پیوستها و یادداشتهای غیرعمومی فایل |
| داخلی | دستورالعمل اجرا یا گزارش جلسه | تعیین ابزار مجاز و کاربران مجاز |
| محرمانه | قرارداد، قیمت خرید یا فهرست مشتریان | مجوز مالک داده، حداقلسازی اطلاعات و ارزیابی محیط پردازش |
| اسرار دسترسی | رمز عبور، کلید API یا کلید خصوصی | حذف از ورودی؛ استفاده از سامانهٔ مدیریت اسرار برای اتصال فنی |
پسوند فایل معیار محرمانگی نیست. یک PDF کوتاه میتواند اطلاعات حساستری از یک گزارش چندصدصفحهای داشته باشد. اطلاعات کارکنان، مدارک هویتی و جزئیات مالی افراد نیز به بررسی مجوز و الزامات مربوط به خود نیاز دارند.
پیش از انتخاب ابزار هوش مصنوعی این پنج موضوع را روشن کنید
۱. استفاده از داده و مدت نگهداری
سیاست آموزش، ذخیرهٔ فایل، تاریخچه، بازبینی امنیتی و حذف را جداگانه بخوانید. دربارهٔ دادههای ارسالی از طریق بازخورد، افزونهها و اتصالها نیز سؤال کنید. فعالکردن یک گزینهٔ حریم خصوصی، پاسخ تمام این پرسشها نیست.
۲. مسیر و محل پردازش
مشخص کنید داده به کدام ارائهدهنده و سرویسهای وابسته میرسد و آیا محل پردازش با نیاز شرکت سازگار است. اگر فروشنده واسطهٔ استفاده از مدل دیگری است، مسیر انتقال تا آن مدل نیز باید روشن باشد.
۳. هویت کاربران و اشتراکگذاری
حساب مشترک، لینک عمومی گفتوگو و دسترسی گستردهٔ پوشهها کنترل اطلاعات را دشوار میکند. امکان مدیریت کاربران، قطع دسترسی همکار جداشده از تیم و محدودکردن اشتراک فایل و پاسخ را بررسی کنید.
۴. اتصال به سامانههای شرکت
برای خلاصهکردن چند گزارش، معمولاً نیازی به دسترسی به تمام ایمیلها و پوشهها نیست. محدودهٔ هر اتصال و امکان لغو آن را مشخص کنید. اگر دستیار اجازهٔ ارسال پیام یا تغییر اطلاعات دارد، این اختیار را جدا از دسترسی خواندن ارزیابی کنید.
۵. شواهد قابل بررسی
از فروشنده توضیح روشن دربارهٔ مدیریت دسترسی، رمزنگاری ارتباط و ذخیرهسازی، حذف داده و رسیدگی به رخداد بخواهید. این قابلیتها باید در محصول و طرح انتخابشده وجود داشته باشند؛ عنوان «سازمانی» یا «اختصاصی» بهتنهایی کیفیت اجرای آنها را مشخص نمیکند.
یک مثال عملی: خلاصهسازی قرارداد مشتری
فرض کنید مدیر فروش فقط میخواهد تعهدات تحویل یک قرارداد را استخراج کند. فرستادن کل پروندهٔ مشتری شامل اطلاعات پرداخت و مکاتبات قبلی، دامنهٔ دادهٔ ارسالی را بیدلیل بزرگ میکند. یک مسیر محدودتر میتواند چنین باشد:
- مالک قرارداد، مجازبودن استفاده در ابزار انتخابشده را بررسی کند.
- فقط بندهای لازم برای استخراج تعهدات جدا شوند.
- شناسهها و جزئیات غیرضروری با مقدار جایگزین پوشانده شوند.
- نسخهٔ خروجی برای وجود نظرات، تغییرات ثبتشده و اطلاعات پنهان بازبینی شود.
- پاسخ مدل با بندهای اصلی تطبیق داده شود و فقط در اختیار افراد مجاز قرار بگیرد.
حذف نام مشتری همیشه برای ناشناسکردن سند کافی نیست؛ ترکیب مبلغ، تاریخ و موضوع قرارداد ممکن است طرف قرارداد را مشخص کند. همچنین کشیدن یک مستطیل سیاه روی متن PDF ممکن است متن زیر آن را حذف نکند. پوشاندن اطلاعات باید با ابزار مناسب انجام شود و نتیجهٔ خروجی دوباره بررسی شود.
در چتبات سازمانی، دسترسی به اسناد چگونه کنترل میشود؟
در معماری چتبات مبتنی بر اسناد و RAG، بخشهای مرتبط با پرسش از مخزن اطلاعات بازیابی میشوند و به مدل میرسند. اگر مجوزها درست اعمال نشوند، همین جستوجو ممکن است سند واحد مالی را وارد پاسخ کاربر واحد فروش کند.
کنترل دسترسی باید هنگام بازیابی و پیش از ارسال محتوا به مدل اعمال شود. نوشتن جملهای مانند «اسناد محرمانه را نمایش نده» در دستور مدل، جای احراز هویت و بررسی مجوز را نمیگیرد. تغییر نقش کاربر، حذف سند و لغو دسترسی نیز باید در نمایهٔ جستوجو و حافظههای موقت منعکس شود.
برای آزمون، با دو حساب دارای دسترسی متفاوت یک پرسش یکسان بپرسید. کاربر غیرمجاز نباید متن، خلاصه، عنوان یا پیوند سند محدودشده را دریافت کند. این آزمون را پس از تغییر مجوزها و حذف فایل هم تکرار کنید. OWASP نیز دسترسی نامناسب به مخازن برداری را از مسیرهای افشای اطلاعات در سامانههای RAG میداند.
تزریق دستور در فایل چیست و چرا اهمیت دارد؟
ممکن است داخل یک سند یا صفحهٔ متصل، متنی قرار بگیرد که از مدل بخواهد دستور اصلی را کنار بگذارد یا اطلاعات را به مقصد دیگری بفرستد. به این تلاش برای منحرفکردن رفتار مدل، تزریق دستور یا Prompt Injection میگویند. فایل باید بهعنوان محتوای قابل بررسی پردازش شود؛ نباید بتواند مجوز تازهای برای دستیار ایجاد کند.
محدودکردن ابزارهای در دسترس مدل، بررسی خروجی و تأیید انسانی برای اقداماتی مانند ارسال فایل یا تغییر داده، احتمال و پیامد سوءاستفاده را کاهش میدهد. RAG و دستورهای متنی بهتنهایی این خطر را برطرف نمیکنند؛ سامانه باید با فایلها و پرسشهای مخرب نیز آزمایش شود.
استقرار داخلی یا ابری؛ کدام برای اسناد محرمانه مناسبتر است؟
استقرار داخلی میتواند کنترل بیشتری بر محل نگهداری و ارتباطات سامانه بدهد، اما مسئولیت بهروزرسانی، مدیریت کاربران، پشتیبانگیری و پایش را هم به تیم شما منتقل میکند. در معماری ترکیبی نیز ممکن است اسناد داخل شرکت بمانند، ولی متن بازیابیشده برای تولید پاسخ به مدل ابری فرستاده شود.
انتخاب را از محدودیت داده، توان عملیاتی تیم و مسیر واقعی پردازش شروع کنید. برای ارزیابی راهکار هوش مصنوعی و اتوماسیون سازمانی، ابتدا یک کاربرد محدود با دادهٔ کمحساسیت تعریف کنید و سپس دسترسی، کیفیت پاسخ و نگهداری اطلاعات را در همان کاربرد بسنجید.
از کجا شروع کنیم؟
- فهرست ابزارها را مشخص کنید: کارکنان اکنون از چه ابزارها و حسابهایی استفاده میکنند؟
- دادهٔ مجاز را تعریف کنید: برای هر کاربرد، چه سندی با تأیید چه کسی قابل ارسال است؟
- یک محیط محدود بسازید: آزمون اولیه را با سند عمومی یا دادهٔ ساختگی انجام دهید.
- دسترسی و حذف را آزمایش کنید: نتیجهٔ تغییر نقش، خروج کاربر و حذف فایل را در عمل ببینید.
- مسئول رسیدگی تعیین کنید: کارکنان بدانند بارگذاری اشتباه یا پاسخ حاوی اطلاعات غیرمجاز را به چه کسی گزارش کنند.
پرسشهای متداول دربارهٔ محرمانگی اسناد در هوش مصنوعی
آیا نسخهٔ پولی ابزار، محرمانگی اسناد را تضمین میکند؟
پرداخت هزینه بهتنهایی چنین تضمینی نمیدهد. شرایط محصول، نوع حساب، تنظیمات اشتراکگذاری و سیاست استفاده و نگهداری داده باید برای همان سرویس بررسی شوند.
اگر مدل با اطلاعات ما آموزش نبیند، باز هم بررسی امنیت لازم است؟
بله. فایل و تاریخچه ممکن است ذخیره شوند یا از طریق دسترسی نادرست و اتصالهای جانبی در معرض افراد غیرمجاز قرار بگیرند. آموزش مدل فقط یکی از موضوعات ارزیابی است.
آیا داشتن RAG یعنی فایلها از شرکت خارج نمیشوند؟
خیر. محل مخزن اسناد با محل اجرای مدل یکسان نیست. باید بررسی کنید متن بازیابیشده به کدام مدل و زیرساخت ارسال میشود.
اگر سند محرمانه اشتباه بارگذاری شد، چه کنیم؟
ارسال بیشتر را متوقف کنید، موضوع را به مسئول مربوط گزارش دهید و طبق فرایند شرکت دسترسی و اشتراک فایل را محدود و درخواست حذف را پیگیری کنید. اگر رمز یا کلید دسترسی افشا شده، لغو و جایگزینی آن هم باید انجام شود؛ حذف گفتوگو بهتنهایی کافی نیست.