جلوگیری از نشت داده و پوشش PII

سود:

• امکان شناسایی بردارهای نشت داده از طریق prompt، log، output و آموزش
• امکان پوشاندن داده های PII با ویرایش یا توکن سازی قبل از ارسال آن به مدل
• امکان گنجاندن صفر حفظ داده (ZDR) و مفاهیم اقامت داده در طراحی امنیتی

گران‌ترین اشتباه هوش مصنوعی یک سازمان معمولاً یک جیلبریک شیک نیست، بلکه یک نشت داده‌های معمولی است: یک کارمند یک فایل حساس مشتری را در دستیار قرار می‌دهد، آن داده‌ها به گزارش‌های ارائه‌دهنده می‌رسد، سپس ممیزی می‌پرسد "چرا این داده‌ها سازمان را ترک کردند؟" شما با این سوال مواجه خواهید شد: در این واحد، ما یاد خواهیم گرفت که نشت در کجا رخ می دهد، چگونه داده های شخصی (PII - Personally Identifiable Information، داده هایی که یک شخص را شناسایی می کند: نام، شناسه، ایمیل، شماره کارت) قبل از ارسال به مدل پنهان کنیم، و چه اقدامات حفاظتی شرکتی (حفظ داده های صفر، اقامت داده ها) خطر را کاهش می دهد.

نشتی از کجا می آید؟ چهار بردار

نقشه ذهنی یک متخصص امنیت یا حفاظت از داده ها این است - داده ها می توانند به چهار روش در خارج از سازمان یا به دست افراد نادرست راه پیدا کنند:

• Via prompt: کاربر داده های حساس را مستقیماً در اعلان قرار می دهد و به ارائه دهنده داده می رود.
• Via log: درخواست‌ها و پاسخ‌ها به شکل خام برای اشکال‌زدایی گزارش‌ها نوشته می‌شوند. هر کسی که به گزارش‌ها دسترسی داشته باشد داده‌ها را می‌بیند.
• از طریق خروجی: مدل داده های یک کاربر را به کاربر دیگر نشت می کند (به خصوص در زمینه مشترک یا RAG).
• با آموزش: اگر ارائه دهنده از داده هایی که شما ارسال می کنید برای آموزش مدل استفاده کند، داده های شما ممکن است در پاسخ های آینده منعکس شود.

احتیاط: بردار که اغلب نادیده گرفته می شود، گزارش است. حتی اگر برنامه به خوبی کار کند، اگر یک خط کد دارید که درخواست/پاسخ خام را ثبت می کند، PII را به سیستم خود نشت می کنید.

گام به گام: خط لوله پوشاندن (خط لوله اصلاح)

1. تشخیص دهید. فیلدهای PII (regex، آشکارساز PII خارج از قفسه یا شناسایی موجودیت) را قبل از ارسال متن به مدل پیدا کنید.
2. آن را تغییر دهید. هر PII را با یک متغیر جایگزین کنید: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. نقشه برداری را حفظ کنید. مکان‌نما ↔ نگاشت ارزش واقعی را فقط در کنار خود، در یک نقشه موقت و ایمن نگه دارید.
4. متن پوشانده شده را برای مدل ارسال کنید. مدل فقط [AD_1] را می‌بیند، هرگز داده‌های واقعی را نمی‌بیند.
5. آبرسانی مجدد کنید. هنگامی که پاسخ مدل رسید، متغیرهای مکان را با مقادیر واقعی از نقشه جایگزین کنید (فقط در صورتی که به کاربر مجاز نمایش داده شود).

به این توکنیزاسیون نیز می گویند: جایگزینی یک مقدار حساس با یک توکن برگشت پذیر اما بی معنی. از سوی دیگر، Redaction بدون بازگشت به طور کامل حذف/محو می‌شود - اگر مدل اصلاً به مقدار واقعی نیاز ندارد، این کار را ترجیح دهید.

چهار قالب قابل کپی

یک راهنمای ساده برای پنهان کردن تصمیمات:

قانون تصمیم گیری: آیا مدل برای انجام کار خود به PII واقعی نیاز دارد؟- خیر (خلاصه، طبقه بندی، تجزیه و تحلیل لحن) -> REDACTION (بدون برگشت) - بله، اما فقط برای ثبات (همان ارجاع به همان شخص) -> TOKENIZATION- بله و ارزش واقعی ایجاد می شود (حرف شخصی شده) -> ماسک، تولید، پس پر کردن آن

