RAG Data Governance: מסגרת עבודה לניהול מקורות, לינאז' ואחריות בסביבת RAG ארגונית

מאת צוות מדיה דיל · 04.08.2026 · Data Engineering · 10 דק׳

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

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

למה Governance ל-RAG שונה מ-Governance רגיל

ארגונים רבים כבר משתמשים במדיניות Data Governance קלאסית — סיווג רגישות, מדיניות שימור, בעלות על נתונים. אבל RAG מוסיף שכבת מורכבות ייחודית: המידע לא נשאר בטבלה מסודרת עם סכמה ברורה, הוא מתפרק ל-chunks, עובר טרנספורמציה לוקטורים, ומאבד חלק מהקשר המקורי שלו בתהליך. שאלת "מאיפה הגיע המידע הזה בתשובה שהמודל נתן" הופכת קשה בהרבה כשצריך לעקוב מ-token שנוצר על ידי LLM, דרך chunk שהוחזר מ-retrieval, חזרה למסמך המקור והגרסה שלו. בלי מנגנון לינאז' מכוון מטרה, כל חקירה של תשובה בעייתית הופכת לחפירה ארכיאולוגית.

מי בכלל "בעל" ה-Governance: תפקיד חדש או הרחבת תפקיד קיים

שאלה ארגונית שמתעוררת מהר: האם צריך תפקיד חדש לגמרי — AI Data Governance Owner — או שאפשר להרחיב תפקיד קיים כמו Data Protection Officer או Head of Data? התשובה תלויה בהיקף החשיפה. בארגון קטן, אחראי Governance קיים (אם יש) יכול פשוט להוסיף RAG לתחום האחריות שלו, בתנאי שהוא מבין את המאפיינים הייחודיים שתוארו למעלה — במיוחד את עניין ה-chunking שמפרק מסמכים למקטעים שקשה לעקוב אחריהם בלי כלים ייעודיים. בארגון גדול עם הרבה מקורות ידע ומודלים מרובים, שווה למנות בעלים ייעודי, כי המורכבות של תיאום בין צוותי תוכן, אבטחת מידע והנדסה גדולה מכדי להיות "תוספת" לתפקיד עמוס אחר. בכל מקרה, הבעלות חייבת להיות מוגדרת במפורש בכתב — לא "כולם אחראים ביחד", שבפועל אומר שאף אחד לא אחראי.

לינאז' (Lineage): מעקב מלא מ-Source ועד Response

מנגנון לינאז' תקין דורש ששלושה סוגי מזהים ילוו כל chunk לאורך כל חייו: מזהה מקור (source_id — איזו מערכת, איזה קונקטור), מזהה מסמך וגרסה (document_id + version_hash), ומזהה chunk עצמו. כשה-LLM מייצר תשובה, שכבת ה-orchestration אמורה לתעד אילו chunks בדיוק שימשו לבניית ה-context, ולצרף לוג הניתן לשליפה: "תשובה X נבנתה מ-chunks Y ו-Z, שמקורם במסמך A גרסה 14, שמקורו במערכת Confluence, שעודכן לאחרונה בתאריך כך וכך". תיעוד כזה הופך חקירת תשובה שגויה מניחוש למעקב עובדתי, ומאפשר גם audit trail מלא לצרכי תאימות רגולטורית — נושא קריטי בתחומים כמו פיננסים ובריאות.

בעלות ותוקף: מי אחראי על כל פיסת מידע

שאלה שרוב הצוותים לא שואלים מספיק מוקדם: כשמסמך מדיניות מתעדכן, מי אחראי לוודא שהגרסה הישנה מוסרת מהאינדקס? התשובה הנכונה היא לקבוע Data Owner לכל מקור ידע — בדרך כלל בעל התוכן המקורי (למשל צוות משאבי אנוש עבור מסמכי מדיניות), לא צוות ה-AI. ה-Owner אחראי על נכונות התוכן ועל עדכון תאריך תוקף (expiry) כשרלוונטי. שכבת ה-Governance אחראית לוודא שהמערכת הטכנית מכבדת את תאריכי התוקף האלה — chunk שפג תוקפו לא אמור להיכלל ב-retrieval, גם אם הוא עדיין קיים פיזית באינדקס. הפרדת האחריות הזו — תוכן מול תשתית — מונעת מצב נפוץ שבו "אף אחד לא באמת מרגיש בעלות" על נכונות מה שהבוט אומר.

