הטמעת מדיניות ממשל עבור סוכני AI של Paperclip

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

ממשל סוכני AI של Paperclip: היכן נשברת השליטה

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

הכשל הטיפוסי הראשון — יציאה מההיקף המוסכם: המשימה הייתה "להכין טיוטת תשובה ללקוח", והסוכן בשרשרת הגיע עד לשליחת מייל ועריכת רשומה ב-CRM.

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

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

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

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

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

מה נותן מעגל ניהול מבוקר לסוכני AI

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

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

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

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

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

מצבי פעולה של סוכנים: מבודד, מואצל, אוטונומי

מצב ההפעלה אינו הגדרה "ליתר ביטחון", אלא גבול האמון בין הסוכן למערכות שלכם. אותו תרחיש בדיוק במצב מבודד ובמצב אוטונומי נבדל לא במהירות, אלא במי שנושא באחריות להשלכות: אדם בכל שלב או מדיניות המוטמעת בתצורה. להלן שלושה מצבים שביניהם באמת בוחרים בעת הטמעת מדיניות governance לסוכני AI Paperclip.

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

מה משתנה במעבר בין מצבים

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

היכן המצבים מתערבבים

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

כיצד אנו מיישמים מדיניות governance: שלבי העבודה

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

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

  1. מיפוי מלאי של סוכני AI ופעולותיהם. אנו אוספים מרשם: ייעוד הסוכן, הבעלים, המערכות המחוברות, רשימת הפעולות וטריגרים להפעלה. אנו מתעדים היכן הסוכן פועל בעצמו והיכן נדרש אדם.
  2. סיווג נתונים וסיכונים. אנו מסמנים לאילו נתונים הסוכן ניגש ומה ההשלכות של טעות — מחמורה ועד בלתי הפיכה. זה קובע את רמת הבקרה לכל תפקיד.
  3. תכנון סכמת התפקידים. עבור כל סוכן אנו מתארים פעולות מותרות, מגבלות, תנאי הסלמה ונקודות אישור חובה. התפקידים הופכים לבסיס המדיניות.
  4. כתיבה וניהול גרסאות של מדיניות. את הכללים אנו מעצבים כקונפיגורציה תחת בקרת גרסאות: שינוי מדיניות — עריכה נפרדת עם היסטוריה ואחראי, ולא הסכמה בעל פה.
  5. בדיקת מדיניות בסביבת בדיקה. אנו מריצים תרחישים: מנסים להוציא את הסוכן מחוץ לגבולות התפקיד, בודקים את הפעלת המגבלות ואת תקינות ההסלמה. מאתרים חורים לפני הפרודקשן.
  6. יישום וניטור. מפעילים את המדיניות בסביבת העבודה, מגדירים תיעוד פעולות הסוכן והתראות על ניסיונות לחרוג מהמותר.
  7. מסירת נהלים והדרכת האחראים. מוסרים תיעוד, מרשם הסוכנים ונוהל שינוי המדיניות, ומקיימים הדרכה לבעלים ולתורנים.

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

מדיניות גישה ותפקידים עבור סוכני AI של Paperclip

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

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

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

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

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

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

מקרה בוחן: כיצד צומצם שיעור הבדיקות הידניות של סוכנים

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

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

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

מה שינו

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

מה התקבל

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

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

במה שונה ממשל סוכני AI של Paperclip מתיעוד רגיל?

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

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

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

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

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

מה לעשות אם הסוכנים כבר פרוסים ופועלים

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

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

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

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

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

האם ניתן להטמיע מדיניות בלי לעצור סוכנים פעילים?

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

מה לעשות אם לחלק מהסוכנים אין בעלים ותיעוד?

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

בואו נדון במשימה: נתאים קונטור לתרחיש שלכם

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

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

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

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

תארו את המשימה בצורה חופשית — תרחיש, מערכות, מגבלות. נחזור עם הערכה ותוכנית עבודה שאפשר לדון בהן באופן ענייני.