AI Asset Inventory: איך בונים מלאי נכסי AI שתופס גם Shadow AI

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

מדריך ארכיטקטוני לבניית מלאי נכסי AI ארגוני - מודלים, prompts, agents ו-MCP servers - שמזהה Shadow AI לפני שהוא הופך לתקרית אבטחה.

הבעיה: אף אחד לא יודע כמה מודלים רצים אצלכם בפרודקשן

תשאלו CISO בארגון בינוני-גדול "כמה מודלי AI רצים היום בסביבת הפרודקשן שלכם" ותקבלו הערכה, לא מספר. מודל אחד ב-SageMaker, שניים ב-Vertex AI, שלושה fine-tuned checkpoints ששוכבים ב-S3 bucket ששכחו למחוק, עשרות אינטגרציות ל-OpenAI ול-Anthropic דרך API keys שהופצו בין צוותים, ו-Copilot/Cursor שכל מפתח מפעיל מקומית עם גישה לקוד הפרטי. זו לא תיאוריה - זו התמונה הריאלית ברוב הארגונים שמריצים AI בקנה מידה, וההשלכה הישירה שלה היא Shadow AI: נכסי AI שקיימים ופועלים בלי שאף גורם מרכזי מודע להם, מנהל אותם, או יודע איזה מידע עובר דרכם.

AI Asset Inventory הוא התשתית שפותרת בדיוק את זה: מאגר מרכזי, מתעדכן אוטומטית, של כל נכס AI בארגון - מודלים, datasets, prompts, agents, vector stores, MCP servers ו-API keys - עם metadata עשיר מספיק כדי לענות בזמן אמת על שאלות כמו "אילו מודלים ניגשים לנתוני PII", "מי הבעלים של ה-agent הזה", ו"מתי בפעם האחרונה בוצע red team לשירות הזה".

מה בדיוק נכלל ב-Inventory - ולמה זה שונה מ-CMDB רגיל

CMDB קלאסי (Configuration Management Database) בנוי סביב שרתים, VMs, ורכיבי תשתית עם מחזור חיים איטי יחסית. נכסי AI מתנהגים אחרת לגמרי: מודל יכול להתעדכן כל שבוע, prompt template משתנה בכל deploy, ו-agent יכול לרכוש יכולות חדשות (tools נוספים) בלי שום שינוי בקוד - רק על ידי חיבור MCP server נוסף. לכן מלאי AI צריך לעקוב אחרי קטגוריות שאין ל-CMDB מסורתי מושג עליהן:

Models - כולל foundation models חיצוניים (עם ספק, גרסה, ותאריך cutoff), מודלים מכווננים (fine-tuned) עם lineage מלא לדאטה שעליו אומנו, ו-embeddings models.
Datasets ו-vector stores - מקור הנתונים, סיווג רגישות (PII, PHI, סודות מסחריים), ומי מעדכן אותם.
Prompts ו-system instructions - גרסאות, בעלים, והיסטוריית שינויים - כי שינוי ב-system prompt הוא שינוי התנהגותי מהותי בדיוק כמו deploy של קוד.
Agents ו-tool chains - אילו כלים (tools) לכל agent יש הרשאה להפעיל, ואיזה scope הרשאות יש לו בפועל.
MCP servers וחיבורי API - כל endpoint חיצוני שה-AI stack שלכם מדבר איתו, כולל credentials וה-rotation policy שלהם.

ארכיטקטורה: איך בונים Discovery שבאמת תופס הכל

הבעיה המרכזית ב-inventory היא לא האחסון - זו שאלת ה-discovery. אי אפשר לבקש מצוותים "לדווח" על נכסי AI ולצפות לכיסוי אמיתי; חייבים discovery אקטיבי ופסיבי במקביל:

Discovery פסיבי (Network ו-Traffic Analysis)

הצבת proxy או sidecar ברמת ה-egress traffic (למשל דרך API gateway מרכזי או Envoy sidecar ברמת ה-mesh) שמזהה קריאות ל-domains ידועים של ספקי AI - api.openai.com, api.anthropic.com, generativelanguage.googleapis.com וכו' - ומתעד אותן אוטומטית. זו השיטה היחידה שתופסת Shadow AI אמיתי: מפתח שהתקין SDK והפעיל אותו בלי לדווח לאף אחד.

Discovery אקטיבי (API-based Scanning)

סריקה תקופתית מול ה-control planes של ספקי הענן והמודלים - AWS Bedrock, Azure OpenAI, Vertex AI, פלטפורמות MLOps כמו MLflow או Weights & Biases - כדי לקבל רשימה מוסמכת של מודלים שנפרסו, כולל תגיות owner, environment, ו-data-classification. זה נותן "ground truth" שאפשר להצליב מול הממצאים הפסיביים.

אינטגרציה עם CI/CD

כל pipeline שמפרסם מודל, prompt, או agent חדש צריך "לרשום" את עצמו במלאי כחלק מה-deployment gate - בדיוק כמו ש-SBOM (Software Bill of Materials) נוצר אוטומטית בכל build. זה מבטיח שנכסים חדשים נכנסים למלאי מהיום הראשון, במקום להתגלות רק בסריקה הבאה.

סכימת נתונים: מה חייב להיות בכל רשומת נכס

רשומת inventory שלא כוללת שרשרת אחריות (ownership chain) ותלותיות (dependencies) היא בקושי טובה יותר מגיליון Excel. סכימה מינימלית שעובדת בפרודקשן כוללת:

{
  "asset_id": "model-fraud-detector-v14",
  "type": "fine-tuned-model",
  "base_model": "gpt-4o-mini-2024-07-18",
  "owner_team": "risk-eng",
  "data_classification": "PII-high",
  "training_data_lineage": ["ds-transactions-2025q4"],
  "deployed_environments": ["prod-eu", "staging"],
  "connected_tools": ["mcp-payments-readonly"],
  "last_red_team_date": "2026-06-02",
  "vulnerability_status": "clean",
  "access_scope": ["risk-eng", "compliance-audit"]
}

שימו לב לשדה connected_tools - זו נקודת ההצטלבות הקריטית עם עולם ה-MCP וה-agents: מודל שמחובר לכלי שיכול לבצע פעולות (לא רק לקרוא מידע) הוא נכס בסיכון גבוה משמעותית ממודל שרק עונה על שאלות, וה-inventory חייב לשקף את זה בדירוג הסיכון.

Trade-offs מרכזיים בבחירת ארכיטקטורת המלאי

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

מרכזי מול מבוזר - מאגר מרכזי אחד נותן שליטה ונראות טובה יותר, אבל הופך לצוואר בקבוק ול-single point of failure תפעולי. גישה מבוזרת (כל domain team מנהל את המלאי שלו עם federation ברמת query) קנה מידה טוב יותר בארגונים גדולים אבל דורשת סכימה משותפת מוקפדת.
Real-time מול Batch - discovery בזמן אמת (streaming מה-egress proxy) תופס Shadow AI מהר יותר אך יקר יותר חישובית ודורש תשתית stream processing. batch יומי זול יותר אבל משאיר חלון חשיפה של עד 24 שעות.
Push מול Pull - לדרוש מצוותים לדווח (push, דרך CI/CD gate) הוא זול ומדויק כשעובד, אבל תלוי בציות; discovery יזום (pull, סריקות אקטיביות) עצמאי מציות אבל דורש הרשאות רחבות יותר ברחבי הארגון, מה שיוצר בעיה אבטחתית בפני עצמה.

מודל בעלות (Ownership Model) ותהליך אישור שינויים

נכס בלי בעלים ברור הוא נכס שאף אחד לא אחראי עליו כשמתגלה חולשה. לכן חלק בלתי נפרד מארכיטקטורת המלאי הוא מודל בעלות שמוגדר ברמת ה-schema, לא רק כתיוג רשלני: לכל נכס יש owner team (הצוות שאחראי תפעולית), data steward (מי שאחראי על הרגישות של הנתונים שהנכס נוגע בהם), ו-approver (מי שצריך לאשר שינויים מהותיים כמו הוספת tool חדש או שינוי ב-scope הרשאות). כשמתגלה חולשה - נניח, גרסת מודל עם חשיפה ל-jailbreak ידוע - המערכת צריכה להיות מסוגלת לשלוח התראה ממוקדת לבעלים הנכון תוך שניות, במקום לפתוח ticket כללי שמתגלגל בין צוותים ימים שלמים לפני שמישהו לוקח אחריות.

מעבר לכך, שינויים מהותיים בנכס - כמו הענקת tool חדש ל-agent או חיבור dataset חדש עם PII - צריכים לעבור דרך workflow אישור מובנה במלאי עצמו, ולא רק ב-PR review רגיל בקוד. הסיבה: PR review בודק אם הקוד עובד, אבל לא בהכרח שואל "האם ל-agent הזה מותר, מבחינת מדיניות ארגונית, לגשת למאגר הזה". הפרדת השאלות האלה - נכונות טכנית מול התאמה למדיניות - היא בדיוק התפקיד של שכבת המלאי.

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

הטעות הכי שכיחה היא לבנות inventory שמכסה רק מודלים ומתעלם מ-prompts ו-tool bindings - וזה בדיוק המקום שבו מתרחשים רוב תקריות ה-2026: לא המודל עצמו התעדכן והתחיל להתנהג אחרת, אלא ה-system prompt או רשימת הכלים המחוברים אליו. טעות שנייה היא לתת ל-inventory "לרקוב" - לבנות אותו כפרויקט חד-פעמי במקום כתהליך רציף עם SLA לעדכון (למשל: כל נכס שלא עודכן ב-30 יום מסומן כ-stale ונבדק מחדש). טעות שלישית, ואולי הכי יקרה: להתייחס למלאי ככלי דיווח בלבד ולא לחבר אותו ל-enforcement - אם מלאי מזהה נכס בסיכון גבוה אבל אין מנגנון שחוסם או מגביל אותו אוטומטית, הערך המעשי מוגבל מאוד.

