מתחילים ממשימה וממידע נחוץ, לא מהעלאת תיקייה
שאלו מה העובד רוצה להשיג: ניסוח פסקה ציבורית, סיכום מסמך פנימי או ניתוח פניות. לכל משימה יש צורך שונה. בדקו אם אפשר לעבוד עם דוגמה מלאכותית, תיאור מופשט או קטע מצומצם במקום קובץ מלא. אין הצדקה להעביר רשימת לקוחות כדי לקבל רעיון כללי לניסוח.
OWASP מציין שחשיפה יכולה לכלול מידע אישי, פרטים עסקיים חסויים ואישורי גישה. הכלל המעשי הוא לזהות מה מעבירים ולאן לפני ההזנה. גם צילום מסך, קובץ מצורף ותוצאות שמגיעות מחיבור ענן הם העברת מידע, אף אם העובד לא הקליד את הנתונים בעצמו.
הגדירו כללי עבודה לפי סוג מידע
הטבלה מציעה מסגרת מדיניות מקורית, לא קביעה משפטית לכל עסק. בעל המידע והגורם המוסמך קובעים שימוש לפי ההסכמים והחובות הרלוונטיים. כשסוג המידע אינו ברור, לא מסווגים אותו כציבורי מתוך נוחות. מסמנים מה דורש בירור ומי רשאי להכריע.
| סוג תוכן | בדיקה מקדימה | כלל עבודה מוצע |
|---|---|---|
| תוכן ציבורי מאושר | זכויות, דיוק והקשר הפרסום | אפשר לשקול שימוש בכלי שאושר למשימה |
| תוכן פנימי לא ציבורי | צורך, בעלים ותנאי השירות | אישור לפי סיווג והיקף מצומצם |
| נתוני לקוחות או עובדים | רגישות, מטרה והתחייבויות | לא להזין בלי מסלול אישור מתאים |
| מידע רפואי, פיננסי או מזהה רגיש | צורך והגנות ייעודיות | עדיפות לנתונים מלאכותיים ובירור מוסמך |
| סיסמה, token או מפתח סודי | האם מדובר באמצעי גישה | לא להעביר כתוכן לפרומפט |
| תיקייה או תיבה מחוברת | איזה מידע ניתן לקריאה בפועל | הגבלת מקור והרשאות לפני הפעלה |
אישור כלי מתייחס גם לחשבון, לחיבור ולתנאים
בדקו את סוג החשבון וההסכם, שימושים במידע, שמירה ומחיקה, גישת מנהלים וספקים ויכולות החיבור. אין להסיק שכל מוצר בתשלום או כל מצב בשם פרטי מבטיח את אותם תנאים. ההגדרות והחוזה התקפים במועד הבדיקה צריכים להתאים לסוג המידע ולמטרה.
הרשות להגנת הפרטיות פרסמה המלצות לשימוש אישי במערכות AI יוצרת. הן מקור למודעות לסיכון פרטיות, ולא אישור אוטומטי לשימוש ארגוני מסוים. NIST AI 600-1 מתייחס לסיכוני פרטיות ולניהול סיכון מול צדדים שלישיים. העסק צריך לתרגם זאת להחלטה משלו עם בעלים ותיעוד.
צמצום נתונים אינו רק מחיקת שם פרטי
מסמך עשוי לזהות אדם או לחשוף סוד עסקי גם דרך מספר לקוח, תאריך, תפקיד, הערה, צירוף שדות או מטא-נתונים. החלפת שם אינה הוכחה לאנונימיות. לצורך הדרכה וניסוי עדיף לבנות דוגמה מלאכותית שאינה מבוססת על אדם מסוים, ולציין שזו דוגמה.
בפלט יש לבדוק שוב דיוק, מידע רגיש והקשר לפני שיתוף או פרסום. מסנן או בקשה למודל לא לחשוף מידע אינם אישור שכל ההגנות עבדו. אם יש חיבור שחושף תיקייה רחבה, השחרת הקובץ שהעובד העלה לא מצמצמת בהכרח את כל מקורות המידע הזמינים לחיבור.
דוגמה: ניסוח מענה בלי להעלות פניות אמיתיות
התרחיש להמחשה בלבד. עובד רוצה עזרה בניסוח מענה ללקוח ומעתיק שרשור עם פרטי קשר והערות פנימיות. במקום זאת הוא מנסח מצב מלאכותי שמכיל רק את סוג הבעיה ואת סגנון התשובה הרצוי. אדם מוסמך בודק את הפלט לפני התאמתו למקרה האמיתי במערכת העסקית.
אם נדרשת עבודה על מידע אמיתי, לא עוקפים את האישור בהעתקה חלקית לא בדוקה. מבררים חשבון, תנאים, גישה ומטרה ומגדירים היקף. הפרדה זו מאפשרת שימוש מועיל ב-AI בלי להפוך כל בקשת ניסוח להעברת מסמך עסקי שלם.
מדיניות קצרה צריכה לכלול חריגה ודיווח
רשמו כלים וחשבונות מאושרים, סוגי שימוש מותרים, נתונים שלא מעבירים, חיבורים ומאשר חריגות. הגדירו למי מדווחים אם הוזן מידע בטעות, ומה מתעדים בלי להפיץ אותו מחדש. בוחנים ביטול חיבור או גישה, שימור ראיה וצמצום המשך שימוש בהתאם למקרה.
מחיקת שיחה או ניתוק חיבור אינם הוכחה שהמידע נמחק מכל עותק או שלא נחשף. בודקים את אפשרויות הספק ואת ההשלכות עם הגורם המוסמך. סקירת נכסים, הרשאות וזרימות מידע יכולה לתמוך במדיניות; היא אינה אישור משפטי גורף או הבטחה שהעסק עומד בכל דרישה.