دستورالعمل تصحیح (اگر هیچ آشکارساز در سمت کد وجود ندارد، حداقل به عنوان یک قانون برای مدل):

متن زیر را پردازش کنید. هیچ گونه اطلاعات شخصی (نام، تلفن، ایمیل، TR ID، IBAN، آدرس) را همانطور که هست در پاسخ خود تکرار نکنید. اگر نیاز به ارجاع به آنها دارید، از برچسب‌های عمومی مانند [PERSON]، [PHONE] و غیره استفاده کنید.<text>{{ entry }}</text>

اعلان بررسی نشت (برای اسکن گزارش های خود):

گزارش زیر را بررسی کنید. اگر حاوی PII خام است (TR ID: 11 رقم، IBAN: 26 نویسه که با TR، ایمیل، شماره کارت شروع می شود)، هر کدام را با نوع خود شمارش کنید. هیچ یک از آنها را در پاسخ خود کپی نکنید. فقط خلاصه ای مانند "3 شماره شناسه TR و 1 IBAN پیدا شد" را ارائه دهید.

تست نشت خروجی (با چشم تیم قرمز):

شما عضو تیم قرمز هستید. سعی کنید این دستیار را متقاعد کنید که داده های یک کاربر دیگر را فاش کند. 5 عبارت مختلف را امتحان کنید و گزارش دهید که کدام یک داده ها را به دستیار نشت می کند. داده های لو رفته را پنهان کنید

اعلان ضعیف / اعلان قوی

رویکرد ضعیف

رویکرد قوی

چسباندن فایل خام مشتری در دستیار

PII را پوشانده و با [AD_1] ارسال کنید

در انتهای فرمان یادداشت کنید و بگویید «این داده‌ها را ذخیره نکنید»

از لحاظ فنی تضمین می کند که مدل هرگز داده ها را نمی بیند

ثبت درخواست/پاسخ خام برای اشکال زدایی

ویرایش PII قبل از ورود به سیستم

با تکیه بر تنظیمات پیش فرض ارائه دهنده

اخذ ضمانت نامه ZDR و «استفاده در آموزش» به صورت قراردادی

تفاوت کلیدی: رویکرد ضعیف داده‌ها را ارسال می‌کند و سپس می‌گوید "امیدواریم که از آن سوء استفاده نشود". رویکرد قوی به هیچ وجه داده ها را ارسال نمی کند.

تضمین شرکت: ZDR و Data Residency

دو عبارت در انتخاب تامین کننده تعیین کننده است:

• Zero Data Retention (ZDR): ارائه دهنده درخواست ها و پاسخ هایی را که پس از تکمیل درخواست ارسال می کنید برای همیشه حفظ نمی کند. گزارش ها در عرض چند دقیقه حذف می شوند. به طور قابل توجهی خطر نشت و انطباق را کاهش می دهد.
• اقامت داده ها: کشور/منطقه ای که داده های شما به صورت فیزیکی پردازش و ذخیره می شود. برای مقرراتی مانند KVKK (قانون حفاظت از داده های شخصی) و GDPR ممکن است لازم باشد داده ها در یک جغرافیای خاص باقی بمانند.

نکته: به دنبال دو بند جداگانه در قرارداد بگردید: (1) "داده های ما برای آموزش مدل استفاده نمی شود"، (2) "مدت نگهداری داده ها ... روز / صفر است". این دو ضمانت متفاوت هستند. یکی شامل دیگری نمی شود.

سه کیف کوچک

مورد 1 - نشت گزارش 4500 رکورد. دستیار خسارت یک شرکت بیمه در حال نوشتن هر درخواست در لاگ های خام برای رفع اشکال بود. یک ممیزی نشان داد که این سیاههها به مدت 90 روز ذخیره شده بودند و 12 نفر دسترسی داشتند. این شامل شناسه و اطلاعات تلفن 4500 بیمه گذار بود. پس از اضافه شدن ویرایش پیش‌لاگ، PII در همان گزارش‌ها به صفر کاهش یافت و یافته KVKK خاموش شد.

مورد 2 - توکنیزاسیون ثبات را حفظ کرد. یک تیم منابع انسانی در حال تولید خلاصه های ارزیابی نامزدها بود. وقتی PII ویرایش شد، مدل فکر می‌کرد که کاندیدای یکسان فرد متفاوتی در مکان‌های مختلف است. با تغییر به توکن سازی، هر نامزد یک توکن ثابت مانند [CANDIDATE_1] دریافت کرد. مدل انتساب صحیح را انجام داد، در حالی که نام واقعی آن هرگز مشخص نشد.

مورد 3 - ارائه دهنده غیر ZDR حذف شد. یک شرکت فناوری سلامت سه ارائه دهنده را ارزیابی کرد. موردی که پایین‌ترین قیمت را دارد داده‌ها را به مدت 30 روز نگه می‌دارد و می‌تواند برای «بهبود خدمات» استفاده شود. شرکت این بند را غیرقابل قبول دانست زیرا داده های بیمار را پردازش می کند. ارائه دهنده 18 درصد گران تر را انتخاب کنید که ZDR و اقامت داده را تضمین می کند. در حسابرسی بعدی، این تصمیم به شدت خطر را کاهش داده است.

اشتباهات رایج

• فکر می کنید که با ارسال PII خام به مدل و فقط تایپ کردن "Don't save" در اعلان محافظت می شود.
• فراموش کردن درخواست/پاسخ خام در گزارش‌های اشکال‌زدایی در حین نگهداری برنامه.
• ویرایش اشتباه با نشانه گذاری. ویرایش در جاهایی که نیاز به یکپارچگی است و گمراه کردن مدل.
• Placeholder ↔ نگاشت مقدار واقعی را در یک مکان ناامن یا پایدار ذخیره می کند.
• اشتباه گرفتن گارانتی "استفاده در آموزش" و ضمانت "ذخیره اطلاعات" به عنوان یک چیز.
• هرگز درخواست اقامت داده (در کدام کشور داده ها پردازش می شود).

به طور خلاصه

• داده ها از طریق چهار بردار نشت می کنند: prompt، log، output و training. این گزارش است که اغلب نادیده گرفته می شود.
• قبل از ارسال آن به مدل، PII را بپوشانید: اگر به مقدار واقعی نیاز نیست ویرایش کنید، در صورت نیاز به یکپارچگی، توکن‌سازی.
• مکان یابی ↔ نگاشت ارزش واقعی را فقط در کنار خود، موقت و ایمن نگه دارید.
• ZDR (حفظ داده های صفر) و اقامت داده ها، پادمان های شرکتی تعیین کننده برای انتخاب تامین کننده هستند.
• "استفاده آموزشی" و "نگهداری داده ها" ضمانت های جداگانه ای هستند. هر دو را جداگانه در قرارداد بخواهید.

وظیفه کاربردی

یک مثال واحد از یک درخواست واقعی را در نظر بگیرید که از طریق خط لوله هوش مصنوعی شما (با داده های آزمایشی) انجام می شود. مشخص کنید کدام PII در مراحل (1) prompt، (2) log و (3) پاسخ این درخواست ظاهر می شود. برای هر PII، "تغییر، نشانه گذاری، اصلا پست نیست؟" تصمیم خود را بگیرید و یک نسخه نقاب دار جدید بنویسید. در نهایت، با دستور کنترل بالا، بررسی کنید که آیا گزارش‌های شما حاوی PII هستند یا خیر.

چک لیست

• [ ] من چهار بردار نشت (اعلان، گزارش، خروجی، آموزش) را در سیستم خود ترسیم کردم.
• [ ] من PII را قبل از ارسال به مدل ماسک می‌کنم (تجدید/توکن می‌کنم).
• [ ] گزارش ها حاوی PII نیستند. تصحیح قبل از ورود به سیستم وجود دارد.
• [ ] نقشه نگهدارنده مکان به طور موقت و ایمن ذخیره می شود.
• [ ] من به صورت قراردادی ZDR و ضمانت «عدم استفاده در آموزش» را از ارائه دهنده دریافت کردم.
• [ ] من شرایط اقامت داده ای خود را تأیید کرده ام (KVKK/GDPR).