איך מייצרים קובץ אקסל עם נתוני דמה ל-AI, לדאשבורדים ולבדיקות

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס ניתוח נתונים עם AI

לפרטים נוספים לחצו כאן >>

למה מחיקת עמודת השם לא מספיקה

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

ייצוא טיפוסי ממערכת CRM. הנתונים המוצגים בצילום סינתטיים לחלוטין

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

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

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

ויש מקום נוסף שקל לפספס: שדות טקסט חופשי. הערת שירות בנוסח "דיברתי עם אשתו רונית, מבקש שנחזור אליו ל-052 אחרי 18:00" עלולה לשרוד את מחיקת העמודות המזהות, מפני שהפרטים נמצאים דווקא בתוך טקסט שנראה תמים.

ארבע גישות שכדאי להכיר

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

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

לפני שמתחילים

מה צריך? גיליון אלקטרוני כמו Excel או Google Sheets, חשבון בכלי AI וכעשר דקות. אין צורך בהתקנות.

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

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

מה לא לעשות: גם בפלט "האנונימי" העיר, הגיל וההערות עדיין נשארו

התהליך בשישה שלבים

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

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

3. מוסיפים כללי בטיחות מפורשים: כתובות אימייל רק בדומיין example.com, מזהי לקוח בפורמט CUST-0001, וללא מספרי טלפון אלא אם הם הכרחיים לבדיקה. אם חייבים לכלול טלפונים או מספרי זהות, משתמשים בערכי בדיקה ייעודיים שאינם עוברים ולידציה. בלי כללים ברורים, המודל עלול ליצור פרטים שנראים אמיתיים ואף להתלכד במקרה עם פרטים קיימים.

4. מריצים ומורידים כ-CSV: מבקשים במפורש קידוד UTF-8 with BOM, כדי שהעברית תיפתח בצורה תקינה ב-Excel.

5. בודקים את התוצאה: פותחים את הקובץ ומחפשים @ כדי לוודא שכל כתובות האימייל משתמשות בדומיין השמור. מחפשים גם רצפי ספרות שנראים כמו מספרי טלפון או מספרי זהות, ובודקים לפחות התפלגות אחת כדי לוודא שהנתונים מגוונים והגיוניים ולא אחידים מדי.

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

הפרומפט שמייצר את הקובץ

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

צור קובץ CSV שמדמה ייצוא מ-CRM של חנות אונליין ישראלית, 500 שורות.

העמודות:
customer_id, age_group, region, registration_month, order_amount,
product_category, payment_method, customer_status

כללים:
- אין להשתמש בשמות, טלפונים או כתובות של אנשים אמיתיים.
- מזהה הלקוח בפורמט CUST-0001.
- כתובות מייל על הדומיין example.com בלבד.
- סכומים בשקלים, בטווח 50 עד 5,000, בהתפלגות מציאותית
  (רוב הרכישות בטווח הנמוך, מיעוט גבוה).
- אזורים: צפון, חיפה, מרכז, תל אביב, ירושלים, דרום.
- טווחי גיל בלבד, לא תאריכי לידה: 18-24, 25-34, 35-44, 45-54, 55+.
- חודש ושנה בלבד, לא תאריך מדויק.
- החזר CSV להורדה בקידוד UTF-8 with BOM.

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

אותו תהליך בקוד, עם Faker

כשצריך לייצר אלפי שורות, או כשחשוב לחזור על התהליך בצורה עקבית, עדיף לעבור לקוד. הספרייה Faker כוללת תמיכה בהגדרות אזוריות בעברית:

from faker import Faker
import csv
import random

fake = Faker("he_IL")
Faker.seed(42)

regions = ["צפון", "חיפה", "מרכז", "תל אביב", "ירושלים", "דרום"]

with open("synthetic_customers.csv", "w", newline="", encoding="utf-8-sig") as file:
    writer = csv.writer(file)
    writer.writerow([
        "customer_id", "name", "email", "region", "age_group", "order_amount"
    ])

    for index in range(1, 501):
        writer.writerow([
            f"CUST-{index:04d}",
            fake.name(),
            f"customer{index}@example.com",
            random.choice(regions),
            random.choice(["18-24", "25-34", "35-44", "45-54", "55+"]),
            random.randint(50, 5000)
        ])

השורה Faker.seed(42) גורמת ל-Faker לייצר את אותם ערכים בכל הרצה, וזה שימושי כשבודקים מערכת ורוצים להשוות בין תוצאות. חשוב לשים לב שבדוגמה נעשה שימוש גם במודול random של Python. כדי שכל הקובץ יהיה זהה בכל הרצה, צריך לקבע גם אותו באמצעות random.seed(42). אחרת השמות יחזרו על עצמם, אך האזורים, קבוצות הגיל והסכומים עשויים להשתנות.

שימו לב גם שכתובת האימייל אינה נלקחת מ-Faker, אלא נבנית ידנית בדומיין example.com. זו אינה קפדנות מיותרת, אלא שכבת בטיחות חשובה, כפי שנראה בהמשך.

ומה אם כבר יש לכם קובץ אמיתי?

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

הנה פרומפט לדוגמה:

כתוב לי סקריפט Python שרץ מקומית ומייצר גרסה מותממת של קובץ CSV.
אל תבקש ממני את הקובץ ואל תעבד נתונים. רק תכתוב את הקוד.

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

מה הסקריפט צריך לעשות:

1. למחוק לגמרי את העמודות: שם_מלא, תעודת_זהות, טלפון, אימייל, כתובת.
   למחוק, לא להחליף בטוקן כמו PERSON-0001.

