استفاده امن از AI در شرکت‌ها؛ چه اطلاعاتی را وارد مدل نکنیم؟

بزرگ‌ترین ریسک استفادهٔ روزمره از مدل‌های زبانی در شرکت، لزوماً «هوشمند نبودن مدل» نیست؛ فرستادن چیزی است که نباید از مرز سازمان خارج شود یا در زمینهٔ گفت‌وگو بماند. دادهٔ مشتری، رمز و توکن، کد proprietary، و اسناد استراتژی با یک کپی‌پیست وارد پرامپت می‌شوند.

OWASP در LLM02:2025 Sensitive Information Disclosure هشدار می‌دهد که مدل‌ها می‌توانند داده‌های حساس را در خروجی فاش کنند و کاربران باید از وارد کردن اطلاعات حساس آگاه باشند. NIST با نمایهٔ Generative AI برای AI RMF از سازمان‌ها می‌خواهد ریسک حریم داده و یکپارچگی اطلاعات را مدیریت کنند. این مقاله فهرست عملی «چه چیزی را وارد نکنیم» و جایگزین‌های کاری است.

پاسخ کوتاه

به ابزارهای GenAI عمومی یا بدون قرارداد سازمانی این‌ها را ندهید: دادهٔ شناسایی‌پذیر مشتری، اسرار احراز هویت، کلیدها و رشتهٔ اتصال، کد یا سند دارای مالکیت فکری حساس، و اطلاعات غیرعمومی مالی/حقوقی/سلامت. برای کار مجاز، داده را کمینه، ماسک، یا به محیط قراردادی (enterprise) با کنترل ببرید — و باز هم حداقل دسترسی را رعایت کنید.

اگر برای ایمیل خارجی مناسب نیست، برای پرامپت عمومی هم مناسب نیست.

چهار دستهٔ داده که معمولاً نباید وارد مدل عمومی شوند

۱) دادهٔ مشتری و PII

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

۲) اسرار و اعتبارنامه‌ها

رمز عبور، توکن API، کلید خصوصی، رشتهٔ اتصال پایگاه‌داده، کوکی جلسه، و محتوای فایل‌های .env. این‌ها را حتی برای «دیباگ سریع» در پرامپت نگذارید. به‌جای آن خطا را sanitize کنید، نام متغیر را بگویید نه مقدار را، و از مدیر اسرار سازمان استفاده کنید. نشت اسرار در چت شبیه commit کردن اسرار در Git است — فقط کانال عوض شده.

۳) کد منبع و IP

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

۴) دادهٔ حقوقی، مالی غیرعمومی و سلامت

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

جدول تصمیم سریع قبل از پیست

آنچه GitHub دربارهٔ دادهٔ Copilot می‌گوید

طبق مستندات GitHub، دادهٔ مشتریان Copilot Business و Copilot Enterprise برای آموزش مدل‌های AI استفاده نمی‌شود و تحت توافق حفاظت داده قرار دارد. برای طرح‌های فردی مصرف‌کننده، سیاست استفاده از داده‌های تعامل می‌تواند متفاوت باشد و تنظیم opt-out مطرح است. پیام عملی برای شرکت: کار روی کد proprietary را روی مسیر سازمانی کنترل‌شده ببرید، نه روی حساب شخصی رایگان همکار.

حتی در طرح سازمانی، «آموزش نمی‌شود» به‌معنای «هر داده‌ای را آزادانه بفرستید» نیست. اصل حداقل داده، تفکیک محیط، و ممنوعیت اسرار همچنان برقرار است. قابلیت‌هایی مثل content exclusion برای محدود کردن مسیرهای حساس را جدی بگیرید.

NIST و حکمرانی GenAI

NIST AI 600-1 به‌عنوان نمایهٔ Generative AI برای AI RMF به سازمان‌ها کمک می‌کند ریسک‌های ویژه‌ای مثل حریم داده و confabulation را در توابع Govern/Map/Measure/Manage ببینند. ترجمهٔ عملی برای استفادهٔ کارکنان:

• سیاست نوشته‌شده: چه ابزارهایی مجازند و چه داده‌هایی ممنوع.
• آموزش کوتاه onboarding برای همهٔ نقش‌های دانشی.
• مسیر تأیید برای Use Caseهای حساس.
• ثبت حادثه وقتی دادهٔ ممنوع پیست شد — مثل پاسخ به نشت Secret در Git.

