למה כלי PII עצמאיים נכשלים בביקורות ציות
GDPR דורש הוכחה. עליכם להראות שהסרת PII בוצעה באותה דרך בכל פעם. מבקרי DPA בודקים זאת. הם רוצים לראות שיטה ברורה ועקבית שנעשה בה שימוש על פני כל הנתונים.
ל-Presidio עצמאי יש בעיה אמיתית כאן. זו לא בעיית הגדרה. זוהי מגבלה מרכזית של כלי NLP עצמאיים.
מהו סחף סביבה?
Presidio עצמאי פועל ב-dev, staging וייצור. כל אחת מאלה יכולה להתנהג בצורה שונה. כך שאותה קלט יכולה לייצר תוצאות שונות בכל אחת מהן.
זה נקרא סחף סביבה. יש לו ארבע סיבות עיקריות.
סחף גרסת מודל
מודלי spaCy מגיע בגרסאות. מודל en_core_web_lg 3.4.4 ו-en_core_web_lg 3.5.1 אומנו על נתונים שונים. הם גם משתמשים בעיצובים שונים. כך שאותו מסמך יכול לתת תוצאות NER שונות עם כל גרסה.
הגדרה נפוצה נראית כך:
- Dev:
en_core_web_lg 3.4.4— הותקן בתחילת הפרויקט - Staging:
en_core_web_lg 3.5.0— עודכן במהלך עבודה שוטפת - Production:
en_core_web_lg 3.5.1— עודכן במהלך תיקון אבטחה
אלו שלוש הגדרות. שלוש גרסאות מודל. שלוש תוצאות זיהוי שונות. בדיקות עוברות ב-staging. אך ייצור מריץ מודל שונה. כך הפער נשאר מוסתר.
סחף גרסת תלויות
spaCy 3.4.x ו-3.5.x שונים באופן שבו הם מפצלים משפטים. שינוי זה משפיע על האופן שבו שמות נמצאים ליד מעברי משפטים. שינויים אלה נמצאים בהערות הגרסה של spaCy. אך רוב הצוותים אינם בודקים אותם להשפעת PII.
סחף הגדרה
ספי ציון שנקבעו ב-dev עלולים שלא לעבור לייצור. רשימות מילים מותאמות אישית יכולות גם להיות שונות בין הגדרות. פערים אלה נפוצים. הם לעיתים נדירות עוקבים אחריהם. ראו את מדריך הציות GDPR שלנו לגבי מה מבקרים מחפשים.
הבדלי חומרה
חישובים במודלי NLP אינם זהים על כל מעבד ו-GPU. מחשב נייד לצרכן ושרת יכולים לתת תוצאות ציון שונות במקצת. כך שחלק מהשמות עשויים להימצא במכונה אחת אך לא באחרת.
ממצא ביקורת אמיתי
בנק בדק את הגדרת Presidio העצמאית שלו.
הגדרת בדיקה: Presidio עם spaCy 3.4.4 על אשכול ה-staging. הגדרה חיה: Presidio עם spaCy 3.5.1 על אשכול הייצור.
הם הריצו את אותה קבוצת מסמכים דרך שניהם. ואז השוו את התוצאות. הממצא: 3% מהמסמכים הכילו תוצאות הסרת PII שונות. חלק מהשמות נתפסו ב-staging אך לא בייצור. לחלק היו טווחי טקסט שזוהו שונים.
ממצא הביקורת היה ישיר: "החברה אינה יכולה להראות שימוש עקבי באמצעות הסרת PII טכנית בשל הבדלים ספציפיים להגדרה בפלט הזיהוי."
GDPR Article 32 דורש אמצעים טכניים ראויים. כללי EDPB על הסרת PII דורשים עקביות וחזרתיות. שיעור של 3% מ-100,000 מסמכים בחודש פירושו 3,000 מסמכים עם תוצאות לא עקביות מדי חודש. חלקם הם false negatives. PII שסטג'ינג היה תופס נשאר בפלט החי. זהו כשל ציות.
הבנק עבר לאחר מכן ל-SaaS מנוהל. ממצא הביקורת נסגר. ראו את דף האבטחה והציות שלנו לגבי כיצד הגדרות מנוהלות מטפלות בכך.
למה שירותים מנוהלים שונים
שירות מנוהל מריץ גרסת מנוע אחת. כל המשתמשים מריצים את אותה גרסה בו זמנית. עדכוני מודל מיושמים ממקום אחד. גם הגדרה מנוהלת ממקום אחד, עם יומן שינויים מלא. חומרת המשתמש אינה משפיעה על התוצאות.
כך שאותו מסמך שעובד היום נותן אותה תוצאה בחודש הבא. אם גרסת המנוע השתנתה, השינוי מתועד ומגיע בגרסאות.
הבדל רשומת הביקורת הוא קריטי.
רשומת ביקורת עצמאית:
- "נעשה שימוש ב-Presidio 2.2.35 עם spaCy
en_core_web_lg 3.5.1על Ubuntu 22.04." - האם זו הייתה אותה גרסה כמו ב-staging? לא ידוע.
- האם המודל השתנה מאז שהמסמך הזה עובד? לא ידוע אלא אם כן עוקבים אחריו.
- האם סף הציון זהה לזה שבבדיקה? תלוי בניהול הגדרות.
רשומת ביקורת של שירות מנוהל:
- "נעשה שימוש ב-anonym.legal API, גרסת מנוע 4.22.1, ב-2025-03-15T14:22:31Z."
- אותה גרסה לכל המשתמשים? כן.
- האם השתנה? גרסאות מנוע מקובעות. גרסה 4.22.1 תמיד פירושה אותו מנוע.
- האם ההגדרה חזרתית? כן. מזהה ה-preset מתועד. ניתן לאחזר הגדרות בגרסה זו.
הנתיב המנוהל ברור. הנתיב העצמאי דורש מעקב קפדני שרוב הצוותים מדלגים עליו.
כיצד לשפר עקביות עצמאית
אם אירוח עצמי נדרש, תוכלו לצמצם סחף עם ארבעה צעדים.
ראשית, קבעו גרסאות מודל. נעלו גרסאות מודל מדויקות בכל קבצי הפריסה. חסמו עדכונים אוטומטיים. עקבו אחר גרסאות בבקרת מקור.
לאחר מכן, הקפאו תמונות קונטיינר. בנו תמונות Docker עם גרסאות מודל מדויקות מובנות פנימה. תייגו כל תמונה עם גרסת המודל, גרסת Presidio ותאריך. אל תעדכנו תמונות בסיס ללא בדיקה מוקדמת.
כמו כן, שמרו הגדרות בקוד. אחסנו את כל הגדרות Presidio בקבצים המנוהלים בבקרת גרסאות. זה כולל גלאים, ספי ציון ושפות פעילות. פרסו הגדרות עם האפליקציה.
לבסוף, בדקו על פני הגדרות. לאחר כל עדכון, הריצו קבוצת מסמכי בדיקה קבועה דרך ההגדרה החדשה. השוו תוצאות לפלט ייחוס מאוחסן. אוטומטו בדיקה זו. ראו את ה-FAQ לשאלות נפוצות על בדיקת PII אוטומטית לרגרסיה.
צעדים אלה עוזרים. אך הם גם מוסיפים עבודה. שירות מנוהל נותן את אותה עקביות ללא המאמץ הנוסף.
השורה התחתונה
הסרת PII עקבית לא מופיעה בגיליוני מוצר. אך היא הופכת קריטית כשמבקרים מבקשים ראיות.
ללא טיפוח פעיל, כלי PII עצמאיים נסחפים. שינויי גרסה מוסיפים פערים שקטים. פערים אלה מתגלים כממצאי ביקורת.
שירותים מנוהלים מספקים עקביות כברירת מחדל. המנוע פועל ממקום אחד. הגדרות משתמש אינן משפיעות על התוצאות. לצוותים ממוקדי ציות, זהו יתרון ישיר.