במאמר הזה
סוכן AI שמדבר עם SAP הוא אחד ה-use cases עם ה-ROI הגבוה ביותר שאנחנו פוגשים, וגם אחד המפחידים ביותר עבור מנהלי אבטחת מידע. ה-ERP מחזיק את הנתונים הרגישים ביותר בארגון: שכר, ספקים, מחירים, מלאי. במאמר הזה נפרק איך בונים את החיבור נכון, שכבה אחרי שכבה.
שלב 1: משתמש טכני ייעודי עם הרשאות מינימליות
הטעות הנפוצה ביותר היא לתת לסוכן להשתמש במשתמש של עובד קיים. במקום זה, מגדירים משתמש טכני (Communication User) ייעודי לסוכן, עם roles שנגזרים בדיוק מהמשימות שהוא אמור לבצע. סוכן שקורא סטטוס הזמנות לא צריך גישה לטבלאות שכר.
שלב 2: RFC או OData, ומתי כל אחד
לקריאות פשוטות ומודרניות, OData דרך ה-Gateway הוא הבחירה הנכונה: הוא מקבל את כל בקרות ההרשאה של SAP ומחזיר JSON נקי. ל-BAPIs מורכבים או למערכות ישנות יותר, RFC עדיין רלוונטי, אבל אז חובה לעטוף אותו בשכבת API פנימית שמגבילה אילו function modules הסוכן יכול להפעיל.
שלב 3: שכבת ביניים, לעולם לא חיבור ישיר
הסוכן אף פעם לא מדבר עם SAP ישירות. בין ה-LLM ל-ERP יושבת שכבת API שאנחנו שולטים בה: היא מאמתת כל בקשה, אוכפת rate limits, מנקה פרמטרים ומתעדת הכל. אם הסוכן "מחליט" לבקש משהו שהוא לא אמור, השכבה חוסמת לפני ש-SAP בכלל רואה את הבקשה.
שלב 4: Audit trail שעומד בביקורת
כל בקשה של הסוכן נרשמת: מי המשתמש שהפעיל את השיחה, מה הסוכן ביקש, מה הוחזר ומתי. הלוג הזה הוא מה שהופך את הפרויקט מ"ניסוי מפחיד" ל"מערכת שעוברת ביקורת ISO ו-SOX".
שלב 5: Human-in-the-loop לפעולות כתיבה
קריאת נתונים יכולה להיות אוטומטית לגמרי. כתיבה ל-SAP (יצירת הזמנה, עדכון ספק) עוברת דרך אישור אנושי לפחות בחודשים הראשונים. ככל שהביטחון במערכת עולה, אפשר להרחיב את מרחב הפעולות האוטונומיות בהדרגה.
השורה התחתונה
סוכן SAP בטוח הוא לא קסם, הוא הנדסה: הרשאות מינימליות, שכבת ביניים, תיעוד מלא ואישורים אנושיים בנקודות הנכונות. עשיתם את זה נכון? קיבלתם סוכן שחוסך מאות שעות אנוש בלי לילה לבן אחד למנהל האבטחה.
ספרו לנו על תהליך אחד בשיחה של 30 דקות. נגיד לכם בכנות אם סוכן יכול לעשות אותו.
