קוד שנכתב על ידי AI: מי אחראי כשהמערכת קורסת?

מאת צוות מדיה דיל · 12.08.2026 · Developer Culture · 6 דק׳

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

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

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

למה "הסוכן אשם" היא תשובה ריקה

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

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

ההשוואה למקצועות אחרים שכבר פתרו שאלות דומות

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

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

מה כן ברור: מסלול האישור הוא נקודת האחריות המרכזית

הדבר הקרוב ביותר לתשובה ברורה בענף היום הוא זה: האחריות המשפטית והארגונית נוטה להיצמד לנקודת האישור האחרונה שבה בן אדם היה יכול לעצור את הבעיה ולא עצר. מי שאישר את ה-PR, גם אם לא כתב שורה אחת מהקוד, נושא באחריות המקצועית לכך שהוא אישר משהו שלא בדק כראוי. זו בדיוק הסיבה שהשאלה של code review כצוואר בקבוק, שדנו בה בCode Review כצוואר הבקבוק החדש, לא רק שאלה של יעילות — היא שאלה של אחריות משפטית של ממש.

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

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

הכלים שיכולים לצמצם את האזור האפור

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

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

מה חוזי לקוחות ופוליסות ביטוח עדיין לא הדביקו

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

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

מה אפשר לעשות כבר עכשיו כדי להגן על עצמכם

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

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

מה קורה כשהלקוח עצמו לחץ להאיץ

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

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

אחריות בעולם החדש היא עיצוב, לא מקרה

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

תגיות: AI accountability · code review · software liability · AI coding agents · engineering responsibility

← חזרה לבלוג · צור קשר