מהי הרשאה נכונה לסוכן AI?
הרשאה נכונה מאפשרת לסוכן לבצע את התהליך המוסכם ורק אותו. היא מגדירה חשבון, מערכת, נתונים, פעולות וזמן, לצד נקודות שבהן הסוכן עוצר ומבקש מאדם להחליט.
חיבור טכני אינו הרשאה עסקית. העובדה שממשק של ERP או CRM מסוגל לשנות רשומה אינה אומרת שהסוכן צריך לקבל את היכולת הזאת. מתחילים מתיאור העבודה, ואז נותנים את הגישה המצומצמת שהשלבים דורשים.
חמש שכבות של הרשאה
1. זהות
השתמשו בחשבון ייעודי כשמערכת המקור תומכת בכך. החשבון צריך להיות מזוהה, ניתן לביטול ונפרד מחשבון אישי רחב של עובד.
2. סביבה ונתונים
הגדירו חברה, סביבת עבודה, תיקייה, רשומות ושדות. תהליך שבודק מצב הזמנה אינו צריך בהכרח שכר, פרטי בנק או מסמכים שאינם קשורים.
3. פעולות
הפרידו בין קריאה, יצירה, עדכון, מחיקה, שליחה והפעלת תהליך. הרשאת קריאה אינה הרשאת כתיבה, והרשאת עדכון סטטוס אינה הרשאה לערוך כל שדה.
4. כללים ואישורים
גם פעולה זמינה יכולה להיות כפופה לתנאי עסקי: סכום, סוג לקוח, סטטוס, שעה או אישור של בעל תפקיד. פעולות רגישות נשארות אצל אדם.
5. מעקב וביטול
צריך לדעת איזה חשבון ביצע פעולה, על איזו רשומה ומה הייתה התוצאה. בעל מערכת מוסמך צריך להיות מסוגל לבטל את הגישה; הפעולה התלויה בה צריכה להיעצר ולהציג מצב ברור.
למה כדאי להתחיל בקריאה?
קריאה מאפשרת לבדוק אם הסוכן מוצא את הרשומה הנכונה, מפרש שדות כראוי ומחזיר הקשר שימושי לפני שמאפשרים שינוי. גם בקריאה צריך לצמצם מידע: דוח שמסכם הזמנות אינו זקוק אוטומטית לכל נתוני הלקוח.
אחרי שמקרי הבדיקה עוברים, אפשר לבחון פעולה נוספת בנפרד. כל הרחבה צריכה מטרה, בעלים, דוגמאות, תנאי קבלה ודרך לעצור. אין חובה להרחיב; תהליך קריאה שמכין מידע לאדם יכול להיות תוצאה מלאה ושימושית.
מה GIMMI מתעדת כיום לגבי Priority ERP?
היכולת המתוארת באתר GIMMI עבור Priority ERP היא קריאת נתוני לקוחות, ספקים, הזמנות ופריטים, במסגרת הרשאות החשבון והמערכת. שימוש אפשרי הוא איסוף פרטי הזמנה לצורך בדיקה ועדכון לצוות. זהו היקף שימוש מתועד, ולא טענה שכל ממשק Priority מוגבל מטבעו לקריאה.
התיעוד הרשמי של Priority מתאר ממשק REST שמאפשר גם בקשות נתונים וגם פעולות שינוי, בכפוף לתצורת המשתמש וליכולות המערכת. לכן בודקים את החשבון ואת הגישה בפועל, ולא מסיקים הרשאה מרשימת יכולות כללית. פעולות נוספות נבחנות בנפרד מול המערכת, סוג החשבון והגישה הזמינה.
ראו את היקף החיבור הנוכחי בעמוד החיבורים.
דוגמה להמחשה: סיכום הזמנות פתוחות
הוא אינו תיאור של לקוח, חבילת שירות קבועה או הוכחה להרשאה במערכת מסוימת.
נניח שמנהל תפעול מבקש ב-WhatsApp סיכום של הזמנות פתוחות לספק מסוים. עובד AI מזהה את הספק לפי מזהה מוסכם, קורא את שדות ההזמנה הנדרשים ומחזיר טיוטת סיכום. הוא אינו משנה הזמנה, ספק, מלאי או תשלום.
אם נמצאות כמה רשומות דומות, חסר מזהה או שהחשבון אינו מורשה לקרוא את הנתון, הסוכן עוצר ומציג את החסר. אם בעתיד רוצים לאפשר עדכון סטטוס, זו פעולה חדשה שדורשת מיפוי, הרשאה ובדיקות משלה.
איך בודקים הרשאות ושינויים?
- רושמים במילים פשוטות את הפעולה המותרת ואת הפעולות האסורות.
- בודקים רשומות רגילות, חסרות, כפולות ובלתי מורשות בסביבה מתאימה.
- מאמתים שהסוכן עוצר כשאין ודאות ואינו מציג הצלחה אחרי דחייה.
- בודקים מה מופיע ביומן המערכת ומי מקבל התראה.
- מנסים לבטל גישה ומוודאים שהפעולה נפסקת.
- מתעדים כל הרחבה ומריצים שוב את מקרי הבדיקה הרלוונטיים.
אין לתת לסוכן נתוני התחברות בשיחה. החיבור נעשה במסלול ההרשאה הרשמי שהמערכת מציעה, על ידי מי שמוסמך לנהל את החשבון.
רשימת בדיקה קצרה לבעל המערכת
- יש תהליך אחד מוגדר ותוצאה שאפשר לבדוק.
- החשבון והסביבה הנכונים מזוהים.
- יש רשימה מפורשת של נתונים ופעולות מותרים.
- כל פעולה רגישה מחייבת אדם או נשארת חסומה.
- כשל, דחייה וחוסר מידע אינם מוצגים כהצלחה.
- יש דרך לבטל גישה ולראות מי עשה מה.
הבחירה במערכות מתחילה רק אחרי הגדרת העבודה. קראו על בחירת תהליך ראשון ועל חיבור עובד AI לכלים קיימים.
מקורות מקצועיים וקריאה נוספת
- Priority Developer Portal — REST API, תיעוד רשמי לבקשות נתונים ולפעולות שינוי באמצעות OData. נבדק ב-7 בספטמבר 2026.
- Priority Developer Portal — REST API and Web SDK overview, סקירת יכולות והרשאות של ממשקי Priority. נבדק ב-7 בספטמבר 2026.
- NIST AI Resource Center, משאבים למיפוי, מדידה, ניהול ובקרה של סיכוני AI. נבדק ב-7 בספטמבר 2026.