סיווג רגישות ומדיניות שימור

לא כל מידע צריך להיכנס ל-RAG באותה רמת אמון. מסגרת Governance בשלה מגדירה רמות סיווג (ציבורי, פנימי, סודי, מוגבל) שנקבעות כבר בשלב ה-ingestion ומלוות את ה-chunk כ-metadata. הרמה הזו קובעת גם מי רשאי לראות אותו בתשובה (ראו הרחבה במאמר על בקרת גישה ב-RAG), וגם כמה זמן הוא נשמר. מדיניות שימור (Retention Policy) קובעת מתי chunk מבוטל אוטומטית — למשל, טרנסקריפט שיחת תמיכה שיש חובה חוקית למחוק לאחר תקופה מסוימת, חייב להימחק גם מהאינדקס הוקטורי, לא רק מהמקור המקורי. פספוס הזה הוא נקודת כשל נפוצה בביקורות תאימות: הארגון "מוחק" נתון כנדרש, אבל שוכח שיש עותק וקטורי שלו שממשיך לחיות באינדקס.

Human-in-the-Loop: אימות ואישור לפני כניסה לאינדקס

עבור מקורות מידע רגישים או בעלי השפעה גבוהה (מדיניות משפטית, מחירון רשמי), הגישה הבשלה יותר היא לא לתת לכל מסמך להיכנס אוטומטית לאינדקס, אלא להטמיע שלב אישור אנושי — Staging Area שבו מסמך חדש ממתין לאישור לפני שהוא הופך לחלק מהקורפוס החי. זה מוסיף חיכוך, אבל עבור מקורות בעלי סיכון גבוה זה חיוני: מסמך טיוטה שהוזן בטעות לתיקייה הלא נכונה לא אמור להפוך אוטומטית למקור אמת עבור עוזר AI שעונה ללקוחות. מנגנון סביר בפועל הוא לקבוע רשימת "מקורות מהימנים" (trusted sources) שעוברים ingestion אוטומטי מלא, ורשימת "מקורות בבדיקה" (staged sources) שדורשים אישור ידני בכל הוספה — כאשר ההחלטה לאיזו רשימה מסמך שייך נקבעת לפי רמת הסיכון של המקור כולו ולא לפי כל מסמך בנפרד, כדי לא להפוך את התהליך לצוואר בקבוק תפעולי.

ביקורת (Audit) תקופתית ומדדי בריאות

מסגרת Governance שלא נבדקת היא מסגרת שקיימת רק על הנייר. ביקורת תקופתית — למשל רבעונית — צריכה לבדוק שלושה דברים: האם כל מקור ידע פעיל עדיין רשום לבעלים תקף (Owner שעדיין עובד בארגון ומודע לאחריותו), האם יש chunks באינדקס שחורגים ממדיניות השימור שלהם (כלומר היו אמורים להימחק אך לא נמחקו), והאם סיווג הרגישות שנקבע בזמן ה-ingestion עדיין תואם את המציאות (מסמך שהיה "פנימי" והפך "סודי" בעקבות אירוע, לדוגמה). ארגונים שמטמיעים דשבורד בריאות Governance — לא רק דשבורד ביצועים טכני — מגלים בעיות כאלה הרבה לפני שהן הופכות לאירוע תאימות ממשי, וזה משנה את היחס למערכת מ"תוכנה" ל"תשתית מבוקרת".

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

