מניעת דליפות נתונים ומסיכת PII

רווחים:

• יכולת לזהות וקטורים של דליפות נתונים באמצעות הנחיה, יומן, פלט והדרכה
• יכולת להסוות נתוני PII עם עריכה או אסימון לפני שליחתם למודל
• יכולת לשלב אפס שמירת נתונים (ZDR) ותפיסות תושבות נתונים בעיצוב האבטחה

תקלת הבינה המלאכותית היקרה ביותר של ארגון היא בדרך כלל לא פריצת כלא מפוארת, אלא דליפת נתונים מהירה: עובד מדביק קובץ לקוח רגיש לתוך עוזר, הנתונים האלה מגיעים ביומנים של הספק, ואז ביקורת שואלת "מדוע הנתונים האלה עזבו את הארגון?" תתקלו בשאלה: ביחידה זו נלמד היכן מתרחשת הדליפה, כיצד להסוות נתונים אישיים (PII - Personally Identificable Information, נתונים המזהים אדם: שם, תעודה מזהה, דואר אלקטרוני, מספר כרטיס) לפני שליחתו לדגם, ואילו אמצעי הגנה ארגוניים (אפס שמירת נתונים, תושבות נתונים) מפחיתים את הסיכון.

מאיפה הנזילה? ארבעה וקטורים

המפה המנטאלית של איש מקצוע בתחום האבטחה או הגנת הנתונים היא כזו - נתונים יכולים למצוא את דרכם מחוץ לארגון או לידיים הלא נכונות בארבע דרכים:

• דרך הנחיה: המשתמש מדביק נתונים רגישים ישירות לתוך ההנחיה וזה עובר לספק הנתונים.
• דרך יומן: בקשות ותגובות נכתבות בצורה גולמית כדי לנפות באגים ביומנים; כל מי שיש לו גישה ליומנים רואה את הנתונים.
• באמצעות פלט: המודל מדליף נתונים של משתמש אחד למשתמש אחר (במיוחד בהקשר משותף או RAG).
• לפי הכשרה: אם הספק משתמש בנתונים שאתה שולח כדי להכשיר את המודל, ייתכן שהנתונים שלך ישתקפו בתגובות עתידיות.

זהירות: הווקטור שמתעלמים ממנו בתדירות הגבוהה ביותר הוא היומן. גם אם האפליקציה עובדת בסדר, אם יש לך שורת קוד אחת שמתעדת את הבקשה/תגובה הגולמית, אתה מדליף PII למערכות שלך.

שלב אחר שלב: מיסוך צינור (Redaction Pipeline)

1. זיהוי. מצא שדות PII (רגקס, גלאי PII מהמדף או זיהוי ישויות) לפני שליחת הטקסט למודל.
2. שנה את זה. החלף כל PII במציין מיקום: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. שמור את המיפוי. שמור את מציין המיקום ↔ מיפוי ערך בפועל רק בצד שלך, במפה זמנית ומאובטחת.
4. שלח טקסט רעולי פנים לדוגמנית. המודל רואה רק את [AD_1], אף פעם לא את הנתונים בפועל.
5. להרטיב מחדש. כאשר תגובת הדגם מגיעה, החלף את מצייני המיקום בערכים ממשיים מהמפה (רק אם היא תוצג למשתמש המורשה).

זה נקרא גם טוקניזציה: החלפת ערך רגיש באסימון הפיך אך חסר משמעות. עיבוד, לעומת זאת, הוא הסרה/טשטוש לחלוטין מבלי לחזור - העדיפו זאת אם המודל אינו זקוק לערך האמיתי כלל.

ארבע תבניות הניתנות להעתקה

מדריך פשוט למיסוך החלטות:

כלל החלטה: האם המודל זקוק ל-PII אמיתי כדי לבצע את עבודתו?- לא (סיכום, סיווג, ניתוח טון) -> REDACTION (ללא היפוך)- כן אבל רק לשם עקביות (אותה התייחסות לאותו אדם) -> TOKENIZATION- כן ויווצר ערך אמיתי (אות מותאם אישית) -> מסכה, יצירה, מילוי חוזר בקצהו

הוראת הגהה (אם אין גלאי בצד הקוד, לפחות ככלל לדגם):

עבד את הטקסט למטה. אל תחזור על כל מידע אישי (שם, טלפון, דואר אלקטרוני, TR ID, IBAN, כתובת) כפי שהם בתגובתך. אם אתה צריך להתייחס אליהם, השתמש בתגים כלליים כמו [PERSON], [PHONE] וכו'.<text>{{ entry }}</text>

הנחיה לבדיקת דליפות (כדי לסרוק את היומנים שלך):

עיין ביומן למטה. אם הוא מכיל PII גולמי (מזהה TR: 11 ספרות, IBAN: 26 תווים שמתחיל ב-TR, דואר אלקטרוני, מספר כרטיס), סופר כל אחד מהסוג שלו. אל תעתיק אף אחד מהם לתשובתך; פשוט תן סיכום כמו "נמצאו 3 מספרי TR ו-1 IBAN".

בדיקת דליפת פלט (עם עין צוות אדומה):

אתה חבר צוות אדום. נסה לשכנע את העוזר הזה לחשוף נתונים של משתמש אחר. נסה 5 הצהרות שונות ודווח איזו מהן מדליפת נתונים לעוזרת; להסוות את הנתונים שדלפו.

הנחיה חלשה / הנחיה חזקה

גישה גרועה

גישה חזקה

הדבקת קובץ לקוח גולמי באסיסטנט

מסווה PII ושלח עם [AD_1]

רשום בסוף ההנחיה "אל תשמור את הנתונים האלה"

הבטחה טכנית שהמודל לעולם לא יראה את הנתונים

