OpenAI: שלושה כובעים, אף אחד לא יודע מי אחראי
תקריות ב-OpenAI וב-Anthropic מדגישות את הצורך בגורם אחראי אחד לכל פעילות בפריסת AI. היעדר גבולות ברורים הוביל לבלבול באחריות, וחברות כמו Microsoft ו-GitHub מציעות הנחיות למניעת תקלות. הדיון מתמקד בשאלה איך למנוע את התקרית הבאה באמצעות מסגרות ברורות.
כשסוכן AI פורץ למערכת של חברה אחרת, למי מתקשרים? מתברר שלפעמים אין למי. הדיון על אחריות בפריסת בינה מלאכותית עולה מדרגה, ותקריות אחרונות מראות למה חייבים גורם אחראי אחד לכל פעולה.
מהי מסגרת האחריות המשותפת?
מסגרת האחריות המשותפת (Shared Responsibility Framework) מציעה כלל פשוט, כמעט משעמם: לכל פעילות בערימת ה-AI צריך להיות צד אחראי אחד. היא מפרקת את תהליך הפריסה לחמש שכבות, מתפעול עסקי ועד לשרשרת האספקה של המודל, וממפה שמונה תפקידים. כך, זיהוי, הכלה ותיקון של בעיות נעשים מראש, ולא במהלך התקרית. הכלל הזה קיים בגלל הכישלון שהוא מונע: בהיעדר צדדים אחראים, צוותים עוברים להאשמות. ספק המודל מאשים את התצורה. הפלטפורמה מצביעה על הדייר. צוות האפליקציה מציין את מגבלות המודל. כולם צודקים חלקית, והשעון ממשיך לרוץ.
תקריות OpenAI ו-Anthropic: מה קרה?
יולי 2026 נראה אחרת כשמודדים אותו מול הכלל הזה. OpenAI, כספקית מודל, מפעילה פלטפורמת הערכה וארגון לפריסת סוכנים, ונטלה על עצמה לפחות שלושה תפקידים. החזקת כמה תפקידים בתוך חברה אחת היא דבר נפוץ, ולא בהכרח מסוכן. הסכנה מופיעה כאשר התפקידים האלה אינם מחולקים לבעלים פנימיים נפרדים, עם הגדרות ברורות של סמכויות וקבלת החלטות. כאשר הספק, המפעיל והגורם המפריס הם אותו גוף, והגבולות ביניהם אינם מוגדרים, לשאלה איזו פונקציה נכשלה יש תשובה אחת — ולכן אין לה ערך של ממש.
התקריות ב-Anthropic מראות כיוון הפוך. הפעם היה גבול בין המעבדה לבין שותף ההערכה, והתקרית נבעה מהפער בין הבנות שונות לגבי מה שהסביבה מאפשרת. הגבול לא סיפק הבנה משותפת של בקרת מפתח: האם סביבת ההערכה יכולה לגשת לאינטרנט. גבול שלא נבדק מול שאלה פשוטה כל כך הוא לא גבול בכלל. שתי התקריות התרחשו במצבים של אוטונומיה גבוהה, כשאמצעי בטיחות סטנדרטיים הופחתו. זה ההקשר שבו גבולות לא ברורים מובילים להפסדים הגדולים ביותר. אני לא מציע שאף מעבדה פעלה ברשלנות. שתיהן חשפו במהירות פרטים לציבור, ושתיהן תיארו את התנאים שאפשרו את הפעילות. זו בדיוק הנקודה. אם אפילו הגורמים המומחים והמוטיבציה ביותר אינם מצליחים להגיע לתשובה ברורה לגבי זהות האחראי, אנחנו לא יכולים להניח שיש לנו תשובה כזו.
הנחיות Microsoft ו-GitHub: איך למנוע?
Microsoft ו-GitHub מציעות הנחיות כדי למנוע תקלות כאלה. Microsoft מדגישה החלטות בטיחות בארכיטקטורה ובעיצוב, כולל גבולות גישה לנתונים, פעולות שדורשות אישור אנושי ובחינה אחראית של AI כחלק מהדרך לייצור. ההנחיות שלה לאבטחת סוכנים אוטונומיים ממליצות על בקרות דטרמיניסטיות, גישה מינימלית, גבולות מערכת ברורים, ניטור ובעלות ברורה. הן גם מזהות סיכונים כמו חטיפת סוכן, דליפת נתונים רגישים, פגיעה בשרשרת האספקה והתרבותם של סוכנים בעלי הרשאות יתר.
GitHub מיישמת רעיונות דומים עבור סוכנים המיועדים למפתחים. הדיון שלה על עקרונות אבטחת סוכנים מדגיש סיכונים כמו הזרקת פרומפט ודליפת נתונים, לצד בקרות כמו גישה מוגבלת למידע רגיש, חומות אש, מעורבות אנושית לפני שינויים בלתי הפיכים ושיוך ברור של פעולות הסוכן. GitHub גם מתעדת דרכים להוציא בקרות אל מחוץ למודל עצמו, כמו שימוש ב-GitHub MCP server לסריקת קוד לזיהוי סודות.
זהות סוכן: נקודת הבקרה החדשה
Broadcom, דרך VMware, מתייחסת לסוכנים כאל זהויות. שלושה עקרונות: זהות, התערבות ופיקוח. נדרשים זהות לסוכן, נקודת בקרה שתאפשר לעצור דברים רעים ויכולת לנטר את המתרחש. Clayton Donley, סגן נשיא ומנהל כללי בחטיבת אבטחת הזהויות וניהולן ב-Broadcom, אמר: "אנחנו מדברים עם חברות כל יום שמבצעות במהירות משימות קריטיות בעזרת AI. זה לא קורה בסביבה שבה יש לנו 50 שנה של ניסיון בהבנה איך להתמודד עם עובדים ולהעניק להם הרשאות. זה קורה בעולם חדש לגמרי."
ארכיטקטורה עם אחריות: מהנדסים, זה הזמן שלכם
ארכיטקטורת AI צריכה להטמיע בקרות, כמו שמערכות תשלום מטמיעות בקרות הונאה. מדיניות הופכת לכללים הניתנים לביצוע, והראיות הופכות לתוצר לוואי של פעולה רגילה. צוותים שולחים מהר יותר כשהאחריות היא חלק מתהליך המשלוח.
בסופו של דבר, אם אין גורם אחראי, התשובה היחידה היא שאין תשובה.