התשובה הקצרה
ממשל AI טוב אינו שכבת אישורים נוספת אלא מנגנון שמכריע מהר בשאלות חוזרות: מי מחליט מה סוכן רשאי לעשות, אילו בקרות חובה לפי רמת הסיכון, ומה נדרש כדי לשנות התנהגות אחרי ההשקה. בהיעדר מנגנון כזה, כל סוכן חדש הופך לדיון מהתחלה.
העיקרון המרכזי הוא דירוג. סוכן פנימי שקורא מידע ואינו כותב דבר לא צריך לעבור את אותו מסלול כמו סוכן שמדבר עם לקוחות ומבצע זיכויים. מסלול אחיד מייצר או חסימה או עקיפה, ובדרך כלל את שניהם.
סיווג סיכון: הבסיס לכל שאר ההחלטות
| דרג | מאפיינים | מאשרים | בקרות חובה |
|---|---|---|---|
| נמוך | פנימי, קריאה בלבד, ללא נתוני לקוח רגישים | בעל תהליך + מנהל פלטפורמה | Grounding מאושר, לוג שיחות, סקירה חודשית |
| בינוני | פנימי עם כתיבה הפיכה, או חשיפת מידע ללקוח | + ארכיטקט + נציג Data | Test set, בדיקות Persona, ניטור שבועי |
| גבוה | פעולה מול לקוח, כסף, הרשאות או נתון בלתי הפיך | + Risk, Legal ו-CISO | אישור אנושי, Audit trail מלא, תוכנית Rollback |
| אסור | החלטות עם השלכה משפטית או רגולטורית ישירה ללא אדם | - | Use Case נדחה או מפוצל לתת-משימה בדרג נמוך יותר |
הסיווג נקבע לפי שלוש שאלות בלבד: האם הפעולה הפיכה, מי נחשף לתוצאה, ואיזה סוג מידע נוגע בתהליך. שלוש שאלות שאפשר לענות עליהן בעשר דקות, וזה בדיוק מה שהופך את המודל לשמיש.
שלושת התפקידים שצריך למנות
בעלים עסקי אחראי לתוצאה, מגדיר מה הסוכן רשאי לעשות ומכריע בהתנגשויות. הוא זה שיצטרך להסביר להנהלה מדוע הסוכן ענה כפי שענה, ולכן אי אפשר להשאיר את התפקיד ריק או לחלוק אותו בין שני מנהלים.
בעלים טכני אחראי למימוש, לניטור, לתהליך השינוי ולעלות. הוא מחזיק את רישום הסוכנים ואת ה-Runbook לטיפול בכשלים.
מבקר עצמאי - לרוב נציג Risk או אבטחת מידע - אינו מעורב בבנייה ולכן יכול לבדוק. תפקידו לדגום שיחות, לאמת שהבקרות שהוצהרו אכן פועלות, ולהעלות ממצאים לפורום ההחלטה. בלי גורם שאינו שותף להצלחת הפרויקט, הבקרה הופכת לדיווח עצמי.
מודל האחריות מול Salesforce וספקי המודלים מפורט באבטחת Agentforce ואחריות משותפת.
רישום הסוכנים
זהו המסמך היחיד שאסור לוותר עליו. הוא אינו צריך להיות מערכת - טבלה מתוחזקת מספיקה - אבל הוא חייב להיות מעודכן. לכל סוכן פעיל: מטרה במשפט אחד, בעלים עסקי וטכני, דרג סיכון, ערוצים פעילים, רשימת Actions וההרשאות שלהן, מקורות Grounding, נקודות אישור אנושי, תאריך סקירה אחרון ושלושת מדדי הביצוע העיקריים.
הרישום פותר בעיה שמופיעה בשנה השנייה: התפשטות סוכנים. כשכל צוות בונה סוכן משלו, מגלים שלושה סוכנים שעונים על אותה שאלה בשלוש דרכים שונות, ואף אחד לא יודע מי אישר את השלישי.
תהליך שינוי אחרי ההשקה
הבחנה בין שינוי שגרתי לשינוי מהותי היא מה שמונע ממשל משתק. שינוי שגרתי - ניסוח, תיקון ניסוח בתשובה, הוספת מאמר Knowledge קיים לאינדקס - עובר בתהליך השינוי הרגיל של הפלטפורמה. שינוי מהותי דורש אישור מחדש בדרג המתאים.
ארבעה שינויים תמיד מהותיים: הוספת Action חדש, הרחבת הרשאה, פתיחת ערוץ חדש, והסרה או ריכוך של נקודת אישור אנושי. אלה בדיוק השינויים שנעשים בשקט תחת לחץ לשפר ביצועים, ולכן צריך לתייג אותם מראש.
מנגנוני הניטור שמזינים את תהליך השינוי מפורטים בObservability לסוכני AI.
מה הממשל בודק בפועל, רבעונית
הסקירה הרבעונית אינה מצגת סטטוס. היא בודקת חמישה דברים: האם הסוכנים ברישום עדיין נחוצים, האם הבקרות שהוצהרו פועלות בדגימה, האם העלות ביחס לתוצאה מוצדקת, אילו הסלמות חוזרות מצביעות על פער תוכן, והאם שינויים מהותיים עברו את המסלול הנכון.
תוצאת הסקירה היא רשימת החלטות: להרחיב, לצמצם, להשעות או לסגור סוכן. ממשל שלא מסוגל לסגור סוכן אינו ממשל - הוא תיעוד.
תרחיש: קמעונאי שהחזיר שליטה בלי לעצור פיתוח
רשת קמעונאית גילתה שבע יוזמות AI במקביל בארבע מחלקות, ללא רישום ובלי ידיעת Risk. התגובה הראשונה שהוצעה הייתה הקפאה גורפת עד להקמת מדיניות - צעד שהיה מקפיא גם את שתי היוזמות שכבר הניבו ערך.
במקום זאת בוצע מיפוי בן שבועיים: כל יוזמה סווגה לדרג סיכון. חמש נמצאו בדרג נמוך והמשיכו עם אישור מקוצר של בעל תהליך ומנהל פלטפורמה. שתיים - האחת נגעה בזיכויים ללקוח והשנייה חשפה נתוני מלאי לספקים - הועברו לדרג גבוה, קיבלו נקודות אישור אנושי ונבדקו על ידי Risk לפני המשך.
שישה חודשים אחר כך, מספר היוזמות גדל אך ההנהלה ידעה לראשונה מה קיים, מי אחראי ומה העלות. המסקנה המעשית: הממשל הרוויח לגיטימציה דווקא משום שהוא לא חסם את הדרג הנמוך.
סיכוני ממשל ופעולות מניעה
| סיכון | איך הוא נראה | פעולת מניעה |
|---|---|---|
| ועדה חוסמת | צוותים בונים מחוץ למסלול המאושר | מסלול מהיר לדרג נמוך עם שני מאשרים בלבד |
| רישום לא מעודכן | מבקר מגלה סוכן שאיש לא הכיר | עדכון רישום כתנאי לעליית גרסה |
| בעלות רק ב-IT | אין מי שמכריע בהתנהגות עסקית | מינוי בעלים עסקי בשם לכל סוכן |
| בקרה מדווחת עצמית | הבקרות קיימות במסמך ולא במציאות | דגימת שיחות בידי גורם שאינו שותף לבנייה |
| שינוי מהותי בשקט | הסרת אישור אנושי לשיפור זמן תגובה | רשימה סגורה של שינויים המחייבים אישור מחדש |
מדדי ממשל
| מדד | מה הוא מגלה | תדירות |
|---|---|---|
| כיסוי רישום | אחוז הסוכנים הפעילים המתועדים | חודשי |
| זמן אישור ממוצע | האם המסלול הפך לצוואר בקבוק | חודשי |
| ממצאי דגימה | פער בין בקרה מוצהרת למצב בפועל | רבעוני |
| שינויים מהותיים במסלול הנכון | משמעת התהליך | רבעוני |
| סוכנים שהושעו או נסגרו | האם הממשל מסוגל להחליט לא | רבעוני |
כאשר נדרש ליווי בהקמת מודל ממשל שמתאים לגודל הארגון ולרגולציה שחלה עליו, שירות Agentforce ו-AI הוא המסלול המעשי להמשך.
Checklist להקמת ממשל
- ☐ מודל סיווג סיכון בן שלוש שאלות אושר
- ☐ נקבעו מאשרים לכל דרג, כולל מסלול מהיר לדרג נמוך
- ☐ מונו בעלים עסקי וטכני לכל סוכן קיים
- ☐ מונה מבקר עצמאי שאינו שותף לבנייה
- ☐ הוקם רישום סוכנים עם כל שדות החובה
- ☐ הוגדרה רשימה סגורה של שינויים מהותיים
- ☐ נקבעה שגרת סקירה רבעונית עם סמכות לסגור סוכן
- ☐ הוגדרו מדדי ממשל ותדירות דיווח להנהלה