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