למה פיילוט של סוכן AI נתקע לפני העבודה האמיתית

# למה פיילוט של סוכן AI נתקע לפני העבודה האמיתית הדגמה היא מבחן עם תנאים מושלמים: קלט שנבחר מראש, מידע מסודר ואדם שמוכן להתערב. עסק אינו מקום כל כך מנומס. אחרי לא מעט שיחות על הטמעת סוכני AI, אני חוזר לאותה נקודה: ההתלהבות בחדר כמעט אף פעם אינה הבעיה. הקושי מגיע אחר כך, כשהודעה חסרה מספר הזמנה, רשומה מופיעה פעמיים ומערכת חיצונית מחזירה שגיאה. ברגע הזה כבר לא מעניין אם התשובה נוסחה יפה. מעניין אם העבודה נסגרה, ואם אפשר להבין מה קרה בדרך. לכן פיילוט אינו תצוגת יכולות. הוא חוזה בדיקה לתהליך אחד. מגדירים מראש תוצאה, ראיות ומסלול לחריגים, ואז מנסים לשבור אותו בכוונה. בלי זה יש סרטון מוצלח. עדיין אין בסיס להפקיד בידי הסוכן עבודה אמיתית. ## הכשל מתחיל במשפט "בואו נראה מה הוא יודע לעשות" זה משפט מפתה, כי הוא פותח את האפשרויות. הוא גם משאיר את הפרויקט בלי קו סיום. צוות אחד מתרשם מאיכות הניסוח, צוות אחר בוחן את המהירות, ומנהל התפעול מחכה לראות אם משהו באמת ירד מהשולחן שלו. השאלה הנכונה צרה יותר: איזו עבודה צריכה להיות גמורה בסוף הריצה, ואילו סימנים יוכיחו שהיא אכן נגמרה? נניח שהפיילוט עוסק בבקשת הצעת מחיר שהגיעה במייל. "הסוכן מטפל בבקשה" אינו יעד. יעד שאפשר לבדוק ייראה כך: הפנייה שויכה ללקוח הנכון, הפרטים החסרים סומנו, טיוטה נוצרה לפי מחירון מאושר, ונפתחה משימת אישור לאדם המתאים. אם כתובת המייל אינה מזוהה או שהמחירון סותר את עצמו, הריצה נעצרת ומועברת לבדיקה. הניסוח הזה פחות מרשים על שקף. הוא הרבה יותר שימושי ביום שני בבוקר. ## תשובה טובה אינה הוכחה לביצוע סוכן יכול לכתוב "פתחתי משימה" גם כאשר פתיחת המשימה נכשלה. הוא יכול לסכם מסמך היטב ולשייך אותו לתיק הלא נכון. לכן בודקים בנפרד את התוצאה שהמשתמש רואה ואת מסלול הפעולות שיצר אותה. בתיעוד הרשמי של Google Cloud להערכת סוכנים מופיעה ההבחנה בין איכות התשובה הסופית לבין איכות השימוש בכלים ומסלול הפעולות. Microsoft מתארת עיקרון דומה: בדיקה של סוכן צריכה למדוד את הפלט ואת הצעדים בתוך התהליך. זו הבחנה טכנית עם משמעות עסקית פשוטה. ניסוח נעים אינו מפצה על עדכון רשומה שגויה. לכל תרחיש בפיילוט צריכים להיות שני סוגי בדיקה: * בדיקת תוצאה: מה השתנה במערכת, איזה מסמך נוצר, מי קיבל משימה ומה הסטטוס הסופי. * בדיקת מסלול: באילו מקורות נעשה שימוש, אילו פעולות בוצעו, היכן התבקש אישור ומדוע הריצה נעצרה. לא חייבים לחשוף למשתמש את כל הפרטים הטכניים. כן חייבים לשמור אותם כך שאפשר יהיה לחקור טעות בלי לנחש. ## חוזה קבלה קטן מחליף רשימת יכולות ארוכה לפני שבונים, כותבים דף אחד. לא מצגת חזון ולא מסמך אפיון של חמישים עמודים. חוזה קבלה לפיילוט. הדף מתחיל באירוע שמפעיל את התהליך ומסתיים במצב עסקי ברור. באמצע מופיעות הפעולות המותרות, נקודות האישור והראיות שיישמרו. כדאי לנסח כל שורה בפורמט חד: "בהינתן מצב מסוים, כאשר מגיע אירוע, התוצאה הצפויה היא...". לדוגמה: > בהינתן לקוח קיים עם עסקה פתוחה, כאשר מתקבל מייל שמכיל הזמנת רכש תקינה, המסמך נשמר בתיק העסקה, נפתחת משימת בדיקה לבעל החשבון ונרשם קישור למקור. עכשיו אפשר להריץ את אותו מקרה שוב. אפשר גם לשנות פרט אחד ולראות מה נשבר. בלי חוזה כזה, כל ריצה הופכת לוויכוח על תחושה. NIST ממליץ להגדיר ולתעד תהליכי בדיקה, מדדים ותנאים שדומים לסביבת השימוש בפועל. לעסק ישראלי קטן אין צורך לאמץ מסגרת ממשל של ארגון ענק כדי ליהנות מהעיקרון. צריך פשוט לכתוב מראש מה עובר, מה נכשל ומי מחליט אם עולים לאוויר. ## מקרה רגיל אחד לא מספיק, צריך את המקומות שבהם העסק מסתבך בדיקת "המסלול השמח" מוכיחה בעיקר שהמפתח הכין הדגמה. העבודה האמיתית נמצאת בנתונים החלקיים ובסתירות. אם הסוכן אמור לטפל בהצעות מחיר, מערך הבדיקות צריך לכלול לקוח מוכר, לקוח חדש, בקשה בלי כמות, שני מחירונים בתוקף, מוצר שלא קיים, קובץ שאי אפשר לקרוא ופעולה שמחייבת אישור. אם הוא מטפל בתיאום פגישות, צריך לבדוק אזורי זמן, ביטול מאוחר, משתתף ללא כתובת מייל ויומן שאינו זמין. לא מנסים לדמיין כל תקלה אפשרית. לוקחים דוגמאות אמיתיות מהחודש האחרון, מסירים מידע מזהה והופכים אותן למקרי בדיקה. כך הפיילוט לומד את העסק כפי שהוא, כולל הפינות הלא אלגנטיות שלו. כאן גם מתגלה אם התהליך בכלל בשל. אם שני מנהלים נותנים תשובות שונות לאותו חריג, הסוכן אינו הבעיה. הארגון טרם החליט מה הכלל. עדיף לגלות את זה במערך בדיקות מאשר לאחר שנשלחה התחייבות ללקוח. ## בלי יומן ראיות, כל תקלה הופכת לסיפור בלשי כאשר עובד מדווח "הסוכן עשה משהו מוזר", צריך להיות אפשר לענות על ארבע שאלות: מה נכנס, על איזה מידע התבססה ההחלטה, אילו פעולות בוצעו ומה היה הפלט. אם אחת התשובות חסרה, קשה להבדיל בין טעות של הסוכן, מידע מקור שגוי, הרשאה חסרה או תקלה בחיבור. יומן ראיות אינו אמור לשמור הכול לנצח. הוא צריך להיות מידתי ולכבד פרטיות. שומרים מזהי אירועים, זמני פעולה, מקורות שנקראו, תוצאות של פעולות, אישורים וגרסת ההגדרות. מידע רגיש מצמצמים או משמיטים לפי הצורך. הערך אינו רק בעת תקלה. היומן מראה אילו חריגים חוזרים, היכן הצוות מתערב ואיזה חלק מהתהליך עדיין דורש עבודה ידנית. מכאן מגיע השיפור הבא. בלי ראיות, משפרים לפי מי שהתלונן הכי חזק באותו שבוע. ## שער העלייה לאוויר צריך להיות בינארי בסוף הפיילוט צריכה להיות החלטה: עולה, חוזר לתיקון או נעצר. "כמעט עובד" הוא תיאור סביר לשלב פיתוח, לא סטטוס תפעולי. שער קבלה יכול לכלול שיעור מעבר מוסכם למקרי הבדיקה, אפס פעולות אסורות, טיפול תקין בכל תרחישי העצירה, תיעוד מלא של הריצות ובעל תפקיד שמאשר חריגים. הספים תלויים בתהליך. טיוטת מייל פנימית יכולה לסבול יותר טעויות מפעולה שמשנה מחיר או יוצרת התחייבות. חשוב להפריד בין שלושה סוגי כישלון, גם אם לא מכריחים אותם לתבנית סימטרית: * כשל איכות, כמו סיכום חסר או סיווג לא מדויק. * כשל תפעולי, כמו פעולה שלא נרשמה או מערכת שלא הגיבה. * חריגה מגבול, כמו ניסיון לבצע פעולה שנדרשת עבורה הסכמה. לכל סוג יש טיפול אחר. שיפור הנחיה לא יתקן הרשאת מערכת, והוספת הרשאה לא תתקן כלל עסקי עמום. ## השבוע שאחרי ההדגמה הוא חלק מהפיילוט גם מערך בדיקות טוב אינו מחקה לחלוטין עבודה חיה. אחרי שער הקבלה מפעילים את הסוכן בתחום מוגבל, עם אפשרות עצירה ועם בדיקה יומית של החריגים. לא מרחיבים מיד לעוד מחלקה ולא מוסיפים חמש יכולות כי "כבר פתחנו את החיבור". בשלב הזה בודקים אם הצוות משתמש בתוצאה או עוקף אותה. משימה שנפתחה נכון אך אף אחד אינו קורא אותה אינה הצלחה. גם תהליך אוטומטי שמייצר יותר עבודת בדיקה מכפי שהוא חוסך צריך לחזור לשולחן. פיילוט מסתיים כאשר העסק יכול להסביר מה הסוכן סוגר, איך יודעים שהוא סגר, מה קורה כשהוא לא בטוח ומי אחראי על ההמשך. המודל הוא רק חלק מהתשובה. ## איך להתחיל בלי לבנות עוד הדגמה בחרו תהליך אחד שכבר מתרחש בתדירות סבירה ואספו עשרה עד עשרים מקרים אמיתיים שלו. כתבו לכל מקרה תוצאה צפויה, נקודת עצירה וראיה שניתן לבדוק. רק אחר כך החליטו אילו מערכות לחבר. AI BUDDY בונה [סוכני AI לעסקים](/services/ai-agents) ומלווה [תהליכי אוטומציה](/services/automation). אם יש אצלכם פיילוט שנראה טוב אבל עדיין לא קיבל אישור לעלות לעבודה, שלחו לנו דרך [aibuddy.co.il](https://aibuddy.co.il) את תיאור התהליך ואת חמש הבדיקות שכבר ניסיתם. נבדוק אם חסרה יכולת, או שפשוט חסר מבחן קבלה שאפשר לסמוך עליו. ### מקורות * [NIST AI Risk Management Framework Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) * [Google Cloud: Evaluate agents using the GenAI Client](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/evaluate) * [Microsoft Learn: Agent evaluators](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators)