מה קורה כשחברה בונה 50 סוכנים ואף אחד לא יודע מה כולם עושים

מאת צוות מדיה דיל · 12.08.2026 · AI Opinion · 6 דק׳

כלים לבניית סוכני AI הפכו כל כך נגישים, שארגונים מוצאים את עצמם עם עשרות סוכנים בפרודקשן בלי מרשם מרכזי, בעלות ברורה או משילות — Shadow IT בגרסה מסוכנת בהרבה.

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

דג'ה וו: זה כבר קרה עם Shadow IT

מי שעבד בתחום התוכנה מספיק זמן מזהה את הדפוס הזה מיד — זו בדיוק אותה תופעה שנקראה Shadow IT לפני עשור וחצי, רק עם מסה קריטית וסיכון גבוהים בהרבה. אז זה היה עובד שמתקין תוסף לא מאושר לדפדפן, או צוות שיוצר Google Sheet משותף עם נתוני לקוחות בלי לדווח ל-IT. הנזק היה אמיתי אבל מוגבל, כי הכלים עצמם היו פסיביים יחסית.

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

הסיכונים הקונקרטיים שנוצרים מ-Agent Sprawl

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

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

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

למה זה קורה: התמריצים של כלים שהופכים בנייה לקלה מדי

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

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

איך נראית משילות סוכנים שעובדת בפועל

הפתרון לא צריך להיות עצירת החדשנות — זה יהרוג בדיוק את היתרון שהביא לפיצוץ בבניית סוכנים מלכתחילה. הפתרון הוא מרשם מרכזי: כמו CMDB (Configuration Management Database) שקיים כבר עשורים בעולם ה-IT, ארגונים צריכים "רישום סוכנים" חי שמתעד לכל סוכן פעיל מי הבעלים שלו, אילו הרשאות יש לו, אילו מערכות הוא נוגע בהן, ומתי נבדק לאחרונה. זה לא שונה במהותו ממה שכל צוות DevOps בוגר עושה כבר עם שירותים ותשתיות — פשוט צריך להחיל את אותו משמעת על סוכני AI, כולל תיוג ברור, בעלים אחראי, ותהליך אישור לפני עלייה לפרודקשן.

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

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

מי בארגון בכלל אמור לבעלים את הבעיה הזו

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

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

הבחירה שכל ארגון גדל צריך לקבל בכוונה

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

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

תגיות: Agent Sprawl · Shadow AI · AI Governance · AI Opinion · agent registry

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