PII Detection באמצעות AI: איך מזהים מידע אישי מזהה בקנה מידה

מאת צוות מדיה דיל · 07.08.2026 · Data Engineering · 9 דק׳

מדריך ארכיטקטוני לזיהוי PII באמצעות AI: שילוב NER, Regex וכללי הקשר, ארכיטקטורת Scanning בקנה מידה, ואיך מודדים Precision מול Recall בפרודקשן.

ארגון פיננסי מגלה, אחרי ביקורת אבטחת מידע, שמספרי תעודות זהות של לקוחות מופיעים לא רק בשדות המיועדים להם אלא גם בשדות "הערות חופשיות" בטפסי שירות, בלוגים של מערכות backend, ואפילו בקבצי Excel שהופצו בין צוותים. זיהוי ידני של כל המקומות האלה בלתי אפשרי בקנה מידה ארגוני. PII Detection מבוסס AI הוא התחום שפותר בדיוק את הבעיה הזו - סריקה אוטומטית של מאגרי נתונים, קבצים, לוגים ומסמכים לזיהוי מידע אישי מזהה (Personally Identifiable Information), כולל במקומות לא צפויים כמו שדות טקסט חופשי שכללי סריקה קלאסיים מפספסים.

שלוש שכבות זיהוי משלימות

מערכת PII Detection בוגרת לא מסתמכת על שיטה אחת. השכבה הראשונה, Pattern Matching (Regex), מזהה פורמטים מובנים היטב - מספרי כרטיס אשראי (עם בדיקת Luhn), מספרי תעודת זהות ישראלית (עם ספרת ביקורת), כתובות אימייל, מספרי טלפון. מהירה, זולה, ומדויקת מאוד לנתונים מובנים - אבל עיוורת לחלוטין לשמות, כתובות בשפה חופשית, או הקשר סמנטי. השכבה השנייה, Named Entity Recognition (NER), משתמשת במודל שפה מאומן לזיהוי ישויות בטקסט חופשי - שמות אנשים, מיקומים, ארגונים - גם כשאין תבנית פורמלית קבועה. השכבה השלישית, Contextual AI Detection, משתמשת ב-LLM כדי להבין הקשר עמוק יותר - למשל להבחין בין "דוד" כשם פרטי לבין "דוד חשמל" כמכשיר, על סמך המשפט כולו ולא רק המילה הבודדת.

ארכיטקטורת Scanning בקנה מידה ארגוני

סריקת כל בסיס הנתונים והקבצים בארגון מדי יום היא יקרה ולא סקיילבילית אם עושים אותה נאיבית. ארכיטקטורה יעילה מבוססת על Sampling חכם - סריקה מלאה של מקורות חדשים בפעם הראשונה, ואז סריקה מדגמית שוטפת (למשל 5-10 אחוז מהרשומות בכל ריצה) שמספיקה לזהות דפוסים חדשים או דליפות בלי לסרוק הכל בכל פעם. בנוסף, סריקה מלאה מופעלת אוטומטית בכל פעם שמתגלה סכמה חדשה או מקור נתונים חדש שלא נסרק קודם. לוגים ומסמכים לא מובנים (PDF, Excel, קבצי טקסט חופשי) דורשים שכבת Extraction נפרדת לפני שאפשר להריץ עליהם זיהוי PII כלל.

Precision מול Recall: הדילמה המרכזית

כמו בכל מערכת סיווג, יש מתח בין Precision (כמה מהתוצאות שסומנו כ-PII באמת PII) ל-Recall (כמה מכלל ה-PII האמיתי במערכת אכן זוהה). ל-PII Detection יש אופי מיוחד: פספוס (False Negative) - מידע רגיש שלא זוהה - הוא בדרך כלל חמור הרבה יותר מזיהוי יתר (False Positive), כי הפספוס משמעו חשיפת מידע אישי בפועל שלא טופל. לכן ארכיטקטורה נכונה נוטה במכוון להעדיף Recall גבוה גם על חשבון Precision נמוך יותר, אבל זה דורש שכבת בדיקה אנושית או ולידציה נוספת לתוצאות עם ביטחון בינוני, כדי לא להציף את הצוותים באלפי התראות שווא שגורמות ל-Alert Fatigue ולהתעלמות מהמערכת כולה.

סיווג רגישות: לא כל PII שווה

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

אינטגרציה עם Pipeline קיימים: Shift-Left

הגישה היעילה ביותר היא לא לסרוק רק מסדי נתונים קיימים אלא לשלב זיהוי PII כבר בשלב הפיתוח וה-CI/CD (גישת Shift-Left) - סריקה אוטומטית של קוד ולוגים לפני שהם מגיעים לפרודקשן, ובדיקת Schema לפני שדה חדש נכנס למסד נתונים כדי לוודא שהוא מסומן נכון אם הוא מכיל PII. זה מונע את הבעיה בשורש במקום לתפוס אותה רק אחרי שהיא כבר קרתה - הרבה יותר זול לתקן בשלב הפיתוח מאשר לנקות אחרי דליפה בפרודקשן.

