זוהי תרגום מכונה של המסמך המקורי באנגלית. במקרה של סתירה בין תרגום זה לבין הגרסה המקורית באנגלית, הגרסה באנגלית היא הקובעת. קרא את הגרסה המקורית באנגלית
אנונימיזציה (Pseudonymizer) מקומית על המכשיר: פיתוח ומבחני ביצועים
2026-05-22 · Caiioo Team
רצינו לפתור את בעיית הפרטיות של מערכות AI המתאמנות על מידע אישי מזהה ושומרות אותו. מדיניות והסכמים של "אפס שמירת נתונים" (Zero Data Retention) מפחיתים סיכונים, אך הם רצופים בחריגים. הם אומרים בעצם: "לא נשמור אף אחת מההנחיות או הפלטים שלכם למעט: (הכנס רשימה ארוכה של חריגים כאן: צרכי אבטחה, פיקוח ממשלתי, הליכים משפטיים, פיתוח מוצר, יומני שגיאות, שיפור השירותים...)"
כדי לפתור זאת, בנינו מסנן נתונים אישיים הרץ על המחשב של המשתמש עצמו, רואה את ההודעה לפני שהיא עוזבת את המכשיר, ומחזיר את אותה תשובה שהמשתמש היה מקבל אילו ההודעה הייתה נכתבת ללא מסנן כלל.
אז בנינו אחד כזה. הגרסה הבאה של Caiioo תכלול את ה-Pseudonymizer. הוא יהיה נגיש דרך אייקון המגן בצ'אט הסוכן וגם בהגדרות.
מסמך זה (white paper) מפרט את הרציונל, הארכיטקטורה, תהליך ההערכה ועקרונות העיצוב שמאחורי מערכת סינון הפרטיות שלנו.
מה שהצבנו לעצמנו כמטרה
הגנה כללית על הפרטיות באמצעות מזעור נתונים. כאשר משתמש משוחח עם מודל מרוחק, המודל אינו זקוק לשם אמיתי, כתובת מגורים, אימייל אמיתי או מספר טלפון של לקוח כדי לענות על שאלת המשתמש. הוא זקוק ל_צורה_ של השאלה, והוא צריך שהיא תיראה כמו שאלה אמיתית כדי שה-LLM לא יבטל את השאילתה כבדיקה. לכן, המסנן מסיר מזהים אמיתיים מהנתונים שנשלחים ל-AI ותופר את הערכים האמיתיים בחזרה בדרך חזור. המודל רואה שמות ומזהים סינתטיים; המשתמש רואה את השיחה האמיתית.
סיוע בעמידה בתקני HIPAA. מצב שני מתמקד ב-18 המזהים בכלל ה-Safe Harbor של HIPAA (§164.514) ובגרסת ה-Limited Data Set המקלה יותר. קלינאי, מנהל במערכת הבריאות, או כל מי שעובד על תהליך עבודה מכוסה (covered workflow) יכול לדבר עם מודל לשימוש כללי על מקרים אמיתיים מבלי לשלוח מידע בריאותי מוגן (PHI) ל-AI. אנחנו לא קציני הציות של הישות המכוסה — אך אנחנו יכולים להיות השכבה שמונעת מה-PHI לעזוב את הלפטופ מלכתחילה. ההערכות שלנו מספקות מדדים מדידים שארגונים יכולים להשתמש בהם כדי להעריך את התאמת המסנן לתקני הציות והפרטיות שלהם. כל אמצעי הפרטיות והאבטחה הם החלטות שבשיקול דעת הנמצאות באחריות המשתמש או הישות המשתמשת.
בחרנו בשניהם מכיוון שההנדסה היא זהה, ומקרה הבוחן של PHI הוא למעשה קל יותר מבחינה טכנית בשל השימוש בישויות בעלות שם מובחנות, שקל יותר להסתיר מאשר את הנתונים הכלליים יותר בקטגוריית הנתונים האישיים. סינון HIPAA נעזר גם בעובדה שהוא מתבצע בדרך כלל באנגלית או בספרדית. אנו מזהים מזהים, מחליפים אותם בפסאודונימים יציבים ובמזהים חלופיים באותו פורמט, משחזרים אותם בדרך חזור, ולעולם לא מתעדים (log) את הערכים האמיתיים. המיפוי בין המידע הסינתטי למידע האמיתי נשאר רק במכשיר של המשתמש, כך שהמשתמש יכול לקרוא מידע אמיתי בתגובות הסוכן. רשימת הקטגוריות ושער המדיניות הם הדברים שמשתנים בין המצבים.
מדוע regex בשילוב עם למידת מכונה, ולא רק אחד מהם
ישנן שתי טכנולוגיות סינון עיקריות במערכת ה-pseudonymizer שלנו: שפת זיהוי תבניות דטרמיניסטית הנקראת regex, ומודלים מאומנים של למידת מכונה.
Regex הוא בלתי מנוצח בפורמטים שטחיים. לכתובת אימייל יש צורה ([email protected]). כך גם ל-IP, כרטיס אשראי, IBAN, VIN, SSN (XXX-XX-XXXX), ומפתח API. אם הפורמט אמין, ה-regex תופס אותו באופן דטרמיניסטי, בכל פעם, ללא עומס על המודל וללא עלות inference.
עם זאת, regex הוא חסר סיכוי בכל הנוגע להקשר (context). המשפט "הגרף של שרה מיום שלישי האחרון" מכיל שם אדם ותאריך, אך לא ניתן להבחין באף אחד מהם על סמך הפורמט שלו בלבד. "המטופל ברחוב Elm 14" מכיל כתובת שחופפת לאלף מקרים שאינם כתובות. המשפט "ה-MRN שלהם הוא 7741032" זקוק למילים שסביב המספר כדי שתהיה לו משמעות כלשהי.
מודל שפה קטן שעבר fine-tuned מטפל בהקשר — המודל שלנו הוא encoder בעל 110M פרמטרים שאומן במיוחד וזוקק ממודל שפה רב-לשוני זעיר. הוא קורא את המשפט, לא רק את מחרוזת המשנה (substring), והוא קטן מספיק כדי לרוץ במהירות קיצונית על מכשיר קצה, אפילו על טלפון נייד.
מבחני הביצועים (benchmarks) ממחישים את החוזקות המשלימות של שתי השכבות. בחנו את שתי השכבות בנפרד כדי לוודא שכל אחת מהן אכן תורמת את חלקה. בערכת השאלות PrivacyBench-PD הכוללת 150 שאלות, שבהן השאלות והתשובות במפורש לא שימשו לאימון המודל:
| שכבה | PII שנתפסו | שיעור תפיסה |
|---|---|---|
| Regex בלבד | 205 / 670 | 30.6 % |
| ML בלבד | 516 / 670 | 77.0 % |
| שניהם (production) | 625 / 670 | 93.3 % |
Regex לבדו מחמיץ שלושה רבעים מהמזהים מכיוון שרוב המזהים בטקסט חופשי אינם מובנים (structured). ML לבדו מחמיץ 16 נקודות אחוז ששכבת ה-regex הייתה תופסת — דברים שהם נטו הצורה שלהם (כרטיס אשראי נראה כמו כרטיס אשראי; למודל אין אות נוסף להוסיף). יחד הם מכסים את מה שאף אחד מהם לא מכסה לבדו.
במבט מעמיק יותר על המקומות שבהם כל שכבה היא מכרעת: לאורך אותה קבוצת בדיקה, 16 ערכי בדיקה נתפסו רק על ידי regex (אימיילים, כתובות IP, חשבונות פיננסיים, מזהים מובנים) ו-327 נתפסו רק על ידי ML (שמות, מזהים תלויי הקשר, ניסוחים רב-לשוניים).
קטן, חכם, מהיר — ורץ בכל מקום
היינו חייבים לגרום למסנן לרוץ על המכשיר, מה שהיה אתגר הנדסי.
הוא חייב להיות קטן כי האפליקציה שלנו רצה על המכשיר במערכות רבות: בתוך תוסף לדפדפן, אפליקציית macOS, אפליקציית iOS, אפליקציית Android, או Windows ו-Linux. החבילה היא בערך 113 MB למודל. ישנם שני מודלים — אחד לנתונים אישיים כלליים, ואחד למידע בריאותי מוגן — ומצב Safe Harbor מריץ את שניהם במקביל. מבין אלו, מכשיר Android חלש הוא בעל הביצועים הנמוכים ביותר, ובכל זאת המערכת שלנו עובדת מצוין.
הוא חייב להיות חכם כי זיהויים חסרים (false negatives) מדליפים נתונים אמיתיים ל-LLM מרוחק, וזיהויים שגויים (false positives) הורסים את השיחה. שמות חייבים לעבור הסוואה; כינויי גוף לא. אימייל של רופא בשרשור שהועבר צריך להיות מוסווה; כותרת תחתונה של [email protected] כנראה לא צריכה.
הוא חייב להיות מהיר כי הוא נמצא ישירות בנתיב של כל הודעה שהמשתמש שולח או מקבל. מדדנו את זמן העיבוד הכולל בפחות מ-200 מילי-שנייה על ליבת CPU בודדת, בעיקר טוקניזציה (tokenization). ב-WebGPU וב-Neural Engine של Apple זהו זמן זניח לעומת השהיית הרשת של קריאת ה-LLM עצמה.
הוא חייב לרוץ בסביבות הרצה מרובות כי Caiioo היא רב-פלטפורמתית. אותה מערכת רצה בתוספי Chrome, ב-macOS ו-iOS, ב-Android, וב-Windows ו-Linux. מודל זיהוי אחד, ספריית regex אחת, ממזג אחד, מדיניות אחת — התנהגות זהה בכל ממשק שבו Caiioo פועלת.
הציונים
לאחר סבבים של בדיקות ואימונים, התבססנו על הגרסה ה-16 של המודלים שלנו. להלן שלושה מדדי ביצוע (benchmarks), שכל אחד מהם מודד היבט אחר.
סט הבדיקה העצמי שלנו, 150 שאלות שהמודל מעולם לא ראה
לפני הבדיקה מול מדדי ביצוע ציבוריים, הרצנו את מסנן ה-Personal Data שלנו מול סט בדיקה פנימי ששמרנו בכוונה מחוץ לנתוני האימון — כך שהגלאי מעולם לא ראה אף אחת מהשאלות הללו לפני כן. 150 שאלות המחולקות לארבע קבוצות (קטעי קוד, פרוזה של מסמכים, ניסוחים לא מוכרים בכוונה, ו-10 שפות שאינן אנגלית), בתוספת קבוצה "שלילית" שאינה מכילה נתונים פרטיים כלל (בדיקת שפיות כדי לוודא שאיננו מבצעים צנזור-יתר). צינור עיבוד (pipeline) משולב של regex + ML:
| תת-מדד | נתפסו | שיעור |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| כל 4 המדדים החיוביים | 625 / 670 | 93.3 % |
(הקבוצה השלילית לא הכילה נתונים פרטיים לאיתור. המסנן הסתיר דבר אחד שלא היה צריך — מה שמתיישב עם נתוני הדיוק (precision) בהמשך.)
הבודק (grader) מחמיר: כל פיסת מידע פרטי מצופה חייבת להיעלם לחלוטין מהפלט המוסתר כדי שהשאלה תקבל ניקוד. אין ניקוד חלקי, ואין "קרוב מספיק". זה מחמיר יותר ממדדי ביצוע המבקשים מ-LLM אחר לשמש כשופט (שופטי LLM נוטים להיות נדיבים). למספרים הניתנים להשוואה ישירה מול מערכות אחרות, ראו את סעיף ההשוואה ראש-בראש בהמשך.
PrivacyBenchHIPAA — 40 שאלות בתחום הבריאות
כל שאלה מפרטת מידע בריאותי מוגן שיש לצנזר (שמות, מספרי תיקים רפואיים וכו') וגם סימנים שיש להשאיר (תאריכים, גיאוגרפיה, גיל אם מתחת ל-90 — כלל ה-HIPAA Limited Data Set). הבודק בודק את שני הכיוונים: האם הסרנו את מה שהיינו צריכים להסיר, והאם השארנו ללא שינוי את מה שהיינו צריכים להשאיר?
| מצב | PHI צונזר | נתונים לשימור נשמרו |
|---|---|---|
| Limited Data Set (שימור תאריכים / גיאוגרפיה / גיל ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (צנזור הכל כולל תאריכים) | 99 / 104 (95.2 %) | — |
תת-מצב ה-Limited Data Set מושלם במדד ביצוע זה. Safe Harbor — שבו יש יותר לצנזר, ולכן יותר הזדמנויות לפספוסים — מכסה 95.2%.
תוצאות לפי קטגוריה על הנתונים שלנו, 200 דגימות לכל מצב
מדדי ביצוע ציבוריים מקבצים הכל יחד. נתוני הבדיקה הפנימיים שלנו מפרטים תוצאות לפי קטגוריה (שמות, אימיילים, כתובות וכן הלאה) ומריצים כל אחת בשלוש דרכים: regex בלבד, ML בלבד, ושניהם יחד. זה אומר לנו בדיוק איזו טכנולוגיה תופסת איזה סוג של מזהה — ואיפה כל אחת זקוקה לשנייה. הרצה אחרונה, 2026-05-20:
סיכום על פני כל שלושת מצבי המסנן
| מצב | Combined recall | Precision | F2 | דגימות |
|---|---|---|---|---|
| מסנן Personal Data | 97.3 % | 97.8 % | 97.4 | 200 |
| מסנן HIPAA — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| מסנן HIPAA — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
מספרים אלו אינם כוללים כתובות URL, אותן אנו משאירים ללא שינוי בכוונה — פגיעה ב-URL תשבור פעולות המשך כמו "פתח קישור זה" או "אחזר דף זה". עוד על כך בסעיף זרימת העבודה (workflow) להלן.
התמונה הגדולה לפני טבלאות הקטגוריות: בכל מצב, המזהים שבאמת מזהים אדם נתפסים ב-100% מהזמן או קרוב לכך. שמות, אימיילים, מספרי טלפון, כתובות דואר, תעודות מזהות ממשלתיות, מזהים ביומטריים, מיקום גיאוגרפי מדויק, מספרי תיקים רפואיים, תאריכי לידה, מספרי ביטוח לאומי — נתפסו בכל דגימה, בכל בדיקה. הקטגוריות שבהן אנו יורדים מתחת ל-100% הן צפויות: מזהי מכשירים (מגוון עצום של פורמטים בטקסט אמיתי), מזהים מוסדיים שונים (מספרי מועדון לקוחות, מזהי עובד — אותה בעיה), ותמונות (מסנן טקסט בלבד לא יכול לראות מה יש בתוך תמונה). אף אחד מאלה אינו המזהה מסוג "שם על גיליון רפואי" או "אימייל בטיוטה" שבאמת משנה לעניין דליפה. הקטגוריות בעלות הסיכון הגבוה הן האמינות ביותר.
מסנן Personal Data
ממוין לפי combined recall (הטוב ביותר תחילה), ולאחר מכן לפי דרגת סיכון (T1 = הרגיש ביותר).
| קטגוריה | דרגה | Regex recall | ML recall (raw) | Combined recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
בקריאה רוחבית, העיצוב הדו-שכבתי משתלם. כתובות דואר, תאריכי לידה ושמות אנשים מקבלים ציון של 0–13% תחת regex בלבד — אין תבנית להתאמה, ולכן רק מודל ה-ML יכול לתפוס אותם. אימיילים, מספרי טלפון, כתובות IP, תעודות מזהות ממשלתיות, מזהים ביומטריים ומיקום גיאוגרפי מדויק מקבלים 100% תחת regex בלבד — פורמטים שטחיים שמודל ה-ML מקבל "בחינם". כינויים מקוונים, מזהי רכב וסודות אימות הם מעורבים: regex תופס את הצורות הסטנדרטיות, ML תופס את השאר. ה-combined recall עומד בביצועים של השכבה החזקה יותר או עולה עליהם, בכל קטגוריה.
מזהי מכשירים ומזהים מוסדיים שונים הם הקטגוריות שמתחת ל-100%, ואנחנו יודעים למה: לאלו יש את המגוון הרחב ביותר של פורמטים בטקסט אמיתי. אנו מעדיפים להיות כנים לגבי הקטגוריות שבהן ה-recall יורד מאשר להעמיד פנים שהמסנן מושלם בכל מקום.
מסנן HIPAA — תת-מצב Limited Data Set
תת-מצב ה-Limited Data Set משמר תאריכים, גיאוגרפיה וגילאים של 89 ומטה לפי התכנון — אלו הם הסימנים ש-HIPAA מאפשר לארגון לשמור לצורכי מחקר קליני ותפעול לגיטימיים.
| קטגוריה | דרגה | Regex recall | ML recall (raw) | Combined recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
תמונות הן פספוס ידוע — מסנן טקסט בלבד לא יכול לראות מה יש בתוך תמונה. PHI בתמונות היא בעיה נפרדת שטרם שחררנו. כל קטגוריה אחרת במצב זה עומדת על 100%.
מסנן HIPAA — תת-מצב Safe Harbor
Safe Harbor מסיר את כל מה שתת-מצב ה-Limited Data Set היה משאיר — תאריכים, גילאים מעל 89, גיאוגרפיה. כדי לקבל את הכיסוי המחמיר ביותר, הוא מריץ את שני מודלי המסננים במקביל: זה הספציפי ל-HIPAA וזה הכללי לנתונים אישיים.
| קטגוריה | דרגה | Regex recall | ML recall (raw) | Combined recall | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
שתי השורות המעניינות הן תאריכים כלליים (regex 100%, ML 30%) וגילאים מעל 89 (regex 100%, ML 0%). אנו נותנים ל-regex לטפל בשניהם ב-Safe Harbor בכוונה: לתאריכים יש צורה ש-regex תופס בכל פעם, ואיננו רוצים שמודל הסתברותי ינחש סף מספרי כמו "89<". כלל דטרמיניסטי אמין יותר מאשר לבקש ממודל ה-ML ללמוד את אותו הכלל.
מספרים כוללים בכל הקטגוריות
בסיכום הכל: איך צינור העיבוד המלא (regex + ML יחד) משתווה לכל שכבה לבדה?
| מצב | שכבות | Recall | Precision | F2 |
|---|---|---|---|---|
| Personal Data | regex בלבד | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | ML בלבד | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | שניהם (מלא) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | regex בלבד | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | ML בלבד | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | שניהם (מלא) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | regex בלבד | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | ML בלבד | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | שניהם (מלא) | 92.4 % | 88.9 % | 91.7 % |
שורת ה-"מלא" של מסנן ה-Personal Data מנצחת את שתי גרסאות השכבה הבודדת בכל מדד — שילוב של regex (עבור פורמטים שטחיים) עם מודל ה-ML (עבור הקשר) מספק באמת משהו שאף שכבה לבדה אינה יכולה לספק. הכותרת של 97.3% מוקדם יותר בפוסט זה היא המספר שמשקף את מה שמשתמש אמיתי מקבל. המספר בטבלה לעיל נמוך מעט רק בגלל שהוא כולל את קטגוריית ה-URL, אותה אנו משמרים בכוונה כדי לא לשבור קישורים וקריאות לכלים (tool calls).
ראש-בראש מול מסנני פרטיות ייעודיים אחרים
ההשוואה ההוגנת עבור מסנן פרטיות הפועל על המכשיר (on-device) וכמעט מיידי כמו שלנו היא מול מסנני פרטיות אחרים הפועלים על המכשיר וכמעט מיידיים — לא מול מודלי LLM ענקיים המתארחים בענן שלוקח להם שניות לכל הודעה וזקוקים לסבב תקשורת ברשת. הרצנו כל מערכת בקטגוריה זו מול אותם סטים של בדיקות, תוך שימוש באותם כללי התאמה. אותו סטנדרט לכולם.
קבוצת השווים:
- openai/privacy-filter — מסנן הפרטיות הייעודי בקוד פתוח של OpenAI. כ-50 מיליון פרמטרים, קטן מספיק כדי לרוץ בכל דפדפן מודרני.
- piiranha-v1 — גלאי בעל 278 מיליון פרמטרים מבית iiiorg. הרישיון שלו מגביל אותו למחקר והערכה בלבד (אנחנו יכולים למדוד אותו, אך לא ניתן לשלוח אותו מסחרית).
- Microsoft Presidio — כלי הצנזור בקוד פתוח הנפוץ ביותר, המשלב התאמת תבניות מסורתית עם מודל שפה קטן להקשר.
- משפחת GLiNER PII — משפחה של מסווגי ישויות קטנים לשימוש כללי. Knowledgator מפיצה גרסאות small (~44M), base (~86M), ו-large (~304M); NVIDIA שחררה גרסת 570M באוקטובר 2025.
- Caiioo בכל שלושת המצבים (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall על פני כל חמשת סטי הבדיקה, ממוין כש-Caiioo ראשון:
| מערכת | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 locales) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo מוביל את קטגוריית המסננים הייעודיים בשתי הבדיקות הגדולות ביותר (PD-200 ו-PHI-200), משתווה או מוביל במדדי הביצוע הציבוריים, ונמצא במקום השני ברב-לשוניות. בבדיקה הקטנה ביותר (PrivacyBench PD-25, רק 25 שאלות) Caiioo ו-openai/privacy-filter משתווים ב-96.2%. ברב-לשוניות, openai/privacy-filter עדיין מוביל ב-94.9% כש-Caiioo ב-92.6% — השפה שבה אנו מפגרים הכי הרבה היא סינית; בכל מקום אחר אנו נמצאים בראש או קרוב אליו. אם כיסוי רב-לשוני הוא קריטי למשימה, openai/privacy-filter הוא חלופה סבירה. עבור רוב עומסי העבודה האחרים בקטגוריה זו, Caiioo הוא הבחירה.
תוצאת ה-HIPAA היא הכותרת. שני מצבי ה-HIPAA של Caiioo הגיעו ל-100% recall בכל בדיקת HIPAA — כל שם מטופל, כל מספר תיק רפואי, כל תאריך לידה, כל מספר חשבון נתפסו. המערכת השנייה בטיבה היא openai/privacy-filter עם 93.7% ב-PrivacyBenchHIPAA — פער של 6.3 נקודות, במדד ביצוע שבו כל פספוס הוא חשיפה בעולם האמיתי.
מספר שני ששווה לקרוא: צנזור-יתר (over-redaction) — הסתרת דברים שלא היו באמת נתונים פרטיים. צנזור-יתר אינו נזק לפרטיות, הוא עלות שימושיות. הסתירו יותר מדי דברים והסקת המסקנות של ה-LLM תהיה גרועה יותר, והתשובה המוחזרת תהיה פחותה בערכה. Caiioo מסתיר שלא לצורך 1–24 פעמים על פני סטי הבדיקה. Presidio: 10–51. ה-GLiNER של NVIDIA: 31–64 בבדיקות ה-HIPAA לבדן. דיוק (precision) חשוב לא פחות מ-recall כאשר המטרה היא התשובה הטובה ביותר האפשרית עם החשיפה המינימלית האפשרית.
מה לגבי שימוש ב-LLM מוביל (frontier) כמסנן?
הם יכולים — וב-recall גולמי, הם מנצחים. מודלי LLM גדולים לשימוש כללי (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B ודומיהם), הרצים בענן או מקומית, יכולים לקבל ציון של 95–100% בכל בדיקה כולל רב-לשוניות. זוהי אפשרות ריאלית עבור משתמשים הזקוקים ל-recall מקסימלי ומוכנים לשלם על כך.
עם זאת, החסרונות הם ממשיים:
- זה איטי. שניות לכל הודעה במקום מילי-שניות. המסנן יושב לפני כל הודעה שהמשתמש שולח.
- או שההודעה עוזבת את המחשב של המשתמש, או שהמודל עושה זאת. כדי לסנן בענן, ההודעה חייבת לעלות לשם — מה שמחטיא את המטרה. כדי לסנן על המכשיר נדרשת הורדה של מודל בנפח 1–17 GB.
- ניתן להערים עליו. ניתן לשכנע מודל גנרטיבי, באמצע הודעה, לא לצנזר (מתקפת "prompt injection"). גלאי קטן כמו שלנו לא ניתן להטעיה כזו.
- אותו קלט, פלט שונה. מודלים גנרטיביים לא תמיד נותנים את אותה תשובה פעמיים. זה שובר את ה-round-trip — הסתרה בדרך החוצה וחשיפה בדרך חזרה מסתמכות על כך שאותו ערך אמיתי תמיד ימופה לאותו ערך מזויף.
Caiioo נבנה עבור הצד השני של הפשרה הזו: מסנן זעיר, צפוי, הפועל בפחות משנייה ורץ ב-composer לפני שהמשתמש לוחץ על שלח, ותמיד מייצר את אותו זיוף עבור אותו ערך אמיתי בתוך שיחה, כך שה-round-trip נשאר עקבי. טבלת קבוצת השווים לעיל היא ההשוואה הנכונה עבור סוג כזה של מקרה בוחן.
ההוכחה היא בתוצאה
מדדי ביצוע (Benchmarks) הם נקודת התחלה, לא קו סיום. המסנן מוטמע בתוך התכונה החדשה של Caiioo: ה-pseudonymizer — הרכיב שיושב בפועל בין ה-composer לבין המודל.
להלן מה שקורה כאשר המשתמש לוחץ על שליחה.
- זיהוי (Detect). שכבת ה-regex רצה ראשונה — היא דטרמיניסטית ומהירה ברמת המיקרו-שניות. מודל ה-ML רץ לאחר מכן על מה שנותר. אם שתי השכבות חופפות על אותו קטע טקסט, אנו משתמשים בכלל פשוט: ה-regex מנצח בפורמטים שטחיים, ה-ML מנצח בהקשר (context).
- תיוג עצמי מול אחרים. Caiioo מפרידה בין מזהים המתייחסים ל_משתמש_ לבין מזהים המתייחסים לאנשים אחרים. המשתמש יכול לבחור לצנזר רק סוג אחד, או את שניהם. שמות שהמשתמש הוסיף למילון אישי נחשבים תמיד כ"עצמי".
- החלפה (Substitute). כל ערך אמיתי מקבל פסבדונים (שם בדוי) יציב ובעל סגנון תואם. "שרה גולדברג" הופכת ל"מאיה הרטוול" — ונשארת "מאיה הרטוול" לאורך כל השיחה, כך שהסקת המסקנות של המודל לגבי אותו אדם לא תתפצל בין סבבי השיחה. טבלת המרה בין ערכים אמיתיים למזויפים נשמרת על מכשיר המשתמש, מוצפנת באמצעות מפתח מתוך ה-keychain של הפלטפורמה.
- שליחה (Send). המודל מקבל הודעה מזויפת לחלוטין. אף מזהה אמיתי לא חוצה את הרשת, ויומן הביקורת (audit log) שלנו מתעד ספירות בלבד — לעולם לא את הערכים עצמם.
- שחזור (Restore). תגובת ה-streaming ממופה בחזרה ככל שהיא מגיעה. "מאיה הרטוול" בתשובת המודל הופכת ל"שרה גולדברג" לפני שהיא מגיעה למסך, ומוצגת עם "בועת זוהר" קטנה כדי שהמשתמש יוכל לראות במבט חטוף מה היה מוגן.
- שחזור ארגומנטים של כלים. אם המודל קורא לכלי (tool) — שליחת אימייל, פתיחת קריאה, כתיבה למסמך — והארגומנטים מכילים זיופים, אנו מחליפים בחזרה לערכים האמיתיים לפני שהכלי מופעל. המודל מבצע הסקת מסקנות על הזיופים; הפעולה מקבלת את הערך האמיתי.
למסנן לא משנה באיזה שירות AI נעשה שימוש. הוא רץ לפני שההודעה מגיעה למודל, כך ש-OpenRouter, Anthropic, Google, OpenAI ו-Ollama מקומי מקבלים כולם את אותו מטען (payload) מוסתר. הוספת ספק חדש אינה פותחת מחדש את פרצת הפרטיות.
על מי הוא מגן
המשתמש. שמו של המשתמש, האימייל, הכתובת, הטלפון, ה-IP ומזהים ביומטריים — הדברים שביחד מזהים אדם בפני גורם אוסף נתונים — לעולם לא עוזבים את המכשיר כשהמסנן פועל.
האנשים שהמשתמש מדבר עליהם. רוב כלי הפרטיות מתמקדים באדם המקליד, אך הם מתעלמים מ'החוזה החברתי' — העובדה שכולנו חבים באחריות כלפי אחרים כפי שאנו חבים כלפי עצמנו. שליחת הבקשה "אנא נתח את התנהלותו של מר סונדרס בגין חוסר כשירות" ל-LLM, שם היא עשויה להישמר ביומני מערכת ללא הגבלה, היא חסרת אחריות (ועלולה להיות לשון הרע). בקשת עזרה מ-LLM עם Google Sheet המכיל 1,000 אנשי קשר עסקיים מפקידה את כולם בתוך "מלכודת הדבק" של שמירת הנתונים (במידות משתנות, תלוי במידת ה-'zero data retention' בפועל). המסנן של Caiioo מכסה גם צדדים שלישיים: הלקוח שעבורו מנוסח חוזה, המטופל שעל התיק שלו מתבצע ניתוח, הקולגה שהאימייל שלו הודבק לתוך ההקשר. הם לא נתנו הסכמה לכך ש-LLM מרוחק יראה את המזהים שלהם. המסנן מכבד זאת כברירת מחדל; המשתמש יכול לעבור למצב "עצמי בלבד" או "אחרים בלבד" אם זרימת העבודה דורשת זאת.
ישויות — עסקים, בתי חולים, פירמות. מספרי חשבון, מספרי רישיון, מספרי תיקים רפואיים, פרטי ניתוב פיננסיים, מזהים פנימיים, מפתחות API, רשימות לקוחות. לעסק יש את אותו אינטרס של מזעור נתונים שיש לאדם פרטי. קלינאי המשתמש ב-Caiioo כדי לנסח מכתב שחרור אינו שולח את מספר התיק הרפואי של המטופל ל-OpenAI. עורך דין אינו שולח את מספר החשבון של הלקוח ל-Anthropic. מהנדס תמיכה אינו שולח את מפתח ה-API מיומן הלקוח ל-Google. המסנן לא שואל אם המזהה שייך לאדם או לישות — הוא פשוט שומר אותו על המכשיר.
מקסימום תועלת, מינימום חשיפה
כל הפואנטה היא שהמשתמש לא אמור להרגיש את המסנן.
רוב כלי הפרטיות כופים בחירה: הסוואה אגרסיבית וצפייה בתשובת המודל הופכת לגרועה יותר, או שמירה על הנחיה שמישה וצפייה בהבטחת הפרטיות נשחקת. דחינו את הטרייד-אוף הזה. המודל עדיין מקבל הנחיה בנויה במלואה — הוא רואה שם, מקום, תאריך, מספר תיק רפואי, כולם במיקומים הדקדוקיים הנכונים. הוא פשוט רואה מזהים מזויפים. הניתוח שלו זהה; רק המחרוזות מנוקות.
החלפה יציבה (Stable substitution) היא מה שגורם לזה לעבוד. מכיוון שאותו ערך אמיתי תמיד ממופה לאותו ערך מזויף בתוך שיחה — לאורך הודעת המשתמש, תוצאת הכלי שחוזרת ומתייחסת לאותו שם, והתשובה המוקדמת של המודל שהזכירה אותו — למודל יש דמות, מקום או חפץ עקביים לנתח. שיחות מרובות סבבים לא מתבלבלות. קריאות לכלים לא נשברות. סוכני-משנה יורשים את המיפוי של שיחת האב ונשארים עקביים לאורך כל המשימה.
הפלט שהמשתמש רואה הוא השיחה האמיתית. הנתונים שהספק רואה הם פיקציה עקבית. העבודה מתבצעת בפער שבין שתי נקודות המבט הללו, והמטרה — המטרה היחידה — היא להפוך את הפער הזה לבלתי נראה.
מסנן פרטיות שמפריע יכובה בסופו של דבר. מסנן פרטיות שנעלם לתוך זרימת העבודה הוא הסוג היחיד ששווה להפיץ.
זהו הרף שלפיו בנינו.