چه چیزی به هوش مصنوعی نشت می‌کند و چطور جلویش را بگیریم

بیشتر داده‌ای که به هوش مصنوعی نشت می‌کند دزدیده نمی‌شود؛ خودِ کارکنان آن را می‌فرستند تا کارشان جلو برود. شکایت مشتری با کد ملی‌اش، قراردادی برای خلاصه شدن، لاگی که نشانی یک سرور داخلی در آن است، فایل تنظیماتی که رمز پایگاه داده را دارد. متن که به ارائه‌دهنده رسید، قواعد او تعیین می‌کند چقدر نگه داشته شود، چه کسی آن را بخواند و آیا مدلی از آن یاد بگیرد.

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

چه چیزی بیرون می‌رود

تازه‌ترین اندازه‌گیری‌ها را شرکت‌های امنیتی‌ای منتشر کرده‌اند که این ترافیک را برای مشتریانشان زیر نظر دارند؛ پس آن‌ها را نشانه بدانید، نه سرشماری. گزارش Cloud and Threat Report 2026 شرکت Netskope، که بازه‌ی مهر ۱۴۰۳ تا آبان ۱۴۰۴ را پوشش می‌دهد، به‌طور میانگین ۲۲۳ تخلف از سیاست داده در ابزارهای هوش مصنوعی مولد را برای هر سازمان در ماه شمرده است؛ در یک‌چهارم بالایی سازمان‌ها این عدد به ۲٬۱۰۰ می‌رسد. ۴۲ درصد این تخلف‌ها کد منبع بوده، ۳۲ درصد داده‌ی مشمول مقررات مثل اطلاعات شخصی، مالی و درمانی، و ۱۶ درصد مالکیت فکری. شرکت Harmonic Security هم در سال ۲۰۲۵ میلادی ۲۲٫۵ میلیون پرامپت و فایل آپلودی را در ۶۶۵ ابزار هوش مصنوعی، در شرکت‌هایی در آمریکا و بریتانیا، بررسی کرد و تقریباً در یکی از هر چهل مورد داده‌ی حساس پیدا کرد: ۵۷۹٬۱۱۳ مورد در یک سال.

نمونه‌ی رایج هیچ چیز عجیبی ندارد. کارشناس پشتیبانی می‌خواهد به مشتری دلخوری جواب مؤدبانه بدهد و کل تیکت را در چت می‌گذارد:

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

شش راه خروج از سازمان

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

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

# .env
DATABASE_URL=postgres://payments:Winter-2026!@10.20.30.40:5432/payments
SMS_API_KEY=sk_live_51H...redacted

برنامه‌نویس چیزی کپی نکرده، اما رمز پایگاه داده، نشانی سرور داخلی و یک کلید API فعال حالا بخشی از پرامپت‌اند. در داده‌های Harmonic برای سال ۲۰۲۵، ۱۲٫۸ درصد داده‌ی حساسی که به ابزارهای برنامه‌نویسی فرستاده شد کلید دسترسی بود: توکن API، اطلاعات ورود و کلیدهای محرمانه. دستیار در حالت عامل (agent) می‌تواند فرمان هم در ترمینال اجرا کند و خروجی‌اش را بخواند؛ پس پرسش اصلی این نیست که برنامه‌نویس چه چیزی نشانش می‌دهد، این است که اجازه دارد چه چیزی را باز کند. قواعد این کار را در استفاده‌ی امن از دستیارهای برنامه‌نویسی هوش مصنوعی نوشته‌ایم.

پایگاه دانش. تیمی روی ۲٬۰۰۰ قرارداد یک دستیار داخلی می‌سازد و برای نمایه‌سازی‌شان از یک API بیرونی برای ساخت embedding استفاده می‌کند. همان روز اول، هر ۲٬۰۰۰ قرارداد به‌طور کامل از شبکه بیرون رفته‌اند، پیش از آن‌که کسی سؤالی پرسیده باشد. بعد از آن هم هر پرسش، همراه با بخش‌هایی از قراردادها که برای پاسخش بازیابی شده، بیرون می‌رود. اگر embedding را مدلی داخل شبکه بسازد، سندها اصلاً بیرون نمی‌روند.

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

داده بعد از خروج چه می‌شود

پرامپت که به ارائه‌دهنده رسید، تصمیم درباره‌ی چهار چیز با کس دیگری است.

چقدر نگه داشته می‌شود و چه کسی آن را می‌خواند. سیاست هر ارائه‌دهنده مدت نگهداری را تعیین می‌کند و به کارکنانش اجازه می‌دهد برای بررسی سوءاستفاده بخشی از گفت‌وگوها را بخوانند. بسیاری از طرح‌های شخصی هم از گفت‌وگوها برای بهتر کردن مدل استفاده می‌کنند، مگر این‌که کاربر خودش این گزینه را خاموش کند؛ طرح‌های سازمانی معمولاً چنین نمی‌کنند. در داده‌های Harmonic برای سه‌ماهه‌ی سوم ۲۰۲۵، ۲۱٫۸ درصد داده‌ی حساس به ابزارهایی رفته بود که با ورودی کاربران آموزش می‌بینند.

