הסכמה והזכות להישכח

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 5 מתוך 6 בפרק איכות נתונים וממשל נתונים, הפרק החמישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: חוקי הפרטיות מעצבים את התכנון · הבא: להגן, לשמור ולהוכיח

השאלה שהיחידה הזו עונה עליה: איך מתכננים בשביל הסכמה, ובשביל מחיקה של אדם?

ל-Steve Trucking יש מספר טלפון של נמען. שאלה פשוטה: מותר לנו לשלוח לו הודעת טקסט? אולי. על המשלוח של היום? של מחר? מותר להשתמש במספר למבצע? ומה אם הוא אמר לא להודעות טקסט, או כן לעדכוני משלוח אבל לא לשיווק, ואז שינה את דעתו?

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

הסכמה היא נתונים

העיקרון הראשון: הסכמה היא נתונים. אל תצמצמו אותה ל-Has_Opted_In__c = true. השאלה האמיתית היא אף פעם לא רק “האם הוא הסכים?”. היא הסכמה למה, דרך איזה ערוץ, באיזו כתובת או מספר, לאיזו מטרה, מתי, האם היא השתנתה, והאם אנחנו יכולים להוכיח אותה? אם העסק מקבל החלטות על פי התשובות האלה, צריך לשמור אותן כנתונים מובנים. פסקה במדיניות פרטיות לא מספיקה, וגם לא תיבת סימון בטופס אינטרנטי: תיבת הסימון קולטת אירוע; הארכיטקטורה צריכה לשמור את מה שהאירוע אומר.

השתמשו במודל ש-Salesforce כבר בנתה

העמדה שלי: השתמשו במודל ההסכמה המובנה (out-of-the-box) בכל מקום שאפשר, במקום לבנות שוב את אותו דבר בשדות מותאמים אישית. מודל נתוני ההסכמה של Salesforce מנהל הסכמה בארבע רמות, כל אחת שאלה ספציפית יותר (Understand the Salesforce Consent Data Model (opens in a new tab)):

• הסכמה גלובלית, על ה-Individual: מי האדם הזה, והאם הוא אמר לא לכל דבר?
• הסכמה לערוץ התקשרות (Contact Point Type Consent): האם מותר לנו להשתמש בסוג הזה של ערוץ, כמו SMS או דוא”ל?
• הסכמה לנקודת קשר (Contact Point Consent): ומה לגבי מספר הטלפון או כתובת הדוא”ל הספציפיים האלה?
• מטרת השימוש בנתונים (Data Use Purpose): מאיזו סיבה: התראות משלוח, שירות, שיווק?

ביחד, הארכיטקטורה יכולה לענות על “האם מותר לנו להשתמש במידע של האדם הזה, דרך נקודת הקשר הזו, למטרה הזו?”, וזה הרבה יותר שימושי מ”הסכמה = כן”. כל רשומה שקשורה לאדם יכולה להשתתף: לידים, אנשי קשר, חשבונות אישיים, משתמשים.

Click to enlarge

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

המטרה חשובה

שותף קמעונאי שולח ל-Steve Trucking מספר של נמען כדי שהצוות יוכל לתאם את המשלוח. זה לא הופך את הנמען לליד שיווקי. לאותם נתונים יכולים להיות שימושים מותרים שונים: תיאום משלוח, מעקב שירות, שיווק, התאמה אישית בעזרת AI. אם המדיניות או החוק מתייחסים אליהם בצורה שונה, המודל צריך להבחין ביניהם. השאלה היא לא האם יש לנו את מספר הטלפון? אלא מה מותר לנו לעשות איתו?

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

להסכמה יש מחזור חיים וסמכות

אנשים נותנים הסכמה, מושכים אותה, משנים העדפות, משנים מספרים. העסק מוסיף מטרות חדשות; החוקים משתנים. אז תכננו את מחזור החיים: מה נבחר, מתי, איך, לאיזו מטרה, ומה קורה במשיכה. וכאן זה נעשה מעניין: כשנמען מושך את ההסכמה שלו, Salesforce יודע. האם פלטפורמת ההודעות יודעת? האנליטיקה? הסוכן? הסכמה שחיה במערכת אחת בזמן שאחרות פועלות לפי הרשאה שכבר לא בתוקף היא לא בדיוק בקרה.

זה אומר לשאול איזו מערכת סמכותית להסכמה. Salesforce, פלטפורמת העדפות, מקום אחר? מה שלא תהיה התשובה, אל תתנו לחמש מערכות להחליט כל אחת בנפרד אם אותו אדם הסכים לאותו שימוש. הסכמה צריכה את מה שכל נתון מנוהל צריך: בעלים, רשומה סמכותית, דרך לסנכרן, ואכיפה.

עכשיו האדם אומר: תשכחו אותי

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

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

Click to enlarge

בקשת “תשכחו אותי” היא החלטה לכל עותק.

