מינימיזציית נתונים GDPR: ממשק API בזמן אמת
עודכן ל-2026
GDPR סעיף 5(1)(ג) קובע: אספו רק מה שאתם צריכים. זהו כלל מינימיזציית הנתונים. רוב הצוותים מפרים אותו דרך עיצוב טפסים, לא מתוך כוונה רעה. שדות טקסט חופשי מושכים שמות, כתובות ומספרי זיהוי שאיש לא תכנן עליהם.
ניקוי מסד הנתונים מאוחר יותר אינו מתקן זאת. ההפרה התרחשה כאשר אספתם את הנתונים. עצירתה במקור היא התיקון האמיתי היחיד. בדיקת ממשק API בזמן אמת בעת הגשת טופס עוצרת איסוף-יתר לפני שהוא מתחיל.
ראו את סקירת הציות ושיטות האבטחה שלנו לאופן שבו אנו תומכים ב-GDPR סעיף 5.
מדוע טפסים אוספים-יתר
שדות טקסט חופשי באפליקציות אינטרנט אוספים PII שאיש לא תכנן עליו:
- שדות "סיבה" בכרטיסי תמיכה ממולאים בהיסטוריות רפואיות ומספרי ביטוח
- מקטעי "הערות נוספות" בסקרים מכילים שמות מלאים ומספרי טלפון
- עמודות "הערות" ב-HR עם שנים של פרטים אישיים לא מובנים
- שדות "הערות" בהזמנות מכילים מספרי זיהוי לקוח שהוזנו לסיוע בבעיות
כלל המינימיזציה דורש שה-PII הזה לעולם לא ייכנס למערכות שלכם. ניקוי רטרואקטיבי מטפל בתסמינים. זיהוי בזמן אמת מסיר את הסיבה.
מדוע ניקוי רטרואקטיבי אינו מספיק
צוותים המנקים PII מאוחסן עומדים בפני ארבע בעיות.
שלמות. התאמת דפוסים מוצאת PII ברור כגון כתובות אימייל ומספרי זיהוי. היא מחמיצה הפניות מבוססות-הקשר. "לאחות שלי Sophie הייתה אותה בעיה" מכיל שם שרוב הסריקות מדלגות עליו.
עיתוי משפטי. ההפרה מתרחשת באיסוף. ניקוי הנתונים חודשים מאוחר יותר אינו מתקן אותה. אם רגולטור בוחן את התקופה שבה הנתונים הוחזקו, ההפרה כבר ברשומה.
מחיקה לא מלאה. מסדי נתונים עושים גיבויים. מערכות כותבות יומנים. כלי אנליטיקה מייצאים נתונים. אפילו לאחר מחיקה ממסד הנתונים הראשי, עותקים עלולים להישאר בקבצי גיבוי ויומני ביקורת.
חשיפה להפרה. בין האיסוף לניקוי, ה-PII הנוסף יושב במערכות שלכם. הפרה בחלון זה מציבה את הנתונים שנאספו-יתר בסיכון.
עצירת האיסוף במקור פותרת את כל ארבעתן. נתונים שלא נכנסים לעולם לא יכולים להיות מופרים, אינם דורשים מחיקה, ואינם נחשבים כהפרה.
דפוסי זיהוי לאימות טפסים
יש שלוש דרכים להוסיף זיהוי PII בזמן אמת לטופס.
בצד הלקוח (תוסף Chrome). התוסף צופה באירועי הדבקה בשדות דפדפן. כאשר משתמש מדביק טקסט עם PII, הוא מדגיש את הישויות מיידית. המשתמש מסיר אותן לפני הגשה. אין צורך בקריאת API — הזיהוי פועל מקומית. ראו את מילון המונחים להגדרות סוגי ישויות.
בצד השרת (שילוב API). הטופס מוגש לשרת שלכם. לפני כתיבה למסד הנתונים, הקוד שלכם קורא לממשק API של הזיהוי. ה-API מחזיר סוגי ישויות עם ציוני ביטחון. התאמות בעלות-ביטחון-גבוה חוסמות את ההגשה עם הודעה ברורה. התאמות בעלות-ביטחון-בינוני מציגות שלב סקירה. הנתונים נקיים לפני אחסון.
היברידי (מומלץ). הדגשה בצד הלקוח נותנת למשתמשים משוב מהיר. בדיקות בצד השרת מספקות את ערובת הציות. אם משתמש מתעלם מהאזהרה של הלקוח, בדיקת השרת עדיין לוכדת את ה-PII. שום דבר לא מגיע למסד הנתונים ללא בדיקה. ראו את שאלות נפוצות שלנו לשאלות נפוצות על סף זיהוי.
דוגמה: פורטל מטופלים בבריאות
פורטל מטופלים מאפשר למטופלים לתאר את הסימפטומים שלהם בשדה טקסט חופשי לפני הזמנה. השדה מקבל באופן קבוע ערכים הכוללים שמות מטופלים אחרים, מספרי זיהוי וכתובות בית. אף אחד מאלה אינו שייך למערכת ניהול הזמנות.
לפני זיהוי בזמן אמת:
- PII בשדה הסימפטומים: כ-12% מההגשות
- שיטת ניקוי: תהליך אצווה שבועי
- מצב ציות: ריאקטיבי — הפרת סעיף 5(1)(ג) התרחשה באיסוף
לאחר שילוב API בעת הגשה:
- ה-API מזהה PII בעל-ביטחון-גבוה לפני כל כתיבה למסד הנתונים
- המטופל רואה: "ההודעה שלך נראית מכילה מידע אישי. אנא הסר אותו לפני הגשה."
- המטופל מתקן ומגיש מחדש
- מסד הנתונים מקבל רק את תיאור הסימפטומים
בתרחיש זה, PII בשדה ירד מכ-12% לפחות מ-1% מהגשות. הציות מוכח כעת דרך יומני זיהוי בצד השרת ולא ריצות ניקוי רטרואקטיביות.
רשומות ביקורת בנקודת האיסוף
רגולטורים מתייחסים לצוותים ריאקטיביים בצורה שונה מאלה עם בקרות פעילות. GDPR סעיף 25 — הגנה בעיצוב ובברירת המחדל — מתגמל את האחרונים.
זיהוי בנקודת האיסוף יוצר רשומות ביקורת שימושיות:
- יומן זיהוי. כל סריקת טופס נשמרת עם סוגי ישויות שנמצאו, ציוני ביטחון, פעולה שננקטה ותוצאה.
- דוחות חודשיים. סיכומים מראים שיעור זיהוי לפי שדה וסוג ישות, וכיצד משתמשים מגיבים.
- רשומות תצורה. הגדרות סף, שדות מכוסים וסוגי ישויות שנצפים — זה מראה מדיניות ברורה ומנוהלת.
רשומות אלה מסייעות בסקירות רגולטוריות. הן גם תומכות בביקורת פנימית ורשומות עיבוד. ראו את מחקרי המקרה שלנו לדוגמאות של בקרות בנקודת האיסוף בפועל.
כלי AI ומינימיזציית נתונים
סוכני תמיכה לעיתים קרובות מדביקים אימיילי לקוחות לכלי ניסוח AI. אימיילים אלה עשויים להכיל שמות, כתובות ומספרי חשבון. שליחה זו למודל AI עלולה לעלות על מה שנחוץ.
שרת MCP מוסיף שלב זיהוי לפני שהטקסט מגיע למודל. שמות לקוחות הופכים ל-[CUSTOMER]. פרטים ספציפיים מנוקים. ה-AI מנסח תשובה תוך שימוש בטקסט הנקי. הסוכן מוסיף חזרה רק מה שהתשובה צריכה.
זה עומד בכלל מינימיזציית הנתונים לשימוש ב-AI. המודל מקבל רק את הנחוץ — שבדרך כלל אין בו PII כלל. ראו ישויות לרשימה המלאה של סוגי ישויות שאנו מזהים.