אבטחת ChatGPT בארגון ופרוטוקול ZTDS: למה הגדרות פרטיות ב-API לא מונעות דליפות ואיך להגן על נתונים רגישים

אשליית הפרטיות של ממשקי AI ארגוניים#

בשנתיים האחרונות, צוותי מכירות של ספקיות AI בינלאומיות משווקים נרטיב מרגיע להנהלות חברות: *"שדרגו לחשבון Enterprise או השתמשו ב-API, והמידע שלכם מוגן ובטוח לחלוטין."*

מנכ"לים, מנהלי מערכות מידע ומחלקות משפטיות חותמים על חוזים משמעותיים בהנחה שההבטחה "אנחנו לא מאמנים את המודל על הנתונים שלכם" מספקת הגנה מלאה מפני דליפות מידע ותביעות רגולטוריות.

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

בחינה טכנולוגית של אופן פעולת ה-API של מודלי שפה חושפת שלוש פרצות מובנות: 1. מעבר נתונים גלוי ברשת (Cleartext Transit): פרומפטים המכילים שמות לקוחות, נתונים פיננסיים, מספרי ת"ז וקוד מקור נשלחים כטקסט ברור דרך פרוטוקול TLS לשרתי הספק. 2. פענוח בשרת היעד: השרת של ספק ה-AI מפענח את המידע לתוך זיכרון כרטיסי ה-GPU כדי להפיק תשובה. 3. יומני ניטור ושימור מידע למשך 30 יום: ברירת המחדל של ספקיות ה-AI היא שמירת כלל הפרומפטים ביומני ניטור (Logs) למשך 30 יום לצורכי בקרה, אלא אם הופעל תהליך חריג ומאושר של אפס שמירת מידע (Zero Data Retention).

מעבדי משנה והחשיפה המשפטית ב-GDPR ובתיקון 13#

ברגע שמידע אישי נשלח ל-API של ספק AI חיצוני, הספק מוגדר כמעבד משנה (Subprocessor): - נדרש משא ומתן משפטי ממושך על הסכמי DPA מורכבים. - הארגון שלכם נושא באחריות משותפת במקרה של פריצה אצל הספק. - העברת המידע לשרתים בארה"ב דורשת תסקירי העברת מידע חוצה גבולות.

┌────────────────────────────────────────────────────────────────────────┐
│               השוואת גישות: API מסחרי מול פרוטוקול ZTDS                │
├──────────────────────────┬──────────────────────┬──────────────────────┤
│ פרמטר טכנולוגי           │ חיבור API רגיל       │ פרוטוקול ZTDS        │
├──────────────────────────┼──────────────────────┼──────────────────────┤
│ מעבר מידע ברשת           │ מידע רגיש נשלח גלוי  │ אפס מידע מזהה ברשת   │
│ אחריות מעבדי משנה        │ מחייב הסכמי DPA      │ פטור מלא (Zero-DPA)  │
│ חשיפה ביומני ניטור       │ מידע נשמר ב-Logs     │ רק טוקנים אנונימיים  │
│ ביצוע טוקניזציה          │ אין                  │ ב-RAM מקומי (פחות מ-5ms)│
│ הגנה מפני פריצה לספק     │ המידע חשוף           │ מוגן מתמטית לחלוטין  │
└──────────────────────────┴──────────────────────┴──────────────────────┘

כיצד פרוטוקול ZTDS מחסל את זליגת הנתונים ברמת המכשיר#

פרוטוקול ZTDS (Zero-Trust Data Sanitization) הופך את המשוואה: במקום לסמוך על הספק החיצוני שישמור על המידע, המערכת מבטיחה שהספק לעולם לא יקבל את המידע הרגיש מלכתחילה.

תהליך החיטוי פועל בתוך פחות מ-5 אלפיות השנייה במכשיר המקומי: 1. זיהוי תבניות וישויות מקומי: מנוע regex מקומי סורק את הטקסט ומאתר תעודות זהות, מספרי טלפון, כתובות מייל ומפתחות API. 2. החלפה בטוקנים סמנטיים: נתונים מוחלפים בתוויות כדוגמת [ISRAEL_ID_TOKEN_1] או [EMAIL_TOKEN_1]. 3. כספת זיכרון נדיף (RAM Vault): טבלת התרגום שמורה אך ורק בזיכרון המקומי הנדיף. היא לעולם אינה נשמרת בדיסק או נשלחת לענן. 4. שחזור מקומי (Re-hydration): עם קבלת התשובה מה-LLM, הרכיב המקומי משחזר את הנתונים המקוריים לתצוגת המשתמש בלבד.

3 שלבים להטמעת ZTDS בארגון#

1. 1
   אבחון מיידי של הפרומפטים שלכם:
2. 2
   התנסו ב-סורק דליפות המידע ב-AI כדי לראות כיצד פרומפטים ארגוניים עוברים טוקניזציה מדויקת.
3. 3
   הטמעת רכיבי סינון מקומיים:
4. 4
   שילוב ספריות ה-SDK בסביבות הפיתוח, מערכות ה-CRM וצ'אטים פנימיים.
5. 5
   ביצוע ביקורת הסמכה:
6. 6
   פנו לצוות BrandMeWeb להזמנת ביקורת תאימות ופרטיות AI וקבלת תזכיר Zero-DPA להנהלה.

שאלות נפוצות (FAQ)#

האם החלפת מידע בטוקנים פוגעת באיכות התשובות של מודל השפה? לא. היות ו-ZTDS משתמש בטוקנים בעלי משמעות סמנטית (כמו `[ISRAEL_ID_TOKEN_1]`), המודל מבין במדויק את התפקיד הדקדוקי של כל ישות ומפיק תשובה באיכות זהה לחלוטין.

כיצד המערכת מטפלת בתעודות זהות ישראליות ובטקסט בעברית? המנוע כולל אלגוריתם אימות מלא לתעודות זהות ישראליות (ספרת ביקורת לפי אלגוריתם לוהן), זיהוי קידומות סלולר ישראליות ותמיכה מושלמת בטקסט דו-כיווני (RTL) ללא עיוותים.

האם ניתן להריץ את ZTDS ללא חיבור לאינטרנט? כן, ב-100%. מנוע החיטוי פועל בזיכרון המקומי במכשיר. ניתן להפעיל מצב טיסה (Airplane Mode) ולראות שהחיטוי מתבצע במלואו ללא שידור אפילו פאקט אחד לרשת.