איך מסדירים החלטות אוטומטיות בארגון בלי לאבד שליטה

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

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

דירוג סיכון מעשי

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

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

לקבוע מי מחליט, מי בודק ומי עוצר

הסדרה טובה אינה מסתיימת בוועדת היגוי. היא מגדירה אחריות במהלך העבודה השוטף. ההבעלים של המערכת (System Owner), כלומר בעל התפקיד שהוגדר כאחראי עליה, נושא באחריות לתוצאה העסקית. 
גורם מקצועי בודק שהשימוש מתאים לתהליך.
מערכות מידע ואבטחת מידע בוחנות הרשאות, חיבורים ושמירת נתונים.
הייעוץ המשפטי בודק את המסגרת החוזית, הפרטיות, חובות הגילוי והחשיפה האפשרית.

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

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

פרטיות ואפליה אינן בדיקות טכניות בלבד

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

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

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

חוזה עם ספק אינו פוטר מאחריות

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

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

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

פיקוח אנושי צריך להיות אמיתי

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

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

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

מדיניות AI טובה נבחנת ביום התקלה

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

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

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

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

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