האם באמת הרובוטים עומדים להחליף אותנו? חלק 11 - המנהל בעידן ה-AI, בין בקרה לאמון מתי לסמוך ומתי להתערב? הכלים שאנשי פיתוח ארגוני חייבים לדעת/ יניב אלטרס
- יניב אלטרס
- 37false37 GMT+0000 (Coordinated Universal Time)
- זמן קריאה 3 דקות
בחלק הקודם בסדרה ניסיתי להציב כמה בעיות ואתגרים בנושא אחריות בהטמעת כלי AI בארגונים, והצעתי 4 רמות של 'אחריות אלגוריתמית'.
עכשיו בואו נרד לפרקטיקה. מה אנחנו כאנשי פיתוח ארגוני יכולים וצריכים לעשות?
כלי ראשון: AI Impact Assessment
לפני שמטמיעים כל מערכת AI צריך לעשות הערכת השפעה. לא רק טכנולוגית: ארגונית-אנושית.
השאלות שאני ממליץ לשאול:
• על מי המערכת הזו תשפיע? מי יקבל החלטות על פיה?
• מה הסיכונים אם המערכת תטעה? מי ישלם את המחיר?
• אילו הטיות יכולות להיות בנתונים שהמערכת לומדת מהם?
• איך נדע אם המערכת עובדת טוב? מה המדדים?
• מה נעשה כשנגלה בעיה? מה תהליך התיקון?
שיהיה ברור, זה לא שאלון טכני. זו שיחה אסטרטגית שיחידת פיתוח ארגוני חייבת להוביל, או לפחות להיות מעורבת בה.
כלי שני: Human-in-the-Loop Design
אחת העקרונות הכי חשובים בעבודה עם AI זה שאסור לתת למכונה להחליט לבד על דברים קריטיים. לא כי ההחלטות לא תהיינה טובות יותר מאלו האנושיות, אלא כי אנחנו נדרשים להיות ערניים ולגלות אחריות כלפי הלקוחות שלנו.
אנחנו צריכים לתכנן את התהליכים ככה שבני אדם יהיו בלופ.
דוגמה פשוטה: מערכת AI יכולה לדרג מועמדים לעבודה. אבל ההחלטה הסופית צריכה להישאר אנושית. ולא רק "אנושית" בצורה פורמלית (מישהו מאשר בלי לבדוק), אלא אנושית באמת - מישהו שמבין למה המערכת המליצה כך, ויכול לאתגר את זה.
התפקיד שלנו כאנשי פיתוח ארגוני זה לעצב את הנקודות שבהן בני אדם צריכים להתערב, ולהכשיר אותם לעשות את זה טוב.
כלי שלישי: Bias Audits
אנחנו צריכים לבנות תהליכים קבועים של בדיקת הטיות.
זה לא משהו שעושים פעם אחת. זה צריך להיות תהליך מתמשך- כי המערכת לומדת כל הזמן, והעולם משתנה.
איך זה נראה בפועל?
כל רבעון, בודקים: האם המערכת מייצרת תוצאות שונות לקבוצות שונות? האם יש דפוסים מדאיגים? האם יש קבוצות שמקבלות יחס שונה?
זה לא רק עבודה לאנשי data אלא עבודה שדורשת הבנה ארגונית- מה נורמלי? מה בעייתי? איזה הבדלים לגיטימיים ואיזה מפלים?
כלי רביעי: Explainability Standards
אחד הדברים הכי חשובים שאנחנו צריכים לדרוש מכל מערכת AI זה שהיא תדע להסביר את עצמה.
לא בשפה טכנית. בשפה אנושית.
כשמערכת ממליצה לא לקדם עובד, היא צריכה לדעת להגיד למה. לא "הציון שלו נמוך" אלא "הוא לא עומד בקריטריונים X, Y, Z שהוגדרו כחשובים"
ואז - וזה הקריטי - העובד והמנהל צריכים לדעת לאתגר את זה. "רגע, למה הקריטריון הזה הוא קריטי? מי קבע את זה? האם זה הגיוני?"
תפקידנו כאנשי פיתוח ארגוני זה לבנות את התרבות הזו - תרבות של שקיפות ואתגור בריא.
כלי חמישי: Fallback Protocols
מה קורה כשהמערכת לא עובדת?
אין לנו תשובה? אז יש לנו בעיה.
אנחנו צריכים לבנות פרוטוקולי חירום - מה עושים כשמגלים שהמערכת מפלה? מה עושים כשהיא מייצרת החלטות מוזרות? איך חוזרים לתהליך ידני אם צריך?
זה חלק מהתכנון. לא דבר שעושים אחרי שהבעיה קורית.
השפה החדשה שאנחנו צריכים ללמוד
בואו נהיה כנים - יש פה קצת ז'רגון שאנחנו לא יכולים להתעלם ממנו יותר.
אלה לא מונחים טכניים בלבד. אלה מושגים שאנחנו כאנשי פיתוח ארגוני חייבים להטמיע בשפה הארגונית.
כשאנחנו מדברים על הטמעת AI אנחנו לא יכולים להסתפק ב"זה יעשה את העבודה יותר יעילה". אנחנו צריכים לשאול: "האם זה יעשה את העבודה יותר הוגנת? יותר שקופה? יותר אנושית?"
התפקיד החדש (עוד אחד...) של פיתוח ארגוני
אני חושב שהתפקיד שלנו כאנשי פיתוח ארגוני משתנה בצורה מהותית.
אנחנו הופכים למעין "שומרי הסף" של הטמעת טכנולוגיה בארגון.
התפקיד שלנו זה לשאול את השאלות הלא נוחות:
• מי זה משרת? למי זה עוזר? מי עלול לשלם מחיר?
• מה ההשלכות על תרבות הארגון? על אמון? על שקיפות?
• איך אנחנו מוודאים שזה נעשה בצורה הוגנת?
• מה אנחנו עושים כשזה לא עובד?
אנחנו צריכים להיות בכל פרויקט AI מההתחלה. לא בשלב ההדרכה- בשלב התכנון.
למה? כי אנחנו אלה שמבינים את המימד האנושי-ארגוני. אנחנו יודעים איך אנשים עובדים, איך הם חושבים, מה מפחיד אותם, מה יוצר אמון.
וזה בדיוק מה שדרוש כדי להטמיע AI בצורה אחראית.
בהצלחה לנו!
תגובות