התשובה הקצרה מורכבת משלושה רכיבים: מדיניות כתובה לשימוש בכלים, סריקות אבטחה אוטומטיות שחלות על כל שורת קוד ללא קשר לזהות הכותב, ובדיקת עמיתים אנושית לפני מיזוג לענף הראשי. ארגון שמסדר את שלושת הרכיבים האלה משפר את תנאי החיתום שלו ומחזק את עמדתו אם וכאשר תוגש נגדו תביעה.
- מודלי שפה מאומנים על מאגרי קוד ציבוריים, ולכן הם משכפלים גם דפוסים ישנים עם חולשות מוכרות. מחקר אקדמי שפורסם ב-2025 מצא שכשלושים אחוזים מקטעי הקוד שנוצרו בכלי השלמה אוטומטית הכילו חולשות אבטחה.
- הסיכון גדל כשהבקשה מהמודל מנוסחת סביב פונקציונליות בלבד. מחקרים שפורסמו ב-2025 מצאו שכ-45% מהקוד שנוצר על ידי מודלי שפה בחר בחלופה הלא-מאובטחת, ובבדיקות שפורסמו ב-2025 מודלים ייצרו קוד עם חולשות XSS ב-86% מהמקרים ו-Log Injection ב-88%.
- דליפת סודות היא הביטוי המיידי ביותר של הבעיה. נתוני תעשייה מ-2026 מצביעים על כך שקומיטים שנכתבו בסיוע AI מדליפים סודות בשיעור כפול מהשיעור הבסיסי, כלומר מפתחות חיים שנשארים בתוך ריפוזיטורי פעיל.
- ההשלכה הביטוחית נוגעת לשלושה ענפים: אחריות מקצועית לחברות טכנולוגיה, ביטוח סייבר וביטוח דירקטורים ונושאי משרה. חתמים שואלים היום שאלות ישירות על תהליכי בדיקת קוד ועל סריקות אוטומטיות, והתשובות משפיעות על התמחור, על ההחרגות ועל ניהול התביעה.
קוד שעובד וקוד שבטוח: הפער שמייצר את החשיפה
קוד שמתקמפל ועובר בדיקות פונקציונליות יכול להכיל חולשת אבטחה מוכרת בת עשור. מודלי שפה מאומנים על ריפוזיטוריז ציבוריים, על תשובות בפורומים ועל דוגמאות מדריכים שמעולם לא נועדו לרוץ בייצור, והם משחזרים את הדפוסים שראו. מחקר אקדמי שפורסם ב-2025 מצא שכשלושים אחוזים מקטעי הקוד שנוצרו בכלי השלמה אוטומטית הכילו חולשות אבטחה, על פני קטגוריות CWE שונות.
הפער נוצר בנקודה מזוהה: הגדרת המשימה. מפתח שמבקש מהמודל פונקציה שמקבלת קלט משתמש ומחזירה תוצאה יקבל בדיוק את זה. כשהפרומפט מוותר על דרישה לוולידציה, לקידוד פלט ולטיפול מסודר בשגיאות, המודל בוחר את הנתיב הקצר. מחקרים שפורסמו ב-2025 מצאו שכ-45% מהקוד שנוצר על ידי מודלי שפה בחר בחלופה הלא-מאובטחת גם כשהייתה קיימת חלופה בטוחה יותר. בבדיקות שפורסמו ב-2025, מודלים ייצרו קוד עם חולשות XSS ב-86% מהמקרים ו-Log Injection ב-88%, כשלא התבקשו במפורש להתייחס לאבטחה. הנתונים האלה מתארים התנהגות ברירת מחדל של הכלי, לא תקלה נקודתית. האחריות לניסוח הדרישה ולבדיקתה נשארת אצל הארגון.
הקוד רץ, המפתח מרוצה, והחולשה נכנסת לענף הראשי בלי שאיש עצר לשאול איך היא תיראה בדוח פורנזי אחרי אירוע.
ארבעה וקטורי סיכון שכדאי למפות לפני החידוש הבא
הסיכון בשימוש בכלי AI לפיתוח מתפרס על ארבעה מסלולים נפרדים, וכל מסלול דורש בקרה אחרת. מיפוי מסודר שלהם הוא הבסיס לכל דיון עם חתם, עם לקוח ארגוני או עם פירמת רואי חשבון שמבצעת בדיקה לצורך דוח SOC 2.
חולשות שנולדות מדפוסי האימון
המודל מייצר את מה שראה הכי הרבה, ולא את מה שנכון היום. הזרקת SQL, הצפנה חלשה, טיפול רשלני בהרשאות ושימוש בספריות עם פגיעויות ידועות חוזרים בפלט מפני שהם נפוצים בקוד הציבורי. סריקת SAST בסיסית תופסת חלק גדול מהמשפחה הזאת, בתנאי שהיא רצה על כל Pull Request ולא על שחרורי גרסה בלבד.
דליפת סודות בקומיטים
כלי AI נוטים לייצר קוד עובד שכולל אישורי גישה מוטמעים, מפני שכך הדוגמה שראו נראתה. נתוני תעשייה מ-2026 מצביעים על כך שקומיטים שנכתבו בסיוע AI מדליפים סודות בשיעור כפול מהשיעור הבסיסי. הקוד רץ, המפתח ממשיך הלאה, והמפתח החי נשאר בהיסטוריית הריפוזיטורי גם אחרי שהשורה נמחקה. סורק סודות שרץ על ההיסטוריה, לצד נוהל רוטציה מהיר, מקצר את חלון החשיפה מחודשים לשעות.
הרעלת קבצי ההנחיה
בשנת 2025 תועדה משפחת התקפות שבה הוראות זדוניות מוזרקות לקבצי ההנחיה שעוזרי הפיתוח קוראים לפני שהם מייצרים קוד. ההוראה מוסתרת בתווי יוניקוד בלתי נראים, והכלי מייצר קוד עם דלת אחורית בלי שהמפתח מזהה שינוי כלשהו בהתנהגות. GitHub הוסיפה בעקבות זאת התרעות על תווים חבויים. זהו משטח תקיפה שלביקורת קוד מסורתית אין לו מקבילה ישירה, ולכן קבצי ההנחיה צריכים להיות תחת בקרת גרסאות ולעבור בדיקת עמיתים כמו קוד רגיל.
הזרקת פרומפט בזמן ריצה
רשימת OWASP Top 10 ליישומי LLM לשנת 2025 מציבה את הזרקת הפרומפט בראש הסיכונים. כשקוד שנוצר ב-AI מעבד קלטים חיצוניים בלי ולידציה מספקת, קלט עוין יכול להסיט את התנהגות המערכת בדרכים שמפתח עם מודעות אבטחה היה חוסם. הסיכון הזה מבני ולא מקרי, והוא מחייב תכנון של גבולות אמון בין רכיבי המערכת.
מעקב מחקרי מ-2026 מתעד עלייה חדה בפגיעויות מתועדות שניתן לייחס לקוד שנוצר על ידי AI. הקו הזה הוא שמסביר למה שאלוני החיתום התארכו בשנה האחרונה.
ואיב קודינג: מערכת בייצור שאיש לא קרא
הדפוס המסוכן ביותר כרגע הוא בנייה של מערכות ייצור בידי אנשים שלא יודעים לקרוא קוד. מייסדים, מנהלי מוצר וצוותי תפעול בונים בפלטפורמות מבוססות פרומפט כלים שנוגעים בנתוני לקוחות, ומעלים אותם לאוויר בתוך ימים. הפלטפורמות עצמן חזקות; הפער נמצא בשלב שבין המוצר שעובד לבין המוצר שאפשר לבטח.
מי שבנה את המערכת לא יכול להעריך אם ההרשאות פתוחות מדי, אם הנתונים מוצפנים במנוחה, אם יש רישום פעולות ואם ניתן בכלל לשחזר מה קרה. כשמתרחש אירוע, חוקר פורנזי מגלה שאין לוגים, שאין בעלים טכני ושאין תיעוד של החלטות. שאלת הכיסוי הופכת אז לשאלה של הצהרות: מה נמסר לחתם על סביבת הפיתוח, ומה באמת רץ בייצור.
מוצר שנבנה בסוף שבוע ועלה לאוויר בלי בדיקת אבטחה הוא אירוע חבות שממתין לטריגר.
איפה הסיכון הטכני פוגש את הפוליסה
רוב נוסחי הפוליסה קובעים כיסוי לפי מהות המעשה ולפי ההחרגות, ולא לפי זהות מי שהקליד את הקוד. מה שהשתנה הוא שאלת הסבירות: כשחקירה מגלה שחולשה מוכרת עברה לייצור ללא סריקה בסיסית, נפתח ויכוח על עמידה בדרישות אבטחה סבירות שמשפיע על תוצאת התביעה. הברוקר (LAMDA Broking) והיועץ המשפטי עוברים על נוסחי פוליסה מול סעיפי החוזה עם הלקוח הארגוני, כדי לאתר החרגות בינה מלאכותית רחבות שהוכנסו לנוסחים בשנים האחרונות.
מיפוי תרחיש לענף הביטוח ולשאלת הליבה בתביעה:
| תרחיש | ענף הביטוח הרלוונטי | מה ייבחן בתביעה |
| חולשה במוצר שמקורה בקוד שנכתב בסיוע AI גרמה נזק ללקוח עסקי | אחריות מקצועית לחברות טכנולוגיה | קיומו של תהליך בדיקת קוד מתועד, ותחולתו גם על תוצרי כלי AI |
| ניצול אותה חולשה לגישה למאגר לקוחות | ביטוח סייבר | האם סריקה סטטית בסיסית הייתה מזהה את החולשה לפני השחרור |
| מפתח גישה חי שנשאר בקומיט ושימש לחדירה לסביבת הייצור | ביטוח סייבר, לעיתים גם אחריות מקצועית | מועד הגילוי, קיומו של סורק סודות בצנרת ומדיניות רוטציית מפתחות |
| מצג למשקיעים או ללקוח ארגוני על בקרות פיתוח שלא התקיימו | דירקטורים ונושאי משרה | הפער בין המצג לבין התיעוד התפעולי, ואופן הפיקוח של הדירקטוריון |
| רכיב שסופק על ידי ספק חיצוני ונבנה בכלי AI פגע בזמינות השירות | סייבר, לצד סעיפי שיפוי בחוזה הספק | חלוקת האחריות החוזית ותוקפם של סעיפי הגבלת אחריות |
מה שואלים חתמים לפני חידוש
שאלוני החיתום עברו מהצהרות כלליות לשאלות תפעוליות שאפשר להוכיח או להפריך במסמך. חתם שמקבל תשובה מעורפלת מתמחר את חוסר הוודאות, ולעיתים מוסיף החרגה או מתנה את החידוש בתיקון. הטבלה הבאה מציגה את השאלות שחוזרות בשנה האחרונה ואת ההבדל בין תשובה שמחלישה תיק לבין תשובה שמחזיקה.
שאלות חיתום נפוצות ואיכות התשובה:
| שאלת החתם | תשובה שמחלישה את התיק | תשובה שמחזיקה בחיתום |
| האם קיימת מדיניות מאושרת לשימוש בכלי AI בפיתוח? | אין מסמך, כל צוות מחליט לעצמו | מדיניות כתובה, רשימת כלים מאושרים ובעלים מוגדר לעדכון רבעוני |
| האם קוד שנוצר בסיוע AI עובר בדיקת עמיתים? | רק כשהמפתח מרגיש שצריך | כל מיזוג לענף הראשי מחייב אישור בודק שני, עם רישום ב-Pull Request |
| אילו סריקות אבטחה רצות בצנרת? | יש סורק, לא ברור על מה הוא רץ | סריקה סטטית, ניתוח תלויות וסריקת סודות על כל Pull Request, עם חסימת מיזוג בממצא חמור |
| מהן ההרשאות של סוכני קוד אוטומטיים? | לסוכן יש גישה לכל הריפוזיטורי ולסביבת הענן | הרשאה מזערית, סביבות מבודדות ואיסור גישה ישירה לייצור |
| איזה חלק מהקוד שנשלח לייצור נוצר בסיוע AI? | אין מדידה | מדידה חודשית לפי תיוג קומיטים, עם דיווח להנהלה |
| כיצד מטופלת חולשה שהתגלתה אחרי שחרור? | מתקנים כשמגיעה תלונה | נוהל תיקון עם זמני יעד לפי חומרה, ותיעוד שנשמר לצורכי חיתום ותביעה |
רגולציה, תקינה וחוזי לקוח
הדרישות שמגיעות היום לחברות טכנולוגיה מגיעות משלושה כיוונים בו זמנית: רגולציה, תקינה וחוזים מסחריים. הכיוון השלישי הוא המהיר ביותר, מפני שרכש ארגוני בארצות הברית ובאירופה כבר מבקש תיעוד של מחזור חיי הפיתוח ושל אופן האימות של פלט כלי AI. חברה שמסדרת את התיעוד עבור לקוח אחד מוצאת שהיא מסודרת גם מול החתם.
בארצות הברית, כללי הגילוי של ה-SEC משנת 2023 מחייבים חברות ציבוריות לתאר את אופן הפיקוח של הדירקטוריון על סיכוני סייבר. דרישת הגילוי שהוצעה בנוגע למומחיות סייבר בקרב חברי הדירקטוריון הוסרה מהנוסח הסופי, כך שהמוקד הוא תהליך הפיקוח ולא הרכב הדירקטוריון. לחברות פרטיות עם משקיעים מוסדיים הציפייה דומה במהותה: דיון מתועד, מדדים ותוכנית טיפול.
באירופה נבנית שכבה נוספת. ה-EU AI Act מחייב שקיפות וניהול סיכונים בשימושים מסוימים, NIS2 ו-DORA מחייבים בקרות אבטחה וניהול ספקים בענפים רחבים, וה-Cyber Resilience Act ידרוש מיצרני תוכנה להראות ניהול פגיעויות יזום לקראת סוף 2027. ארגון שמשתמש בכלי AI לפיתוח יידרש להוכיח שהפלט נבדק ואומת לפני שחרור.
כל מערכות הכללים האלה מתכנסות לאותה דרישה תפעולית: תיעוד שמראה מה נבדק, מתי, ובאיזה כלי.
בישראל, תיקון 13 לחוק הגנת הפרטיות הרחיב את סמכויות האכיפה של הרשות להגנת הפרטיות והעלה את מחיר אירוע שנובע מבקרות רשלניות. במקביל, מהירות האימוץ של כלי AI במערכת הישראלית היא יתרון תחרותי אמיתי וגם מקור לפער ממשל מול לקוחות ארגוניים בחו״ל. חברה ישראלית שנכנסת לרכש הארגוני בארצות הברית או באירופה נתקלת בדרישות חוזיות לתיעוד מחזור חיי הפיתוח שלא תמיד הכינה מראש. הפער מתגלה בדרך כלל בשלב מאוחר, כשעסקה כבר נמצאת על השולחן ולוח הזמנים לחתימה קצר. בצד התקינה, דוח SOC 2 הוא דוח ביקורת שמנפיקה פירמת רואי חשבון עצמאית מול קריטריוני AICPA לתקופה מוגדרת, ולא תעודת הסמכה שמישהו מחזיק בכיס. מי שמנהל את התיעוד באופן שוטף חוסך לעצמו את הריצה הזאת.
טעויות נפוצות
- מחשיבים מעבר של בדיקות פונקציונליות כאישור אבטחה.
- כותבים מדיניות AI במסמך כללי, בלי בעלים, בלי תאריך עדכון ובלי אכיפה בצנרת, ואז מגלים בחידוש שהחתם מבקש ראיות תפעוליות ולא כוונות טובות.
- מעניקים לסוכני קוד אוטומטיים הרשאות רחבות בסביבת הענן כדי לחסוך זמן הגדרות.
- מניחים שספק הכלי אחראי לתוצר, בלי לקרוא את תנאי השימוש שמעבירים את האחריות למשתמש.
- מדווחים ללקוח ארגוני על בקרות פיתוח שקיימות בשקף מצגת ולא בקוד.
- מתייחסים לדוח SOC 2 כאל תעודת הסמכה, ומפספסים שמדובר בדוח ביקורת של פירמה חיצונית על תקופה מוגדרת ועל בקרות שהארגון עצמו הגדיר.
- בודקים את נוסח הפוליסה רק אחרי אירוע, כשכבר לא ניתן לשנות הגדרות והחרגות.
צ׳ק־ליסט מקצועי
- הגדירו רשימת כלי AI מאושרים לפיתוח, וקבעו בעלים אחראי לעדכונה אחת לרבעון.
- כתבו מדיניות שימוש שמפרטת מה מותר להזין לכלי, אילו מאגרים חסומים ומה קורה בהפרה.
- שלבו סריקה סטטית בכל Pull Request, והגדירו חסימת מיזוג בממצא בחומרה גבוהה.
- הפעילו סריקת סודות אוטומטית על היסטוריית הקומיטים ולא על השינוי הנוכחי בלבד.
- חייבו בדיקת עמיתים אנושית לפני מיזוג לענף הראשי, גם כשהקוד נראה תקין.
- תייגו קומיטים שנוצרו בסיוע AI, כדי שתוכלו למדוד היקף ולתעדף בדיקות.
- צמצמו את הרשאות סוכני הקוד לעיקרון ההרשאה המזערית, והרחיקו אותם מסביבת הייצור.
- נעלו את קבצי ההנחיה של הכלים תחת בקרת גרסאות, ובדקו אותם כמו קוד לכל דבר.
- הריצו בדיקות דינמיות ובדיקות חדירה תקופתיות על תכונות שנבנו בקצב מהיר.
- תעדו נוהל תיקון חולשות עם זמני יעד לפי חומרה, ושמרו את התיעוד לשלוש שנים.
- רשמו כל מערכת שנבנתה מחוץ לצוות הפיתוח, ובדקו אותה לפני חשיפה חיצונית.
- סנכרנו את המצגים בחוזי לקוח עם מה שקיים בפועל בצנרת הפיתוח.
- הביאו את שאלון החיתום לצוות הפיתוח חודשיים לפני החידוש, ולא שבוע לפני תום התקופה.
- בחנו את נוסחי הסייבר והאחריות המקצועית מול תרחיש של חולשה בקוד שנוצר בסיוע AI.
שאלות נפוצות
האם שימוש בכלי AI לפיתוח פוגע ביכולת לרכוש ביטוח סייבר?
השימוש כשלעצמו אינו חוסם רכישת כיסוי. מה שמשפיע הוא איכות הבקרות סביבו: מדיניות כתובה, סריקות אוטומטיות ובדיקת עמיתים מתועדת. ארגון שמציג תיעוד מסודר מקבל בדרך כלל תנאים דומים לאלה של ארגון שלא משתמש בכלים כאלה כלל. ארגון שמצהיר על שימוש נרחב ללא בקרות עלול להיתקל בהחרגה, בהשתתפות עצמית גבוהה יותר או בדרישת תיקון כתנאי לחידוש.
האם פוליסת אחריות מקצועית מכסה נזק שמקורו בקוד שנוצר בסיוע AI?
ברוב הנוסחים הכיסוי נקבע לפי הגדרת המעשה המקצועי ולפי ההחרגות, ולא לפי זהות הכותב. הנקודה שדורשת בדיקה היא האם הנוסח כולל החרגת בינה מלאכותית רחבה שהוכנסה בשנים האחרונות, ואיך היא מתיישבת עם המוצר שהחברה מוכרת. בדיקה מול נוסח הפוליסה ומול סעיפי החוזה עם הלקוח הארגוני היא הדרך לוודא שהתרחיש נכנס לגדר הכיסוי.
מה הקשר בין דוח SOC 2 לבין שימוש בכלי AI בפיתוח?
SOC 2 הוא דוח ביקורת שמנפיקה פירמת רואי חשבון עצמאית מול קריטריוני AICPA, ולא תעודת הסמכה. כשארגון משתמש בכלי AI בפיתוח, הבקרות שנבדקות בדוח צריכות לכלול את התהליך שחל על תוצרי הכלים: אישור כלים, בדיקת קוד, ניהול הרשאות וסריקות בצנרת. פער בין המתואר בדוח לבין הפעילות בשטח הוא חשיפה בפני עצמה, גם מול לקוחות וגם מול חתמים.
מה נדרש מהדירקטוריון בהקשר הזה?
כללי הגילוי של ה-SEC משנת 2023 מחייבים חברות ציבוריות לתאר את אופן הפיקוח של הדירקטוריון על סיכוני סייבר. דרישת הגילוי שהוצעה בנוגע למומחיות סייבר בקרב חברי הדירקטוריון הוסרה מהנוסח הסופי. עבור חברות פרטיות עם משקיעים ולקוחות ארגוניים הציפייה דומה במהות: דיון מתועד בפרוטוקול, מדדים שמוצגים להנהלה ותוכנית טיפול עם לוחות זמנים.
האם אפשר פשוט לאסור שימוש בכלי AI ולסגור את הסיכון?
איסור גורף מייצר שימוש לא מדווח ומקשה על גיוס מפתחים, ולכן הוא כמעט תמיד מחליף סיכון גלוי בסיכון סמוי. הכיוון שעובד הוא אישור מבוקר: רשימת כלים מאושרים, כללים ברורים לגבי מידע רגיש שמוזן לכלי, והרשאות מוגבלות לסוכנים אוטומטיים. שליטה מדידה עדיפה על איסור שקשה לאכוף, גם בחיתום וגם בניהול היומיומי.
מה קורה כשמנהל מוצר בונה מערכת בפלטפורמת פרומפט ומעלה אותה לייצור?
המערכת נכנסת לסביבת הארגון ללא בדיקת אבטחה וללא בעלים טכני. בתרחיש כזה חולשה פשוטה עלולה להיחשף לאינטרנט הפתוח יחד עם גישה לנתוני לקוחות, ולעיתים ללא רישום פעולות שמאפשר לשחזר מה קרה. הפתרון המעשי הוא רישום מרוכז של כל מערכת שנבנתה מחוץ לצוות הפיתוח, בדיקה לפני חשיפה חיצונית וסיווג של סוגי הנתונים שמותר להריץ בפלטפורמות כאלה.
האם קיימת עלייה מדידה בהיקף התביעות סביב AI?
דוח משנת 2026 מצא שמספר התביעות בארה״ב הקשורות ל-AI גדל ב-978% בין 2021 ל-2025. במקביל, מעקב מחקרי מ-2026 מתעד עלייה חדה בפגיעויות מתועדות שניתן לייחס לקוד שנוצר על ידי AI. שני הקווים האלה מסבירים למה שאלוני החיתום התארכו ולמה חתמים מבקשים היום ראיות תפעוליות במקום הצהרות כלליות על מדיניות.
כלי AI מייצרים קוד מהר יותר ממה שרוב הארגונים מסוגלים לבדוק, ולכן איכות הכיסוי הביטוחי נקבעת היום לפי תהליך הפיתוח שהארגון יכול להוכיח במסמכים.
האמור לעיל הוא מידע כללי בלבד ואין בו משום ייעוץ ביטוחי, משפטי או מקצועי אחר. תנאי הכיסוי, ההחרגות והחובות נקבעים בנוסח הפוליסה הספציפי ובכפוף לדין החל. יש לבחון כל מקרה לגופו מול נוסח הפוליסה ומול יועץ מוסמך.




































