جایگزین‌های کاری به‌جای «هیچ‌کس از AI استفاده نکند»

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

1. ابزار سازمانی با قرارداد، کنترل هویت، و سیاست نگهداری مشخص.
2. قالب‌های پرامپت از پیش‌ماسک‌شده برای پشتیبانی و کد.
3. دادهٔ مصنوعی برای مثال؛ دادهٔ واقعی فقط در محیط تأییدشده.
4. مرور PR برای جلوگیری از چسباندن اسرار در توضیح یا اسکرین‌شات.
5. کانال گزارش سریع اشتباه پیست — بدون تنبیه اولیه برای گزارش داوطلبانه.

ماسک‌کردن عملی

قبل از پیست:

• نام‌ها را با CustomerA/CustomerB عوض کنید.
• شماره‌ها را با الگوی جعلی هم‌شکل جایگزین کنید.
• آدرس IP و دامنهٔ داخلی را حذف کنید.
• قطعه کد را تا حد بازتولید مسئله کوتاه کنید؛ جداول کامل مشتری لازم نیست.

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

خروجی مدل هم می‌تواند نشت کند

LLM02 فقط دربارهٔ ورودی شما نیست؛ خروجی می‌تواند دادهٔ کاربر دیگر، جزئیات سیستم، یا محتوای حساس زمینه را برگرداند. پس:

• خروجی را قبل از فرستادن به مشتری بخوانید.
• سیستم پرامپت را جای نگه‌داری کلید نگذارید (هم‌راستا با توصیهٔ جداسازی داده از system prompt).
• دسترسی ابزار Agent را حداقل کنید تا مدل نتواند خودکشانه داده بکشد.

سناریوهای رایج اشتباه

دیباگ با لاگ خام

لاگ production اغلب توکن و دادهٔ کاربر دارد. به‌جای پیست خام، یک خطای sanitize‌شده و stack بدون payload بفرستید.

خلاصه‌سازی تیکت مشتری

متن تیکت را کامل ندهید مگر ابزار تأییدشده دارید. اول PII را حذف کنید؛ بعد خلاصه بخواهید.

بازبینی قرارداد با مدل عمومی

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

کمک گرفتن برای اسکریپت مهاجرت

schema را می‌توانید در سطح انتزاعی بگویید؛ مقدار اتصال و نمونهٔ ردیف واقعی را نه.

حداقل سیاست یک‌صفحه‌ای برای تیم

• فهرست ابزارهای مجاز و ممنوع.
• فهرست طبقات دادهٔ قرمز/زرد/سبز.
• قانون: اسرار هرگز؛ مشتری فقط با ماسک یا مسیر enterprise.
• مسئول تأیید Use Caseهای زرد.
• لینک به آموزش ۱۵ دقیقه‌ای و کانال گزارش حادثه.

سیاست بدون مسیر جایگزین، دور زده می‌شود. سیاست با ابزار مجاز و مثال ماسک، رعایت می‌شود.

ارتباط با مقالات سری

سوالات متداول

آیا محیط enterprise یعنی هر داده‌ای مجاز است؟

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

برای کد متن‌باز داخلی چه کنیم؟

اگر واقعاً عمومی است، ریسک IP کمتر است؛ اما اسرار و دادهٔ مشتری داخل همان مخزن همچنان قرمزند. .env و پیکربندی را جدا نگه دارید.

اگر اشتباه پیست کردیم چه؟

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

مدل on-prem همهٔ مشکلات را حل می‌کند؟

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

چک‌لیست روزانهٔ ۳۰ ثانیه‌ای

1. آیا اسرار در متن هست؟
2. آیا فرد واقعی شناسایی می‌شود؟
3. آیا این متن برای رقیب ارزشمند است؟
4. آیا ابزار مسیر سازمانی مجاز است؟
5. آیا می‌توانم با دادهٔ مصنوعی همان کمک را بگیرم؟

مرز Agent و ابزارهای متصل

