מפת החלטות הנדסית לפני שמעבירים נתוני לקוחות לשירות AI: מיפוי שדות, מזעור, פסאודונימיזציה, הגדרות שימוש בנתונים אצל הספק ושמירה. תיאור טכני, לא ייעוץ.
עיקרי הדברים
- יחידת ההחלטה היא שדה בודד. "להעלות את טבלת הלקוחות" היא לא החלטה אלא ויתור על החלטה.
- רוב המשימות עובדות מצוין בלי שדות מזהים, כי המודל לא צריך לדעת מי הלקוח כדי לסכם את מה שהוא כתב.
- תנאי השימוש והגדרות החשבון אצל הספק קובעים מה נעשה בנתונים שנשלחו. אלה מסמכים והגדרות שאפשר לקרוא, לא הנחות.
- שמירה ומחיקה הן הגדרה שצריך לבחור במפורש, אחרת נבחרה ברירת מחדל שאיש לא בדק.
- יומן החלטות קצר שווה יותר ממדיניות ארוכה, כי הוא עונה בעוד שנה על השאלה למה שדה מסוים נשלח.
לפני שנתוני לקוחות עוברים לשירות AI, ההחלטה מתקבלת ברמת השדה הבודד ולא ברמת המערכת או הטבלה. עוברים על השדות שהמשימה באמת דורשת, מחליטים לגבי כל אחד מהם אם הוא נשאר בבית, עובר מוסווה או נשלח כמו שהוא, ומתעדים את ההחלטה ואת מי שקיבל אותה.
זהו תיאור טכני של שיטת עבודה. אין כאן מסקנה משפטית, ואין כאן קביעה מה מותר או חובה בעסק מסוים. בישראל חוק הגנת הפרטיות ותיקון 13 קיימים, והרשות להגנת הפרטיות מפרסמת הנחיות; שאלה על חובות היא שאלה לעורך דין או לרשות.
למה השדה ולא המערכת הוא יחידת ההחלטה?
מפני שהמערכת היא שם של קובץ, והשדה הוא מה שבאמת נוסע. שתי משימות שונות על אותה טבלה דורשות שדות שונים לגמרי, ואם ההחלטה מתקבלת ברמת הטבלה, המשימה הצנועה מקבלת את אותה חשיפה כמו הגדולה.
- "לסווג פניות לפי נושא" צריך את גוף הפנייה, ולא את השם, הטלפון או ת"ז.
- "לנסח תשובה אישית" צריך שם פרטי, ולא כתובת מלאה או היסטוריית תשלומים.
- "לזהות לקוחות בסיכון נטישה" צריך התנהגות ותאריכים, ולא פרטי קשר.
- "לחלץ פרטים מחשבונית" צריך את המסמך, ולעיתים אפשר להסתיר ממנו שדות לפני השליחה.
ההבדל בין ארבע השורות האלה לבין "מעלים את הטבלה" הוא כל ההבדל. מיפוי מוקדם של המקומות שבהם מידע אישי בכלל נמצא מתואר במיפוי מידע אישי בעסק קטן, והוא התנאי המקדים לכל אחת מההחלטות כאן.
שלוש האפשרויות לכל שדה
| מחלקת שדה | דוגמה | לא יוצא | מוסווה | נשלח כמו שהוא | מה זה עולה באיכות |
|---|---|---|---|---|---|
| מזהה ישיר | ת"ז, מספר לקוח | ברירת מחדל טבעית | מזהה מוחלף בטוקן | נדיר שנדרש | כמעט אפס |
| פרטי קשר | טלפון, דוא"ל | לרוב אפשרי | מוסתר בתבנית | נדרש רק לשליחה בפועל | כמעט אפס |
| שם | שם מלא | פוגע בפרסונליזציה | שם פרטי בלבד | מקובל לניסוח | נמוך |
| תוכן חופשי | גוף פנייה, הערה | המשימה מתה בלעדיו | ניקוי מזהים בתוך הטקסט | ברירת המחדל בפועל | תלוי בניקוי |
| נתונים פיננסיים | סכומים, מספר חשבון | מספר חשבון נשאר בבית | סכום בלי מזהה | לצורך חישוב בלבד | נמוך |
| נתוני בריאות ורגישים | כל אזכור | הבחירה הזהירה | קשה לעשות נכון | דורש החלטה נפרדת | תלוי הקשר |
הטבלה לא אומרת מה מותר. היא מסדרת את השאלה כך שאפשר לענות עליה שדה-שדה במקום להתווכח על הכול בבת אחת.
מזעור ופסאודונימיזציה כשלבים הנדסיים
מזעור הוא לא הצהרה אלא קוד שרץ לפני הקריאה לספק. שני הכלים הפרקטיים הם השמטה והחלפה, והם עובדים אחרת.
- בונים את מבנה הבקשה מהשדות שהמשימה דורשת, ולא מהשורה כפי שהיא במסד.
- מוחקים כל שדה שאין לו שימוש בפלט הצפוי.
- מחליפים מזהים בטוקן קצר, ושומרים את טבלת ההמרה אצלכם בלבד.
- סורקים טקסט חופשי ומסתירים דפוסים מזוהים כמו מספרי טלפון וכתובות דוא"ל.
- מחזירים את הערכים האמיתיים אחרי התשובה, לפי טבלת ההמרה.
- בודקים על מדגם אמיתי שהתשובה עדיין נכונה אחרי המזעור.
שלב שש הוא זה שנוטים לדלג עליו. מזעור שמוריד את איכות התשובה מתחת לסף השימושי אינו פתרון, וצריך לדעת את זה לפני העלייה לאוויר ולא אחריה.
מה בדיוק קובעים תנאי הספק ואיפה קוראים אותם?
תנאי השימוש, מסמך הפרטיות ומסך ההגדרות של החשבון קובעים ביחד מה קורה לנתונים אחרי שנשלחו. אלה מסמכים פומביים והגדרות שאפשר לפתוח, ולכן זו לא שאלה של אמון אלא של קריאה.
- האם קלט של לקוחות משמש לאימון מודלים, ואם כן האם יש הגדרה שמכבה זאת.
- כמה זמן נשמרים קלט ופלט, והאם יש אפשרות לשמירה מקוצרת או אפסית.
- באיזה אזור גיאוגרפי מעובד המידע, אם הספק מציע בחירה.
- אילו קבלני משנה מעורבים בעיבוד.
- מה ההבדל בין החשבון האישי לבין החשבון הארגוני או ה-API אצל אותו ספק.
- אילו הגדרות ניתנות לנעילה ברמת הארגון, כך שמשתמש בודד לא יוכל לשנות אותן.
ההבחנה האחרונה מפילה עסקים קטנים. אותו ספק יכול להתנהג אחרת בממשק הצריכה החופשי ובממשק המפתחים, ולכן "מה קורה לנתונים שלנו" היא שאלה שחייבת לציין את המסלול. רקע נוסף על ההבדל הזה יש במה קורה למידע שלך בכלי AI.
שמירה, מחיקה ומה נשאר אצלכם
הצד של הספק הוא רק חצי. החצי השני הוא מה שהמערכת שלכם שומרת סביב הקריאה, וזה בדרך כלל יותר ממה שחשבתם.
- הפרומפט המלא בלוג, כולל השדות שדווקא לא רציתם לשלוח.
- התשובה הגולמית, שנשמרת לצורך ניפוי שגיאות ונשארת לנצח.
- טבלת ההמרה של הפסאודונימיזציה, שהיא בפועל מפתח הזיהוי.
- קבצים שהועלו והועתקו לאחסון זמני שלא נוקה.
- גיבויים של כל אלה, שממשיכים להתקיים גם אחרי מחיקה במערכת החיה.
לכן החלטת שמירה בלי החלטת מחיקה היא חצי החלטה. מי שכבר הגדיר גישה ושמירה לתיקיית לקוח ימצא כאן את אותו דפוס, כמתואר בתיקיית לקוח דיגיטלית עם כללי גישה ושמירה.
יומן ההחלטות, ומה נשאר לשאול איש מקצוע
- מה המשימה, ואילו שדות בדיוק היא דורשת.
- מה נקבע לכל שדה: לא יוצא, מוסווה, או נשלח כמו שהוא.
- איזה ספק ואיזה מסלול חשבון, ומתי נקראו התנאים.
- אילו הגדרות שימוש ושמירה נבחרו, ומי בחר אותן.
- תאריך הבדיקה הבאה, כי הגדרות ותנאים משתנים.
מה שנשאר מחוץ ליומן הוא לא פחות חשוב: האם שימוש מסוים מותר, מה חובה לתעד או להודיע, וכמה זמן מותר לשמור סוג מסוים של מידע. אלה לא שאלות הנדסיות, והתשובה עליהן מגיעה מעורך דין או מהרשות להגנת הפרטיות. הערך של היומן הוא שהוא הופך שאלה כללית ומעורפלת לרשימה קצרה של שאלות ממוקדות שאפשר לקבל עליהן תשובה.
מקורות
שאלות נפוצות
אפשר פשוט להסתיר שמות ולסיים עם זה?
החלפת שמות מקטינה חשיפה אבל לא מבטלת אותה, כי טקסט חופשי מכיל לעיתים קרובות פרטים שמזהים בעקיפין: כתובת, מקום עבודה, תאריך אירוע. לכן פסאודונימיזציה נבדקת על טקסט אמיתי, ולא רק על עמודות מסודרות במסד הנתונים.
מה ההבדל בין חשבון צריכה רגיל לבין ממשק מפתחים?
זה תלוי ספק, וזו בדיוק הסיבה לקרוא. לאותו ספק יכולים להיות תנאי שימוש בנתונים, אפשרויות שמירה והגדרות ארגוניות שונים בין המסלולים. אל תניחו העברה של מדיניות ממסלול אחד לשני בלי לפתוח את המסמך הרלוונטי.
האם מודל מקומי פותר את השאלה?
הוא משנה אותה. הרצה מקומית מסירה את שאלת העברת המידע לספק, ומשאירה את שאלות הגישה, השמירה, הגיבוי וההרשאות אצלכם. גם התשתית שלכם מתעדת, מגבה ומחזיקה לוגים, ולכן ההחלטות ברמת השדה נשארות רלוונטיות.
מי צריך לאשר את ההחלטה הזאת בעסק קטן?
מבחינה הנדסית, מי שמפעיל את התהליך ומי שאחראי על נתוני הלקוחות צריכים לחתום על אותו יומן. מבחינת חובות, זו שאלה שתלויה בנסיבות העסק ובמידע, ולכן היא מופנית לעורך דין או לרשות להגנת הפרטיות.
להמשך קריאה
שירות רלוונטי
פיתוח MVP
להפוך רעיון למוצר מאומת תוך שבועות, לא חודשים.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.