آیا «پاک‌شده» واقعاً پاک شده است. اردیبهشت ۱۴۰۴، در پرونده‌ی شکایت نیویورک‌تایمز از OpenAI بر سر حق نشر، دادگاهی در آمریکا به این شرکت دستور داد لاگ‌های خروجی ChatGPT را نگه دارد، حتی گفت‌وگوهایی را که خود کاربران پاک کرده بودند. این دستور طرح‌های Free، Plus، Pro و Team و استفاده از API بدون قرارداد «نگهداری صفر» را در بر می‌گرفت و طرح‌های Enterprise و Edu بیرون از آن بودند. تکلیف ادامه‌ی نگهداری از ۴ مهر ۱۴۰۴ برداشته شد، اما داده‌ای که تا آن روز کنار گذاشته شده بود همچنان نگه داشته می‌شود. هیچ‌کدام از آن کاربران خطایی نکرده بودند.

آیا لینک اشتراک خصوصی می‌ماند. مرداد ۱۴۰۴ حدود ۴٬۵۰۰ گفت‌وگوی اشتراکی ChatGPT، که کاربرانشان گزینه‌ی «قابل جست‌وجو کردن این گفت‌وگو» را تیک زده بودند، در نتایج گوگل پیدا شد و این گزینه یک روز بعد حذف شد. چند هفته بعد معلوم شد بیش از ۳۷۰ هزار گفت‌وگوی اشتراکی Grok نمایه شده است؛ گفت‌وگوهایی که فقط با زدن دکمه‌ی اشتراک ساخته شده بودند.

آیا می‌شود دستیاری متصل را وادار به فرستادنش کرد. دستیاری که ایمیل و سند می‌خواند، با متنی که درون همان‌ها پنهان شده هدایت‌پذیر است. آسیب‌پذیری EchoLeak با شناسه‌ی CVE-2025-32711 و امتیاز ۹٫۳، که خرداد ۱۴۰۴ و پس از رفعش روی سرورهای مایکروسافت افشا شد، به یک ایمیل دست‌کاری‌شده اجازه می‌داد Microsoft 365 Copilot را وادار کند داده‌ی داخلی را در نشانی یک تصویر بگذارد تا مرورگر خودش آن نشانی را باز کند. کافی بود قربانی سؤالی مرتبط از Copilot بپرسد. سازوکارش همان تزریق غیرمستقیمی است که در راهنمای تست نفوذ اپلیکیشن‌های مبتنی بر مدل زبانی توضیح داده‌ایم.

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

چرا ممنوع کردن جواب نمی‌دهد

طبق گزارش Netskope، ۴۷ درصد کسانی که در کار از هوش مصنوعی مولد استفاده می‌کنند هنوز سراغ اپلیکیشن‌های شخصی می‌روند؛ این سهم یک سال پیش‌تر ۷۸ درصد بود و با فراهم شدن حساب‌های سازمانی پایین آمده است. Harmonic هم منشأ ۱۶٫۹ درصد از موارد داده‌ی حساسی را که در سال ۲۰۲۵ دید، حساب‌های رایگان شخصی می‌داند. در ایران این اثر شدیدتر است، چون بسیاری از سرویس‌های هوش مصنوعی خارجی فقط با VPN و حساب شخصی در دسترس‌اند. ممنوعیت نیاز را از بین نمی‌برد؛ فقط دید سازمان را به آن از بین می‌برد.

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

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

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

۱. پیش از تشخیص، یکسان‌سازی کنید. متن فارسی با ارقام فارسی، عربی و لاتین، با «ی» و «ک» فارسی و عربی، و با نویسه‌های نامرئی می‌رسد. سامانه‌ای که فقط یک شکل را بشناسد، بقیه را نمی‌بیند. همین مشکل فیلترهای تزریق پرامپت را هم از کار می‌اندازد، که در تزریق پرامپت در چت‌بات‌های فارسی نشانش داده‌ایم.

۲. سه نوع چیز را تشخیص دهید. شناسه‌های ساخت‌یافته (کد ملی، شماره‌ی کارت و شبا، تلفن، ایمیل، نشانی IP) با الگو پیدا و با رقم کنترلشان تأیید می‌شوند. نام مشتری‌ها، اسم رمز پروژه‌ها و نام سرورهای داخلی الگویی ندارند و باید از فهرست‌های خود سازمان بیایند. سندهای کامل، مثل نامه‌ی محرمانه‌ی اسکن‌شده، بعد از خوانده شدن متنشان با OCR، با یک دسته‌بند (classifier) روی مدل محلی شناخته می‌شوند.