הטעות הנפוצה ביותר: לטפל ב-Governance כפרויקט חד-פעמי ("סיווגנו את המסמכים בהתחלה") ולא כתהליך שוטף — מקורות חדשים ותוכן חדש נכנסים כל הזמן, ובלי אכיפה אוטומטית של מדיניות הסיווג, המערכת "נסחפת" עם הזמן. השנייה: היעדר קישור בין מדיניות שימור ארגונית לבין האינדקס הוקטורי בפועל, מה שיוצר פער תאימות. השלישית: לינאז' חלקי — תיעוד מאיפה הגיע ה-chunk אבל לא איזו גרסת מודל embedding ואיזה prompt template שימשו לבניית התשובה, מה שמקשה על שחזור מדויק של אירוע בעייתי. הרביעית: הטלת כל האחריות על צוות ה-AI, בלי לערב את בעלי התוכן המקוריים — מה שמוביל לכך שאף אחד לא באמת בודק אם המידע שמוזן עדיין נכון. טעות חמישית, שכיחה במיוחד בארגונים גדולים: לבנות מדיניות Governance מפורטת מאוד על הנייר, אך בלי אכיפה טכנית אוטומטית — מדיניות שתלויה בכך שמישהו "יזכור" לעדכן שדה, ולא באכיפה מבנית שהמערכת פשוט לא מאפשרת לעקוף, כמעט תמיד נשחקת תוך חודשים ספורים.

מתי להשקיע במסגרת Governance מלאה

לא כל פרויקט RAG זקוק ל-Governance מלא מהיום הראשון. כלי פנימי קטן לצוות של עשרה אנשים, על מסמכים לא רגישים, יכול להתחיל פשוט. אבל ברגע שיש חשיפה ללקוחות חיצוניים, מידע רגיש, או דרישות רגולטוריות (GDPR, HIPAA, תקנות ישראליות בתחום הפרטיות) — Governance הוא לא "nice to have" אלא תנאי סף. הסימן הברור: אם מישהו בארגון שואל "מה קורה אם המערכת חושפת מידע שלא הייתה אמורה" ואין תשובה ברורה — זה הזמן להשקיע. שיקול נוסף הוא גודל צוות התוכן: ככל שיותר אנשים מוסיפים ומעדכנים מקורות ידע בעצמם (ולא רק צוות טכני מרכזי), כך גדל הסיכון שמישהו יעלה בטעות מסמך רגיש למקור לא מתאים — ואז אכיפה אוטומטית של סיווג הופכת קריטית יותר מאשר בארגון עם מספר מצומצם של אנשי תוכן מיומנים.

ממשקי בקרה: מי בפועל מפעיל את המדיניות

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

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

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

הטמעת Governance סביב RAG לא חייבת להתחיל מגיליון אקסל עם רשימת מקורות. כלי Data Catalog קיימים כמו Collibra, Alation או הפתרון הקוד-פתוח DataHub כבר תומכים במושגים של בעלות, סיווג רגישות ולינאז' ברמת מסד נתונים — ואפשר להרחיב אותם כדי לכלול גם מקורות RAG כאזרח שווה-מעמד לצד טבלאות SQL רגילות. עבור לינאז' ברמת אירוע (איזה chunk שימש לאיזו תשובה), פרויקטים כמו OpenLineage נותנים תקן פתוח שמאפשר לשלב מעקב לינאז' ישירות בתוך שכבת ה-orchestration של הפייפליין, בלי לבנות פתרון תיעוד קנייני מאפס. גם שכבת ה-Vector DB עצמה יכולה לשאת חלק מהעומס: רוב הפלטפורמות המודרניות תומכות ב-metadata עשיר שיכול לכלול document_owner, sensitivity_level ו-expiry_date ישירות על כל chunk, כך שאכיפת מדיניות שימור יכולה להיעשות כ-scheduled job פשוט שסורק ומוחק chunks שפג תוקפם, בלי מערכת Governance נפרדת ומורכבת. הבחירה הנכונה תלויה בהיקף: ארגון קטן יכול להסתפק בשדות metadata פשוטים ותהליך רבעוני ידני, בעוד ארגון גדול עם דרישות תאימות מחמירות ירוויח מהשקעה בכלי Catalog ייעודי שמספק גם ממשק לבעלי תוכן לא-טכניים וגם API לאכיפה אוטומטית.

סיכום

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

תגיות: Data Governance · RAG · Data Lineage · Compliance · Data Ownership · Retention Policy · GDPR

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