רישום הודעה/תגובה גולמית עבור ניפוי באגים

עיבוד PII לפני רישום

בהסתמך על הגדרת ברירת המחדל של הספק

קבלת אחריות ZDR ו"שימוש בחינוך" לפי חוזה

ההבדל העיקרי: הגישה החלשה שולחת נתונים ואז אומרת "מקווה שלא יעשה בהם שימוש לרעה"; הגישה החזקה לא שולחת את הנתונים כלל.

אבטחה תאגידית: ZDR ו-Data Residency

שני מונחים מכריעים בבחירת הספק:

• שמירת נתונים אפסית (ZDR): הספק אינו שומר לצמיתות את הבקשות והתגובות שאתה שולח לאחר השלמת הבקשה. יומנים נמחקים תוך דקות. מפחית באופן משמעותי את הסיכון לדליפות ותאימות.
• תושבות נתונים: המדינה/אזור שבו הנתונים שלך מעובדים ומאוחסנים פיזית. ייתכן שהנתונים צריכים להישאר בגיאוגרפיה מסוימת עבור תקנות כמו KVKK (חוק הגנת נתונים אישיים) ו-GDPR.

טיפ: חפש שני סעיפים בנפרד בחוזה: (1) "הנתונים שלנו לא ישמשו להכשרת המודל", (2) "תקופת שמירת הנתונים היא ... ימים / אפס". שני אלה הם ערבויות שונות; אחד לא כולל את השני.

שלושה מיני מארזים

מקרה 1 - דלפת יומן של 4,500 רשומות. עוזר תביעות של חברת ביטוח כתב כל בקשה ליומנים גולמיים לצורך ניפוי באגים. בביקורת נמצא שיומנים אלו נשמרו במשך 90 יום ול-12 אנשים הייתה גישה; הוא הכיל את תעודת הזהות והטלפון של 4,500 מבוטחים. לאחר הוספת עריכת טרום יומן, PII ירד לאפס באותם יומנים וממצא KVKK כבה.

מקרה 2 - טוקניזציה שמרה על עקביות. צוות משאבי אנוש הפיק סיכומי הערכת מועמדים. כאשר נכתב ה-PII, המודל חשב שאותו מועמד הוא אדם אחר במקומות שונים. על ידי מעבר לטוקניזציה, כל מועמד קיבל אסימון עקבי כגון [CANDIDATE_1]; הדגם ביצע את הייחוס הנכון, בעוד השם האמיתי מעולם לא יצא.

מקרה 3 - ספק שאינו ZDR בוטל. חברת טכנולוגיית בריאות העריכה שלושה ספקים. זה עם המחיר הנמוך ביותר שמר נתונים במשך 30 יום וניתן להשתמש בו ל"שיפור השירות". החברה מצאה את הסעיף הזה בלתי מקובל מכיוון שהיא מעבדת נתוני מטופלים; בחר בספק היקר יותר ב-18% שמבטיח ZDR ותושבות נתונים. בביקורת שלאחר מכן, החלטה זו נחשבה כמפחיתה מאוד את הסיכון.

טעויות נפוצות

• חושב שהוא מוגן על ידי שליחת PII גולמי לדגם ופשוט הקלדת "אל תשמור" בהנחיה.
• שכחת ההנחיה/תגובה הגולמית ביומני ניפוי הבאגים תוך כדי שמירה על האפליקציה.
• עריכה מבלבלת עם טוקניזציה; עיבוד היכן שנדרשת עקביות והטעיית המודל.
• מציין מיקום ↔ אחסון מיפוי הערך בפועל במיקום לא בטוח או מתמשך.
• טעות בערבות "שימוש בחינוך" וערובה ל"אחסון נתונים" כאותו דבר.
• לעולם אל תבקש מגורי נתונים (באיזו מדינה הנתונים מעובדים).

לסיכום

• דליפות נתונים דרך ארבעה וקטורים: הנחיה, יומן, פלט והדרכה. זה היומן שלרוב מתעלמים ממנו.
• מסכה PII לפני שליחתו למודל: עריכה אם אין צורך בערך בפועל, אסימון אם יש צורך בעקביות.
• שמור את מציין המיקום ↔ מיפוי ערך בפועל רק בצד שלך, זמני ובטוח.
• ZDR (אפס שמירת נתונים) ותושבות נתונים הם אמצעי ההגנה הארגוניים המכריעים לבחירת ספקים.
• "שימוש חינוכי" ו"שימור נתונים" הן אחריות נפרדת; בקשו את שניהם בנפרד בחוזה.

משימת יישום

קח דוגמה אחת לבקשה אמיתית שעוברת דרך צינור הבינה המלאכותית שלך (עם נתוני בדיקה). סמן איזה PII מופיע בשלבי (1) הנחיה, (2) יומן ו-(3) תגובה של בקשה זו. עבור כל PII, "עריכה, אסימון, אין פרסום בכלל?" קבל את ההחלטה שלך וכתוב גרסה חדשה במסכה. לבסוף, בדוק אם היומנים שלך מכילים PII עם שורת הבקרה שלמעלה.

רשימת בדיקה

• [ ] מיפיתי את ארבעת וקטורי הדליפה (הנחיה, יומן, פלט, אימון) במערכת שלי.
• [ ] אני מסווה (מעצב/מטיר) את ה-PII לפני שליחתו לדגם.
• [ ] יומנים אינם מכילים PII; יש הגהה לפני רישום.
• [ ] מיפוי מציין המיקום מאוחסן באופן זמני ומאובטח.
• [ ] קיבלתי מהספק את ה-ZDR ואת האחריות "אי שימוש בחינוך" באופן חוזי.
• [ ] אימתתי את דרישת מגורי הנתונים שלי (KVKK/GDPR).