۳. اقدام را برای هر فضای کاری تعیین کنید، نه برای هر نفر. چهار اقدام تقریباً همه‌ی حالت‌ها را پوشش می‌دهد:

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

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

ارائه‌دهنده یک درخواست منسجم می‌گیرد و هیچ‌کدام از آن شش مقدار را نمی‌بیند. یک مقدار در یک درخواست همیشه همان جای‌نگه‌دار را می‌گیرد، پس «مشتری» در سراسر متن همان یک نفر می‌ماند. وقتی پاسخ با [[TERM_CLIENT_1]] برگشت، نام واقعی داخل شبکه جایگزین می‌شود و بعد به دست کارشناس می‌رسد.

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

2026-10-24T09:41:12Z workspace=support user=agent-17 model=external
  found: TERM:CLIENT=1 IR_NATIONAL_ID=1 IR_BANK_CARD=1 IR_PHONE=1
         IR_SHEBA=1 INTERNAL_IPV4=1
  action: mask   sent: placeholders only   restored: yes

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

چرا رقم کنترل مهم است

کد ملی رقم کنترل دارد، شبا آزمون MOD-97 و شماره‌ی کارت آزمون Luhn. سامانه‌ای که این آزمون‌ها را انجام دهد، 0012345679 را که کد ملی درستی است از 0012345678 که کد ملی نیست تشخیص می‌دهد:

def national_id_ok(code: str) -> bool:
    if len(code) != 10 or not code.isdigit() or len(set(code)) == 1:
        return False
    s = sum(int(code[i]) * (10 - i) for i in range(9)) % 11
    check = int(code[9])
    return check == s if s < 2 else check == 11 - s

national_id_ok("0012345679")   # True: تشخیص داده و پوشانده می‌شود
national_id_ok("0012345678")   # False: کد ملیِ اشتباه تایپ‌شده، کد ملی نیست

این آزمون از دو طرف محدودیت دارد. از هر ده عدد ده‌رقمی تصادفی، تقریباً یکی از آزمون کد ملی می‌گذرد (روی ۲۰۰٬۰۰۰ عدد امتحانش کردیم)؛ پس گاهی یک شماره‌ی سفارش هم به‌جای کد ملی پوشانده می‌شود، هرچند بدون آزمون همه‌ی عددهای ده‌رقمی پوشانده می‌شدند. از آن طرف، کد ملی‌ای که یک رقمش اشتباه تایپ شده از آزمون نمی‌گذرد و شناخته نمی‌شود. جمله‌ای مثل «هیئت‌مدیره خرید ۱۲۰ میلیارد تومانی پروژه‌ی سیمرغ را تصویب کرد» هم شناخته نمی‌شود، چون هیچ شناسه‌ای در آن نیست. گذاشتن «سیمرغ» در فهرست اسم‌های رمز حالت دوم را پوشش می‌دهد. برای کاری که هیچ شکافی در آن پذیرفتنی نیست، پاسخ اقدام سوم است: روی مدل محلی بماند.

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

راه‌اندازی در چهار هفته

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

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

پرسش‌های رایج

آیا طرح سازمانی (Enterprise) ارائه‌دهنده کافی است؟ شرایط را بهتر می‌کند؛ طرح‌های سازمانی معمولاً داده را از آموزش مدل کنار می‌گذارند و مدت نگهداری را در اختیار مدیر سازمان می‌گذارند. اما داده همچنان بیرون می‌رود، حساب‌های شخصی‌ای که کارکنان کنارش استفاده می‌کنند را پوشش نمی‌دهد و برای پنج مسیر دیگر کاری نمی‌کند.

آیا پوشاندن پاسخ‌ها را بدتر می‌کند؟ به‌ندرت، چون بیشتر کارها به شکل پرسش نیاز دارند، نه به شناسه‌های داخلش. جایی که خودِ مقدار موضوع کار است، مثلاً بررسی درستی یک شماره‌ی شبا، آن درخواست جایش روی مدل محلی است.

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

تصویر و سند اسکن‌شده چه می‌شود؟ با آن‌ها مثل متنی رفتار کنید که هنوز خوانده نشده. پیش از ارسال با OCR، فارسی و انگلیسی، خوانده شوند و همان تشخیص و سیاست روی نتیجه اجرا شود.

ما ابزار جلوگیری از نشت داده (DLP) داریم. این را هم پوشش می‌دهد؟ دو چیز را بررسی کنید: آیا اصلاً ترافیک سرویس‌های هوش مصنوعی را می‌بیند، از جمله فراخوانی‌های API از اپلیکیشن‌های خودتان؟ و آیا متن فارسی و شناسه‌های ایرانی را می‌شناسد؟ بسیاری از این ابزارها برای متن انگلیسی و ایمیل ساخته شده‌اند.

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