סוכני AI עם בלם חירום: הקריאה של סאטיה נדלה והמבחן הארגוני
סוכן AI שמבצע פעולות בארגון חייב להיות ניתן לעצירה בידי אדם מוסמך, בלי להסתמך על הסכמת המודל עצמו. אבל כפתור עצירה הוא רק הממשק. מאחוריו נדרשים מנגנונים שחוסמים פעולות נוספות, מבטלים הרשאות לפי הצורך ומשאירים תיעוד ברור של מה שכבר קרה.
הקריאה של סאטיה נדלה לתכנן סוכנים שניתן לעצור במהלך משימה מחדדת שאלה עסקית: האם הארגון שולט בתהליך, או רק מקווה שהמודל יפעל נכון? מבחינת מנהלים בישראל, זו אינה סיבה להקפיא את אימוץ ה-AI. זו סיבה להפסיק להתייחס להדגמה מוצלחת כהוכחה למוכנות לייצור.
מה הקריאה של נדלה משנה בפועל?
שלושת העקרונות שהציג נדלה, לפי הדיווח, הם הפרדה בין המודל למנגנון שמנהל את פעולותיו, תיעוד עמיד לשינויים של פעולות משמעותיות ויכולת עצירה בידי אדם מוסמך. המשמעות המשותפת שלהם ברורה: השליטה בסוכן צריכה להיות חלק מהמערכת, לא הבטחה בתוך הפרומפט.
מודל יכול להבין מסמך, להציע החלטה ולבחור כלי. הוא לא צריך להיות הסמכות היחידה שקובעת אם מותר לבצע העברה כספית, לשנות פרטי ספק או לשלוח מידע מחוץ לארגון. החלטות כאלה דורשות מדיניות שהמערכת אוכפת גם כאשר המודל טועה.
ההבחנה הזאת חשובה משום שסוכן אינו רק חלון שיחה. הוא עשוי להפעיל שירותים, לכתוב למערכות וליצור משימות שממשיכות לרוץ לאחר שהשיחה הסתיימה. עצירת התשובה על המסך אינה בהכרח עצירת התהליך העסקי.
בלם חירום לא מחזיר את הכסף לחשבון
נניח שסוכן מטפל בבקשות לעדכון פרטי ספק. הוא קורא הודעת דוא״ל, משווה אותה למסמכים קיימים ומכין שינוי במערכת הכספים. אם התגלתה התחזות, עצירה צריכה למנוע את העדכון ואת הפעולות שתלויות בו. אם התשלום כבר הועבר, העצירה לא תחזיר אותו אוטומטית.
לכן יש להפריד בין עצירה, ביטול פעולה ממתינה ותיקון פעולה שכבר בוצעה. אלה יכולות שונות, ולעיתים גם בעלי תפקידים שונים אחראים עליהן.
- עצירה מונעת מהסוכן להתחיל פעולות נוספות.
- ביטול מנסה לעצור בקשות שכבר נשלחו, אם המערכת המקבלת מאפשרת זאת.
- תיקון מטפל בתוצאה קיימת, למשל שחזור רשומה או פתיחת תהליך להשבת תשלום.
- חידוש פעילות דורש בדיקה שהתקלה טופלה ושהרשאות הסוכן עדיין מתאימות.
את ההתנהגות הזאת צריך לבדוק בתרחישי כשל, לא רק לתאר במסמך אפיון. אם סוכן ממשיך לפעול דרך משימות רקע לאחר שנעצר, הארגון קיבל כפתור עם תחושת ביטחון, לא שליטה.
הארכיטקטורה: המודל מציע, המערכת מאשרת
הפרדה בין המודל לבין שכבת ניהול הפעולות מאפשרת להחליף מודל בלי לשכתב את כל כללי הבקרה. חשוב יותר, היא מאפשרת להחיל כללים עסקיים באופן עקבי: אילו כלים זמינים, מי רשאי לאשר חריגה ואילו פעולות אסורות לחלוטין.
ביישום נכון, פעולה עוברת דרך בדיקת הרשאות ומדיניות לפני ביצועה. הבדיקה יכולה להתייחס לסוג הפעולה, לרגישות המידע, למצב התהליך ולצורך באישור אנושי. בפעולות רגישות כדאי לבדוק את ההרשאה שוב סמוך לביצוע, כדי ששינוי מדיניות או עצירה לא יישארו חסרי השפעה.
| רכיב | פתרון שברירי | פתרון בשל |
|---|---|---|
| הרשאות | חשבון משותף רחב | הרשאות מצומצמות לסוכן |
| עצירה | הודעה בשיחה | חסימה בשכבת הביצוע |
| אישורים | שיקול דעת המודל בלבד | כללים עסקיים מוגדרים |
| תיעוד | היסטוריית שיחה | יומן פעולות מוגן |
| התאוששות | הפעלה מחדש | בדיקה וחידוש מבוקר |
הפער בטבלה אינו בין מודל חלש למודל חזק. הוא בין מערכת שמבקשת מהמודל להתנהג יפה לבין מערכת שמגבילה את הנזק האפשרי גם כשאינו עושה זאת.
מה צריך להופיע ביומן הפעולות?
תיעוד שימושי כולל את זהות הסוכן, גרסת התצורה, הפעולה שהתבקשה, תוצאת בדיקת המדיניות, אישור שניתן והתגובה מהמערכת המקבלת. הוא צריך להיות קריא לבעלי התהליך העסקי, ולא רק למפתחים.
אין צורך לחשוף תהליך חשיבה פנימי של המודל כדי להשיג שקיפות תפעולית. צריך לדעת מה בוצע, על סמך איזה מידע, באיזו הרשאה ומה הייתה התוצאה. את היומן יש להגן מפני שינוי בדיעבד, אך גם לצמצם בו מידע אישי וסודות עסקיים. תיעוד ביקורת אינו היתר להעתיק כל מסמך רגיש למאגר נוסף.
אדם בלולאה, בלי להפוך אותו לצוואר בקבוק
אישור אנושי לכל פעולה נראה בטוח, אבל עלול למחוק את התועלת התפעולית. אם עובד עדיין בודק כל מקרה באותה רמת פירוט, הארגון הוסיף מערכת בלי לשנות באמת את יכולת הביצוע שלו.
היעד הוא פיקוח מבוסס סיכון. פעולות שגרתיות והפיכות יכולות להתבצע אוטומטית בתוך גבולות מוגדרים. פעולות חריגות, רגישות או קשות לתיקון עוברות לאדם. לצד זאת נדרשות בדיקות מדגמיות, כדי לזהות כשלים שלא הפעילו התראה.
אדם בלולאה אינו אדם שמאשר הכול. הוא אדם שמחזיק בסמכות, בהקשר ובכלים להתערב במקום שבו שיקול הדעת שלו משנה את התוצאה.
כדי שהפיקוח יהיה אפקטיבי, העובד צריך לראות את החריגה ואת ההקשר שלה, לא לקרוא שיחה שלמה ולנחש מה השתבש. כאן נפגשים ידע ב-AI, הבנת התהליך המקצועי וניסיון ניהולי. תכנון טוב של ממשק אישור חשוב לא פחות מבחירת המודל.
מה מנהלים בישראל צריכים לדרוש לפני פריסה?
אין צורך לחכות למדיניות ענפית מלאה כדי להגדיר תנאי קבלה פנימיים. מנהל כספים, מנהלת תפעול ומנהל מערכות מידע צריכים להסכים מראש על גבולות הסוכן, על אחריות לפיקוח ועל התנהגות בזמן תקלה.
ממפים פעולות וסיכונים
מזהים מה הסוכן רשאי לשנות, איזה מידע הוא נחשף אליו ומה קשה להחזיר לאחור.
מגדירים סמכות וגבולות
קובעים בעל תהליך, הרשאות, תנאי אישור וזהות הגורמים המוסמכים לעצור.
בודקים עצירה תחת עומס
מוודאים מה קורה לפעולות פעילות, למשימות ממתינות ולמערכות המשך בזמן עצירה.
פורסים ומודדים בהדרגה
מרחיבים פעילות רק לאחר בחינת התוצאות העסקיות, החריגות ועלות הפיקוח.
הסדר הזה מונע טעות נפוצה: לחבר סוכן למערכות ייצור ואז לנסות להוסיף לו ממשל בדיעבד. הבדיקה צריכה לכלול גם טעויות בנתונים, כשל בשירות חיצוני וניסיון לגרום לסוכן לחרוג מהרשאותיו באמצעות תוכן שהוא קורא.
מבחינה פיננסית, המדד אינו רק כמה זמן הסוכן חסך. צריך להביא בחשבון את עלות הבדיקה האנושית, הטיפול בחריגות, תיקון השגיאות והתשתית. סוכן מהיר שמייצר תור חדש של בדיקות אינו בהכרח השקעה טובה.
יכולת פנימית חשובה יותר מהבטחת הספק
Microsoft Copilot Studio, פלטפורמות כמו n8n או פיתוח ייעודי יכולים לשמש בסיס לסוכנים. אף בחירת מוצר אינה פוטרת את הארגון מבדיקת הרשאות, תיעוד ועצירה בתהליך המסוים שלו. גם העדפה ל-Claude או למודל אחר אינה תחליף לבחינת אבטחת מידע והתאמה עסקית.
לכן כדאי לפתח יכולת פנימית להקמה ולניהול סוכנים, במקביל להכשרת העובדים בתקשורת עם מודלים ובזיהוי מגבלותיהם. אלה שני מסלולים משלימים: אוריינות משפרת את עבודת האדם עם AI; תשתית סוכנים מאפשרת לבצע תהליכים בתוך סביבת העבודה הקיימת.
בחירת צוות ההטמעה דורשת יותר מהדגמה מרשימה. השכלה רלוונטית, בסיס מחקרי וניסיון עסקי ויישומי מסייעים להבין לא רק איך לבנות סוכן, אלא מתי לא לתת לו לפעול לבד. לעסקים קטנים ובינוניים, שאין להם תמיד שכבות בקרה פנימיות, ההבחנה הזאת חשובה במיוחד.
השאלה הנכונה להנהלה אינה רק מה הסוכן מסוגל לעשות. היא מי מוסמך לעצור אותו, מה באמת ייעצר ומה יידרש כדי לחזור לעבודה. ארגון שיודע לענות על השאלות האלה יכול להרחיב אוטומציה בביטחון מבוסס, במקום להחליף שליטה בתקווה.
