כלי AI שכותב טקסט הוא כלי כתיבה. כלי AI שמעלה את הטקסט לאתר, משנה תבנית או מריץ פקודה בשרת הוא כבר משתמש במערכת, ויש לו הרשאות. ההבדל הזה נשמע טריוויאלי, אבל רוב התקלות שאנחנו שומעים עליהן נובעות מכך שסוכן קיבל הרשאות של בן אדם שסומך על עצמו, בלי הבקרות שבן אדם היה מקבל בחברה מסודרת.
המאמר הזה לא עוסק בכלי ספציפי. הוא מציע שלוש שאלות שכדאי לענות עליהן לפני שמחברים סוכן לכל מערכת שמייצרת שינוי בעולם: אתר, מאגר נתונים, חשבון ענן.
שאלה 1: מה הוא רשאי לעשות, ברמת הפעולה
״גישה לאתר״ היא לא הרשאה, היא כותרת. הרשאה היא רשימה של פעולות: לקרוא מאמרים, ליצור טיוטה, לפרסם, למחוק, לשנות הגדרות, להריץ קוד. העיקרון הישן של least privilege תקף כאן בדיוק כמו אצל עובד חדש: הסוכן מקבל רק מה שהמשימה דורשת.
דוגמה מהאתר הזה: מערכת הפרסום שמזינה את המאמרים (WordPress Desk) מתחברת עם מפתח שמאפשר ליצור טיוטה, לעדכן אותה ולפרסם מאמר שלה. היא לא יכולה למחוק מאמר, לשנות את העיצוב, לגעת בהגדרות או בקבצים. אם מחר יחליטו להפעיל סוכן שכותב ומפרסם דרך אותה מערכת, הוא יירש את אותה גבולות. זה לא מקרי; זה התכנון.
מה שכדאי לדרוש מכל כלי: הרשאות לפי פעולה (לא ״הכול או כלום״), מפתח נפרד לסוכן (לא המפתח האישי שלכם), ואפשרות לבטל את המפתח בלי לשנות סיסמאות של אנשים.
שאלה 2: איך רואים מה הוא עשה
סוכן שעובד נכון במשך שבוע ועושה טעות אחת ביום השמיני מזיק יותר מסוכן שנכשל מיד, כי בינתיים הפסקתם להסתכל. יומן פעולות הוא הדרך היחידה לדעת מה קרה: אילו פעולות בוצעו, מתי, על אילו פריטים, ומה היה המצב לפני.
יומן טוב עונה על שאלות כמו ״מי שינה את הכותרת של המאמר הזה״ ו״כמה מאמרים פורסמו אתמול בלילה״. יומן רע הוא קובץ טקסט שאף אחד לא קורא. כמה סימנים ליומן שאפשר לעבוד איתו:
- כל פעולה נושאת מזהה של מי שביצע אותה: אדם, או סוכן בשם, לא ״admin״.
- לכל שינוי יש גרסה קודמת שמורה. במערכת שלנו כל שמירה של מאמר יוצרת גרסה; אפשר לראות מה היה לפני.
- פעולות רגישות (פרסום, מחיקה, שינוי הגדרות) מופיעות בנפרד מפעולות שגרה, כדי שאפשר יהיה לסרוק אותן.
שאלה 3: איך מחזירים שינוי שגוי
זו השאלה שרוב האנשים שואלים אחרי התקלה. התשובה צריכה להיות מוכנה לפני. ״יש לנו גיבוי״ היא תשובה חלקית: גיבוי מחזיר את כל האתר למצב של אתמול, כולל מה שכן היה טוב. דרך חזרה טובה היא ממוקדת: להחזיר מאמר אחד לגרסה קודמת, לבטל פרסום אחד, להסיר שינוי אחד בהגדרות.
כמה מנגנונים שהופכים חזרה לאפשרית:
- טיוטה לפני פרסום. סוכן שיוצר טיוטות ואדם שמאשר פרסום הוא הסידור הפשוט ביותר, והוא מספיק לרוב האתרים. עלות: דקה של אדם לכל מאמר. תועלת: שום דבר לא מופיע לציבור בלי עין אנושית.
- גרסאות. כל עריכה שומרת את הקודמת. חזרה היא העתקה, לא שחזור מגיבוי.
- פעולות שלא ניתנות לחזרה נחסמות. מחיקה סופית, שינוי כתובת של מאמר שפורסם, החלפת מפתח. אם הסוכן לא יכול לבצע אותן, אין מה להחזיר.
מה קורה כשמדלגים על השאלות
התרחישים שחוזרים בדיווחים על תקלות עם סוכנים נראים דומים: סוכן שקיבל גישה למאגר ומחק טבלה כי ״ניקה נתוני בדיקה״; סוכן שפרסם 40 מאמרים כי הפרומפט לא הגביל כמות; סוכן ששינה הגדרת DNS כי ההוראה הייתה ״תקן את האתר״. בכל המקרים האלה הבעיה לא הייתה שהמודל ״טיפש״. הבעיה הייתה שהיו לו הרשאות שאדם באותו תפקיד לא היה מקבל, ואף אחד לא ראה את הפעולה לפני שהיא השפיעה.
מסגרת עבודה בארבעה שלבים
- הגדירו את המשימה כרשימת פעולות, וצרו לסוכן מפתח שמאפשר רק אותן.
- התחילו במצב ״טיוטה בלבד״: הסוכן מציע, אדם מאשר. אחרי תקופה שבה האישורים כמעט תמיד חיוביים, אפשר לשקול אוטומציה של פעולות מסוימות.
- בדקו את היומן בקצב קבוע, לא רק כשיש תקלה. פעם ביום בהתחלה, פעם בשבוע כשיש אמון.
- תרגלו חזרה: בחרו שינוי שהסוכן עשה והחזירו אותו, רק כדי לוודא שאתם יודעים איך.
כל זה לא מניח שסוכנים מסוכנים או מועילים במיוחד. הוא מניח שהם משתמשים, ושמשתמשים מקבלים הרשאות לפי תפקיד, פעולותיהם נרשמות, ושינויים שלהם ניתנים לביטול. זו לא דרישה חדשה; רק הנמען חדש.
