טסטמו איי.אי. מתחילה את Agent Assurance לבדוק סוכני AI לפני השקתן

TestMu AI משיקה את Agent Assurance: בדיקת סוכני AI לפני העלייה לאוויר

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

זהו הפער ש-TestMu AI מבקשת לצמצם באמצעות Agent Assurance, מוצר חדש שנועד לבדוק סוכני AI לפני השקתם. במקום להסתפק בתשובה שהסוכן מספק, המערכת בוחנת מה התרחש בפועל: אילו קבצים השתנו, אילו כלים הופעלו, אילו קריאות API נשלחו ומה הייתה התוצאה הממשית במערכת.

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

הבעיה: סוכן AI יכול לדווח על הצלחה גם כשהפעולה נכשלה

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

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

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

שני סוגי סוכנים תחת מערכת בדיקה אחת

לפי הודעת TestMu AI מ-19 באוגוסט 2026, Agent Assurance נועדה לכסות שתי קטגוריות מרכזיות: סוכנים שמשוחחים עם בני אדם וסוכנים אוטונומיים שפועלים בתוך מערכות.

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

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

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

לא להאמין לדיווח: לבדוק את ההשפעה האמיתית

העיקרון המרכזי של Agent Assurance הוא מעבר מהערכת תשובת הסוכן לאימות התוצאה בפועל. המוצר מנתח את הקוד ואת הממשקים שהסוכן מצהיר עליהם, מייצר תרחישי בדיקה מקצה לקצה, מפעיל את הסוכן ואוסף ראיות מהסביבה שבה הוא פועל.

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

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

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

המדד החריג: מה לא היה אפשר לבדוק

אחד המאפיינים הבולטים במוצר הוא פסק דין שלישי: לצד “עבר” ו“נכשל”, קיימת גם התוצאה “לא ניתן לבדיקה”. TestMu AI מכנה את שיעור הפעולות שלא ניתן לאמת בשם Assurance Gap — פער האימות.

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

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

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

מה משתנה בסביבת אפליקציות ללא קוד

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

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

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

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

בדיקות וידאו: כשהסוכן מופיע מול המצלמה

TestMu AI מרחיבה את קטגוריית סוכני השיחה גם למפגשי וידאו. לפי החברה, יכולת Video Agent Testing משתמשת בדמות מדומה בעלת פנים וקול מציאותיים, שמצטרפת לפגישת וידאו חיה, מנהלת שיחה ובוחנת את הסוכן לפי קריטריונים שהצוות הגדיר.

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

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

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

כך משלבים בדיקות בתהליך פיתוח אפליקציה ללא קוד

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

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

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

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

איך לבחור פתרון בדיקה מתאים לארגון

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

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

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

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

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

זמינות המוצר והמשמעות המעשית

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

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

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

סיכום: מה חשוב לבדוק לפני השקת סוכן AI

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

חמש שאלות שכדאי לשאול לפני העלייה לאוויר

1. האם אנחנו בודקים את הפעולה שבוצעה במערכת, או רק את התשובה שהסוכן ניסח?
2. אילו פעולות של הסוכן איננו יכולים כיום לראות, לתעד או לאמת?
3. מהו הנזק האפשרי אם הסוכן טועה, והאם ניתן לבטל את הפעולה בקלות?
4. באילו מצבים נדרש אישור אנושי לפני עדכון נתונים, שליחת הודעה או ביצוע פעולה כספית?
5. האם פתרון הבדיקה משתלב באפליקציה ללא קוד, במערכות החיצוניות ובקצב העבודה של הארגון?

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

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