מתי כן להשקיע ב-inventory ייעודי, ומתי זה overkill

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

ארגון עם פחות מחמישה מודלים בפרודקשן וצוות AI קטן ומרוכז כנראה לא צריך פלטפורמת inventory ייעודית - גיליון מנוהל עם review רבעוני מספיק. אבל ברגע שיש יותר מצוות אחד שבונה עם AI, יש רגולציה רלוונטית (GDPR, ISO 42001, EU AI Act), או שיש שימוש ב-agents עם יכולת לבצע פעולות (ולא רק לענות), הצורך במלאי אוטומטי הופך לקריטי - כי הסיכון האמיתי הוא לא "מודל לא רשום", אלא agent לא רשום עם הרשאות כתיבה למסד נתונים ייצור.

איך זה נראה אצלנו

במדיה דיל אנחנו בונים שכבת discovery כזו כחלק בסיס מכל פרויקט agentic שאנחנו מוציאים לפרודקשן - לא כתוסף בדיעבד. זה אומר שכל MCP server וכל tool binding נרשמים אוטומטית ב-pipeline של הפריסה, כדי שהלקוח מקבל תמונת מלאי חיה מהיום הראשון ולא צריך לגלות אחרי תקרית מי בדיוק חיבר את מה.

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

מלאי טוב לא נמדד רק ב"כמה נכסים רשומים" אלא בכמה טוב הוא משקף את המציאות. שלושה מדדים מעשיים ששווה להציג בדשבורד ניהולי: Coverage Ratio - היחס בין נכסים שהתגלו ב-discovery פסיבי לבין נכסים שנרשמו דרך תהליך ה-push המסודר (פער גדול מעיד על Shadow AI פעיל); Staleness Rate - אחוז הנכסים שלא עודכנו מעל 30 יום, שמעיד על כמה המלאי "חי" בפועל; ו-Ownership Gap - אחוז הנכסים בלי בעלים מוגדר, שהוא לרוב האינדיקטור החזק ביותר לסיכון תפעולי, כי נכס בלי בעלים הוא נכס שאף אחד לא יתקן כשהוא נשבר או ייסגר כשהוא כבר לא נחוץ.

מעבר למדדים, שווה להטמיע תהליך רבעוני של "Inventory Reconciliation" - השוואה ידנית מדגמית בין מה שהמלאי האוטומטי מדווח לבין מה שבאמת רץ בסביבה, בדומה ל-cycle count במחסן פיזי. זה חושף פערים שה-discovery האוטומטי מפספס, כמו נכסים שרצים בסביבות פיתוח מבודדות (air-gapped) שה-proxy המרכזי לא רואה אותן, או אינטגרציות ownCloud/on-prem שלא עוברות דרך ה-egress הסטנדרטי.

אינטגרציה עם שכבות אבטחה אחרות

מלאי שחי בבידוד, בלי לדבר עם שאר מערך האבטחה, מפספס חלק גדול מהערך שלו. האינטגרציה החשובה ביותר היא עם ה-SIEM הארגוני: כל אירוע ב-inventory (נכס חדש שהתגלה, שינוי הרשאות, נכס שהפך stale) צריך לזרום כאירוע מובנה ל-SIEM, כדי שצוות ה-SOC יוכל לתאם בין תנועה במלאי לבין אנומליות בתעבורה או ב-logs. אינטגרציה שנייה, פחות מובנת מאליה אך קריטית, היא עם מערכת ניהול הזהויות (IAM/IGA): הרשאות ה-tool-calling של agent הן בעצם זהות מכונה (machine identity), וצריך שהן יעברו את אותו מחזור חיים כמו כל זהות אחרת - יצירה, review תקופתי, וביטול אוטומטי כשה-agent מוצא משימוש. ארגונים שמנהלים הרשאות agent בנפרד לגמרי מתהליך ה-IAM הרגיל שלהם מוצאים את עצמם עם "orphaned permissions" שאף אחד לא זוכר למה הן קיימות.

סיכום

AI Asset Inventory הוא לא פרויקט תיעוד - הוא תשתית האכיפה שכל שאר בקרות אבטחת ה-AI נשענות עליה. אי אפשר לעשות threat modeling, red teaming, או patch management על נכסים שאתם לא יודעים שקיימים. הבנייה הנכונה משלבת discovery פסיבי ואקטיבי, סכימת נתונים שמכסה גם prompts וגם tool bindings, ותהליך רציף - לא פרויקט חד-פעמי - עם חיבור ישיר למנגנוני אכיפה.

תגיות: AI Asset Inventory · Shadow AI · AI governance · CMDB · MLOps · model registry · AI-BOM

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