השעון מתקתק

הבקשות האלה מגיעות עם מועדים. לפי GDPR, הארגון צריך לפעול על פי בקשה של אדם ללא דיחוי מיותר ובתוך חודש מקבלתה; לבקשות מורכבות או רבות אפשר להאריך את זה בעוד חודשיים, אבל צריך להודיע לאדם בתוך החודש הראשון, עם הסיבות (סעיף 12(3), Regulation (EU) 2016/679 (opens in a new tab)). חוקים אחרים קובעים מועדים משלהם; המחלקה המשפטית תגיד לכם אילו חלים. כך או כך, חודש זה לא מספיק זמן כדי לגלות את מפת המערכות. זה המועד שמפת העותקים צריכה להקדים.

למחוק, להסיר זיהוי או לשמור?

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

זכרו את ההבחנה מיחידה 4. ניתוק הקישור לאדם נחשב שכחה רק כשאי אפשר באופן סביר לזהות את האדם מחדש. מידע שעבר פסאודונימיזציה הוא עדיין מידע אישי. אל תשתמשו בהסוואה כקיצור דרך שעוקף דרישה חוקית.

אי אפשר למחוק את מה שלא מוצאים

לפני שאפשר למחוק מישהו, צריך למצוא אותו. הבקשה מגיעה מכתובת דוא”ל. שותף קמעונאי אחד שלח “Jane Smith”, אחר “J. Smith”, ומספר הטלפון השתנה. הנמען הוא בכלל לא איש קשר; הפרטים שלו יושבים על כל משלוח. אותו אדם קיבל משלוחים משני שותפים שונים. מערכת אחת מכירה אותו לפי דוא”ל, אחרת לפי מזהה חיצוני. המחיקה תלויה בזהות, ואתם לא רוצים למחוק נתונים של מישהו אחר כי ההתאמה שלכם הייתה אגרסיבית מדי. ארכיטקטורת הזהות היא חלק מארכיטקטורת הפרטיות.

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

גם תמונות וטקסט חופשי הם נתונים

קל לחשוב על פרטיות כעל שדות: שם, דוא”ל, טלפון, כתובת. אבל Steve Trucking מצלמת מיליוני תמונות משלוח בשנה, וחלקן מראות אנשים או את פנים הבית. מדיניות שמירה או מחיקה שמסתכלת רק על שדות מובנים היא חלקית; כך גם מדיניות שמתעלמת מקבצים, מסמכים, תמלולים, לוגים, ומהנחיות (prompts) ותשובות של AI.

וטקסט חופשי הוא מסוכן. אתם מסירים את השם, הטלפון והכתובת, ואז מוצאים את הערת המשלוח הזו: “Call Jane at 602-555-0198. Gate code 4821. Dog is in the yard.” הנה זה. סיווג של הערות משלוח כרגישות אומר לכם שאולי יש בעיה; הוא לא מוצא ומסיר את המידע האישי שבתוך הטקסט. לפעמים התשובה הטובה ביותר היא למנוע מלכתחילה מפרטים אישיים מיותרים לנחות שם. שלטו קודם כול לאן מידע אישי הולך.

Privacy Center הוא כלי, לא כל הארכיטקטורה

Privacy Center של Salesforce עוזר להפעיל את התהליכים האלה. מדיניות הזכות להישכח שלו נבנית לכל אובייקט, כדי לתפוס את כל מה שאתם רוצים להסיר, ורצה על רשומת לקוח ספציפית (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). זה שימושי. אבל “קנינו Privacy Center, אז סיימנו” זו לא ארכיטקטורה. הנתונים של האדם יכולים לחיות מחוץ להישג ידו של כל כלי בודד: Data 360, מחסן הנתונים, מערכות של שותפים, ארכיונים, לוגים, חיפוש, קבצים, שיחות של סוכנים. הארגון עדיין צריך תשובה ארגונית, ואתם צריכים לבדוק מה כל כלי באמת מכסה לפני שאתם סומכים עליו.

ניוד והוכחה

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

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

מעבר למבחן: מה ה-AI משנה. ה-AI יוצר מטרות חדשות ועותקים חדשים. הרשאה להשתמש בנתונים כדי לספק שירות לא מכסה אוטומטית עיגון של סוכן בנתונים, התאמה אישית או אימון; Data Use Purpose הוא המקום הטבעי להבחין ביניהם. ומידע אישי יכול לשרוד בהנחיות (prompts), בהקשר העיגון, בשיחות, בסיכומים, באינדקסי חיפוש ובאינדקסים וקטוריים, ובלוגים. “מחקנו את רשומת המקור” זו לא תשובה שלמה אם שכבת ה-AI עדיין זוכרת.

מה הארכיטקט מחליט כאן

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

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

להרחבה

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), סעיף 12(3), המועד לטיפול בבקשה (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center) (באנגלית, נבדק ב-2026-10-14).