איך מתכננים סוכן AI לעסק: מתחילים מהחלטה, לא מהפרומפט

# איך מתכננים סוכן AI לעסק: מתחילים מהחלטה, לא מהפרומפט אחרי שיחה טובה עם סוכן AI, קל לחשוב שהפרומפט הוא המוצר. הוא מנוסח היטב, התשובה נראית חכמה וההדגמה זורמת. אבל ברגע שהסוכן צריך לפעול בתוך עסק, הפרומפט הופך לחלק קטן מהתמונה. החלק הקשה הוא להגדיר החלטה: איזה מידע נחשב מספיק, איזו אפשרות עדיפה, מתי מותר להתקדם ומתי חייבים לעצור. בלי ההגדרה הזאת, גם מודל מצוין יאלתר במקום שבו העסק זקוק לעקביות. זו העמדה שלי: תכנון סוכן AI לעסק צריך להתחיל בכתיבת מדיניות החלטה לתהליך אחד. את הפרומפט כותבים אחר כך. לא מפני שהוא חסר חשיבות, אלא מפני שאין טעם לנסח הוראות יפות לפני שהעסק החליט מהי פעולה נכונה. ## פרומפט מסביר כיצד לדבר, מדיניות קובעת כיצד לבחור ניקח בקשת הנחה מלקוח. אפשר לכתוב לסוכן: "ענה בנימוס, התחשב בהיסטוריית הלקוח והצע פתרון ששומר על הרווחיות". זה נשמע סביר, עד שמנסים לבצע את ההחלטה. מהי היסטוריה טובה? מהו שיעור רווחיות שאסור לרדת ממנו? האם נציג מכירות רשאי לאשר חריגה? האם לקוח עם חשבונית פתוחה מקבל אותה הצעה? ומה קורה כשמחיר הרכישה במערכת לא עודכן? אלה אינן שאלות ניסוח. הן מדיניות עסקית. פרומפט יכול להסביר לסוכן איך להפעיל מדיניות, אך הוא לא צריך להמציא אותה מתוך כמה משפטים כלליים. ההבחנה הזו חשובה מפני שסוכן פועל מול מצב משתנה. הוא קורא טקסט חופשי, מחבר הקשר ובוחר צעד. אם הקריטריונים לבחירה נשארו בראש של מנהל ותיק, המערכת תיראה חכמה במקרים הרגילים ותהפוך ליצירתית מדי בדיוק במקרים הרגישים. ## המקום שבו מנהלים אומרים "זה תלוי" הוא חומר הגלם בתהליך עסקי אמיתי כמעט תמיד מגיע רגע שבו התשובה היא "זה תלוי". עסקים נוטים לראות בו הפרעה לאפיון. אני רואה בו את נקודת ההתחלה. כשמנהל אומר שהטיפול תלוי בסוג הלקוח, בדחיפות, בסכום או במסמך שחסר, הוא כבר מצביע על משתני ההחלטה. עכשיו צריך להוציא אותם מהראש ולתת להם צורה שאפשר לבדוק. אפשר להתחיל מארבע שאלות: * מה הסוכן מנסה להחליט ברגע הזה? * אילו עובדות משנות את ההחלטה? * אילו תנאים מחייבים עצירה או אישור? * איזו ראיה תראה בדיעבד מדוע נבחר הצעד? אין צורך להפוך כל שיקול לתרשים ענק. המטרה היא למצוא את ההבדל בין שיקול מקצועי אמיתי לבין הרגל שאיש לא בחן שנים. לפעמים נגלה שהכלל פשוט. במקרים אחרים נגלה ששני מנהלים מקבלים החלטות שונות על אותו מקרה. זאת אינה תקלה של AI. זאת מחלוקת תפעולית שהייתה קיימת קודם, רק בלי חלון ראווה. ## כך מפרקים החלטה אחת בלי לכתוב ספר נהלים נניח שהסוכן אמור לתעדף בקשות שירות. במקום להתחיל מרשימת כל הדברים שהוא יכול לעשות, בוחרים החלטה אחת: איזו בקשה צריכה לעבור מיד לאדם, ואיזו יכולה להיכנס לתור הרגיל. השלב הראשון הוא לאסוף מקרים אמיתיים. רצוי לבחור גם מקרים קלים וגם כאלה שעוררו ויכוח. ליד כל מקרה רושמים מה הוחלט בפועל ומדוע. אם אין הסבר מעבר ל"ככה הרגשתי", לא מסתירים את זה. מסמנים שהכלל עדיין חסר. לאחר מכן מפרידים בין עובדות לפרשנות. "הלקוח כתב שהמערכת נפלה" הוא טקסט. "כל המשתמשים מושבתים" היא מסקנה שדורשת אימות. ההפרדה מונעת מסוכן להפוך ניסוח לחוץ לעובדה תפעולית. עכשיו מגדירים מסלולים אפשריים. למשל, העברה מיידית, בקשת פרט נוסף או כניסה לתור. לכל מסלול מצרפים תנאי כניסה ותנאי עצירה. זה כבר מספיק כדי לבנות גרסה ראשונה ולבחון אותה מול דוגמאות שלא שימשו לכתיבת הכללים. רק בשלב הזה מגיע הפרומפט. תפקידו להסביר לסוכן כיצד לקרוא את הבקשה, להשתמש בעובדות שאושרו, להחיל את הקריטריונים ולהציג את הנימוק. הוא יושב על החלטה קיימת במקום לנסות להיות ההחלטה. ## החלטה טובה משאירה אחריה קבלה מערכת עסקית צריכה להיות מסוגלת להסביר מה קרה בלי לשחזר שיחה ארוכה. לכן לכל החלטה של סוכן כדאי לשמור קבלה קצרה: הקלט הרלוונטי, העובדות ששימשו אותו, הכלל שהופעל, התוצאה והאם היה אישור אנושי. הקבלה אינה אמורה לחשוף את כל תהליך החשיבה של המודל. היא צריכה להציג ראיות תפעוליות שאדם יכול לבדוק. בתעדוף בקשת שירות, לדוגמה, אפשר לשמור שהבקשה סווגה כדחופה מפני שהשירות אינו זמין לכל הסניף, ושסטטוס המערכת אומת במקור נוסף. לפי מסגרת ניהול הסיכונים של NIST, מדידה וניהול של מערכות AI דורשים תיעוד, אחריות ומעקב אחר ביצועים בהקשר שבו המערכת פועלת. לעסק קטן אין צורך להקים ועדה מפוארת. כן צריך לדעת מי בודק החלטות שגויות ומי מוסמך לשנות כלל. בלי קבלה כזאת, כל טעות נגמרת בוויכוח על ניסוח. איתה אפשר לשאול שאלה מועילה יותר: האם העובדה הייתה שגויה, הכלל היה חסר או שהסוכן החיל אותו לא נכון? ## מודל חדש אינו פותר מדיניות עמומה כשסוכן מקבל החלטות לא עקביות, הפיתוי הראשון הוא להחליף מודל או ללטש שוב את הפרומפט. לפעמים זה מוצדק. לעיתים קרובות הבעיה נמצאת קודם. אם אין הגדרה מוסכמת ללקוח בסיכון, שום מודל לא יידע אותה. אם שני מחירונים פעילים במקביל, ניסוח חד יותר לא יבחר מקור אמת. אם איש אינו יודע מי מאשר חריגה, הסוכן לא יכול להמציא סמכות ארגונית. מודל חזק יותר עשוי להסתיר את העמימות לזמן מה, מפני שהוא מנסח תשובה משכנעת יותר. זו דווקא סכנה. תשובה חלקה גורמת לאנשים לבדוק פחות את ההנחות שמאחוריה. הבדיקה הנכונה היא להסיר לרגע את ה־AI מהדיון. תנו לאדם חדש בארגון את אותם נתונים ואת אותה מדיניות. אם גם הוא אינו יכול להגיע להחלטה צפויה, הבעיה אינה במודל. ## ההתנגדות הסבירה: אי אפשר לכתוב כלל לכל מצב נכון. גם לא צריך. סוכן שימושי מפני שהוא מסוגל לעבוד עם שפה ועם מצבים שלא נכתבו מראש אחד לאחד. מדיניות החלטה אינה אמורה לחזות כל פנייה. היא מגדירה עקרונות, מקורות מוסמכים, גבולות וסיבות לעצור. ההבדל דומה להבדל בין תסריט לבין שיקול מקצועי. תסריט אומר בדיוק איזה משפט לומר. מדיניות אומרת מה צריך להשיג, באילו נתונים מותר להשתמש ומה אסור להבטיח. בתוך המסגרת הזאת נשאר לסוכן מרחב להתאים את הטיפול למקרה. גם בני אדם עובדים כך כשהעסק מנוהל היטב. הם אינם קוראים טקסט קבוע בכל מצב, אבל הם יודעים מתי הנחה דורשת אישור ומאיזה מסמך לוקחים מחיר. סוכן זקוק לאותה בהירות, בגרסה שניתן לאכוף ולבדוק. ## מבחן קטן לפני שבונים את הסוכן בחרו החלטה אחת שחוזרת בתהליך שלכם. לא מחלקה שלמה ולא חזון לשנה. החלטה אחת, כמו האם בקשה מוכנה להצעת מחיר, האם פנייה דורשת טיפול דחוף או האם מסמך שלם מספיק להמשך. כתבו חמישה מקרים אמיתיים. ליד כל אחד רשמו את העובדות ששינו את ההחלטה, את התוצאה הרצויה ואת הסיבה לעצירה אם הייתה. אחר כך העבירו את הדף לאדם שלא מטפל בתהליך ביום יום. אם הוא מבין מה לבחור ומתי לבקש עזרה, יש בסיס טוב לסוכן. אם הוא חוזר עם הרבה שאלות, מצוין. השאלות האלה זולות עכשיו. אחרי חיבור למייל, ל־CRM וליומן הן כבר הופכות לתקלות. תכנון סוכן AI מתחיל ברגע שבו העסק מוכן לנסח כיצד הוא מקבל החלטה. הטכנולוגיה יכולה לקרוא, להשוות ולבצע. האחריות להגדיר מה נחשב נכון נשארת אצל העסק. אם יש אצלכם החלטה שחוזרת עשרות פעמים אך עדיין חיה בעיקר בראש של אדם אחד, שלחו ל־AI BUDDY דרך [aibuddy.co.il](https://aibuddy.co.il) חמישה מקרים שונים שלה. נבדוק אם אפשר להפוך אותם למדיניות עבודה לסוכן, לפני שמתחילים לחבר מערכות או לכתוב פרומפטים. ### מקורות * [NIST AI Risk Management Framework 1.0](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) * [Microsoft Learn: Agent evaluation checklist](https://learn.microsoft.com/en-us/agents/agent-evaluation/evaluation-checklist)