טעויות נפוצות בפרודקשן

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

מתי להשקיע ב-PII Detection מבוסס AI

זה משתלם כשיש כמות גדולה של טקסט חופשי במערכות (הערות שירות, פניות תמיכה, מסמכים) שכללי Regex לא יכולים לכסות, וכשיש דרישה רגולטורית לוודא כיסוי מלא (GDPR, HIPAA, תקנות הגנת פרטיות ישראליות). לארגון קטן עם מספר מצומצם של שדות מובנים בלבד (בלי טקסט חופשי), Regex פשוט לרוב מספיק ולא מצדיק את המורכבות הנוספת.

PII בקוד ובמאגרי לוגים: הבעיה הפחות מדוברת

הרבה תשומת לב ניתנת לזיהוי PII בבסיסי נתונים, אבל אחד הערוצים הנפוצים ביותר לדליפת מידע אישי הוא לוגים של אפליקציות - מפתח שמדפיס payload מלא של בקשת API לצורכי דיבוג, כולל שדות רגישים, ישירות לקובץ לוג שנשמר לחודשים או שנים ולעיתים נגיש לצוותים רבים. סריקת PII צריכה לכלול לא רק מסדי נתונים אלא גם צנרת הלוגים עצמה (ELK, Splunk, CloudWatch) עם כללי Masking שרצים כבר בשכבת ה-Logging Framework, לפני שהמידע נכתב בכלל לדיסק - הרבה יותר יעיל מניסיון לנקות לוגים אחרי שהם כבר נכתבו.

הבדל בין Structured PII ל-Unstructured PII בהערכת סיכון

שדה 'תעודת זהות' בעמודה ייעודית עם ולידציה הוא Structured PII - קל לזהות, קל להגן, קל לבקר. אותו מספר תעודת זהות שמופיע בתוך פסקת טקסט חופשי בהערת שירות הוא Unstructured PII - הרבה יותר קשה לאתר באופן שיטתי, וגם הרבה יותר קשה לטפל בו בלי לפגוע בהקשר השימושי של שאר הטקסט (מחיקה גורפת של המשפט כולו במקום רק המספר עצמו). מערכת PII Detection בוגרת מבחינה בין שתי הקטגוריות ומיישמת אסטרטגיית טיפול שונה לכל אחת - Redaction חלקי וממוקד עבור טקסט חופשי, לעומת Tokenization מלאה עבור שדות מובנים.

PII Detection כשירות משותף לכל הארגון

ארגונים גדולים עם עשרות מערכות ובסיסי נתונים נהנים מבניית PII Detection כשירות ארגוני מרכזי (Shared Service) במקום פתרון נפרד לכל צוות. שירות כזה חושף API אחיד לסריקה, תחזוקה מרכזית של מודלי הזיהוי והכללים, ותצוגה ארגונית אחת של כל מקומות ה-PII שהתגלו ברחבי הארגון (Data Map) - יתרון קריטי כשצריך לענות לבקשת נושא מידע (Data Subject Access Request) לפי GDPR או חוק הגנת הפרטיות, ולדעת בוודאות בכל המערכות שבהן מידע על אדם ספציפי מופיע.

מדידת סיכון שיורי (Residual Risk) אחרי טיפול

גם אחרי שמזהים ומטפלים ב-PII (Tokenization, מחיקה, הצפנה), נשאר לרוב סיכון שיורי - לדוגמה, שילוב של כמה שדות לא-רגישים כשלעצמם שביחד עדיין מאפשרים שחזור זהות חלקי. מדידת הסיכון השיורי הזה, ולא רק ספירת כמות ה-PII שטופל, היא המדד האמיתי לאפקטיביות התהליך. ארגונים בוגרים מריצים תקופתית ניתוח Re-identification Risk (כפי שנדון בהקשר האנונימיזציה) גם על נתונים שכבר עברו טיפול PII, כדי לוודא שהשילוב של כל השדות שנותרו לא פותח מחדש דלת לשחזור זהות.

סיכום

PII Detection מבוסס AI משלב שלוש שכבות משלימות - Regex לפורמטים מובנים, NER לשמות והקשרים, ו-LLM להבנה סמנטית עמוקה - כדי לתפוס מידע אישי גם במקומות הכי בלתי צפויים. ההצלחה בפרודקשן תלויה בהטיה מכוונת לכיוון Recall גבוה, סיווג רגישות שמאפשר תעדוף תגובה, ואינטגרציה מוקדמת בתהליך הפיתוח ולא רק סריקה חד-פעמית. בפרויקטי Compliance שמדיה דיל בונה, זיהוי PII הוא לרוב השלב הראשון בכל תהליך עמידה ברגולציית פרטיות - כי אי אפשר להגן על מה שלא יודעים שקיים.

תגיות: PII Detection · NER · Data Privacy · GDPR · Compliance · Data Loss Prevention · AI Scanning

← חזרה לבלוג · צור קשר