אני אוהב וייבקודינג. באמת. רעיון שפעם דרש צוות, תקציב וחודשיים עבודה הופך היום לאב טיפוס עובד בתוך כמה שעות. מנהלת תפעול בונה לעצמה כלי פנימי. מייסד בודק רעיון מול לקוחות לפני שגייס שקל. צוות פיתוח מקצר רבעון לכמה שבועות.
אני לא כותב את זה מהצד. אני בונה בעצמי עם הכלים האלה: Lovable, Bolt, Replit, Base44, Cursor ו-Claude Code, הכלים של מיקרוסופט כמו Copilot Studio, Power Apps, Power Automate ו-GitHub Copilot, כלי אוטומציה כמו n8n, ועוד (הרשימה מתעדכנת כל שעה 😉). אני רוצה להכיר אותם לעומק לפני שאני ממליץ עליהם ללקוחות. ההמלצה שלי ברורה: להשתמש. אבל לדעת מה מקבלים.
השאלה שצריכה להעסיק הנהלה היא לא אם העובדים משתמשים בכלים האלה. הם כבר משתמשים. השאלה היא מה נבנה, על איזה מידע, ומי אחראי לזה ביום שמשהו משתבש.
הקוד עובד. הסיכון לא נראה
מחקר שפורסם באוקטובר 2026 בדק מודלים מובילים על משימות פיתוח מציאותיות. רוב הקוד עבד. אבל גם המודל הטוב ביותר הפיק קוד שגם עובד וגם מאובטח רק בכרבע מהמקרים.1
במחקר אחר מספטמבר 2026, מפתחים שבחרו בין הצעות קוד של בינה מלאכותית לא הצליחו להבדיל בין הצעה מאובטחת להצעה פגיעה. רק 22% מהפתרונות שהגישו היו מאובטחים לגמרי.2
המשמעות העסקית: הדגמה מוצלחת היא לא בדיקת אבטחה. ואם גם מפתחים מתקשים לזהות את הפער, אי אפשר לצפות שמנהלת התפעול תזהה אותו.
מידע של לקוחות, פתוח לכל העולם
רבים מהמשתמשים בכלי וייבקודינג בוחרים לשמור את המידע ב-Supabase, שירות מנוהל של מסדי נתונים. חברת UpGuard סרקה כ-300,000 אתרים שמשתמשים בשירות הזה, ומצאה 16,326 מסדי נתונים שכל אחד יכול היה לקרוא. ביותר ממחציתם נמצאו סימנים למידע אישי.3
לא פריצה מתוחכמת. הגדרה אחת שאף אחד לא בדק.
מפתחות גישה שמסתובבים חופשי
מפתח גישה הוא כרטיס כניסה דיגיטלי למערכת. מי שמחזיק אותו, נכנס. לפי GitGuardian, בפרסום מספטמבר 2026, סוכני קוד משאירים מפתחות כאלה בקבצים ובהיסטוריה של מחשבי המפתחים, במקומות שכלי הסריקה הרגילים לא מגיעים אליהם. רק בקובצי הגדרות ציבוריים של כלי AI נמצאו יותר מ-2,000 מפתחות שעדיין עבדו.4
ובאוקטובר 2026 דווח על חולשה בתצוגה המקדימה של אפליקציית Claude Code: מספיק היה שמפתח יבקש מהכלי לפתוח קובץ זדוני אחד מתוך פרויקט, כדי שמפתחות גישה יישלפו מהמחשב שלו. החולשה תוקנה, אבל היא מראה כמה קרוב המפתחות יושבים לכלים האלה.5
סוכן עושה מה שמותר לו, לא מה שביקשתם
צוות החירום הלאומי של הודו, CERT-In, דיווח באוקטובר 2026 שסוכני בינה מלאכותית שהיו בבדיקה חרגו מהמשימה שלהם ונכנסו למערכות חיות של חברות. הם השתמשו בסיסמאות שנשארו בקוד ובחשבונות ענן עם הרשאות רחבות מדי. אף אחת מהחברות לא שמה לב.6
ובסקר של EY בקרב בכירי AI בחברות הגדולות בארה"ב, רבע מאלה שמשתמשים בסוכנים אמרו שהם לא מסוגלים לזהות סוכנים לא מורשים שפועלים אצלם.7 זו לא שאלה טכנולוגית. זו שאלה של מדיניות: איזה כוח מקבל כל סוכן, ומי אישר אותו.
פתרונות פנימיים: קודם לאפיין את הצורך
לא כל כלי פנימי צריך להיבנות בכלי וייבקודינג חיצוני. לרוב הארגונים כבר יש פתרונות פנימיים בתוך הסביבה שהם עובדים בה: אצל מיקרוסופט, אצל גוגל, במערכות כמו Salesforce ו-ServiceNow, ועוד. אלה מסגרות סגורות ומנוהלות. ההזדהות, ההרשאות ותהליך עזיבת עובד כבר קיימים, ומה שנבנה שם יורש אותם.
זה יתרון אמיתי, אבל לא בהכרח הבחירה הנכונה. לפני שבוחרים כלי, צריך לאפיין את הצורך: מה בונים, על איזה מידע, מי ישתמש בזה ומי יתחזק את זה בעוד שנה. לפי זה בוחרים, ולא להפך.
וגם מסגרת סגורה צריכה עיניים מקצועיות. מיקרוסופט, למשל, כותבת שהעוזר החכם שלה פועל לפי ההרשאות הקיימות, ולכן קובץ ששותף יותר מדי יגיע גם למי שלא אמור לראות אותו.8 זה נכון לכל פלטפורמה מהסוג הזה. הגדרות, הרשאות וחשיפה צריכות בדיקה מסודרת. וזה בדיוק המקום שבו אנחנו נכנסים לתמונה.
תיקון 13: לא צריך להיות משפטן כדי להבין
תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף באוגוסט 2025. גם בקריאה ברפרוף מבינים שיש כאן כבר הגדרה אחרת של מה זה מידע אישי, מי אחראי עליו ומה קורה כשהוא דולף. לא צריך להיות משפטן כדי להבין שזו עבודה נוספת לכל ארגון שבונה מערכות עם הכלים האלה.
- מידע אישי מוגדר היום רחב מאוד: כל מידע על אדם מזוהה, או שאפשר לזהות באופן סביר, כולל מזהים מקוונים ומיקום. כלי פנימי שמחזיק רשימת לקוחות או עובדים הוא מאגר מידע, גם אם נבנה בסוף שבוע.
- מידע רגיש במיוחד, כמו מידע רפואי, ביומטרי או פיננסי, מחייב רמת הגנה גבוהה יותר.
- פלטפורמה, ספק או יועץ שמעבדים את המידע עבורכם הם "מחזיקים". האחריות להגדיר אותם, להסדיר את הגישה שלהם ולפקח עליהם נשארת אצלכם.
- תקנות אבטחת המידע מחייבות נהלים, בקרת גישה ודיווח מיידי לרשות על אירוע אבטחה חמור, בלי לחכות לסוף הבדיקה הפנימית.
- לרשות להגנת הפרטיות יש היום סמכות להטיל עיצומים כספיים משמעותיים, שגדלים לפי היקף המאגר ורגישות המידע.
עכשיו תחברו את זה לאפליקציה שעובד בנה בסוף שבוע. היא שומרת רשימת לקוחות, אז היא מאגר מידע. הפלטפורמה שמארחת אותה היא מחזיק, ואתם אחראים על מה שהיא רואה ועושה. אם יש בה מידע פיננסי או רפואי, נדרשת רמת הגנה גבוהה יותר ממה שמישהו הגדיר. ואם הנתונים שלה נחשפו, חובת הדיווח חלה עליכם, גם אם אף אחד בהנהלה לא ידע שהיא קיימת.
במילים אחרות: הארגון אחראי גם על מערכות שהוא לא יודע עליהן. זה הפער שתיקון 13 חושף, ואף כלי וייבקודינג לא סוגר אותו בשבילכם.
בשורה התחתונה: כל אפליקציה שנבנתה בווייבקודינג ונוגעת במידע אישי היא גם החלטה משפטית, לא רק טכנולוגית.
מה שלא רואים בהדגמה
אין בדיקות. אין ניטור. אין גיבוי שמישהו וידא שהוא עובד. ובעיקר אין בעלים, כי אף אחד לא כתב את הקוד. הרגע המסוכן הוא לא הבנייה. הוא הרגע שבו ניסוי של ערב אחד הופך בשקט לתוכנה שהעסק תלוי בה, ואף אחד לא עצר לשאול מי אחראי עליה.
את הממצאים האלה מצאתי בחיפושים בגוגל ובמנועי בינה מלאכותית. אני בהחלט משתמש בבינה מלאכותית, אבל את הבדיקה הביקורתית אני משאיר אצלי בראש: פתחתי כל מקור ווידאתי שהוא אומר את מה שכתוב כאן.
חמש נקודות למחשבה
- נניח שמחר בבוקר מתברר שאפליקציה שעובד בנה בסוף שבוע חשפה פרטי לקוחות. מי בארגון היה מגלה את זה ראשון, תוך כמה זמן, ומי מחליט אם ומתי מדווחים לרשות?
- אם הייתם צריכים לשרטט היום מפה של כל האפליקציות, האוטומציות והסוכנים שעובדים בנו, על איזה מידע הם נשענים ומה מותר להם לעשות, איפה המפה הייתה נשארת ריקה, ולמה דווקא שם?
- כשסוכן בינה מלאכותית מוחק, שולח או משנה משהו בשם הארגון, איך נקבעו ההרשאות שלו, מי אישר אותן, ואיך הייתם משחזרים בדיעבד מה הוא עשה ולמה?
- אילו ספקים, פלטפורמות ויועצים נוגעים היום במידע אישי שלכם דרך הכלים האלה, ואיך הייתם מוכיחים לרגולטור שאתם יודעים מה כל אחד מהם רואה ומה הוא רשאי לעשות?
- אם עובד יבקש מחר מהעוזר החכם של הארגון סיכום של שכר, חוזים או תלונות לקוחות, מה הוא יקבל בפועל, ומי בארגון החליט, במודע או בלי לשים לב, שזה מה שמותר לו לראות?
אם חלק מהשאלות האלה פתחו פער, זה הזמן לעצור ולהסתכל.
מוזמנים לפנות אלינו לשיחה. נמפה יחד מה נבנה אצלכם, על איזה מידע ומי הבעלים של כל מערכת, ונבדוק איפה אתם עומדים מול תיקון 13, בלי לעצור את מי שבונה.
מקורות
- מחקר על קוד שכותבים מודלים מובילים, אוקטובר 2026: arxiv.org
- מחקר על מפתחים שבוחרים בין הצעות קוד, ספטמבר 2026: arxiv.org
- סריקת מסדי נתונים חשופים של UpGuard: www.upguard.com
- מפתחות גישה שסוכני קוד משאירים, GitGuardian: blog.gitguardian.com
- החולשה ב-Claude Code, CSO Online: www.csoonline.com
- דיווח צוות החירום של הודו, The Next Web: thenextweb.com
- סקר של EY על פיקוח על סוכנים: www.ey.com
- תיעוד מיקרוסופט על אבטחת העוזר החכם: learn.microsoft.com
