איך משתמשים בנתונים סינתטיים לניסויי AI פיננסיים

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

למי המדריך מתאים?

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

• להדגים use case להנהלה לפני חיבור ל־ERP.
• להשוות בין כלי AI על אותו קובץ.
• לבדוק פרומפטים בלי לחשוף לקוחות, עובדים וספקים.
• לתרגל איתור חריגות וכפילויות.
• להכשיר עובדים בסביבה בטוחה יותר.
• לבנות POC לפני תהליך הרשאות מלא.

נתונים סינתטיים אינם מחליפים את אישור אבטחת המידע. הם מפחיתים את הצורך להשתמש בנתוני אמת בשלב הלמידה והניסוי.

נתונים סינתטיים, אנונימיזציה ומיסוך אינם אותו דבר

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

מיסוך מחליף שדות מסוימים ברשומה אמיתית, למשל שם או מספר זהות. שאר הרשומה עשויה להישאר אמיתית.

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

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

איך בונים קובץ דמה פיננסי שימושי?

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

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

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

דוגמה מלאה: בדיקת גיול חובות

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

שלב 1: הגדירו schema

צרו טבלה עם השדות:

customer_id, customer_name, invoice_id, invoice_date, due_date, currency, invoice_amount, open_amount, payment_terms, account_manager, risk_level.

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

שלב 2: הגדירו חוקי יצירה

לדוגמה:

• 500 חשבוניות של 80 לקוחות מלאכותיים.
• 70% מהחשבוניות שולמו או אינן בפיגור.
• 20% בפיגור של עד 30 יום.
• 8% בפיגור של 31–90 יום.
• 2% בפיגור מעל 90 יום.
• עשר חשבוניות כפולות.
• חמישה סכומים חריגים.
• שני לקוחות עם ריכוז חשיפה גבוה.

שלב 3: הוסיפו תשובות ידועות

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

שלב 4: הריצו משימה אחידה

בקשו מהכלי:

1. לוודא שסכום יתרת החוב הכוללת תואם לקובץ.
2. לסווג יתרות לפי גיל.
3. לזהות כפילויות וחריגים.
4. להציג את עשרת הלקוחות בעלי החשיפה הגבוהה.
5. להציע סדר גבייה ולנמק אותו.

שלב 5: מדדו

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

שימוש ב־Tonic Fabricate

Tonic Fabricate מאפשר לייצר נתונים מאפס באמצעות Data Agent, או להגדיר מסד מבוסס חוקים בתוכניות מתאימות. ניתן להגדיר טבלאות, עמודות וקשרים ולייצא פורמטים כגון CSV, JSONL או SQL.

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

מה נתוני דמה אינם מוכיחים?

פיילוט על מידע סינתטי אינו מוכיח שהפתרון:

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

המעבר לנתוני אמת צריך להתבצע בהדרגה, בסביבה מאושרת, על מדגם מוגבל ועם reconciliation מלא.

סיכונים ובקרות

1. דליפה דרך הקלט: אל תדביקו נתוני אמת לתיאור היצירה.
2. דמיון נמוך מדי: נתונים אקראיים לחלוטין עלולים לייצר מבחן קל ולא מציאותי.
3. שכפול מקור: מחולל שלמד מדאטה רגיש עלול לשמר פרטים או דפוסים מזהים.
4. הטיה: התפלגות מלאכותית עשויה להסתיר מקרים נדירים.
5. בלבול סביבות: סמנו בבירור כל קובץ כ־SYNTHETIC ואל תאפשרו טעינה למערכת ייצור.
6. תיעוד חסר: שמרו schema, חוקי יצירה, seed ותאריך גרסה.

חלופות

• יצירה באמצעות סקריפט פנימי ופשוט כאשר המבנה מוגדר היטב.
• כלי synthetic data ארגוניים שמספקים מדדי פרטיות ואיכות.
• קובצי תרגול ידניים עבור סדנה קטנה.
• סביבת sandbox של ספק ה־ERP, אם קיימת.

לבדיקת כמה מודלים על אותו קובץ ראו ChatGPT, Claude או Gemini לאנשי כספים. להפיכת הניסוי לתהליך חוזר ראו Skills וסוכני AI במחלקת כספים.

שאלות נפוצות

האם נתונים סינתטיים נחשבים תמיד אנונימיים?

לא. הדבר תלוי באופן היצירה ובמידע ששימש ליצירתם. יש לבצע הערכת פרטיות ולא להסתפק בשם “synthetic”.

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

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

האם חייבים כלי ייעודי?

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

מקורות ותאריך אימות

המידע נבדק ב־4 באוגוסט 2026:

• Tonic Fabricate — User Guide
• Tonic Fabricate — Data generation processes
• Tonic — Fabricate Trust Center
• UK Government — AI Insights: Synthetic Data
• NVIDIA — Generating Safe Synthetic Data

רוצים לבנות POC בלי לסכן נתוני אמת?

בסדנאות AI Finance אנחנו מגדירים use case, בונים סביבת תרגול ומודדים תוצאה לפני חיבור למידע אמיתי. לפרטים על סדנאות AI למחלקות כספים.