השוואת גישות

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

השוואת גישות

	zer0pii (שער מיסוך)	בקרות נתונים בצד הספק	DLP כללי	regex תוצרת בית
האם הספק אי פעם רואה מידע אישי גולמי?	לא - ישויות שזוהו מוחלפות בטוקנים ממלאי-מקום לפני שהבקשה יוצאת מהשער, ומשוחזרות בתשובה. מקור: apps/gateway/core/pipeline.py, apps/gateway/core/token_vault.py	הספק כן רואה את הטקסט הגולמי; הבקרה היא הבטחה חוזית או הגדרתית (תנאי אפס-שמירה, הסכם עיבוד נתונים ארגוני) על מה שקורה לו אחר כך, לא מחסום טכני לפני הקריאה.	בדרך כלל בודק תעבורה כדי לזהות או לחסום דפוס; הוא לא כותב מחדש את המטען, כך שאם הבקשה עוברת, הספק רואה את התוכן הגולמי.	רק מה שה-regex באמת תופס מוסר לפני השליחה; כל מה שהדפוס מפספס מגיע לספק גולמי.
האם המודל עדיין מקבל הקשר שימושי?	כן - ממלאי המקום שומרים על מבנה המשפט וסוג הישות, ומשוחזרים בתשובה, כך שהמודל מנמק על אותה צורת טקסט. מקור: apps/gateway/core/reconstitutor.py	כן, תמיד - מכיוון שהמודל מקבל את הטקסט ללא שינוי.	לא רלוונטי באותו מובן - כלי חסימה/התראה לא כותב מחדש את המטען, כך שההקשר נוכח במלואו (מותר) או שהבקשה לא ממשיכה כלל (נחסמה).	תלוי בהחלפה שנבחרה; regex גס של מצא-ומחק יכול להסיר מילים שהמודל היה צריך, או להשאיר פערים שנקראים מוזר.
שמות, ארגונים, מקומות (ישויות תלויות הקשר)	השכבה הסמנטית (NER) תופסת אותן כשהיא מופעלת; ה-recall הנמדד משתנה לפי ישות ושפה, ואינו מושלם. מקור: docs/DETECTION-EVAL.md (שכבה סמנטית 2: PERSON 76.2%, LOCATION 86.8%, ORGANIZATION 51.4% על מדגם של 1,500 שורות)	לא מטופל כלל בגישה הזו - היא לא מזהה או מסתירה דבר, מכיוון שהיא רק קובעת מה הספק עושה עם מה שהוא מקבל.	חלש בקטגוריה הזו מעצם התכנון: ספריות דפוסים של DLP בנויות סביב מזהים מובנים (מספרי כרטיסים, פורמטים של תעודות זהות), לא שמות או ארגונים בטקסט חופשי, שאין להם צורה קבועה להתאמה.	כמעט חסר יכולת לתפוס את אלה באופן אמין - לשם או למקום אין דפוס קבוע, כך ש-regex או מפספס את רובם או תופס יתר על המידה מילים נפוצות.
מזהים עם ביקורת תקפה (כרטיסים, תעודות זהות, IBAN)	השכבה הדטרמיניסטית מאמתת מזהים מובנים מול ביקורת (Luhn, mod-97 וכו') לפני שהיא מתייחסת להתאמה כאמיתית. מקור: apps/gateway/core/deterministic.py; docs/DETECTION-EVAL.md (למשל IBAN עם recall של 99.92% מול הזהב)	לא מטופל - זו יכולת זיהוי שאין לבקרה בצד הספק.	לעיתים קרובות נתמך - אימות ביקורת עבור פורמטים נפוצים של מזהים הוא תכונה סטנדרטית בספריות דפוסים של DLP.	אפשר לכתוב ידנית, אבל כל אלגוריתם ביקורת הוא משטח באגים משלו, והכיסוי מלא רק כמו המזהים שמישהו חשב להוסיף.
תשובות בזרימה (streaming) משוחזרות נכון?	כן - מרכיב שחזור ייעודי מטפל בגבולות טוקן שמפצלים ממלא-מקום על פני קטעי SSE שרירותיים, בלי לאגור את כל התשובה. מקור: apps/gateway/core/reconstitutor.py (StreamReconstitutor)	לא רלוונטי - שום דבר לא הוסתר, אז אין מה לשחזר בזרימה.	לא רלוונטי לזרימות תשובה של מודל שפה באותו אופן שהוא רלוונטי לתעבורת רשת; רוב כלי ה-DLP מכוונים להעברת קבצים ודוא"ל, לא לפלט מודל טוקן-אחר-טוקן.	קשה לבצע נכון - סריקה-והחלפה ביתית מעל זרימה צריכה לטפל בהתאמה שמתפצלת על פני שני קטעים, וקל לפספס וקל לטעות בעדינות.
בלוקי קוד נשארים שלמים?	כן בעיצוב - בלוקי קוד ב-markdown, שמות משתנים, שמות חבילות ותחביר AST מוחרגים ממיסוך אלא אם אושר כפרטי גישה מקודדים בקוד. מקור: CLAUDE.md (עיקרון ליבה 4, חוסן קוד); apps/gateway/core/ast_filter.py	לא רלוונטי - שום דבר לא נכתב מחדש, אז קוד אף פעם לא בסיכון להשחתה מהעברת הסתרה.	תלוי בכלי; סורק דפוסים שלא נכתב לקוד מקור עלול לסמן או לפגוע במחרוזות דומות (קבוע הקסדצימלי, נתון בדיקה שנראה מזויף) בתוך הקוד.	סיכון אמיתי - regex כללי המכוון לפרוזה לעיתים קרובות יתאים בתוך קוד (מזהה UUID, קבוע בדיקה שנראה כמו מספר טלפון) וישבור אותו.
הוכחה למה שקרה (קבלות חתומות)?	כן - כל בקשה מקבלת אישור עם חתימת Ed25519 מעל hash של המטענים הגולמי והמסונן, שניתן לאמת באופן עצמאי מ-zer0pii. מקור: apps/gateway/core/attestation.py (Attestor.sign, verify)	רק מה שיומני הספק או דוחות הציות שלו מציינים; הוכחה קריפטוגרפית עצמאית לכל בקשה אינה תכונה סטנדרטית בגישה הזו.	בדרך כלל רשומת יומן פנימית בקונסולה של ספק ה-DLP עצמו, לא תוצר נייד וניתן לאימות עצמאי.	אין, אלא אם מישהו בונה זאת - לסקריפט ביתי אין שכבת אישור אלא אם היא נוספת במכוון.
עלות זמן תגובה	נתיב דטרמיניסטי בלבד: p50 מתחת ל-10ms, p99 מתחת ל-20ms. נתיב סמנטי (NER): p50 מתחת ל-300ms לעמוד מודבק מלא, וחוזר לנתיב הדטרמיניסטי אם עומד לחרוג מהתקציב הזה. מקור: CLAUDE.md (תקציב זמן תגובה, לפי נתיב)	שום עלות מעבר לזמן התגובה של הספק עצמו - אין שלב סריקה נפרד לפני הקריאה.	משתנה לפי פריסה (בדיקת רשת מוטבעת מוסיפה זמן, ניטור מחוץ לנתיב לא מוסיף כלום לבקשה עצמה), אבל זה לא מספר שהעמוד הזה יכול לקבוע בלי מוצר ספציפי בראש.	תלוי לגמרי במימוש; קבוצת regex גדולה ונאיבית שרצה על כל בקשה יכולה להיות איטית, אבל אין מספר קבוע, מכיוון שזה תלוי בקוד שמישהו כותב.
מאמץ הגדרה	הפנו את כתובת הבסיס של ה-SDK לשער והוסיפו את מפתח ה-API - צורת הבקשה/תשובה נשארת זהה מעבר לכך. מקור: apps/web (עמודי אינטגרציות/תיעוד: דפוס החלפת כתובת בסיס + כותרת)	בדרך כלל שינוי חוזה או שכבת חשבון (תנאים ארגוניים, נספח עיבוד נתונים) ולא שינוי קוד.	בדרך כלל פריסת תשתית: סוכן, פרוקסי, או האזנת רשת, בתוספת כתיבת מדיניות - שטח תפעולי גדול יותר משינוי בצד הלקוח.	מהיר להתחיל, מכיוון שזה רק סקריפט - אבל כל סוג ישות, מקרה קצה וביקורת חייבים להיכתב ולתחזק ידנית.
מה שהיא לא מכסה	recall של PASSWORD הוא 47.96% (מחרוזות חסרות הקשר מעצם טבען) ו-recall של PHONENUMBER הוא 84.41% על הערכת הזהב; השכבה הסמנטית יורדת לדטרמיניסטי-בלבד כשהיא עומדת לחרוג מתקציב זמן התגובה שלה; ומצב מושב מנוי של Cursor ו-Claude Code אינם ניתנים לכיסוי (אין דריסת כתובת-בסיס / אין מפתח לפרוקסי במושב מנוי). מקור: docs/DETECTION-EVAL.md (שורות 64-65); CLAUDE.md (חזרה דטרמיניסטית של תקציב זמן התגובה); תיעוד: כלי פיתוח (dev-tools.md)	לא מזהה ולא מסתיר דבר כלל - זו מדיניות לגבי הטיפול של הספק במה שהוא מקבל, לא בקרה טכנית על הנתונים עצמם.	ישויות בטקסט חופשי, תלויות הקשר (שמות, ארגונים, כתובות) ללא צורה קבועה להתאמה; גם בדרך כלל לא מיועד לפלט זרימה ברמת טוקן של מודל שפה.	כל מה שהמחבר לא צפה - פורמטים חדשים, אזורים חדשים, זרימה, אימות ביקורת ובטיחות קוד הם כולם בעיות נפרדות שגישת regex בלבד לא פותרת מעצמה.

האם הספק אי פעם רואה מידע אישי גולמי?

zer0pii (שער מיסוך): לא - ישויות שזוהו מוחלפות בטוקנים ממלאי-מקום לפני שהבקשה יוצאת מהשער, ומשוחזרות בתשובה.מקור: apps/gateway/core/pipeline.py, apps/gateway/core/token_vault.py
בקרות נתונים בצד הספק: הספק כן רואה את הטקסט הגולמי; הבקרה היא הבטחה חוזית או הגדרתית (תנאי אפס-שמירה, הסכם עיבוד נתונים ארגוני) על מה שקורה לו אחר כך, לא מחסום טכני לפני הקריאה.
DLP כללי: בדרך כלל בודק תעבורה כדי לזהות או לחסום דפוס; הוא לא כותב מחדש את המטען, כך שאם הבקשה עוברת, הספק רואה את התוכן הגולמי.
regex תוצרת בית: רק מה שה-regex באמת תופס מוסר לפני השליחה; כל מה שהדפוס מפספס מגיע לספק גולמי.

האם המודל עדיין מקבל הקשר שימושי?

zer0pii (שער מיסוך): כן - ממלאי המקום שומרים על מבנה המשפט וסוג הישות, ומשוחזרים בתשובה, כך שהמודל מנמק על אותה צורת טקסט.מקור: apps/gateway/core/reconstitutor.py
בקרות נתונים בצד הספק: כן, תמיד - מכיוון שהמודל מקבל את הטקסט ללא שינוי.
DLP כללי: לא רלוונטי באותו מובן - כלי חסימה/התראה לא כותב מחדש את המטען, כך שההקשר נוכח במלואו (מותר) או שהבקשה לא ממשיכה כלל (נחסמה).
regex תוצרת בית: תלוי בהחלפה שנבחרה; regex גס של מצא-ומחק יכול להסיר מילים שהמודל היה צריך, או להשאיר פערים שנקראים מוזר.

שמות, ארגונים, מקומות (ישויות תלויות הקשר)

zer0pii (שער מיסוך): השכבה הסמנטית (NER) תופסת אותן כשהיא מופעלת; ה-recall הנמדד משתנה לפי ישות ושפה, ואינו מושלם.מקור: docs/DETECTION-EVAL.md (שכבה סמנטית 2: PERSON 76.2%, LOCATION 86.8%, ORGANIZATION 51.4% על מדגם של 1,500 שורות)
בקרות נתונים בצד הספק: לא מטופל כלל בגישה הזו - היא לא מזהה או מסתירה דבר, מכיוון שהיא רק קובעת מה הספק עושה עם מה שהוא מקבל.
DLP כללי: חלש בקטגוריה הזו מעצם התכנון: ספריות דפוסים של DLP בנויות סביב מזהים מובנים (מספרי כרטיסים, פורמטים של תעודות זהות), לא שמות או ארגונים בטקסט חופשי, שאין להם צורה קבועה להתאמה.
regex תוצרת בית: כמעט חסר יכולת לתפוס את אלה באופן אמין - לשם או למקום אין דפוס קבוע, כך ש-regex או מפספס את רובם או תופס יתר על המידה מילים נפוצות.

מזהים עם ביקורת תקפה (כרטיסים, תעודות זהות, IBAN)

zer0pii (שער מיסוך): השכבה הדטרמיניסטית מאמתת מזהים מובנים מול ביקורת (Luhn, mod-97 וכו') לפני שהיא מתייחסת להתאמה כאמיתית.מקור: apps/gateway/core/deterministic.py; docs/DETECTION-EVAL.md (למשל IBAN עם recall של 99.92% מול הזהב)
בקרות נתונים בצד הספק: לא מטופל - זו יכולת זיהוי שאין לבקרה בצד הספק.
DLP כללי: לעיתים קרובות נתמך - אימות ביקורת עבור פורמטים נפוצים של מזהים הוא תכונה סטנדרטית בספריות דפוסים של DLP.
regex תוצרת בית: אפשר לכתוב ידנית, אבל כל אלגוריתם ביקורת הוא משטח באגים משלו, והכיסוי מלא רק כמו המזהים שמישהו חשב להוסיף.

תשובות בזרימה (streaming) משוחזרות נכון?

zer0pii (שער מיסוך): כן - מרכיב שחזור ייעודי מטפל בגבולות טוקן שמפצלים ממלא-מקום על פני קטעי SSE שרירותיים, בלי לאגור את כל התשובה.מקור: apps/gateway/core/reconstitutor.py (StreamReconstitutor)
בקרות נתונים בצד הספק: לא רלוונטי - שום דבר לא הוסתר, אז אין מה לשחזר בזרימה.
DLP כללי: לא רלוונטי לזרימות תשובה של מודל שפה באותו אופן שהוא רלוונטי לתעבורת רשת; רוב כלי ה-DLP מכוונים להעברת קבצים ודוא"ל, לא לפלט מודל טוקן-אחר-טוקן.
regex תוצרת בית: קשה לבצע נכון - סריקה-והחלפה ביתית מעל זרימה צריכה לטפל בהתאמה שמתפצלת על פני שני קטעים, וקל לפספס וקל לטעות בעדינות.

בלוקי קוד נשארים שלמים?

zer0pii (שער מיסוך): כן בעיצוב - בלוקי קוד ב-markdown, שמות משתנים, שמות חבילות ותחביר AST מוחרגים ממיסוך אלא אם אושר כפרטי גישה מקודדים בקוד.מקור: CLAUDE.md (עיקרון ליבה 4, חוסן קוד); apps/gateway/core/ast_filter.py
בקרות נתונים בצד הספק: לא רלוונטי - שום דבר לא נכתב מחדש, אז קוד אף פעם לא בסיכון להשחתה מהעברת הסתרה.
DLP כללי: תלוי בכלי; סורק דפוסים שלא נכתב לקוד מקור עלול לסמן או לפגוע במחרוזות דומות (קבוע הקסדצימלי, נתון בדיקה שנראה מזויף) בתוך הקוד.
regex תוצרת בית: סיכון אמיתי - regex כללי המכוון לפרוזה לעיתים קרובות יתאים בתוך קוד (מזהה UUID, קבוע בדיקה שנראה כמו מספר טלפון) וישבור אותו.

הוכחה למה שקרה (קבלות חתומות)?

zer0pii (שער מיסוך): כן - כל בקשה מקבלת אישור עם חתימת Ed25519 מעל hash של המטענים הגולמי והמסונן, שניתן לאמת באופן עצמאי מ-zer0pii.מקור: apps/gateway/core/attestation.py (Attestor.sign, verify)
בקרות נתונים בצד הספק: רק מה שיומני הספק או דוחות הציות שלו מציינים; הוכחה קריפטוגרפית עצמאית לכל בקשה אינה תכונה סטנדרטית בגישה הזו.
DLP כללי: בדרך כלל רשומת יומן פנימית בקונסולה של ספק ה-DLP עצמו, לא תוצר נייד וניתן לאימות עצמאי.
regex תוצרת בית: אין, אלא אם מישהו בונה זאת - לסקריפט ביתי אין שכבת אישור אלא אם היא נוספת במכוון.

עלות זמן תגובה

zer0pii (שער מיסוך): נתיב דטרמיניסטי בלבד: p50 מתחת ל-10ms, p99 מתחת ל-20ms. נתיב סמנטי (NER): p50 מתחת ל-300ms לעמוד מודבק מלא, וחוזר לנתיב הדטרמיניסטי אם עומד לחרוג מהתקציב הזה.מקור: CLAUDE.md (תקציב זמן תגובה, לפי נתיב)
בקרות נתונים בצד הספק: שום עלות מעבר לזמן התגובה של הספק עצמו - אין שלב סריקה נפרד לפני הקריאה.
DLP כללי: משתנה לפי פריסה (בדיקת רשת מוטבעת מוסיפה זמן, ניטור מחוץ לנתיב לא מוסיף כלום לבקשה עצמה), אבל זה לא מספר שהעמוד הזה יכול לקבוע בלי מוצר ספציפי בראש.
regex תוצרת בית: תלוי לגמרי במימוש; קבוצת regex גדולה ונאיבית שרצה על כל בקשה יכולה להיות איטית, אבל אין מספר קבוע, מכיוון שזה תלוי בקוד שמישהו כותב.

מאמץ הגדרה

zer0pii (שער מיסוך): הפנו את כתובת הבסיס של ה-SDK לשער והוסיפו את מפתח ה-API - צורת הבקשה/תשובה נשארת זהה מעבר לכך.מקור: apps/web (עמודי אינטגרציות/תיעוד: דפוס החלפת כתובת בסיס + כותרת)
בקרות נתונים בצד הספק: בדרך כלל שינוי חוזה או שכבת חשבון (תנאים ארגוניים, נספח עיבוד נתונים) ולא שינוי קוד.
DLP כללי: בדרך כלל פריסת תשתית: סוכן, פרוקסי, או האזנת רשת, בתוספת כתיבת מדיניות - שטח תפעולי גדול יותר משינוי בצד הלקוח.
regex תוצרת בית: מהיר להתחיל, מכיוון שזה רק סקריפט - אבל כל סוג ישות, מקרה קצה וביקורת חייבים להיכתב ולתחזק ידנית.

מה שהיא לא מכסה

zer0pii (שער מיסוך): recall של PASSWORD הוא 47.96% (מחרוזות חסרות הקשר מעצם טבען) ו-recall של PHONENUMBER הוא 84.41% על הערכת הזהב; השכבה הסמנטית יורדת לדטרמיניסטי-בלבד כשהיא עומדת לחרוג מתקציב זמן התגובה שלה; ומצב מושב מנוי של Cursor ו-Claude Code אינם ניתנים לכיסוי (אין דריסת כתובת-בסיס / אין מפתח לפרוקסי במושב מנוי).מקור: docs/DETECTION-EVAL.md (שורות 64-65); CLAUDE.md (חזרה דטרמיניסטית של תקציב זמן התגובה); תיעוד: כלי פיתוח (dev-tools.md)
בקרות נתונים בצד הספק: לא מזהה ולא מסתיר דבר כלל - זו מדיניות לגבי הטיפול של הספק במה שהוא מקבל, לא בקרה טכנית על הנתונים עצמם.
DLP כללי: ישויות בטקסט חופשי, תלויות הקשר (שמות, ארגונים, כתובות) ללא צורה קבועה להתאמה; גם בדרך כלל לא מיועד לפלט זרימה ברמת טוקן של מודל שפה.
regex תוצרת בית: כל מה שהמחבר לא צפה - פורמטים חדשים, אזורים חדשים, זרימה, אימות ביקורת ובטיחות קוד הם כולם בעיות נפרדות שגישת regex בלבד לא פותרת מעצמה.

מקור: docs/DETECTION-EVAL.md, apps/gateway/core/pipeline.py, apps/gateway/core/reconstitutor.py, apps/gateway/core/deterministic.py, apps/gateway/core/attestation.py, apps/gateway/core/ast_filter.py, CLAUDE.md

מתי לא לבחור ב-zer0pii

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