מי באמת שולט בסוכן: המשתמש, המודל או ספק התשתית?

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

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

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

שלוש שכבות שליטה, שלוש נקודות כשל

כשארגון בונה סוכן AI הוא בדרך כלל מגדיר system prompt, מצמיד לו כלים (APIs, גישה למסדי נתונים, יכולת לשלוח מיילים או לבצע פעולות בממשק), ומניח שזה מספיק כדי "לשלוט" בהתנהגות. בפועל, מתחת לשכבה הזו יושב מודל שאומן על ידי גוף חיצוני, עם משקלים שהארגון אינו רואה ואינו יכול לבדוק לעומק, ועם נטיות התנהגות שנקבעו במהלך אימון שלא הוא ביצע. מעל השכבה הזו יושב ספק תשתית — API של ספק מודל, פלטפורמת orchestration, שכבת caching — שיכול לשנות גרסת מודל, לעדכן מדיניות בטיחות, או לשנות זמינות פיצ׳ר בלי שהארגון יידע מראש.

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

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

האשליה של "אני כתבתי לו את ההוראות"

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

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

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

ספק התשתית כגורם שליטה שקוף מדי

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

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

מי אחראי כשמשהו קורה — ומה אומר הרישיון

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

המסקנה מכאן היא שהשאלה "מי שולט בסוכן" צריכה להיענות פעמיים: פעם אחת ברמה הטכנית (מי קובע התנהגות בפועל), ופעם שנייה ברמה הארגונית (מי נושא בתוצאות). כשהתשובות לשתי השאלות לא מיושרות — כלומר, ספק חיצוני שולט בהתנהגות אבל הארגון נושא בתוצאה — נוצר פער אחריות מסוכן. הדרך היחידה לסגור אותו היא לא לסמוך על "אמון" במודל, אלא לבנות שכבות בקרה אנושית במקומות הנכונים, נושא שאנחנו סוקרים בהרחבה במדריך על ארכיטקטורת human-in-the-loop.

אז מי באמת שולט?

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

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

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

תגיות: AI agents · אחריות · governance · control · least agency · AI infrastructure

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