מדיניות שימוש בעוזרי AI לפיתוח: תבנית

למה מדיניות ולא איסור

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

התבנית

1. תחולה

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

2. כלים מאושרים

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

3. מה העוזר אף פעם לא מקבל

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

4. גישה מינימלית

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

5. סקירה ואחריות

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

6. מעקב

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

7. אירועים

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

איך הופכים את המדיניות לניתנת לבדיקה

כלל בלי בדיקה הוא משאלה. אם אי אפשר לבדוק כלל, כתבו אותו מחדש עד שאפשר, או וותרו עליו.

איך אנחנו מיישמים את זה בעצמנו

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

שאלות נפוצות

כדאי לחברה לאסור על עוזרי AI לקוד?

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

מה אסור אף פעם להעביר לעוזר AI?

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

מי אחראי לקוד שכתב עוזר AI?

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

איך מונעים מסוכן AI לגרום נזק?

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

איך יודעים שהמדיניות נשמרת?

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