האם אנחנו נותנים לסוכני AI יותר מדי כוח, מהר מדי?

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

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

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

ה-scope creep של הרשאות סוכן

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

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

למה זה קורה — לחצים שדוחפים לכיוון הלא נכון

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

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

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

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

מה קורה כשהמאזן הזה מופר

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

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

מסגרת מעשית: לגדול בכוח באיטיות מכוונת

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

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

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

המסקנה: מהירות בלי בשלות היא סיכון, לא יתרון

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

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

תגיות: AI governance · permission creep · least agency · agent autonomy · production drift

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