סוכני AI בארגון: מה אסור לאוטומציה לעשות בלי אישור אנושי

האתגר החדש של סוכני AI: לא מה הם יכולים לעשות, אלא מה אסור להם לעשות

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

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

אוטונומיה בלי מסגרת היא חוב תפעולי

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

שינוי קטן בפונקציה, הוספת בדיקת יחידה או שיפור תיעוד הם פעולות הפיכות יחסית. לעומת זאת, מחיקת קבצים שלא נמצאים בבקרת גרסאות, שינוי הרשאות IAM, הרצת terraform apply, או ביצוע DROP בטבלת ייצור, הם אירועים שבהם מחיר הטעות עשוי להיות גבוה בהרבה מהרווח שבאוטומציה מלאה. לכן השאלה הראשונה לפני כל משימה אינה “האם הסוכן מסוגל”, אלא “האם אפשר לשחזר בקלות אם הוא טועה”.

רשימת האיסורים צריכה להיות קובץ עבודה, לא מדיניות מעורפלת

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

לצדו כדאי להחזיק קובץ פקודות חסומות, הכולל פעולות כמו rm -rf, git reset --hard, git clean -fd, git push --force, מחיקות או שינויים בבסיסי נתונים, פעולות Kubernetes הרסניות, שינויי הרשאות בענן וטיפול בקבצי סודות כמו env. עצם ההפרדה בין “מותר” ל”דורש אישור” הופכת את הסוכן מכלי חכם אך אימפולסיבי למשתתף ממושמע בתהליך הנדסי.

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

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

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

המסקנה למנהלים טכנולוגיים

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