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