עמוד השירות: עורך דין מסחר דיגיטלי ו-AI: תקנון, פרטיות ודיוור.
תרחיש לדוגמה: חברה שבנתה מוצר עם 100,000 משתמשים, גילתה ב-due diligence לקראת גיוס שיש לה חשיפת פרטיות ענקית בארכיטקטורת הנתונים — ואת ה-round היא איבדה. Privacy by Design הוא לא רק "נכון לעשות" — זה עניין של הישרדות עסקית. מי שנתקל בכך בפועל ימצא את הצעדים המעשיים ב היבטים משפטיים של מסחר מקוון.
מהו Privacy by Design?
Privacy by Design (PbD) היא גישה לפיתוח מוצרים שלפיה הגנת הפרטיות נבנית לתוך המערכת מהיום הראשון — לא מתווספת בדיעבד. הרעיון פותח בשנות ה-1990 על ידי ד״ר אן קבוקיאן מקנדה, והפך לחובה משפטית ב-2018 עם כניסת תקנות ה-GDPR האירופאיות לתוקף (סעיף 25).
בישראל, תקנות הגנת הפרטיות (אבטחת מידע), תשע״ז-2017, הולכות לאותו כיוון: הן מחייבות ארגונים לאמץ אמצעי אבטחה שמותאמים לרגישות המידע ולסיכונים — כלומר, לחשוב על פרטיות כחלק מהעיצוב, לא כ-checkbox.
שאלה על המקרה שלכם? כתבו בוואטסאפ · 050-431-3155
שבעת העקרונות של Privacy by Design
קבוקיאן הגדירה שבעה עקרונות מנחים. כך הם נראים בפועל בחברת טכנולוגיה:
- מניעה, לא תיקון: זיהוי סיכוני פרטיות לפני הפיתוח — לא בדיקה אחרי שהקוד בפרודקשן. Threat modeling בשלב ה-design.
- פרטיות כברירת מחדל: המוצר משתף הכי מעט מידע אפשרי, ודורש הסכמה אקטיבית להרחבת השיתוף. ה-default הוא "לא שתף" — לא "שתף הכל".
- פרטיות מובנית בארכיטקטורה: הגנת הפרטיות היא חלק מהעיצוב הטכני — לא פלאגין חיצוני. הצפנה, הפרדת רשתות, ומינימום גישה מתוכננים מראש.
- לא אפס-סכום: פרטיות ואבטחה לא סותרות פונקציונליות — אפשר לבנות מוצר שעושה את שניהם. "זה יפגע בחוויית המשתמש" — זה לרוב תירוץ, לא מגבלה אמיתית.
- אבטחה מקצה לקצה: הנתון מוגן מרגע האיסוף ועד למחיקה. לא רק בעת השידור — גם באחסון, בגיבויים, ובכל ממשק פנים-ארגוני.
- שקיפות וגלוי: המשתמשים יודעים מה אוספים, למה, ואיך. לא מסמך privacy policy של 40 עמוד שאף אחד לא קורא — שקיפות אמיתית.
- כבוד לפרטיות המשתמש: מידע רגיש מוגן יותר, הסכמות ניתנות לביטול, ומשתמשים יכולים לגשת ולמחוק את הנתונים שלהם.
שאלה על אתר, פרטיות, תנאי שימוש או AI בעסק?אחזור אליכם בשעות הפעילות (א׳–ה׳, 9:00–18:00).
יישום מעשי בפיתוח תוכנה
ארבעה כלים שכל צוות פיתוח צריך לאמץ:
- Data Flow Diagram: מיפוי של כל מסע הנתון — מאיפה הוא נאסף, לאיפה הוא עובר, מי מגיע אליו, ומתי הוא נמחק. בלי מפה — אי אפשר לדעת איפה החשיפה.
- Data Minimization: אוספים רק מה שבאמת צריך. מאגר נתונים עשיר הוא נכס — אבל גם אחריות. כל שדה מיותר הוא פוטנציאל דלף.
- Access Control: הגדרה מדויקת של מי ניגש למה ומתי — לא גישה גורפת לכל הנתונים לכל מפתח. Principle of least privilege.
- Retention Policy: נתונים שאין בהם עוד צורך — נמחקים (ראו תקופות השמירה לפי חוק). גיבויים ישנים שמצטברים הם אחד ממקורות הדלף הנפוצים.
Privacy Impact Assessment — מתי ולמה
DPIA (Data Protection Impact Assessment) הוא תהליך הערכת ההשלכות של פרויקט חדש על פרטיות. ב-GDPR — חובה לפני עיבוד שצפוי להוביל לסיכון גבוה, למשל עיבוד בהיקף נרחב של קטגוריות מיוחדות כמו מידע ביומטרי או רפואי, או פרופיילינג שיטתי ונרחב (סעיף 35). בישראל — לא חובה בחוק אבל הפך לכלי הגנה משפטי חשוב.
DPIA כולל: תיאור עיבוד הנתונים, הערכת הצורך וההיתר, זיהוי הסיכונים לנושאי המידע, ואמצעי הפחתה. חברה שעשתה DPIA ותיעדה אותו — במצב טוב הרבה יותר מול רגולטור ומול בית משפט, אם תגיע הפרה.
מה קורה לחברות שלא מיישמות?
שלוש חשיפות עיקריות:
- קנסות רגולטוריים: ב-GDPR — הפרת סעיף 25 עד 10 מיליון יורו או 2% מהמחזור העולמי (סעיף 83(4)), והפרת עקרונות העיבוד, כמו צמצום המידע, עד 20 מיליון יורו או 4% (סעיף 83(5)). בישראל, מאז תיקון 13 רשאית הרשות להגנת הפרטיות להטיל עיצום כספי גם על הפרת תקנות אבטחת המידע (סעיף 23כו(ח) והתוספת השלישית לחוק הגנת הפרטיות). למשל, מי שלא בחן או לא תיעד את הבחינה השנתית אם המידע במאגר רב מהנדרש למטרותיו (תקנה 2(ג)) חשוף לעיצום של 2,000 ₪ במאגר ברמת אבטחה בסיסית, 40,000 ₪ ברמה בינונית ו-160,000 ₪ ברמה גבוהה (פרט 3 לתוספת השלישית; סכומי בסיס שמתעדכנים ב-1 בינואר בכל שנה לפי סעיף 23לב(ב)).
- תביעות אזרחיות: נפגעי הפרת פרטיות יכולים לתבוע פיצויים. בהפרות בהיקף רחב עלולה להיות מוגשת גם בקשה לאישור תביעה ייצוגית.
- נזק עסקי: דלף נתונים הרס חברות. משקיעים, לקוחות ארגוניים, ושותפים בינלאומיים בודקים פרטיות כ-deal breaker. GDPR readiness הפך לדרישת כניסה לשוק האירופאי.
צ'קליסט לחברה שרוצה להתחיל
חמישה צעדים מעשיים לחברה שמתחילה ליישם:
- מנו DPO (Data Protection Officer) — מאז תיקון 13 זו חובה לגופים ציבוריים, לסוחרי מידע ולמי שעיסוקו העיקרי כולל ניטור שיטתי או עיבוד מידע רגיש בהיקף ניכר (סעיף 17ב1; ראו מי חייב במינוי ממונה אחרי תיקון 13); ובשאר המקרים — לפחות גורם פנימי אחראי. מישהו צריך לאחוז בנושא.
- צרו Data Inventory — רשימה של כל המידע האישי שאתם מחזיקים, מאיפה הגיע, ואיפה הוא יושב.
- בצעו DPIA לפרויקטים חדשים — לפני ה-sprint, לא אחריו.
- כתבו Privacy Policy שאנשים יכולים לקרוא — קצרה, ברורה, ומדויקת.
- הכשירו את צוות הפיתוח — מפתח שיודע מה זה PbD יקבל החלטות טובות יותר בלי לחכות לעו״ד.
מקורות
- חוק הגנת הפרטיות, התשמ״א-1981
- תקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017 — קובץ התקנות 7809
- Regulation (EU) 2016/679 (GDPR) - EUR-Lex (סעיפים 25, 35 ו-83)
הקישורים מפנים לנוסח החקיקה במקור. הנוסח המחייב הוא זה שפורסם בספר החוקים.
מה בודקים בפועל
- טיפ פרקטי: כשמייצגים חברת טכנולוגיה — בקשו לראות את Data Flow Diagram לפני שאתם נותנים כל חוות דעת. בלי לדעת לאן הנתונים הולכים, כל ייעוץ פרטיות שטחי. אם הלקוח לא יכול להציג DFD — זה עצמו ממצא.
- חקיקה רלבנטית: סעיף 25 ל‑GDPR (Data protection by design and by default); תקנות הגנת הפרטיות (אבטחת מידע), תשע״ז-2017; חוק הגנת הפרטיות, התשמ״א-1981.
- טעות נפוצה: לחשוב שמדיניות פרטיות (Privacy Policy) טובה = Privacy by Design. ה-Policy הוא מסמך — PbD הוא ארכיטקטורה. לקוח יכול להיות עם Policy מצוין ועם ארכיטקטורה שבורה לחלוטין.
- נקודה טקטית: בביקורת לפני השקת מוצר — בצעו DPIA מתועד, גם אם לא חובה. תיעוד שחברה הכירה בסיכונים ועשתה הכל לצמצמם עשוי לשמש ראיה להתנהלות סבירה אם תגיע תביעה.