Data Governance למערכות AI: מי אחראי על הדאטה שהמודל רואה, לומד ממנו ומחזיר

מאת צוות מדיה דיל · 01.08.2026 · Enterprise AI · 12 דק׳

כשמודל AI ניזון מדאטה ארגוני, כל בעיית איכות, בעלות או סיווג בדאטה המקורי מתבטאת בתשובות שהמערכת נותנת. Data Governance היא התשתית שמונעת את זה.

הבעיה: דאטה גרוע נכנס, תשובות גרועות יוצאות

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

ארבעת עמודי התווך של Data Governance ל-AI

Data Governance רציני נשען על ארבעה מרכיבים: Data Lineage (מעקב אחרי מקור כל פיסת דאטה ומסלול העיבוד שלה), Data Classification (סיווג לפי רגישות - ציבורי, פנימי, סודי, רגיש ביותר), Data Quality (וידוא שהדאטה מדויקת, עדכנית ולא כפולה), ו-Data Retention (מדיניות ברורה כמה זמן שומרים כל סוג דאטה ומתי מוחקים אותו). במערכות AI, כל אחד מהמרכיבים האלה מקבל משמעות ייחודית: Lineage צריך לעקוב לא רק אחרי המסמך המקורי אלא גם אחרי ה-embedding שנוצר ממנו והגרסה של מודל ה-embedding ששימש; Classification צריך לקבוע אילו מסמכים בכלל מותר להזין ל-context של ספק חיצוני; ו-Retention צריך להתמודד עם השאלה המורכבת - כמה זמן שומרים sessions ותשובות שהמודל ייצר.

Data Lineage: המסלול המלא מהמקור לתשובה

ב-Data Lineage מסורתי, עוקבים אחרי איך שדה במסד נתונים זז בין טבלאות. ב-AI, ה-Lineage מורכב יותר: מסמך מקורי עובר chunking, מומר ל-embedding, נשמר ב-Vector Database, נשלף בזמן שאילתה, ומוזרק ל-context של prompt שנשלח למודל. כדי לדעת למה המודל ענה מה שענה - יכולת קריטית לצורך אבחון וגם לצורך ציות רגולטורי - צריך יכולת לשחזר את כל השרשרת הזו: איזה מסמך מקורי, איזו גרסת chunking, ואיזו שאילתת retrieval הובילו לתשובה הסופית.

סיווג דאטה וקביעת מה מותר להזין למודל

אחת ההחלטות הקריטיות ביותר ב-Data Governance ל-AI היא קביעת מדיניות ברורה - איזה דאטה מותר להזין כ-context לספק חיצוני, ואיזה חייב להישאר בתוך הגבולות הארגוניים (למשל, מודל שרץ On-Premise או VPC פרטי). דאטה שמסווג כ'סודי ביותר' - נניח, מידע פיננסי לא-פומבי או קניין רוחני קריטי - צריך לעבור בדיקה מפורשת לפני שהוא בכלל נכנס לתהליך שמערב API חיצוני, ללא קשר להסכמי הפרטיות שהספק מציע. הגדרת המדיניות הזו צריכה להיעשות מראש, ברמה ארגונית, ולא להישאר להחלטה אד-הוק של כל מפתח שבונה feature חדש.

דוגמת קוד: תיוג סיווג במטא-דאטה של Chunk

class DocumentChunk:
    def __init__(self, text, source_doc_id, classification, created_at):
        self.text = text
        self.source_doc_id = source_doc_id
        self.classification = classification  # public/internal/confidential/restricted
        self.created_at = created_at

def is_allowed_for_external_provider(chunk, provider_policy):
    return chunk.classification in provider_policy.allowed_classifications

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

איכות דאטה: הגורם השקט שהורס את אמינות המערכת

בעיית איכות דאטה במערכות AI מתבטאת בכמה צורות: מסמכים כפולים או סותרים במאגר ה-RAG, מסמכים שפג תוקפם אך לא הוסרו, ותוכן שנוצר על ידי AI עצמו (synthetic content) שמוזן בחזרה למאגר בלי סימון - תופעה שנקראת Model Collapse כשהיא קורית בקנה מידה גדול לאורך זמן, כי המודל 'לומד' בהדרגה מהפלט של עצמו ולא מדאטה אמיתי. תהליך Data Quality טוב כולל בדיקות אוטומטיות תקופתיות שמזהות כפילויות, מסמכים ישנים לפי תאריך עדכון אחרון, וסימון ברור של תוכן שנוצר על ידי AI לעומת תוכן אנושי מקורי.

מדיניות שימור: כמה זמן שומרים שיחות ותשובות

Data Retention במערכות AI כולל שאלה שלרוב לא נשאלת מספיק - כמה זמן שומרים את היסטוריית השיחות עצמה, כולל השאלות של המשתמשים והתשובות שהמודל נתן. שמירה ארוכת טווח מאפשרת שיפור המערכת (fine-tuning, ניתוח דפוסי שימוש) אבל מגדילה את חשיפת הפרטיות ואת הנזק הפוטנציאלי מפריצה. מדיניות טובה מגדירה תקופות שימור שונות לפי סוג הדאטה - שיחות עם מידע רגיש נמחקות מוקדם יותר, בעוד מטא-דאטה אנונימית לצורך אנליטיקה נשמרת זמן ארוך יותר.

טעויות נפוצות בפרודקשן

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

מתי כדאי להשקיע ב-Data Governance מלא

לפרויקט פנימי קטן עם מספר מסמכים מוגבל, Data Governance פורמלי הוא לרוב מיותר - סקירה ידנית תקופתית מספיקה. אבל ברגע שמאגר הדאטה גדל, כשיש כמה צוותים שתורמים תוכן למאגר, או כשהמידע כולל דאטה רגיש של לקוחות, השקעה במסגרת Governance מובנית היא תנאי הכרחי לאמינות המערכת לטווח ארוך. ב-מדיה דיל אנחנו רואים ש-Data Governance הוא לעיתים קרובות ההשקעה הכי פחות 'מרשימה' אך בעלת ה-ROI הגבוה ביותר בפרויקטי RAG ארגוניים.

סיכום

Data Governance למערכות AI היא לא בירוקרטיה מיותרת - היא התשתית שקובעת אם המערכת תיתן תשובות אמינות ועדכניות או תשובות סותרות ומטעות. Lineage, סיווג, איכות ומדיניות שימור, כשמיושמים יחד, הם ההבדל בין מערכת AI שאפשר לסמוך עליה לבין מערכת שדורשת בדיקה ידנית של כל תשובה.

תגיות: Data Governance · Data Lineage · Data Classification · RAG · Data Quality · Data Retention · Enterprise AI

← חזרה לבלוג · צור קשר