2. לערבב את סדר השורות לפני שמקצים מזהה חדש, ורק אז לתת
   customer_id בפורמט CUST-0001. זה קריטי: בלי ערבוב, סדר השורות
   עצמו מאפשר לשחזר את הזהויות מול הקובץ המקורי.

3. להכליל מזהים עקיפים:
   - עיר -> אזור (צפון, חיפה, מרכז, תל אביב, ירושלים, דרום)
     לפי מיפוי אמיתי של ערים לאזורים, לא לפי טוקן.
   - תאריך_לידה -> קבוצת גיל: 18-24, 25-34, 35-44, 45-54, 55-64, 65+
   - תאריך_הצטרפות -> חודש ושנה בלבד (YYYY-MM)
   - סכום_רכישה_אחרונה -> להשאיר כמספר, אבל לעגל למאה הקרובה

4. הערת_שירות: להחליף בקטגוריה בלבד (משלוח, תשלום, מוצר, ביטול,
   שביעות רצון, אחר, ללא הערה) לפי מילות מפתח. לא להשאיר טקסט חופשי.

5. בדיקת k-anonymity: כל צירוף של אזור + קבוצת גיל + סטטוס_לקוח
   שמופיע בפחות מ-5 שורות, יש לרוקן בו את שדה האזור.
   הדפס כמה שורות תוקנו כך.

6. אופציונלי וכבוי כברירת מחדל: טבלת התאמה בין המזהה החדש למקורי,
   שנשמרת לקובץ נפרד בשם mapping_DO_NOT_SHARE.csv.

7. בסיום, הדפס דוח: כמה שורות עובדו, אילו עמודות נמחקו, כמה שורות
   תוקנו בבדיקת k-anonymity, וכמה ערכים ייחודיים נשארו בכל עמודה.

קרא ב-encoding utf-8-sig וכתוב ב-utf-8-sig.

שני סעיפים חשובים במיוחד הם 2 ו-5. סעיף 2 מטפל בתקלה נפוצה: קובץ שנראה אנונימי, אך סדר השורות בו זהה למקור ולכן מאפשר לקשר בין הרשומות. סעיף 5 מוסיף בדיקת k-anonymity, כלומר דורש שכל שילוב של המאפיינים שנבחרו יופיע אצל חמישה אנשים לפחות. הבדיקה מצמצמת את הסיכון ששורה יחידה תישאר לאחר סינון, אך היא אינה הוכחה מוחלטת לכך שאי אפשר לזהות אדם מחדש.

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

טיפים שמשפרים את התוצאה

• שמרו על קשרים בין טבלאות: אם אתם מייצרים טבלת לקוחות, טבלת הזמנות וטבלת פניות שירות, השתמשו באותו customer_id בכולן. בלי מזהה עקבי לא תוכלו לבדוק תהליכים שדורשים חיבור בין טבלאות.
• אל תשתמשו ב-XXXX כערך ממלא מקום: עמודה שמלאה באיקסים לא תעזור לבדוק מיון, סינון או חישוב. ערך דמה צריך להיות שימושי לצורך הבדיקה, ולא רק למלא שדה.
• השאירו כמה מקרי קצה בכוונה: לקוח ללא הזמנות, סכום חריג בגובהו או שדה ריק. אלה בדיוק המקרים שעלולים להפיל מערכות, ואם המאגר יהיה נקי מדי, הבאג יתגלה רק מול הלקוח.
• בדקו את שדות הטקסט החופשי בנפרד: חיפוש אחר @, אחר 05 ואחר המילה "קישור" בעמודת ההערות יכול לאתר דליפות ברורות. אל תסתפקו בחיפוש הזה בלבד, משום שמידע מזהה יכול להופיע בצורות נוספות.
• בדקו גם את שם הקובץ: קובץ בשם "לקוחות_חברת_כהן_סופי" חושף מידע עוד לפני שפותחים אותו.

שלוש אזהרות שחשוב להכיר

"מזויף" לא אומר "לא קיים". העובדה שספרייה או מודל יצרו מספר טלפון אקראי אינה מבטיחה שהוא לא שייך במקרה לאדם אמיתי. לכן עדיף לא לייצר מספרי טלפון או מספרי זהות אם הבדיקה אינה דורשת אותם. לכתובות אימייל אפשר להשתמש בדומיינים שמורים כמו example.com, ולמזהים פנימיים בפורמט ברור כמו TEST-. אם חייבים ערך שנראה כמו מספר תעודת זהות, יש לוודא שהוא נכשל בכוונה בבדיקת התקינות ואינו יכול לשמש כמספר תקף.

טבלת ההתאמה היא נקודת תורפה מרכזית. אם בחרתם בפסאודונימיזציה ולא בנתונים סינתטיים, כלומר קיים קובץ שמקשר בין CUST-1042 לבין אדם אמיתי, יש לשמור אותו בנפרד ובהרשאות מצומצמות. טבלת התאמה שנשמרת באותו קובץ או באותה תיקייה משותפת הופכת את הזיהוי מחדש לפשוט מאוד.

אנונימי אינו שם נרדף לאפס סיכון. גם לאחר התממה עלול להישאר סיכון לזיהוי מחדש, במיוחד כאשר משלבים את המאגר עם מקורות מידע נוספים. בישראל, תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף באוגוסט 2025 והרחיב, בין היתר, את סמכויות האכיפה ואת האפשרות להטיל עיצומים כספיים. זו אינה סיבה להיבהל, אבל זו בהחלט סיבה לא להסתפק באמירה "מחקתי את השמות". כשמדובר במאגר גדול, במידע רגיש או בשיתוף מחוץ לארגון, כדאי להתייעץ עם גורם מקצועי ולא להסתמך על מדריך כללי, כולל המדריך הזה.

מאיפה מתחילים כבר היום?

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