מי אישר לסוכן ה־AI לעשות את זה? מסלול הביקורת שחסר לכם

מבקר חיצוני שואל: “הסוכן אישר את הבקשה הזו — מי בדק אותה ולפי איזה כלל?” אם התשובה היא “הסוכן פשוט החליט”, הצוות אינו יכול לבסס את ההחלטה. זו בעיה תפעולית, והיא עשויה להיות גם סוגיית ציות.

ככל שסוכנים עוברים משיחה לפעולה — עדכון רשומת לקוח, סיוע בהערכת אשראי או פתיחת תביעה — גדלה החשיבות של החלטות שאפשר לעקוב אחריהן. Camunda 8.9 מוסיפה יכולות שרלוונטיות לכך. בארגון ישראלי מפוקח, צריך להבין מה הפלטפורמה מתעדת ומה צריך להשלים ביישום.

מה חדש ב-Camunda 8.9

Camunda 8.9 מוסיפה יומן ביקורת מרכזי לפעולות נתמכות בתחומי התהליך, הזהות ומשימות המשתמש. תיעוד יומן הביקורת מתאר רישום של מי ביצע פעולה, מתי ועל איזו ישות. הרשומות יכולות לתמוך בביקורת, אבל הן אינן תיאור מלא של ההיגיון של מודל ה-AI או של כל פעולה במערכת חיצונית.

ליומן יש כמה מאפיינים שרלוונטיים לארגון מפוקח:

• גישה דרך API: הרשומות זמינות ב-Orchestration Cluster REST API לצורך שילוב במערכות דיווח וממשל.
• ממשקי תפעול: הרשומות זמינות ב-Operate, ב-Tasklist וב-Admin, שנקרא בעבר Orchestration Cluster Identity.
• בקרת גישה: הרשאות קובעות מי יכול לצפות ברשומות.
• הגדרת היקף התיעוד: אפשר לבחור סוגי מבצעים ופעולות. ברירת המחדל המתועדת כוללת פעולות משתמשים, ולא פעולות של לקוחות API. בדקו שההגדרות מכסות את הזהויות שבהן הסוכנים והמחברים משתמשים בפועל.

הגרסה מוסיפה גם מחברי לקוח A2A (Agent-to-Agent) לגילוי סוכנים מרוחקים, לשליחת הודעות ולקבלת תשובות. עם זאת, בתיעוד 8.9 הם מופיעים כיכולות אלפא, ומצוין שאין כרגע תמיכה באימות זהות מול שרת A2A מרוחק. תמיכה בפרוטוקול אינה הבטחה להודעות חתומות, לגישה מרוחקת מאומתת או לתיעוד מלא בין סוכנים. אבטחה, קישור הרשומות ומסלולי העברה לטיפול אנושי דורשים תכנון ובדיקה מפורשים.

למה זה חשוב לגוף מפוקח בישראל

בתהליך בנקאי או ביטוחי רגיש, התחילו בתיעוד שצוותי הסיכון והציות צריכים: מזהה מקרה, מבצע הפעולה, גרסת המדיניות, פעולה, אישור ותוצאה. מפו את הדרישות למערכות המשתתפות. כדי להסביר מקרה שלם, ייתכן שצריך לקשר רשומת פעולה ב-Camunda לרשומות מהיישום, מספק הזהויות ומסוכן חיצוני.

הנחיות הרשות להגנת הפרטיות ליישום תקנה 10 עוסקות בתיעוד גישה למאגרים שחלה עליהם רמת אבטחה בינונית או גבוהה. הן מתארות רישום של זהות, זמן, רכיב המערכת, סוג הגישה והיקפה, והאם אושרה או נדחתה. זו דרישה מדויקת יותר מהנחיה כללית לתעד פעילות AI. יומן ביקורת של תהליך לבדו לא בהכרח מכסה גישה למסד הנתונים או את כל האירועים הנדרשים.

התייחסו ליומן הביקורת כחלק ממערך הבקרה. בדקו את היקף התיעוד, משך השמירה, ההגנה מפני שינוי והגישה למורשים מול דרישות המערכת שלכם. עצם קיומה של היכולת אינו אישור רגולטורי ואינו הופך רשומה אוטומטית לראיה קבילה משפטית.

מה זה אומר לארגון שלכם

אם אתם שוקלים סוכני AI בתהליך רגיש - אשראי, תביעות, שירות לקוחות עם השלכה כספית - שלוש שאלות כדאי לשאול לפני ההטמעה:

1. האם אפשר לשחזר את הטיפול במקרה? בדקו כיצד מקושרים פעולות הסוכן, אישורים אנושיים, גרסאות מדיניות ואירועים במערכות חיצוניות.
2. האם גורמים מורשים יכולים לשלוף את התיעוד? הגדירו ייצוא או שאילתה שאפשר לחזור עליהם, עם הרשאות ואחראי ברור. הצורך בשאילתה אינו כשל בפני עצמו; מידע חסר או לא נגיש הוא הבעיה.
3. מה קורה כשסוכן מפעיל סוכן אחר? בדקו זהויות, הרשאות, מזהים לקישור בין הרשומות, טיפול בכשלים ותיעוד שנשמר בשני הצדדים.

זו בדיוק הגישה שאנחנו מקדמים ב-NG Workshop: AI שעובד בתוך התהליך, לא במקומו - כך שהתיעוד, הבקרה וההרשאות הם חלק מהארכיטקטורה מהיום הראשון, ולא תוספת שמנסים לצרף אחרי שהרגולטור שאל שאלה. הרחבנו על ההפרדה בין הסוכן למנוע התהליך בסוכני AI צריכים מנצח, ועל האיזון בין אוטומציה לפיקוח אנושי בHuman-in-the-Loop כממשל.

מקורות

• Camunda 8.9: Fastest Path to Agentic Orchestration

סיכום

• Camunda 8.9 מספקת יומן מרכזי לפעולות נתמכות, הנגיש דרך API וכלי התפעול.
• ההגדרות חשובות: פעולות של לקוחות API אינן מתועדות כברירת מחדל, ולתמיכה ב-A2A יש מגבלות מתועדות.
• מוכנות לביקורת דורשת תיעוד לאורך התהליך כולו ובקרות שמתאימות לחובות הארגון.

רוצים לבחון את מוכנות הארגון שלכם לסוכני AI מבוקרים? דברו איתנו