למה סוכן מול ERP צריך כללים משלו?
ה־ERP מחזיק את הכספים, הלקוחות והמלאי. צ׳אטבוט שטועה כותב משפט לא נכון. סוכן שטועה יכול לרשום הזמנה, לשלוח מייל או להראות נתון למי שלא אמור לראות אותו. לכן השאלה היא לא רק כמה הסוכן חכם, אלא מה עוצר אותו כשהוא טועה.
הרשימה כאן היא מה שאנחנו בודקים בכל סוכן שאנחנו בונים, והיא מתאימה לבדיקת כל ספק. לשרת שמחבר את הסוכן ל־Priority יש שאלות משלו, ופירטנו אותן במדריך על MCP.
שמונה דברים לבדוק בכל סוכן AI לפריוריטי
| מה לבדוק | השאלה לספק | איך אנחנו עושים את זה |
|---|---|---|
| זהות בכניסה | איך הסוכן יודע מי כותב לו? | רשימת עובדים מאומתת. מספר לא מוכר לא מקבל מידע, ושם תצוגה לא נותן הרשאה |
| רמות הרשאה | כל עובד רואה הכול? | הרשאה לכל עובד, גישה לכספים לכל אדם בנפרד, ואיש מכירות מקבל רק את נתוני הלקוחות שלו |
| אישור לפני כתיבה | מה נרשם בלי שאדם ראה? | כלום. תצוגה מקדימה, ואז אישור אחד לפעולה אחת |
| קריאה חוזרת | איך יודעים שהכתיבה באמת קרתה? | הסוכן קורא את הרשומה מחדש, ומדווח רק כשיש ראיה |
| יומן ביקורת | אפשר לדעת אחר כך מי ביקש מה? | כל קריאה לכלי נרשמת, ביומן משורשר בחתימות SHA-256 |
| שעת הנתונים | מאיזו שעה המספר הזה? | מקור, שעת בדיקה ותקופה לכל מספר, ותשובה חלקית מסומנת כחלקית |
| בלי המצאות | מה קורה כשהסוכן "זוכר" מספר שלא קיים? | בדיקה אוטומטית משווה כל מספר מסמך למה שחזר מהמערכת |
| פרטי נשאר פרטי | מה עובר בין שיחות? | בזיכרון המשותף רק מה שכל הצוות רשאי לדעת. שיחה פרטית ודואר לא עוברים לקבוצה |
איך זה עובד
- בקשה של עובד
- זהות בכניסההודעה ממספר לא מוכר לא מגיעה למודל בכלל
- רמות הרשאההרשאה לכל עובד, וגישה לכספים לכל אדם בנפרד
- הסוכן קורא ומכיןמקור, שעת בדיקה ותקופה לכל מספר
- כשצריך לכתובאישור לפני כתיבהתצוגה מקדימה, ואז אישור אחד לפעולה אחת
- נרשם ב־Priority
- קריאה חוזרתהסוכן קורא את הרשומה מחדש, ומדווח רק כשיש ראיה
- יומן ביקורתכל קריאה לכלי נרשמת, ביומן משורשר בחתימות SHA-256
זהות והרשאות: מי מדבר עם הסוכן, ומה מותר לו?
בדיקת הזהות צריכה לקרות לפני שהסוכן קורא משהו, ולא להיות משפט בהנחיות של המודל. בסוכנים שבנינו, הזיהוי נעשה מול רשימת עובדים מאומתת בשער הכניסה: הודעה ממספר לא מוכר לא מגיעה למודל בכלל, ועובד מזוהה מקבל את רמת ההרשאה שלו.
רמות הרשאה הן לא רק "קורא" ו"כותב". שאלו אם אפשר להגדיר שאיש מכירות מקבל רק את נתוני הלקוחות שלו, שרווח והפסד פתוח רק למי שהוגדר לו, ושטכנאי לא מריץ שאילתות רחבות על ה־ERP. אצלנו כל אחד מאלה הוא הגדרה לכל עובד.
מול Priority עצמה, ב־MCP for Priority כל משתמש מתחבר בעצמו עם הרשאות קריאה, כתיבה ומודולים, והשרת עובד דרך משתמש ה־API של הארגון, עם ההרשאות שלו בלבד.
כתיבה: אישור לפני, קריאה חוזרת אחרי
הכתיבה כבויה עד שמפעילים אותה
ב־MCP for Priority הכתיבה כבויה כברירת מחדל, ומופעלת למשתמשים שצריכים אותה.
תצוגה מקדימה ואישור
בשיחה כל פעולה מוצגת קודם לאישור, ורק אז נשלחת, עם אסימון חתום בשרת, חד־פעמי, שתוקפו נגמר אחרי 90 שניות. אישור אחד מתיר פעולה אחת.
בדיקה לפני עדכון
לפני עדכון השרת בודק שאיש לא שינה את הרשומה מאז התצוגה המקדימה.
קריאה חוזרת
אחרי יצירת הזמנה השרת קורא את השורות מחדש, והסוכן מדווח שהפעולה הושלמה רק כשיש לכך ראיה. כשהתוצאה לא ידועה, הוא בודק לפני ניסיון נוסף, כדי לא ליצור כפילות.
שאלו גם מה קורה כשאין אדם מול המסך. ב־MCP for Priority, אוטומציה שרצה בלי אדם, למשל ב־n8n, מדלגת על שלב האישור רק עם מפתח API שקיבל הרשאת כתיבה והרשאה מפורשת לכך, וזה כבוי כברירת מחדל.
יומן ביקורת: מה צריך להישאר אחרי השיחה?
אחרי שיחה עם סוכן צריכות להישאר שורות במערכת, לא רק טקסט על מסך: מי ביקש, איזה כלי הופעל, מה חזר ומה נרשם. ב־MCP for Priority כל קריאה לכלי נרשמת ביומן ביקורת משורשר בחתימות SHA-256. אישורים ופרטים מזהים ממוסכים בלוגים, וסיסמאות, מפתחות API ואסימונים לא נרשמים ללוג.
בסוכנים שבנינו גם הודעה קולית משאירה עקבה: התמליל נרשם, כדי שאפשר יהיה לבדוק מה בדיוק התבקש. ומדידת הבריאות של הסוכן סופרת רק מספרים, כמו כמה הודעות, כמה שגיאות וכמה זמן לקחה תשובה, בלי לשמור את תוכן ההודעות.
תשובות: מקור, שעה, ובלי מספרים מומצאים
- כל מספר בתשובה מגיע עם המקור, שעת הבדיקה ותקופת הדוח.
- תשובה חלקית מסומנת כחלקית, ואפס, מידע חסר ותוצאה חלקית נאמרים במילים שונות.
- תשובה מעותק שמור של טבלה אומרת מאיזו שעה הנתונים, ואחרי כתיבה היא מזהירה ששינוי טרי אולי עוד לא בפנים.
- מספר מסמך או קוד שלא חזרו מהמערכת לא נכנסים לתשובה. בסוכנים שבנינו, בדיקה אוטומטית משווה כל מספר כזה למה שהכלים החזירו, ומחזירה את הסוכן לתקן לפני שהתשובה נשלחת.
מה לא נותנים לסוכן לעשות לבד?
גם סוכן שעובד טוב צריך גבולות שלא תלויים בכמה הוא חכם:
- למחוק נתונים: אין בקטלוג של MCP for Priority כלי שמסיר נתוני Priority.
- לשלם, לשנות הרשאות או להתחייב בשם החברה: כל אחד מאלה דורש הרשאה מפורשת שמתאימה לאותה פעולה.
- לשלוח דואר בשם אדם: כל שליחה מוצגת עם הנמענים, הנושא והטקסט המלא, ומחכה לאישור של בעל התיבה.
- לפעול לפי הוראה שכתובה בתוך מסמך, מייל או תוצאת חיפוש: אלה מקורות מידע, לא הוראות, והם לא משנים הרשאות.
- לבקש סיסמה, מפתח API או קוד אימות בתוך השיחה.
- להעביר לקבוצה משהו שנאמר בשיחה פרטית.
איך מתחילים בקטן?
קריאה בלבד, לעובדים מאומתים
בשלב הראשון הסוכן קורא, מנתח ומכין טיוטות. הצוות לומד לסמוך על התשובות לפני שמשהו נכתב.
השאלות שחוזרות כל יום
מתחילים בשאלות שהצוות שואל הכי הרבה, כמו הזמנות פתוחות, חובות בפיגור, פריטים מתחת למלאי המינימום והמשלוחים של היום, ונותנים לכל אחת מסלול קבוע, כך שהתשובה יוצאת באותה צורה בכל פעם.
כתיבה, פעולה אחר פעולה
מוסיפים כתיבה לפי סוג פעולה ובהרשאה מפורשת, למשתמשים שצריכים אותה. בשיחה, כל פעולה עדיין מוצגת לאישור.
ערוץ אחד בכל פעם
ערוץ חדש, כמו תיבת דואר, מתחבר כשהקודם כבר עובד, ובהתחלה באישור לכל פעולה.
איך זה נראה כשהכול מחובר, אצל צוות שעובד ב־WhatsApp, תיארנו במדריך "סוכן AI פנימי ב־WhatsApp לעובדים".
שאלות נפוצות
- מה ההבדל בין צ׳אטבוט לסוכן AI?
- צ׳אטבוט עונה מתוך מידע שהוזן לו מראש. סוכן AI מקבל מטרה, קורא נתונים עדכניים ממערכות כמו Priority, מבצע פעולות ומדווח מה עשה, ואדם מאשר לפני שמשהו נרשם.
- סוכן AI יכול לטעות?
- כן. לכן בשיחה כל כתיבה ל־Priority מוצגת קודם לאישור, לפני עדכון השרת בודק שאיש לא שינה את הרשומה מאז התצוגה המקדימה, וכל קריאה לכלי נרשמת ביומן ביקורת.
- איך בודקים ספק של סוכן AI לפריוריטי?
- שואלים את שמונה השאלות שבטבלה, ומבקשים לראות שלושה דברים בפועל: תצוגה מקדימה של כתיבה לפני האישור, שורה ביומן הביקורת, ותשובה שאומרת מאיזו שעה הנתונים שלה.
- הסוכן זוכר שיחות ומעביר מידע בין עובדים?
- הוא שומר בזיכרון המשותף רק עובדות שכל הצוות רשאי לדעת, כמו איך לקוח מעדיף לקבל משלוחים, ורק כשהוא בוחר לשמור. תוכן משיחה פרטית או מתיבת דואר לא נשמר בזיכרון המשותף ולא עובר לקבוצה.
- אפשר להתחיל בלי לתת לסוכן לכתוב?
- כן, וכך אנחנו ממליצים להתחיל. ב־MCP for Priority הכתיבה כבויה כברירת מחדל: מתחילים בקריאה, ומפעילים כתיבה למשתמשים שצריכים אותה כשהצוות סומך על התשובות.
