בפוסט שפרסמה חברת Zapier, מתארת החברה את תהליך הפיתוח והניסויים של מנגנון ההרשאות והאישורים בסביבת העבודה Sidekick, מרחב העבודה מבוסס הבינה המלאכותית שלה. החברה מציגה את האתגר המרכזי של מוצרי בינה מלאכותית שמבצעים פעולות ולא רק מייצרים טקסט: האם על הסוכן לבקש רשות לפני כל פעולה, או לפעול ולדווח רק לאחר מעשה. לפי Zapier, שתי הגישות הקיצוניות הללו כושלות בסביבת עבודה מעשית, והחברה מפרטת סדרה של איטרציות, טעויות ופתרונות הנדסיים שנבחנו במהלך פיתוח המערכת.
מדוע שני הקצוות של בקשת אישור אינם עובדים בסביבת עבודה
לפי התיאור של Zapier, כאשר עוזר בינה מלאכותית מבקש אישור על כל פעולה קטנה, המשתמשים חווים שחיקה מהירה. החברה מדגימה מצב שבו הסוכן מבקש רשות לקרוא קובץ, לאחר מכן לקרוא קובץ נוסף, ובהמשך לבצע חיפוש ברשת. עד שמגיעים לבקשה העשירית, המשתמש מפסיק לבדוק את פרטי הבקשה ומאשר אותה באופן אוטומטי. כתוצאה מכך, הבקשה האחת-עשרה, שעשויה לכלול שליחת דוא"ל ללקוח, מאושרת באותו אופן רפלקסיבי מבלי שנבדקה.
הקצה הנגדי, שבו הסוכן אינו מבקש אישור כלל, מציב סיכון שקט אך משמעותי. עוזר שפועל ללא בקשת אישורים יכול לפעול שבועות ללא תקלות, אך ברגע שהוא מוחק תיקייה שגויה, האמון של המשתמש במערכת נפגע מיד. לפיכך, השאלה המרכזית שהוגדרה ב-Zapier אינה אם לעצור כל פעולה, אלא אילו החלטות שייכות למשתמש ואילו החלטות שייכות לבינה המלאכותית, כאשר תדירות ההפרעה למשתמש נגזרת מתשובה זו.
איטרציה ראשונה: אישור פרטני לכל כלי והאתגרים הטכניים הראשונים
הגרסה הראשונה של Sidekick חילקה את כלי הסוכן לשתי קבוצות עיקריות. פעולות קריאה רצו באופן עצמאי ללא הפרעה, ואילו כל פעולה ששינתה מידע – כגון כתיבת קובץ, עריכת מסמך, הזזת פריטים או מחיקתם – עצרה את התהליך והציגה למשתמש כרטיס עם שלוש אפשרויות: חסימה (Block), אישור חד-פעמי (Once), או אישור קבוע (Always).
יישום ראשוני זה עורר שורה של בעיות:
- בקשת האישור התקיימה רק בחלון הדפדפן הפתוח; סגירת הלשונית גרמה להיעלמות הבקשה.
- לא ניתן היה להשיב לבקשה ממקומות אחרים, כמו למשל מתוך Slack.
- בחירה באפשרות Always נשכחה ברגע שהמשתמש רענן את דף הדפדפן.
- כאשר פעולה נכשלה, Sidekick עשוי היה לבקש אישור שוב ושוב עבור אותה פעולה.
- בקשות אישור הוסתרו לעיתים בתוך מקטעים מקופלים של השיחה ולא נראו לעין.
- המערכת הציגה בקשות אישור גם עבור שלבים לא מזיקים כמו קריאת קובץ, וכך נבלעו השאלות החשובות בין שאלות שגרתיות.
כדי לפתור חלק מבעיות אלו, שמרה Zapier את האישורים בשרתים שלה, דבר שאפשר לענות לבקשות מכל מקום שבו נעשה שימוש ב-Sidekick. בנוסף, נוסח הכפתורים שונה כדי להבהיר מה בדיוק מאושר, לדוגמה: "אפשר עריכת קבצים עבור צ'אט זה".
איטרציה שנייה: העברת הכללים מהכלי אל המשאב המוגן
כעבור מספר חודשים זיהו המפתחים בעיה עמוקה יותר: ב-Sidekick פעלו שתי מערכות נפרדות לקבלת החלטות אישור. מערכת אחת כיסתה יכולות מובנות, כמו עריכת קובץ, והמערכת השנייה כיסתה תוכניות קטנות ש-Sidekick כותב ומריץ כדי לעבוד מול אפליקציות חיצוניות כמו Slack. שתי המערכות נבנו בזמנים שונים, לא חלקו כללים משותפים, ולעיתים סיפקו תשובות שונות עבור אותו סוג של פעולה.
בנוסף, הכללים היו צמודים לכלי עצמו (כמו "האם מותר להשתמש בכלי הכתיבה"), בעוד המשתמש מתעניין במשאב שבסיכון – כמו חשבון ה-Slack שלו, תיקייה מסוימת או מסמך חשוב. כלל שהוגדר על כלי לא יכול היה לקבוע "לעולם אל תיגע במסמך זה" או "שלח הודעות רק אליי ולא לעמיתיי לעבודה".
לפיכך, המערכת נבנתה מחדש סביב המשאב המוגן: הכללים הוצמדו לקובץ, לאפליקציה המחוברת, לאתר האינטרנט או לאוטומציה עצמה. הכללים הוגדרו כמערכת דטרמיניסטית ועקבית:
- אם כלל כלשהו קובע "לעולם לא" (never), הוראה זו גוברת.
- אם אין כלל חסימה וכלל קובע "שאל תחילה" (ask first), המערכת שואלת את המשתמש.
- רק אם שום כלל אינו חוסם את הפעולה, Sidekick ממשיך ללא שאלות.
הכרטיס פושט לשלוש אפשרויות: ביטול, אישור, או אישור והגדרת כלל. כמו כן, הסוכן קיבל יכולת לקרוא ולערוך את הכללים של עצמו כדי להסביר מדוע פעולה מסוימת נחסמה, ונוסף מנגנון הגנה שאינו מאפשר לסוכן להציע כלל גורף של "אפשר הרצת כל קוד".
איטרציה שלישית: הפיכת בקשות האישור לברורות וקריאות
לפי Zapier, בקשת אישור ללא פרטים ספציפיים גרועה יותר מהיעדר בקשה. בתחילה, כרטיס שינוי ההרשאות הציג את הכלל המוצע כמקטע קוד JSON גולמי. החברה החליפה אותו בשורות קריאות המציגות תגית (אישור, שאל תחילה, או דחייה), את היקף ההרשאה, שורת תנאי ("רק כאשר"), ושמות חשבונות במקום מזהי חיבור טכניים.
בעיה נוספת נגעה לכפתור "אפשר והגדר" (Allow and configure). במקור, הכפתור השאיר הערה בלבד לסוכן, שלעיתים קרובות שכח אותה, כך שהמשתמשים נשאלו שוב את אותה שאלה. התיקון שנבחר פותח שיחת צד שמטפלת בהגדרת ההרשאה מבלי לחסום את השיחה הראשית, ומשאיר שורה יחידה בתמליל השיחה בסיום התהליך. בנוסף, נבחן מנגנון של הרשאות מוצעות שקורא החלטות עבר ומציע כללים קבועים שניתן להפעיל ולכבות. ניסוי נוסף שבו הסוכן שכתב קוד וניסה שוב פעולות הוקפא, אך הרעיון של השקעת מאמץ המחשוב של ה-AI לפני פנייה לתשומת לב האדם נשמר.
העברת מנגנון הבדיקה והאישור מחוץ לזרם השיחה
Zapier מציינת שממשק צ'אט אינו מתאים לבדיקה זהירה של פעולות מוצעות, שכן פרטים עלולים להיקבר בבועות טקסט. לכן הוחלט להפסיק להציג בקשות אישור, שאלות ותוכניות פעולה כהודעות בתוך הצ'אט. אלמנטים אלה הועברו לפאנל המוצמד לתיבת ההקלדה, כך שהם אינם נקברים תחת הודעות ומאפשרים עבודה גם בעת עריכת מסמך ללא שיחה לצידו.
החברה בחרה להשאיר את הפאנל מחוץ לדרכו של המשתמש בזמן העבודה ולפתוח אותו רק כאשר יש פעולה לבדיקה, במקום לדרוש הגדרת הרשאות מראש לפני תחילת המשימה. כדי לטפל בבקשות שמשתמשים החמיצו לאחר שעזבו את המסך שבו רצה המשימה, נוספה תיבת דואר נכנס (inbox) לבדיקת אישורים מכל מקום ב-Sidekick.
המעבר לכללים בשפה חופשית: מצב Auto לעומת מצב YOLO
מהנדס בצוות הציע אב-טיפוס של "מצב אוטומטי" שבו בודק בינה מלאכותית קורא כללים שנכתבו בשפה אנושית פשוטה ומחליט בשם המשתמש. הצוות נחלק בין אלו שדרשו לשמור על יכולת חיזוי מדויקת לבין אלו שטענו כי לא ניתן לצפות ממשתמשים שאינם טכניים לכתוב כללים מדויקים.
העיצוב שהושק שילב בין שתי הגישות: הכללים שהגדיר המשתמש נותרו הרף הקשיח שנבדק תמיד תחילה, ובודק ה-AI מתערב רק כאשר הכללים אינם מכסים מצב מסוים. המערכת הציעה שני מצבים:
- מצב Auto: בודק בינה מלאכותית בוחן כל פעולה שאינה מכוסה מול הנחיות בטיחות בסיסיות וכללי המשתמש, ושואל את המשתמש כאשר אינו בטוח.
- מצב YOLO (קיצור של dangerously skip permissions): המערכת מאפשרת לבצע כל פעולה שאינה מכוסה על ידי הכללים, ללא בדיקת AI נוספת. גם במצב זה, כללי "לעולם לא" ו"שאל תחילה" נותרו תקפים, ונדרש אישור לפני שינוי הרשאות.
הניסיון המעשי עם המצבים והכיוון של המצב הבא
לאחר הפצת המצבים למשתמשי פיילוט, משתמש דיווח כי מצב YOLO מבקש אישור. התברר כי הסוכן ניסה לערוך את הרשאותיו שלו – מקרה ש-YOLO נמנע במכוון מלעקוף. שם המצב הבטיח התנהגות שהמערכת סירבה לספק.
בנוסף, הקושי הגדול ביותר היה ניסוח ההוראות למקרים שבהם אף כלל אינו חל ובודק ה-AI נדרש להפעיל שיקול דעת. ההנחיה הראשונית הורתה להיזהר מכל פעולה שחורגת מעבר לנתונים של המשתמש עצמו. כתוצאה מכך, הסוכן עצר לבקש אישור לפני חיפוש פשוט בקבצים של המשתמש, משום שפירש את המילה "חיפוש" כפעולה הפונה החוצה. הבעיה נפתרה על ידי הבהרה מפורשת שקריאת נתוני המשתמש מותרת.
באמצע אוקטובר הודיעה Zapier למשתמשי הבדיקה של YOLO על ביטול המצב, מכיוון שדילוג על כל אישור התברר כעיצוב שגוי. החברה מפתחת מצב חדש שבו מערכת כללים אחת תקפה תמיד, והחלפת מצב משנה רק את הטיפול במקרים שאינם מכוסים. במקרים אלה, שיקול הדעת נשען על מידת הקלות שבה ניתן לבטל פעולה ועל ההקשר שלה. פעולות הפונות אל מחוץ למערכת (כמו שליחת הודעה) דורשות אישור תחילה, בעוד הסכמה לתנאים משפטיים וביצוע תשלומים אינם מורשים לעולם.
כיצד לבחון ממשקי אישורים במוצרי בינה מלאכותית
לפי Zapier, עצם העובדה שמוצר מבקש אישור אינה מעידה כשלעצמה על איכות המנגנון. המבחן המרכזי הוא האם המשתמש מבין למה הוא מסכים בעת הבקשה, והאם הוא יכול להגדיר כללים במילותיו שלו ולדעת איזה כלל הופעל. החברה מסכמת כי מוצר יכול לבקש אישור פעמים רבות ביום ועדיין לזכות באמון, בתנאי שכל שאלה מבהירה למשתמש מה עומד להתרחש.