ב־30 שניות
- במאמר שפורסם ב-10 באוקטובר, סאטיה נאדלה קורא להתייחס למודלים מתקדמים כאל סיכון פנימי אפשרי: הם יכולים לטעות או להיפגע, גם בלי כוונה זדונית.
- הוא מציע שבעה עקרונות, בהם בקרות עצמאיות, תיעוד פעולות, בדיקות של המערכת כולה ויכולת של אדם מוסמך להשהות או לכבות מודל באמצע משימה.
- המאמר אינו מפרט מוצר חדש, מנגנון זמין או תקן מחייב. הוא גם מזהיר ששקיפות של ההסבר שמודל מספק אינה לבדה ראיה מהימנה לאופן שבו פעל.
מה חשוב להבין
שישה מקורות משישה מפרסמים נקראו במלואם, כולל מאמר נאדלה המקורי ומתווה Microsoft מ-2023 לצורך רקע היסטורי בלבד. פוסט X לא נטען ולא משמש מקור שנקרא. מדובר בהצעת עקרונות, לא בבדיקת מוצר או בהוכחת יישום. Bloomberg החלקי ו-Madrobot שנקרא כרקע אינם ברשימת מקורות הכתבה.
הפרדה בין אינטליגנציה לסמכות
סאטיה נאדלה, מנכ״ל Microsoft, פרסם ב-10 באוקטובר מאמר על מודלים כסיכון פנימי אפשרי בארגון. בבלוג האישי sn scratchpad הוא טוען שאי אפשר להעביר את האחריות למעבדת המודל: הבטחות הספק אינן פוטרות את הארגון מאחריות למה שהמערכת עושה בשמו. TechCrunch, CNBC ו-The Verge דיווחו על הדברים באותו יום.
נאדלה מציע להפריד בין אספקת יכולת ההסקה לבין הסמכות להשתמש בה. לדבריו, מנגנוני הבקרה על המידע שמודל יכול לקרוא ועל הפעולות שהוא יכול לבצע צריכים להיות מחוץ למודל. המודל לא אמור להיות מסוגל לעקוף או לשנות את המנגנון שאוכף את הרשאותיו.
מה פירוש בלם חירום באמצע משימה
בעקרון שהוא מכנה הכלה, נאדלה מבקש לתכנן מראש כאילו המודל עלול להיות פגוע או מנוצל. הוא מדמה זאת לבלם חירום: אדם מוסמך צריך להיות מסוגל להשהות או לכבות מודל באמצע משימה. הוא מוסיף שמודלים מתקדמים יותר ידרשו מנגנוני הכלה מתקדמים יותר ותקינה בתחום.
זו אינה טענה שכל מודל כבר נפרץ או פועל בזדון. במאמר הוא מסביר שגם גורם בעל גישה למערכות חשובות יכול לטעות או להיפגע. Business Insider מדגישה את ההבחנה הזאת. מדובר בהנחת תכנון לצמצום נזק, ולא באבחנה לגבי אירוע תקיפה מסוים.
המאמר אינו מציג כפתור חדש ב-Copilot, ממשק API או הוראות הפעלה למוצר. הוא גם אינו מפרט איזה גורם מוסמך לעצור בכל ארגון, כמה מהר העצירה צריכה לפעול או מה קורה לפעולה שכבר הושלמה. אין להסיק מהקריאה שהפסקת משימה מבטלת אוטומטית הודעה שנשלחה או שינוי שכבר בוצע. זו מגבלה מעשית שצריך לבדוק בנפרד.
שבעה עקרונות, לא עוד מודל שבודק את עצמו
נאדלה מונה גיוון מודלים, תצפית על פעולות, יכולת אימות, בקרות עצמאיות, ביקורת עצמאית, הכלה ודיווח על תקריות. הוא מבקש שכל פעולה משמעותית תשאיר ראיה קריאה לאדם שאינה ניתנת לשינוי בידי הגורם הנבדק, ושאפשר יהיה לשחזר כיצד התקבלה תוצאה בלי להסתמך על עדות המודל עצמו.
בדיקות צריכות, לפי ההצעה, לכלול את המערכת כולה: כישלונות, תקיפות, מקרי קצה ושינויים, לא רק משימות שהצליחו. נאדלה גם מזהיר מפני מצב שבו מודל אטום נמצא בתוך שכבת תזמור אטומה ונצפה בידי מודל אטום נוסף. בדיקה בין מודלים יכולה לעזור, אך אינה מחליפה גבולות וביקורת שאינם בשליטתם.
הוא דורש שקיפות בשרשרת ההסקה, ובאותה נשימה אומר שהיא אינה מספיקה או אמינה לבדה, משום שאין עדיין דרך להבטיח שההסבר שמודל מספק נאמן באופן עקבי לפעולתו. לכן טקסט משכנע על החלטה אינו תחליף ליומן פעולות ולבדיקה חיצונית. זו הבחנה בין הסבר של המודל לבין ראיות על המערכת.
רעיון קודם עם דגש ארגוני רחב
הדימוי של בלם בטיחות אינו חדש ב-Microsoft. ב-25 במאי 2023 הציע נשיא החברה בראד סמית דרישות בטיחות למערכות AI ששולטות בתשתיות קריטיות, דוגמת חשמל ומים. בפוסט הרשמי ההצעה נוסחה כמתווה לממשלות ולחקיקה, לא כחוק שכבר נכנס לתוקף.
המאמר הנוכחי של נאדלה עוסק גם במודלים בעלי גישה למערכות ולמידע רגיש בארגון. הוא קורא לדיווח בזמן למי שנפגע מתקרית ולשיתוף לקחים על בקרות שנכשלו. אבל קריאה ציבורית אינה הוכחה שכל מוצר Microsoft כבר עומד בעקרונות האלה, ואינה מפרטת תקן טכני או מסלול ציות מחייב.
מה ארגון ישראלי יכול לבדוק כבר עכשיו
לפני שמחברים סוכן לדואר, למסמכי לקוחות או למערכת תפעולית, כדאי למפות את הגישה ואת הפעולות שהוא רשאי לבצע. בקשו מהספק להראות מי יכול לעצור משימה, איזה רישום נשמר ומה אדם יכול לבדוק כשהפעולה נכשלת. אלה המלצות מערכתיות בהשראת העקרונות, לא טענה שבדקנו מוצר מסוים.
כדאי להפריד גם בין עצירה, התאוששות וביטול: מניעת הפעולה הבאה אינה בהכרח תיקון הפעולה הקודמת. תרגלו תרחיש עם הרשאה מוגבלת, טעות מתועדת והעברה לאדם. ההמלצה אינה מבטיחה אפס תקלות; היא הופכת את שאלות האחריות והשליטה לחלק מבחירת המערכת, במקום להסתפק בהבטחה שהמודל חכם.
המשמעות שמעבר לכותרת
ארגונים נותנים לסוכני AI גישה למידע ולפעולות, לא רק לשאלות. הקריאה של מנכ״ל Microsoft מחזקת את הצורך לבדוק מי מחזיק בהרשאות וביכולת העצירה, בלי להניח שהצהרת ספק היא הוכחה לבטיחות.
צעד יישומי אחד
בבדיקת ספק סוכנים בקשו הדגמה של הגבלת גישה, עצירה בזמן משימה ותיעוד שניתן לבדוק מחוץ למודל. הגדירו מי מוסמך לאשר פעולות ומה עושים כשהמערכת טועה. אלה המלצות מערכתיות, לא בדיקה שערכנו במוצר.
שאלות נפוצות
האם Microsoft השיקה בלם חירום חדש?
המאמר מציג עקרונות תכנון וקריאה לשליטה אנושית. הוא אינו מכריז על כפתור חדש, ממשק זמין או תקן מחייב במוצר Microsoft.
האם נאדלה טוען שכל מודל כבר נפרץ?
לא. הוא מבקש לתכנן כאילו המודל עלול להיות פגוע או לטעות, ומבהיר שהסיכון אינו מעיד בהכרח על כוונה זדונית.
האם עצירת סוכן מבטלת פעולות שכבר ביצע?
אין במאמר הבטחה כזאת. עצירה וביטול הם מנגנונים שונים, ויש לבדוק בנפרד כיצד המערכת מטפלת בפעולות שכבר הושלמו.
מקורות ובדיקת עובדות
ד״ר יניב שנהב
יועץ ארגוני בכיר ומנחה, העוסק במנהיגות, שינוי התנהגותי והטמעת בינה מלאכותית בארגונים. מביא למערכת מבט ניהולי ויישומי על חדשות הטכנולוגיה.
לפרופיל של ד״ר יניב שנהב
