הרשאות לסוכן AI: מה מותר לו לעשות לבד ומה חייב אישור
# הרשאות לסוכן AI: מה מותר לו לעשות לבד ומה חייב אישור
המיתוס המסוכן ביותר בהטמעת סוכן AI הוא שאוטונומיה מלאה היא סימן למערכת מתקדמת. בפועל, סוכן טוב אינו זה שמקבל חופש מוחלט. הוא זה שיודע בדיוק היכן החופש שלו נגמר.
עסק לא צריך לבחור בין סוכן שעושה הכול לבין מערכת שמבקשת אישור על כל פסיק. הבחירה הנכונה היא פרטנית: איזו פעולה הפיכה, מה עלול ליצור התחייבות, איזה מידע רגיש, וכמה קשה לגלות טעות בזמן. מתוך התשובות בונים מטריצת הרשאות פשוטה. היא הופכת את הדיון מ"אנחנו סומכים על AI?" להחלטות שאפשר לבדוק.
התזה של המדריך הזה ברורה: רמת האוטונומיה צריכה להיקבע לפי הנזק האפשרי של הפעולה, לא לפי הביטחון שבו הסוכן ניסח אותה.
## הרשאה היא החלטה עסקית, לא הגדרה טכנית
כשמחברים סוכן למייל, CRM, יומן, מערכת מסמכים או הנהלת חשבונות, קל לחשוב על הרשאות במונחים של כפתורים: קריאה, כתיבה, עריכה ומחיקה. זו רק שכבת התשתית. השאלה החשובה היא מה משמעות הפעולה בתוך העסק.
שליחת תזכורת פנימית שונה משליחת התחייבות ללקוח. עדכון שדה פנימי שונה משינוי מחיר. יצירת טיוטת חשבונית שונה מהפקת מסמך סופי. אותה פעולת "כתיבה" יכולה להיות זניחה במקום אחד ויקרה מאוד במקום אחר.
לכן מתחילים במפת פעולות, לא ברשימת מערכות. עבור כל פעולה כותבים מי מושפע ממנה, האם אפשר לבטל אותה, איזה מידע היא חושפת ומה יקרה אם היא תבוצע פעמיים. רק אז מחליטים איזו גישה טכנית נדרשת.
הגישה הזאת תואמת את מסגרת ניהול סיכוני ה־AI של NIST, שמפרידה בין ממשל, מיפוי, מדידה וניהול. המסגרת אינה מציעה כפתור קסם. היא דורשת להגדיר הקשר, אחריות וסבילות לסיכון לאורך חיי המערכת. זה נשמע פחות מרגש מהדגמה חיה, ובצדק. ממשל טוב אמור להיות מעט משעמם.
## ארבע רמות במקום מתג אחד
אפשר לנהל את רוב הפעולות באמצעות ארבע רמות. אין צורך באותה רמה לכל התהליך.
ברמת קריאה בלבד, הסוכן מאתר, מסכם ומצליב מידע. זו נקודת פתיחה טובה למידע רגיש. למשל, הוא יכול להכין סיכום של פניות פתוחות מתוך ה־CRM בלי לשנות דבר.
ברמת טיוטה, הוא מכין פעולה וממתין לאישור. כך אפשר לעבוד עם תשובה ללקוח או הצעת מחיר שעדיין דורשת שיקול דעת.
ביצוע עם בקרה מתאים לפעולות חוזרות והפיכות. הסוכן פותח משימה, מתייג פנייה או מתאם פעולה פנימית, ואדם בודק מדגם וחריגים.
ביצוע עצמאי שמור לסיכון נמוך, לכללים ברורים ולפעולה שאפשר לשחזר. שליחת תזכורת קבועה או עדכון סטטוס פנימי יכולים להתאים לרמה הזאת.
הטבלה אינה סולם התקדמות שחייבים לטפס בו. יש פעולות שיישארו תמיד ברמת טיוטה. חוזה, זיכוי חריג או הודעה רגישה אינם "פחות אוטומטיים" מפני שאדם מאשר אותם. הם פשוט מנוהלים נכון.
גם בתוך אותה מערכת אפשר לפצל. סוכן רשאי לקרוא את כל פרטי העסקה הדרושים להכנת תקציר, אבל לעדכן רק שדות מסוימים. הוא יכול להכין מייל, אך לא לבחור בעצמו את הנמען החיצוני. הרשאות צרות דורשות מעט יותר תכנון ומונעות הרבה הסברים מביכים.
## מבחן הנזק קובע את רמת האישור
לכל פעולה כדאי לתת ציון לפי שאלות קבועות. לא צריך נוסחה מתמטית. צריך שיחה כנה.
האם הפעולה יוצרת התחייבות כספית או משפטית? האם היא יוצאת מחוץ לארגון? האם היא חושפת מידע אישי או מסחרי? האם אפשר לבטל אותה בלי שהלקוח ירגיש? האם טעות תתגלה מיד, או רק בסוף החודש?
פעולה עם נזק נמוך ויכולת ביטול פשוטה מתאימה לביצוע עצמאי. פעולה חיצונית, רגישה או בלתי הפיכה צריכה אישור. בין שני הקצוות נמצאות פעולות שאפשר לבצע עם מגבלות: תקרה כספית, רשימת נמענים מאושרת, שעות פעילות, תבנית קבועה או עצירה כשחסר מידע.
נניח שסוכן מטפל בבקשות לפגישה. הוא יכול לקרוא זמינות ביומן ולהציע מועדים. קביעת פגישה פנימית עשויה להתבצע לבד. פגישה עם לקוח אסטרטגי יכולה לדרוש אישור. ביטול פגישה קיימת, במיוחד בשם מנהל, צריך מסלול מחמיר יותר. היכולת הטכנית זהה. הנזק העסקי שונה.
## הסכנה אינה "AI שטועה", אלא גישה רחבה מדי
OWASP מגדיר "סוכנות עודפת" כסיכון שנוצר כאשר מערכת מבוססת מודל מקבלת יותר מדי יכולות, הרשאות או אוטונומיה. טעות בניסוח היא מטרד. טעות שמחוברת למחיקה, העברה כספית או שליחה חיצונית כבר יכולה להפוך לאירוע עסקי.
המסקנה המעשית אינה להימנע מסוכנים. היא לצמצם את מרחב הפעולה. אם הסוכן צריך לקרוא מסמכים, אין סיבה לתת לו גם למחוק אותם. אם הוא מעדכן סטטוס עסקה, הוא לא חייב לקבל גישה לשינוי בעלות או תנאי תשלום. חיבור רחב "כדי שיהיה נוח אחר כך" הוא חוב סיכונים שמתחיל לצבור ריבית מיד.
כדאי גם להפריד בין מקור ההוראה לבין סמכות הביצוע. הודעה נכנסת, מסמך מצורף או טקסט שהועתק מאתר אינם הוראה אמינה רק מפני שהסוכן הצליח לקרוא אותם. פעולה רגישה צריכה להישען על כלל שהוגדר מראש, על משתמש מזוהה או על אישור בערוץ מוסכם.
## כך נראית מטריצת הרשאות שאפשר לעבוד איתה
פתחו גיליון אחד. בכל שורה רשמו פעולה, לא מערכת. "CRM" רחב מדי. "פתיחת ליד חדש" היא פעולה. "שינוי סכום עסקה" היא פעולה אחרת.
לכל שורה הוסיפו את העמודות הבאות:
* האירוע שמפעיל את הפעולה
* המידע שהסוכן רשאי לקרוא
* השדות או המערכות שהוא רשאי לשנות
* רמת האוטונומיה שנבחרה
* התנאים שמחייבים עצירה
* האדם שמאשר או מטפל בחריג
* הרישום שנשמר לאחר הביצוע
* דרך הביטול או השחזור
קחו לדוגמה בקשה להנחה. הסוכן יכול לאסוף את נתוני העסקה, לבדוק מחירון ולהכין המלצה. עד שיעור שנקבע מראש, אולי מותר לו להכין הצעה לאישור מנהל מכירות. מעל הסף הוא עוצר ומעביר את ההקשר, בלי לנסות לשכנע ובלי להמציא חריג. המטריצה מגדירה את הגבול לפני שהמקרה הלחוץ מגיע.
העמודה החשובה ביותר היא בעל האחריות. "הצוות" אינו בעלים. צריך שם או תפקיד שמקבל התראה, מסוגל להחליט ומוסמך לשנות את הכלל אם הוא גורם יותר נזק מתועלת.
## אישור אנושי צריך להיות קצר, אחרת יעקפו אותו
שער אישור יכול להגן על העסק, אבל שער גרוע הופך את הסוכן למכונת התראות. אם המאשר מקבל הודעה בלי הקשר, הוא צריך לפתוח שלוש מערכות כדי להבין מה קרה. אחרי כמה ימים הוא יאשר אוטומטית או יבקש לכבות הכול.
בקשת אישור טובה מציגה את הפעולה המוצעת, הסיבה, הנתונים שעליהם הסתמכה, ההשפעה הצפויה והאפשרויות הזמינות. לעיתים מספיקים "אישור", "דחייה" ו"עריכה". במקרים מורכבים צריך קישור לתיק המלא, אבל לא כדאי להטביע את ההחלטה בתוך דוח.
יש להגדיר גם מה קורה כשאיש אינו מגיב. ברירת מחדל בטוחה היא לעצור, לא להניח הסכמה. בפעולות תפעוליות אפשר להעביר לאדם חלופי לאחר זמן מוגדר. בפעולה רגישה עדיף שהעיכוב יהיה גלוי מאשר שהמערכת תאלתר סמכות.
## בקרה אינה צפייה בכל פעולה
אחרי ההשקה, אין טעם לבדוק ידנית כל עדכון שגרתי לנצח. מצד שני, "לא שמענו תלונות" אינו מדד איכות.
בקרה טובה משלבת רישום פעולות, בדיקת מדגם וסקירה של חריגים. בתחילת הדרך בודקים יותר. כשהתוצאות יציבות, מצמצמים את המדגם וממשיכים לעקוב אחרי פעולות שנדחו, תיקונים ידניים וניסיונות לבצע פעולה מחוץ להרשאה.
חשוב למדוד את כל השרשרת. אם הסוכן יוצר משימות מדויקות אבל הצוות אינו מטפל בהן, ההרשאה אינה הבעיה. אם אנשים מתקנים שוב ושוב אותו שדה, ייתכן שהכלל לא נכון. ואם כמעט כל טיוטה מאושרת בלי שינוי, אפשר לשקול בזהירות מעבר לביצוע עם בקרה.
הרחבת הרשאה צריכה להגיע בעקבות ראיות. לא בגלל שהדגמה עבדה פעם אחת ולא מפני שהמודל החדש נשמע בטוח יותר.
## מסמך אחד שמאפשר להתחיל בלי הימור
לפני שמחברים [סוכן AI לעסק](/services/ai-agents), בחרו תהליך אחד ובנו עבורו מטריצת הרשאות. התחילו בקריאה או בטיוטה, תעדו חריגים, ורק לאחר שיש דוגמאות עקביות החליטו אילו פעולות אפשר לשחרר.
זו אינה שכבת בירוקרטיה מעל האוטומציה. זו התשתית שמאפשרת אוטונומיה בלי למסור לסוכן מפתחות לכל הבניין.
AI BUDDY בונה סוכני AI וסוכנים אוטונומיים לעסקים בישראל. אם יש לכם תהליך שכבר ברור אבל גבולות הסמכות שלו עדיין מעורפלים, שלחו לנו דרך [aibuddy.co.il](https://aibuddy.co.il) חמש פעולות שהוא כולל. בשיחת מיפוי נבנה טיוטת מטריצת הרשאות ונבדוק מה אפשר לבצע, מה דורש אישור ומה לא צריך לחבר בכלל. אפשר גם להתקשר ל־[054-2539582](tel:0542539582).