وقتی به مدل اجازه می‌دهید ایمیل، تیکت، یا مخزن را بخواند، ریسک از «پیست دستی» به «دسترسی سیستمی» ارتقا می‌یابد. اصل حداقل دسترسی را برای توکن‌های اتصال هم اعمال کنید: فقط صندوق یا مخزن لازم، فقط خواندن اگر نوشتن لازم نیست، و ثبت لاگ فراخوانی‌ها. OWASP در کنار افشای اطلاعات، به agency بیش از حد و تزریق غیرمستقیم پرامپت نیز حساس است؛ محتوای بازیابی‌شده می‌تواند دستور مخرب داشته باشد.

قبل از اتصال Agent به دادهٔ مشتری، از امنیت بپرسید: آیا این Use Case بدون دادهٔ خام ممکن است؟ آیا می‌توان فقط فیلدهای ماسک‌شده را ایندکس کرد؟ آیا خروجی قبل از ارسال به کانال خارجی Review می‌شود؟

تفکیک محیط: شخصی، تیمی، تولیدی

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

در onboarding یک جدول کوچک بگذارید: چه کاری در کدام محیط مجاز است. ابهام اینجا گران تمام می‌شود.

هماهنگی با حقوقی و خرید

قبل از خرید ابزار GenAI، حقوقی باید به نگهداری داده، مکان پردازش،subprocessors، و استفاده برای آموزش مدل پاسخ روشن بگیرد. خرید بدون این بندها بعداً تیم را بین بهره‌وری وcompliance گیر می‌اندازد. مستندات فروشنده را بخوانید؛ به اسلاید بازاریابی اکتفا نکنید.

اگر فروشنده گفت «داده شما برای آموزش استفاده نمی‌شود»، بپرسید استثناها چیست: دورهٔ آزمایشی، ویژگی‌های preview، پشتیبانی انسانی، و لاگ‌های abuse. جزئیات را در قرارداد ببندید.

آموزش کوتاه بهتر از بخشنامهٔ بلند

یک تمرین ۱۵ دقیقه‌ای با سه مثال واقعی تیم (لاگ، تیکت، قطعه کد) از ده صفحه سیاست مؤثرتر است. در تمرین، افراد باید نسخهٔ ماسک‌شده بسازند و نسخهٔ خطرناک را رد کنند. تکرار فصلی این تمرین، حافظهٔ عضلانی می‌سازد.

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

جمع‌بندی عملی برای مدیر و فرد

اگر مدیرید: این هفته ابزار مجاز را اعلام کنید، یک صفحهٔ قرمز/زرد/سبز منتشر کنید، و کانال گزارش اشتباه را باز کنید. اگر فردید: پیش‌فرض را «ماسک اول» بگذارید، اسرار را از چت دور نگه دارید، و کار مشتری را از حساب شخصی جدا کنید. امنیت GenAI بیشتر از خرید یک فیلتر جادویی، به عادت‌های کوچک و مسیرهای جایگزین وابسته است.

با مقالهٔ ۱۳۹ برای راستی‌آزمایی خروجی و مقالات Secret در Git جفتش کنید تا هم ورودی و هم خروجی و هم مخزن پوشش داده شوند.

خلاصه

استفاده امن از AI در شرکت یعنی ندادن دادهٔ مشتری، اسرار، کد و اسناد حساس به مدل‌های نامناسب، و ساختن مسیر سازمانی جایگزین. OWASP روی افشای اطلاعات حساس، NIST روی حکمرانی ریسک GenAI، و GitHub روی تفاوت سیاست دادهٔ طرح‌های سازمانی و فردی تأکید دارند. حداقل داده، ماسک، ابزار مجاز، و پاسخ حادثه را به عادت تیم تبدیل کنید.

منابع و مراجع

• OWASP — LLM02:2025 Sensitive Information Disclosure — https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/2_0_vulns/LLM02_SensitiveInformationDisclosure.md
• OWASP — Top 10 for Large Language Model Applications — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) — https://doi.org/10.6028/NIST.AI.600-1
• GitHub Docs — Hosting of models for GitHub Copilot (Business/Enterprise data not used for training) — https://docs.github.com/en/copilot/reference/ai-models/model-hosting
• GitHub Docs — Managing Copilot policies as an individual subscriber — https://docs.github.com/copilot/how-tos/manage-your-account/managing-copilot-policies-as-an-individual-subscriber