מיקרוסופט מציגה Guardian Agents לפיקוח על סוכני AI
מיקרוסופט מרחיבה את Project Perception עם Guardian Agents וכלים לחקירה ולבלימה של פעילות מסוכנת מצד סוכני AI, לפי בקרות שמגדירים בני אדם.
מיקרוסופט הודיעה ב־19 באוקטובר 2026 על הרחבת Project Perception עם Guardian Agents ו־Playbooks לחקירה ולבלימה של פעילות מסוכנת מצד סוכני AI. לצד זאת, החברה מרחיבה את יכולת הגילוי ל־60 סוגי סוכנים מקומיים. עבור ארגונים בישראל שמחברים סוכנים לקוד, למידע ולמערכות עסקיות, ההכרזה נוגעת בשאלה מעשית: לא רק מה הסוכן עונה, אלא מה מותר לו לעשות ומי יכול לעצור אותו.
מה הוכרז: גילוי סוכנים, חקירה ובלימת פעילות
לפי הודעת מיקרוסופט, ההרחבה מחברת בין גילוי סוכנים לבין מנגנוני פיקוח ותגובה. Guardian Agents וה־Playbooks נועדו לסייע בחקירה ובבלימה של פעילות מסוכנת, באמצעות בקרות שמוגדרות בידי בני אדם. זהו הבדל חשוב לעומת בדיקה של תוכן התשובה בלבד: תשובה יכולה להיראות תקינה, בזמן שהפעולה שבוצעה כדי להפיק אותה חורגת ממה שהארגון התכוון לאפשר.
הרחבת הגילוי ל־60 סוגי סוכנים מקומיים היא נתון קונקרטי על היקף הכיסוי שמיקרוסופט מציגה. עם זאת, אין לקרוא אותו כהבטחה לכיסוי של כל כלי או כל תצורת עבודה בארגון. בבחינת המוצר, השאלה החשובה אינה רק כמה סוגים נכללים ברשימה, אלא האם הוא מזהה את הסוכנים שבשימוש בפועל ואת הפעילות שהארגון צריך לפקח עליה.
גם המונח Playbooks דורש הבחנה בין היכולת הטכנולוגית לבין המדיניות שתפעיל אותה. באופן כללי, נוהל תגובה מגדיר כיצד להתקדם מזיהוי פעילות חשודה לבירור ולטיפול. ההכרזה מתארת כיוון של חקירה ובלימה, אך פרטי תרחישי התגובה, תנאי ההפעלה וההתאמה לסביבה מסוימת צריכים להיבדק לפני הטמעה. אין בתחקיר המצורף פירוט שמאפשר לקבוע שכל פעולה מסוכנת תיחסם אוטומטית.
גבולות המידע: ההכרזה כוללת Guardian Agents, Playbooks והרחבת גילוי ל־60 סוגי סוכנים מקומיים. התחקיר אינו מפרט מחירים, תנאי רישוי או זמינות לכלל הלקוחות, ולכן אין להסיק שהיכולות כבר זמינות בכל סביבת מיקרוסופט.
למה אבטחת תשובות אינה מספיקה לסוכן שפועל במערכת
ההקשר הוא המעבר מעוזר שמציע פעולה לסוכן שיכול לבצע אותה. כאשר כלי רק מנסח טיוטה, אדם יכול לקרוא אותה לפני השימוש. כאשר אותו תהליך מקבל גם הרשאה לשנות רשומה, לשלוח קובץ או להריץ קוד, הבקרה צריכה להתייחס לפעולה עצמה. איכות הניסוח אינה מעידה שהגישה למידע הייתה נחוצה או שהשינוי אושר.
למשל, בתרחיש היפותטי של שירות לקוחות, סוכן עשוי להזדקק לקריאת פרטי הזמנה כדי לענות על שאלה. מכאן לא נובע שעליו לקבל גם הרשאה לייצא את מאגר הלקוחות או לשנות את פרטי התשלום. ההבחנה הזו אינה תלויה בשאלה עד כמה המודל חכם: היא נוגעת לגבולות שהמערכת מציבה סביבו וליכולת לבדוק מה התרחש בפועל.
הרשאה לבצע פעולה אינה הוכחה שהפעולה נכונה או נחוצה.
מכאן החשיבות של בקרות שמוגדרות בידי בני אדם. הארגון צריך להחליט מראש אילו פעולות מותרות, מה נחשב חריגה ומתי יש להעביר את ההחלטה לאדם. סוכן מפקח יכול להיות חלק מהמערך הזה, אך גם את סמכויותיו צריך לבחון. כלי שמסוגל לעצור תהליך עסקי דורש גבולות ברורים לא פחות מכלי שמסוגל להפעיל אותו.
המשמעות לישראל: לבדוק את מסלול הפעולה, לא רק את הדמו
בחברת תוכנה ישראלית, סוכן פיתוח עשוי לפעול בסביבה שבה נמצאים קוד, מפתחות גישה ומידע של לקוחות מחו״ל. בעסק מקומי, סוכן תפעולי עשוי לחבר בין מערכת הזמנות, מסמכים ותכתובות בעברית. אלה תרחישי שימוש אפשריים, לא מקרי לקוח שדווחו בהכרזה. בשניהם, נקודת הבדיקה היא אותה נקודה: מה הסוכן יכול לעשות בכל מערכת שאליה הוא מחובר.
לארגון בארץ שבוחן את ההרחבה של מיקרוסופט כדאי להגיע לפיילוט עם תרחישים מהעבודה שלו, ולא להסתפק בהדגמה כללית. בפרט, תהליכים שמשלבים עברית ואנגלית צריכים להיבדק כפי שהם מתרחשים בפועל, לרבות שמות קבצים, בקשות משתמשים ונתוני מערכת. אין בהכרזה שבתחקיר מידע שמאפשר לקבוע את רמת התמיכה בתרחישים כאלה, ולכן זו שאלה לבדיקה ולא הנחת מוצא.
- זהות: האם אפשר לשייך פעולה לסוכן מסוים ולהבחין בינה לבין פעולה של עובד?
- הרשאות: האם הסוכן מקבל רק את הגישה הנדרשת למשימה, והאם אפשר לבטל אותה בנפרד?
- תיעוד: האם ניתן להבין איזה מידע נקרא, מה שונה ומה הייתה תוצאת הפעולה?
- תגובה: מי מוסמך לעצור את הסוכן, ומה קורה למשימה שנקטעה באמצע?
- אחריות: מי מטפל בהתראה כאשר הפעילות חוצה בין צוות הפיתוח, התפעול ואבטחת המידע?
השאלות האלה רלוונטיות גם לעסק שאין בו מוקד אבטחה ייעודי. אם אין מי שיבחן התראות או יאשר חריגות, כדאי לצמצם את עצמאות הסוכן במקום להניח ששכבת פיקוח נוספת תפתור את הפער. לעיתים הבחירה המעשית היא לאפשר הכנת פעולה לאישור, בלי לתת לסוכן סמכות לבצע אותה לבדו.
מה הלאה: לבחון גם חסימות שגויות ויכולת התאוששות
המבחן של Guardian Agents לא יהיה רק היכולת לזהות פעילות חשודה, אלא גם התועלת לצוות שמקבל את ההתראה. בבדיקת התאמה כדאי לבקש הדגמה של מקרה תקין, מקרה שחורג מההרשאות ומקרה גבולי שדורש בירור. חשוב לבדוק גם מה רואה המפעיל, האם ההסבר מאפשר לקבל החלטה, ומה נדרש כדי לחדש עבודה שנעצרה בטעות.
לכן, צעד פתיחה סביר הוא פיילוט מוגבל בסביבת בדיקה, עם מידע שאינו רגיש ונתיב ברור לביטול הרשאות. יש לבחון גם את מחיר הטעות התפעולית: חסימה מיותרת עלולה לעכב שירות או עבודה, בעוד היעדר חסימה עלול לאפשר שינוי לא רצוי. זו המלצת הטמעה כללית, לא תיאור של מנגנון מסוים שמיקרוסופט התחייבה לספק.
החידוש בהכרזה הוא המיקוד בפיקוח על סוכנים כגורמים שמבצעים פעולות בתוך הארגון, ולא רק כמחוללי תשובות. עבור מנהלים ומפתחים בישראל, המשמעות המיידית אינה רכישה אוטומטית של מוצר נוסף, אלא דרישה ברורה מכל פרויקט סוכנים: להגדיר זהות, להגביל הרשאות, לתעד פעילות ולהבטיח שאדם מוסמך יכול להתערב. את ההרחבה של מיקרוסופט יהיה צריך לבחון מול הדרישות האלה.
שאלות נפוצות
מהם Guardian Agents של מיקרוסופט?
מיקרוסופט הציגה את Guardian Agents במסגרת הרחבת Project Perception ב־19 באוקטובר 2026, לצד Playbooks לחקירה ולבלימה של פעילות מסוכנת מצד סוכני AI. ההכרזה מתמקדת בפיקוח על פעולות והרשאות באמצעות בקרות שמגדירים בני אדם.
האם Guardian Agents מחליפים את צוות אבטחת המידע?
לא נכון לראות בהם תחליף לאחריות אנושית: לפי ההכרזה, הבקרות מוגדרות בידי בני אדם. הארגון עדיין צריך לקבוע אילו פעולות מותרות לסוכנים, מי מאשר חריגות ומי אחראי לטיפול באירוע.
מה כדאי לבדוק לפני שנותנים לסוכן AI גישה למערכות הארגון?
יש לבדוק באיזו זהות הסוכן פועל, אילו הרשאות הוא מקבל והאם ניתן לתעד ולעצור את פעולותיו. בפיילוט מומלץ להתחיל בהרשאות מצומצמות, ולהגדיר מראש אילו פעולות דורשות אישור אנושי.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות