SLA לסוכן AI: איך מגדירים רמת שירות שאפשר לנהל
# SLA לסוכן AI: איך מגדירים רמת שירות שאפשר לנהל
**Meta title:** SLA לסוכן AI עסקי: מדריך להגדרת רמת שירות | AI BUDDY
**Meta description:** כך מגדירים SLA לסוכן AI לפי זמן תגובה, השלמה, איכות והסלמה, עם טבלת החלטה ודוגמה שאפשר להתאים לעסק.
**Slug:** ai-agent-sla-service-level-guide
SLA טוב לסוכן AI אינו מבטיח שהכול יקרה מיד. הוא מגדיר מה נחשב בקשה תקינה, מתי היא צריכה לקבל תגובה, מתי העבודה צריכה להסתיים, איזו תוצאה נחשבת נכונה ומה קורה כשהסוכן אינו יכול להשלים אותה. מתחילים מההשפעה העסקית של איחור או טעות, ורק אחר כך קובעים זמן, מדד ובעל אחריות.
**תיבת תשובה קצרה**
* הפרידו בין זמן קבלה, זמן התחלת טיפול וזמן השלמה.
* מדדו תוצאה עסקית תקינה, לא רק זמינות של שרת או תשובה מהמודל.
* קבעו יעד שונה לכל סוג עבודה לפי דחיפות ומחיר הטעות.
* הגדירו מראש מי מקבל חריגה, עם איזה הקשר ובאיזה זמן.
* התחילו ביעד פנימי שנמדד בפיילוט. התחייבות חוזית מגיעה רק אחרי שיש נתונים.
**SLA לסוכן AI** הוא הסכם שמגדיר את רמת השירות שהעסק או הספק מתחייבים לספק, את אופן המדידה ואת התוצאה במקרה של חריגה. יעד פנימי למדידה נקרא SLO, והמדד שמראה אם עומדים בו נקרא SLI.
## ארבע השורות שצריכות להופיע לפני כל אחוז
רוב הדיונים על SLA מתחילים במספר כמו 99.9%. זה מספר נקי, מרשים, ולעיתים כמעט חסר משמעות. סוכן יכול להיות זמין כל החודש ועדיין להכין הצעה שגויה, להיתקע בהמתנה לאישור או להחזיר תשובה אחרי שהלקוח כבר קנה במקום אחר.
מסגרת שימושית מתחילה בארבע שורות:
1. **אירוע פתיחה:** מה בדיוק מכניס עבודה למסלול. למשל, טופס מלא שהתקבל בשעות הפעילות.
2. **תוצאה נדרשת:** מה צריך להתקיים כדי לסמן את העבודה כהושלמה. למשל, טיוטת הצעה שנבנתה לפי מחירון פעיל ונשמרה בתיק הנכון.
3. **חלון זמן:** מאיזה רגע סופרים, מתי עוצרים את השעון ואילו מצבים אינם בשליטת הסוכן.
4. **מסלול חריגה:** מי מקבל אחריות כאשר חסר מידע, מערכת חיצונית אינה זמינה או נדרשת החלטה אנושית.
Google SRE ממליצה להתחיל במה שמעניין את המשתמש ורק אז לבחור מדד שקל לאסוף. Microsoft מפרידה בין SLA חוזי לבין SLO פנימי ומדגישה שהתחייבות של ספק תשתית אינה מחליפה יעד אמינות של התהליך המלא. עבור סוכן AI זה הבדל מהותי: זמינות המודל היא רק חוליה אחת במסלול שבו יש גם CRM, מייל, מסמכים ולעיתים אדם.
## זמן תגובה, זמן טיפול וזמן השלמה אינם אותו שעון
נניח שסוכן מקבל בקשה להכנת הצעת מחיר. בתוך דקה הוא מאשר שהבקשה נקלטה. בתוך חמש דקות הוא קורא את תיק הלקוח ומגלה שחסר מפרט. אחרי שעה הלקוח משלים אותו, ואז הסוכן מכין טיוטה ומעביר אותה לאישור מנהלת.
איזה זמן נמדד כאן? תלוי בהבטחה.
```text
שעון בודק שימוש מרכזי טעות נפוצה
זמן קבלה עד אישור הקליטה מניעת אי ודאות הצגת קליטה כהשלמה
תחילת טיפול עד תחילת הבדיקה ניהול תור ועומס מדידה רק ברגעים נוחים
עבודה פעילה עבודה ללא המתנה תכנון קיבולת ועלות עצירת שעון ללא סיבה
מקצה לקצה מהבקשה עד תוצאה עסקית חוויית לקוח האשמת הסוכן בכל עיכוב
זמן להסלמה עד העברה לבעל תפקיד פעולות רגישות התראה ללא בעלים
```
אין צורך לבחור שעון אחד. צריך לבחור את השעון שמתאים לכל הבטחה. אם הלקוח צריך לדעת שפנייתו לא נעלמה, מודדים אישור קבלה. אם העסק מבטיח הצעה עד סוף יום העבודה, מודדים מקצה לקצה. אם רוצים לשפר את הסוכן, מודדים גם את זמן העבודה הפעיל ואת זמן ההמתנה בנפרד.
## רמת שירות נמדדת לפי עבודה נכונה, לא לפי הודעת הצלחה
זמן הוא החלק הקל. איכות דורשת להגדיר מהי יחידת עבודה תקינה. עבור טיוטת הצעת מחיר, אפשר לדרוש שהלקוח זוהה, שהמחירון הפעיל שימש כמקור, ששדות החובה קיימים ושהטיוטה נשמרה בתיק הנכון. תשובה מהירה שחסרה בה אחת מהבדיקות האלה אינה עמידה ברמת השירות.
המדד צריך להסתכל מנקודת המבט של התהליך. Microsoft מציעה למדוד נכונות לצד זמינות ומהירות, ולבחון זרימות לפי החשיבות העסקית שלהן. לכן נכון להפריד בין כמה תוצאות:
* הושלם ונבדק מול מערכת המקור.
* נעצר נכון מפני שחסר מידע.
* הועבר בזמן לאדם המתאים.
* נכשל טכנית ונדרש ניסיון נוסף.
* דווח כהצלחה אף שהתוצאה אינה תקינה.
המצב האחרון הוא החמור ביותר. סוכן שאומר "בוצע" בלי תוצאה נכונה פוגע באמון יותר מסוכן שעוצר ומסביר מה חסר. ב־SLA טוב, עצירה מוצדקת יכולה להיחשב טיפול תקין. אישור שגוי לעולם לא.
## טבלת החלטה לרמות שירות לפי מחיר האיחור והטעות
לא כל משימה מצדיקה אותה רמת שירות. תזכורת פנימית שנשלחת באיחור אינה דומה לשינוי בפרטי תשלום. גם בתוך אותו סוכן כדאי להגדיר מחלקות שירות נפרדות.
```text
סוג עבודה מחיר איחור מחיר טעות יעד מתאים חריגה
איסוף מידע פנימי נמוך נמוך עד בינוני חלון עבודה רחב ניסיון חוזר ובדיקה
טיוטה ללקוח בינוני בינוני טיוטה בזמן ללא שליחה בעל התיק מקבל חוסרים
עדכון CRM בינוני בינוני עד גבוה כתיבה מאומתת או עצירה קונפליקט לבעל הרשומה
קביעת פגישה גבוה לעיתים בינוני אישור יומן בחלון קצר הצעת חלופות לאדם
פעולה כספית גבוה גבוה אין השלמה בלי אישור עצירה אצל בעל סמכות
```
הטבלה אינה קובעת מספרים עבור העסק. היא קובעת את סדר החשיבה. קודם מסווגים מחיר איחור ומחיר טעות, אחר כך מחליטים אם נדרשת מהירות, בדיקה נוספת או אישור. ניסיון לתת לכל הפעולות יעד אחיד יוצר בדרך כלל אחת משתי תוצאות: הבטחה יקרה מדי או שירות מהיר שאי אפשר לסמוך עליו.
## כך הופכים יעד יפה לכלל שאפשר למדוד
הניסוח "רוב הפניות יטופלו במהירות" אינו יעד. גם "95% הצלחה" אינו מספיק אם לא ברור מה נספר, באיזה חלון ומי מוחרג. יעד מדיד צריך לכלול אוכלוסייה, תוצאה, סף זמן, תקופת מדידה ומקור אמת.
דוגמה שימושית, בלי להעמיד פנים שהיא מתאימה לכל עסק:
> מתוך כל הבקשות המלאות להכנת טיוטת הצעה שנקלטו בשעות הפעילות, שיעור מוסכם יסתיים בתוך חלון הזמן שנקבע. השלמה פירושה שטיוטה נשמרה בתיק הלקוח לפי המחירון הפעיל, או שהבקשה הועברה לבעל התיק עם סיבה והקשר. המדידה תילקח מה־CRM ולא מהודעת הסוכן.
עכשיו אפשר לנהל ויכוח מועיל. מהי בקשה מלאה? האם זמן המתנה ללקוח נספר? מה קורה בערב חג? האם העברה לאדם נחשבת השלמה לכל סוג פנייה? המספר מגיע בסוף הדיון הזה, לא בתחילתו.
כדאי להחזיק יעד פנימי מעט מחמיר יותר מההבטחה החיצונית. כך מזהים הידרדרות לפני שהלקוחות פוגשים אותה. Google SRE גם מזהירה מפני יעד של מאה אחוז כברירת מחדל. יעד כזה עלול לייקר את המערכת ולעצור שינויים, בלי שהעסק באמת זקוק לשלמות הזאת.
## חריגה צריכה לשנות פעולה, אחרת היא רק דוח
SLA שלא קובע מה עושים כשהיעד נשבר הוא לוח מחוונים. לכל חריגה צריך להיות בעלים והחלטה.
אם זמן הקבלה נשבר, בודקים תור או חיבור כניסה. אם זמן ההשלמה נשבר בגלל המתנה קבועה לאישור, ייתכן שהבעיה נמצאת בחלוקת העבודה. אם שיעור האישורים השגויים עולה, עוצרים הרחבה ומחזירים פעולות רגישות לטיוטה או לאישור. אם מערכת חיצונית אינה זמינה, הסוכן צריך לדעת אילו פעולות ממתינות ואילו כבר מאבדות ערך.
תקציב שגיאות הוא דרך להחליט כמה חריגות העסק מוכן לספוג בתקופה נתונה לפני שמשנים עדיפות. הוא אינו היתר לטעות בחופשיות. הוא גבול שמכריח החלטה: כאשר חורגים ממנו, מפסיקים להוסיף יכולות ומטפלים באמינות. Google מפרסמת מדיניות לדוגמה שבה חריגה מהתקציב עוצרת שינויים שאינם תיקוני אמינות או אבטחה. בעסק קטן הכלל יכול להיות פשוט יותר, אך הוא עדיין צריך להוביל לפעולה.
## מתי SLA לסוכן AI הוא מוקדם מדי
AI BUDDY אינה הבחירה הנכונה כאשר העסק רוצה התחייבות לפני שהגדיר את התהליך, מקור האמת ובעל ההחלטה. אי אפשר להתחייב לזמן השלמה של בקשה שהכניסה שלה אינה מוגדרת, או לאיכות של תוצאה שאיש אינו יודע לאשר.
במצב כזה מתחילים בתקופת מדידה. הסוכן עובד על מסלול מוגבל, אוספים זמני קבלה, טיפול, המתנה ותיקון, ורואים אילו חריגים חוזרים. אחרי שיש מדגם שמייצג ימים רגילים ועמוסים, קובעים SLO פנימי. SLA חוזי, אם צריך כזה, מגיע אחר כך ובבדיקה משפטית מתאימה. מאמר זה מסביר תכנון תפעולי ואינו ייעוץ משפטי.
## שאלות המשך על SLA לסוכן AI
### מה ההבדל בין SLA, SLO ו־SLI?
SLA הוא הסכם שירות, לרוב מול לקוח או ספק, ויכולות להיות לו השלכות חוזיות. SLO הוא יעד פנימי לרמת השירות, למשל חלון להשלמת סוג עבודה. SLI הוא המדד בפועל, כגון שיעור הבקשות התקינות שהושלמו בזמן. מתחילים במדד וביעד, ורק אחר כך מחליטים אם להפוך אותם להתחייבות.
### האם זמינות של 99.9% מספיקה לסוכן AI עסקי?
לא בהכרח. זמינות אומרת שהשירות היה נגיש לפי הגדרה מסוימת. היא אינה מוכיחה שהסוכן קרא את המקור הנכון, ביצע פעולה תקינה או סיים בזמן שמועיל לעסק. עבור תהליך עסקי צריך למדוד גם נכונות, זמן מקצה לקצה והעברה מסודרת של חריגים.
### האם זמן המתנה לאדם צריך להיכלל במדידה?
בחוויית הלקוח כן, כי מבחינתו העבודה עדיין לא הסתיימה. בניתוח פנימי כדאי להפריד בין זמן עבודה של הסוכן לזמן המתנה לאישור או למידע. ההפרדה מונעת ויכוח מאשים ומראה היכן נדרש שינוי: בסוכן, בתהליך האישור או בהבטחה ללקוח.
### מה עושים כשמערכת חיצונית שוברת את היעד?
מגדירים מראש כיצד מודדים תלות חיצונית ומה הסוכן עושה בזמן התקלה. הוא יכול לשמור עבודה בתור, להפסיק ניסיונות לאחר גבול, להודיע לבעלים ולהימנע מהבטחת השלמה. מבחינת הלקוח, התהליך עדיין באחריות העסק גם אם ספק אחר נכשל. לכן צריך מסלול חלופי ולא סעיף פטור עמום.
### באיזו תדירות בודקים את רמת השירות?
לפעילות שוטפת כדאי לראות חריגות בזמן שמאפשר תגובה, ולסכם מגמות בחלון יציב שמתאים לנפח. תהליך עם מעט משימות אינו מתאים למסקנות יומיות. מעבר תקופתי צריך לבדוק זמן, נכונות, סיבות עצירה ועומס, וכן האם היעד עדיין תואם את מחיר האיחור והטעות.
### מי אחראי ל־SLA של סוכן AI?
נדרש בעל תהליך עסקי שמגדיר תוצאה וסיכון, ובעל תפעולי או טכני שמבטיח מדידה וטיפול בחריגות. ספק יכול להתחייב לחלק מהשירות, אבל העסק נשאר אחראי לתהליך המלא מול לקוחותיו. שם אחד צריך להופיע ליד כל חריגה, אחרת ההתחייבות נשארת בין צוותים.
## הצעד הראשון: כתבו הבטחה אחת עם שעון אחד
בחרו סוג עבודה אחד שהסוכן אמור לבצע. כתבו מה מפעיל אותו, מהי תוצאה תקינה, איזה שעון מודד אותה ומי מקבל חריגה. אם המשפט דורש הסברים בעל פה, הוא עדיין לא מוכן למדידה.
אפשר לקבוע [פגישת גילוי אוטומציה](/automation-discovery) ולהגיע אליה עם המשפט הזה. יחד נהפוך אותו ליעד שירות שניתן לבדוק בפיילוט, לפני שהוא נכנס להצעה או להסכם שאיש אינו יודע לקיים.
### מקורות
* [Google SRE: הגדרת יעדי רמת שירות](https://sre.google/sre-book/service-level-objectives/)
* [Google SRE Workbook: מדיניות תקציב שגיאות](https://sre.google/workbook/error-budget-policy/)
* [Microsoft Learn: איך לקרוא הסכם רמת שירות](https://learn.microsoft.com/en-us/azure/reliability/concept-service-level-agreements)
* [Microsoft Azure Well-Architected: הגדרת יעדי אמינות](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics)
עודכן לאחרונה: 5 בספטמבר 2026.