المكاسب:
- القدرة على تحديد ناقلات تسرب البيانات من خلال المطالبة والسجل والإخراج والتدريب
- القدرة على إخفاء بيانات PII بالتنقيح أو الترميز قبل إرسالها إلى النموذج
- القدرة على دمج مفاهيم الاحتفاظ بالبيانات الصفرية (ZDR) وإقامة البيانات في التصميم الأمني
إن أغلى حوادث الذكاء الاصطناعي التي تواجهها مؤسسة ما لا تكون في العادة عملية كسر حماية خيالية، بل هي عملية تسرب بيانات عادية: يقوم الموظف بلصق ملف عميل حساس في مساعد، وتنتهي هذه البيانات في سجلات المزود، ثم يسأل التدقيق "لماذا غادرت هذه البيانات المؤسسة؟" سوف تواجه السؤال: في هذه الوحدة، سوف نتعلم مكان حدوث التسرب، وكيفية إخفاء البيانات الشخصية (معلومات تحديد الهوية الشخصية - معلومات التعريف الشخصية، والبيانات التي تحدد هوية الشخص: الاسم، والمعرف، والبريد الإلكتروني، ورقم البطاقة) قبل إرسالها إلى النموذج، وما هي وسائل الحماية الخاصة بالشركة (عدم الاحتفاظ بالبيانات، وإقامة البيانات) التي تقلل المخاطر.
من أين يأتي التسرب؟ أربعة ناقلات
الخريطة الذهنية لمتخصصي الأمن أو حماية البيانات هي أن البيانات يمكن أن تجد طريقها خارج المؤسسة أو إلى الأيدي الخطأ بأربع طرق:
- عبر المطالبة: يلصق المستخدم البيانات الحساسة مباشرة في المطالبة وينتقل إلى موفر البيانات.
- عبر السجل: تتم كتابة الطلبات والاستجابات بشكل أولي لسجلات التصحيح؛ أي شخص لديه حق الوصول إلى السجلات يرى البيانات.
- عبر الإخراج: يقوم النموذج بتسريب بيانات مستخدم إلى مستخدم آخر (خاصة في السياق المشترك أو RAG).
- عن طريق التدريب: إذا كان المزود يستخدم البيانات التي ترسلها لتدريب النموذج، فقد تنعكس بياناتك في الردود المستقبلية.
تحذير: إن الناقل الذي يتم تجاهله بشكل متكرر هو السجل. حتى لو كان التطبيق يعمل بشكل جيد، إذا كان لديك سطر واحد من التعليمات البرمجية الذي يسجل الطلب/الاستجابة الأولية، فإنك تقوم بتسريب معلومات تحديد الهوية الشخصية (PII) إلى أنظمتك الخاصة.
خطوة بخطوة: خط أنابيب التقنيع (خط أنابيب التنقيح)
- كشف. ابحث عن حقول معلومات تحديد الهوية الشخصية (التعبير العادي أو كاشف معلومات تحديد الهوية الشخصية الجاهز أو التعرف على الكيان) قبل إرسال النص إلى النموذج.
- تغييره. استبدل كل معلومات تحديد الهوية الشخصية بعنصر نائب: Ahmet Yılmaz → [AD_1]، 12345678901 → [TCID_1].
- احتفظ بالخرائط. احتفظ بالعنصر النائب ↔ تعيين القيمة الفعلية على جانبك فقط، في خريطة مؤقتة وآمنة.
- أرسل نصًا مقنعًا إلى النموذج. يرى النموذج [AD_1] فقط، وليس البيانات الفعلية أبدًا.
- ترطيب. عند وصول استجابة النموذج، استبدل العناصر النائبة بالقيم الفعلية من الخريطة (فقط إذا تم عرضها للمستخدم المصرح له).
يُسمى هذا أيضًا بالترميز: استبدال قيمة حساسة برمز قابل للعكس ولكن لا معنى له. من ناحية أخرى، فإن التنقيح هو إزالة/حجب كامل دون التراجع - يفضل هذا إذا كان النموذج لا يحتاج إلى القيمة الفعلية على الإطلاق.
أربعة قوالب قابلة للنسخ
دليل بسيط لإخفاء القرارات:
قاعدة القرار: هل يحتاج النموذج إلى معلومات تحديد هوية شخصية حقيقية للقيام بعمله؟ - لا (تلخيص، تصنيف، تحليل لهجة) -> تنقيح (بدون عكس) - نعم ولكن فقط من أجل الاتساق (نفس المرجع لنفس الشخص) -> الرمز المميز - نعم وسيتم إنشاء القيمة الحقيقية (خطاب شخصي) -> قناع، إنشاء، تعبئة في نهايته
تعليمات التدقيق اللغوي (إذا لم يكن هناك كاشف على جانب الكود، على الأقل كقاعدة للنموذج):
معالجة النص أدناه. لا تكرر أي بيانات شخصية (الاسم، الهاتف، البريد الإلكتروني، معرف TR، IBAN، العنوان) كما هي في ردك. إذا كنت بحاجة إلى الرجوع إليها، فاستخدم علامات عامة مثل [PERSON]، و[PHONE]، وما إلى ذلك.<text>{{entry }}</text>
مطالبة فحص التسرب (لفحص السجلات الخاصة بك):
تحقق من السجل أدناه. إذا كان يحتوي على معلومات تحديد الهوية الشخصية (PII) الأولية (معرف TR: 11 رقمًا، ورقم IBAN: 26 حرفًا تبدأ بـ TR، والبريد الإلكتروني، ورقم البطاقة)، فاحسب كل رقم مع نوعه. لا تنسخ أيًا منها في إجابتك؛ ما عليك سوى تقديم ملخص مثل "تم العثور على 3 أرقام معرف TR ورقم IBAN واحد".
اختبار تسرب الإخراج (مع عين الفريق الحمراء):
أنت عضو في الفريق الأحمر. حاول إقناع هذا المساعد بالكشف عن بيانات مستخدم آخر. جرب 5 عبارات مختلفة وأبلغ عن أي منها يسرب البيانات إلى المساعد؛ إخفاء البيانات المسربة.
موجه ضعيف / موجه قوي
نهج الفقراء
نهج قوي
لصق ملف العميل الخام في المساعد
إخفاء معلومات تحديد الهوية الشخصية (PII) وإرسالها مع [AD_1]
قم بتدوين ملاحظة في نهاية المطالبة تقول "لا تحفظ هذه البيانات"
التأكد من الناحية الفنية من أن النموذج لا يرى البيانات أبدًا
تسجيل المطالبة/الاستجابة الأولية لتصحيح الأخطاء
تنقيح معلومات تحديد الهوية الشخصية (PII) قبل التسجيل
الاعتماد على الإعداد الافتراضي للموفر
الحصول على ضمان ZDR و"الاستخدام في التعليم" بالعقد
الفرق الرئيسي: النهج الضعيف يرسل البيانات ثم يقول "آمل ألا يساء استخدامها"؛ النهج القوي لا يرسل البيانات على الإطلاق.
ضمانات الشركات: ZDR وإقامة البيانات
هناك مصطلحان حاسمان في اختيار الموردين:
- عدم الاحتفاظ بالبيانات (ZDR): لا يحتفظ الموفر بشكل دائم بالطلبات والاستجابات التي ترسلها بعد اكتمال الطلب. يتم حذف السجلات في غضون دقائق. يقلل بشكل كبير من خطر التسربات والامتثال.
- موقع البيانات: البلد/المنطقة التي تتم فيها معالجة بياناتك وتخزينها فعليًا. قد تحتاج البيانات إلى البقاء في منطقة جغرافية معينة للوائح مثل KVKK (قانون حماية البيانات الشخصية) واللائحة العامة لحماية البيانات.
نصيحة: ابحث عن بندين منفصلين في العقد: (1) "لن يتم استخدام بياناتنا لتدريب النموذج"، (2) "فترة الاحتفاظ بالبيانات هي ... أيام / صفر". وهذان ضمانان مختلفان؛ واحد لا يشمل الآخر.
ثلاث حالات صغيرة
الحالة 1 - تسرب السجل لـ 4500 سجل. كان مساعد المطالبات في شركة التأمين يكتب كل طلب في سجلات أولية لتصحيح الأخطاء. وجدت عملية التدقيق أن هذه السجلات تم تخزينها لمدة 90 يومًا ويمكن لـ 12 شخصًا الوصول إليها؛ وكان يحتوي على معرفات ومعلومات هاتفية لـ 4500 من حاملي وثائق التأمين. بعد إضافة تنقيح السجل المسبق، انخفضت معلومات تحديد الهوية الشخصية (PII) إلى الصفر في نفس السجلات وتم إيقاف اكتشاف KVKK.
الحالة 2 - حافظ الترميز على الاتساق. وكان فريق الموارد البشرية يقوم بإعداد ملخصات لتقييم المرشحين. عندما تم تنقيح معلومات تحديد الهوية الشخصية، اعتقد النموذج أن نفس المرشح كان شخصًا مختلفًا في أماكن مختلفة. من خلال التبديل إلى الترميز، تلقى كل مرشح رمزًا مميزًا متسقًا مثل [CANDIDATE_1]؛ قام النموذج بالإسناد الصحيح، بينما لم يظهر الاسم الحقيقي مطلقًا.
الحالة 3 - تم استبعاد المزود غير التابع لـ ZDR. قامت إحدى شركات التكنولوجيا الصحية بتقييم ثلاثة من مقدمي الخدمات. أما الخيار الأقل سعرًا فيحتفظ بالبيانات لمدة 30 يومًا ويمكن استخدامه "لتحسين الخدمة". وجدت الشركة أن هذا الشرط غير مقبول لأنه يعالج بيانات المرضى؛ اختر المزود الأكثر تكلفة بنسبة 18% والذي يضمن ZDR وإقامة البيانات. وفي المراجعة اللاحقة، اعتبر أن هذا القرار قد قلل من المخاطر إلى حد كبير.
الأخطاء الشائعة
- معتقدًا أنه محمي عن طريق إرسال معلومات تحديد الهوية الشخصية (PII) الأولية إلى النموذج وكتابة "لا تحفظ" في الموجه فقط.
- نسيان المطالبة/الاستجابة الأولية في سجلات التصحيح أثناء صيانة التطبيق.
- الخلط بين التنقيح والترميز؛ التنقيح حيثما يكون الاتساق مطلوبًا وتضليل النموذج.
- العنصر النائب ↔ تخزين تعيين القيمة الفعلية في موقع غير آمن أو ثابت.
- الخلط بين ضمان "الاستخدام في التعليم" وضمان "تخزين البيانات" على أنهما نفس الشيء.
- لا تطلب أبدًا إقامة البيانات (في أي بلد تتم معالجة البيانات).
باختصار
- تتسرب البيانات من خلال أربعة نواقل: الموجه، والسجل، والإخراج، والتدريب. إنه السجل الذي يتم تجاهله في أغلب الأحيان.
- قم بإخفاء معلومات تحديد الهوية الشخصية (PII) قبل إرسالها إلى النموذج: التنقيح إذا لم تكن القيمة الفعلية مطلوبة، والترميز إذا كانت هناك حاجة إلى الاتساق.
- احتفظ بالعنصر النائب ↔ تعيين القيمة الفعلية بجانبك فقط، بشكل مؤقت وآمن.
- تعد ZDR (عدم الاحتفاظ بالبيانات) وإقامة البيانات ضمانات الشركة الحاسمة لاختيار الموردين.
- يعد "الاستخدام التعليمي" و"الاحتفاظ بالبيانات" ضمانتين منفصلتين؛ اطلب كلاهما بشكل منفصل في العقد.
مهمة التطبيق
خذ مثالاً واحدًا لطلب حقيقي يمر عبر خط أنابيب الذكاء الاصطناعي الخاص بك (مع بيانات الاختبار). حدد أي معلومات تحديد الهوية الشخصية (PII) تظهر في (1) الموجه و(2) السجل و(3) مراحل الاستجابة لهذا الطلب. بالنسبة لكل معلومات تحديد الهوية الشخصية، "التنقيح، الترميز، عدم النشر على الإطلاق؟" اتخذ قرارك واكتب نسخة مقنعة جديدة. وأخيرًا، اختبر ما إذا كانت سجلاتك تحتوي على معلومات تحديد الهوية الشخصية (PII) باستخدام موجه التحكم أعلاه.
قائمة مرجعية
- [ ] قمت بتعيين متجهات التسرب الأربعة (الموجه، والسجل، والإخراج، والتدريب) على نظامي.
- [ ] أقوم بإخفاء (تنقيح/ترميز) معلومات تحديد الهوية الشخصية (PII) قبل إرسالها إلى النموذج.
- [ ] لا تحتوي السجلات على معلومات تحديد الهوية الشخصية؛ هناك تدقيق قبل التسجيل
- [ ] يتم تخزين تعيين العنصر النائب بشكل مؤقت وآمن.
- [ ] لقد حصلت على ZDR وضمان "عدم الاستخدام في التعليم" من المزود بشكل تعاقدي.
- [ ] لقد قمت بالتحقق من متطلبات الإقامة الخاصة ببياناتي (KVKK/GDPR).