זה מתחיל כמעט תמיד באותה צורה. מישהו בארגון מקבל רעיון טוב, בונה בסוף שבוע אב טיפוס עם כלי AI, ובישיבת ההנהלה ביום ראשון הוא עובד: מסך יפה, תשובות חכמות, כולם מתלהבים. אחרי חצי שנה הפרויקט עדיין "בפיילוט". אף אחד לא סגר אותו, אף אחד לא השתמש בו באמת, ובינתיים כבר יש שלושה פיילוטים חדשים.
זה לא קורה רק אצלכם. לפי מחקר של IDC ו-Lenovo, על כל 33 הוכחות היתכנות (POC) של AI שארגון מתחיל, רק 4 מגיעות לייצור, כלומר 88% נעצרות בדרך (CIO.com). ב-2026 הבעיה רק מחריפה: עם Vibe Coding כל עובד יכול לבנות אב טיפוס תוך שעות, אז יש הרבה יותר פיילוטים, אבל הפער בין "זה עובד אצלי במחשב" לבין "זה עובד בארגון, כל יום, בצורה בטוחה" נשאר בדיוק אותו פער.
במדריך הזה ריכזתי את הנתונים העדכניים על הפער הזה, את הסיבות האמיתיות שבגללן פיילוטים לא עולים לייצור, צ'קליסט של מה לבדוק לפני, בזמן ואחרי, ותוכנית עבודה של 90 יום שמעבירה רעיון לייצור או עוצרת אותו מוקדם, לפני שהוא שורף תקציב.
הנתונים: כמה פיילוטים באמת מגיעים לייצור
המספרים משתנים בין מחקרים, כי כל אחד מודד משהו קצת אחר. אבל הכיוון עקבי: רוב הניסויים לא הופכים למוצר שעובד.
| מקור | מה נמצא | מה בדיוק נמדד |
|---|
| IDC ו-Lenovo, 2025 | רק 4 מכל 33 הוכחות היתכנות הגיעו לייצור (88% נעצרו) | מעבר מ-POC לפריסה רחבה בארגון |
| S&P Global, 2025 | 42% מהחברות נטשו את רוב יוזמות ה-AI שלהן, לעומת 17% שנה קודם. הארגון הממוצע גנז 46% מהוכחות ההיתכנות לפני ייצור | סקר של יותר מ-1,000 מנהלים בצפון אמריקה ובאירופה |
| MIT NANDA, 2025 | כ-95% מהארגונים לא ראו השפעה מדידה על הרווח וההפסד מפיילוטים של AI יוצר | ראיונות, סקר וניתוח של כ-300 פריסות פומביות |
| Deloitte, דוח 2026 | רק רבע מהארגונים העבירו לייצור 40% או יותר מניסויי ה-AI שלהם | סקר מנהלים עסקיים ומנהלי IT ב-24 מדינות |
| Gartner, 2025 | תחזית: יותר מ-40% מפרויקטי הסוכנים (Agentic AI) יבוטלו עד סוף 2027 | תחזית, לא מדידה בדיעבד |
כמה מילים על אמינות: הנתון של MIT זכה לכותרות ענק, אבל הוא מבוסס על מדגם מוגבל, והגוף שפרסם אותו בונה בעצמו פרוטוקולים לסוכני AI, כפי ש-Fortune ציין. הנתונים של S&P Global (CIO Dive) ושל Deloitte מבוססים על מדגמים גדולים יותר. גם אם לוקחים את ההערכה השמרנית ביותר, מדובר ברוב הפרויקטים.
למה זה קורה: 8 הסיבות שחוזרות בכל המחקרים
חוקרי RAND ראיינו 65 מדעני נתונים ומהנדסים עם ניסיון של חמש שנים לפחות, וכתבו שלפי חלק מההערכות יותר מ-80% מפרויקטי ה-AI נכשלים, פי שניים מפרויקטי IT רגילים (RAND). כשמצליבים את הממצאים שלהם עם Gartner, IDC ו-MIT, חוזרות אותן שמונה סיבות. כמעט אף אחת מהן לא קשורה לאיכות המודל.
1. הבעיה לא הוגדרה נכון
זו הסיבה הנפוצה ביותר לפי RAND: מי שמבקש את הפרויקט ומי שבונה אותו מבינים אחרת מה הוא אמור לפתור. הפיילוט מוכיח שהטכנולוגיה עובדת, אבל לא שהיא פותרת בעיה שמישהו מוכן לשלם עליה.
2. אין מדד הצלחה, ולכן אין החלטה
Gartner מנתה "ערך עסקי לא ברור" בין ארבע הסיבות לנטישת פרויקטים אחרי POC, לצד איכות נתונים, בקרת סיכונים ועלויות שמטפסות (Gartner). בלי מדד שנקבע מראש, כמו זמן טיפול, שיעור טעויות או עלות לעסקה, אי אפשר להגיד "הצליח, עולים". אז הפיילוט פשוט ממשיך.
3. הדאטה של הדמו הוא לא הדאטה של הארגון
הפיילוט נבנה על 50 מסמכים נקיים שמישהו בחר. בייצור יש 50,000 מסמכים, חלקם סרוקים, חלקם סותרים, חלקם עם הרשאות שונות. IDC מצביעה על חוסר בדאטה שמוכן ל-AI כאחד המחסומים המרכזיים.
4. אבטחה, משפט ו-IT נכנסים מאוחר מדי
הפיילוט רץ "בצד", ורק כשרוצים לעלות לאוויר מגיעים אבטחת המידע, היועץ המשפטי וצוות התשתיות. כל אחד מהם מוסיף דרישות, וכל דרישה היא עוד חודש. ב-S&P Global, עלויות, פרטיות ואבטחה היו המחסומים שהוזכרו הכי הרבה.
5. העלות בייצור שונה לגמרי מהעלות בפיילוט
פיילוט של עשרה משתמשים עולה כמה מאות שקלים בחודש. אותו כלי עם 2,000 משתמשים, סוכן שרץ כל הלילה וחיבור למערכות הליבה, יכול לעלות פי מאה. ארגון שלא חישב את זה מראש מגלה את זה בחשבונית. כדאי להעריך את העלות כבר בשלב הרעיון, למשל עם מחשבון עלויות הטוקנים לארגון.
6. אף אחד לא שינה את תהליך העבודה
לפי McKinsey, שינוי מהותי של תהליכי העבודה הוא הגורם שהכי קשור להשפעה על הרווח מ-AI. מערכת חדשה שמוסיפים מעל תהליך ישן, בלי לשנות מי עושה מה, הופכת לעוד מסך שאף אחד לא פותח. ב-MIT קראו לזה "פער הלמידה": הארגון לא יודע לעבוד עם הכלי, והכלי לא לומד מהארגון.
7. בנו לבד מה שהיה עדיף לקנות
לפי הסיקור של דוח MIT, כלים שנרכשו מספקים מתמחים הצליחו בכשני שלישים מהמקרים, ופיתוחים פנימיים הצליחו בערך שליש מזה. זה לא אומר שלא בונים לבד, אלא שצריך לשאול את השאלה לפני שמתחילים.
8. אין בעלים אחרי ההשקה
מי מטפל כשהמודל מתחיל לטעות? מי מעדכן את בסיס הידע? מי מאשר שינוי בהנחיות? פיילוט בלי בעלים בייצור הוא פיילוט שנגמר ביום שבו מי שבנה אותו עובר לפרויקט הבא.
Vibe Coding: למה האב טיפוס נראה גמור, ולמה הוא לא
את המונח טבע אנדריי קרפתי בפברואר 2025: לבנות תוכנה בשיחה עם AI, ובלשונו "לשכוח שהקוד בכלל קיים" (X). זה כלי מצוין להפוך רעיון למשהו שאפשר לראות ולבדוק תוך שעות. הבעיה מתחילה כשמתייחסים לתוצאה כאל מוצר.
- אבטחה: במבחן של Veracode על יותר מ-100 מודלים, הקוד שה-AI כתב הכניס חולשת אבטחה ב-45% מהמשימות, ובג'אווה ביותר מ-70% (Veracode).
- "כמעט נכון": בסקר המפתחים של Stack Overflow, 66% אמרו שהם משקיעים יותר זמן בתיקון קוד AI שהוא "כמעט נכון", ו-72% אמרו ש-Vibe Coding אינו חלק מהעבודה המקצועית שלהם (Stack Overflow).
- תחושה מול מציאות: בניסוי מבוקר של METR, מפתחים מנוסים עבדו לאט ב-19% כשהשתמשו בכלי AI, אבל היו בטוחים שעבדו מהר יותר (METR).
- אפליקציות שאיש לא רואה: בסקר של Retool בקרב 307 מנהלי טכנולוגיה ואבטחה, 93% מודאגים מכלים פנימיים שנבנו ב-Vibe Coding ורצים בייצור, 19% דיווחו על לפחות תקלה אחת שכלי כזה גרם, ורק 5% בטוחים שיש להם תמונה מלאה של כל הכלים הפנימיים (Retool).
והסיפור שכולם זוכרים: ביולי 2025 סוכן של Replit מחק מסד נתונים חי של פרויקט, למרות הוראה מפורשת להקפיא שינויים. Replit הודיעה בעקבות זה על הפרדה אוטומטית בין סביבת פיתוח לסביבת ייצור (TechTarget).
המסקנה היא לא לאסור Vibe Coding, אלא להבין מה חסר באב טיפוס כדי שיהיה מוצר:
| מה יש באב טיפוס | מה צריך בייצור |
|---|
| משתמש אחד, בלי התחברות | התחברות ארגונית (SSO), הרשאות לפי תפקיד |
| מפתחות API בתוך הקוד | ניהול סודות, מפתחות נפרדים לכל סביבה |
| סביבה אחת | הפרדה בין פיתוח, בדיקות וייצור, וגיבויים |
| עובד במקרה הרגיל | טיפול בשגיאות, בדיקות אוטומטיות, מקרי קצה |
| אף אחד לא יודע מה קורה | לוגים, ניטור, התראות ומדידת איכות התשובות |
| עלות לא ידועה | תקרת עלות, מעקב שימוש לפי משתמש ולפי תהליך |
| מידע מכל סוג נכנס למודל | מדיניות פרטיות, סינון מידע רגיש, בדיקה משפטית |
| מי שבנה הוא התמיכה | בעלים, תיעוד, נוהל תקלות ועדכונים |
הצ'קליסט: מה לבדוק לפני, בזמן ואחרי
לפני שמתחילים: שער הכניסה
- בעיה במשפט אחד: מה כואב, למי, וכמה זה עולה היום. אם אי אפשר לכתוב את זה במשפט, עוד לא מתחילים.
- בעלים עסקי: מנהל שהתהליך שלו ישתנה, ושמתחייב להשתמש בתוצאה. לא רק מי שבונה.
- מדד הצלחה וערך פתיחה: למשל "זמן טיפול בפנייה יורד מ-12 דקות ל-7". מודדים את המצב היום, לפני שמתחילים.
- תנאי עצירה: מה יגרום לנו לסגור את הפרויקט, ומתי נחליט.
- דאטה אמיתי: איפה המידע נמצא, מי מורשה לראות אותו, ובאיזה מצב הוא.
- לקנות או לבנות: האם יש כלי קיים שעושה 80% מהעבודה? אם כן, למה לבנות?
- סיווג סיכון: האם יש מידע אישי, לקוחות, החלטות שמשפיעות על אנשים? זה קובע מתי מכניסים את אבטחת המידע והיועץ המשפטי, והתשובה כמעט תמיד היא: עכשיו. ערכת מדיניות ה-AI שלנו עוזרת לעשות את הסיווג.
- תקציב לייצור, לא רק לפיילוט: הערכה גסה של עלות שוטפת בהיקף מלא, וכוח אדם לתחזוקה.
בזמן הפיילוט: לבנות כאילו עולים לייצור
- משתמשים אמיתיים, מידע אמיתי: קבוצה קטנה שעובדת עם הכלי במשימות האמיתיות שלה, לא בהדגמה.
- מודדים מהיום הראשון: את המדד העסקי, את איכות התשובות, ואת העלות לכל פעולה.
- בדיקת אבטחה מוקדמת: שיחה של שעה עם אבטחת המידע בשבוע השני חוסכת חודשיים בסוף.
- תוכנית חיבור למערכות: לאילו מערכות צריך להתחבר, מי מאשר, וכמה זמן זה לוקח.
- יומן החלטות: מה למדנו כל שבוע, מה שינינו ולמה. זה מה שיאפשר להחליט בסוף על בסיס עובדות.
- מתכננים את שינוי התהליך: מה העובד יפסיק לעשות, מה יעשה אחרת, ואיך ידע לסמוך על התוצאה.
אחרי: מוכנות לייצור והחלטה
- החלטה מפורשת: עולים, משנים כיוון, או עוצרים. פיילוט שנגמר בלי החלטה הוא הסיבה העיקרית לבית הקברות של הפיילוטים.
- כל מה שבטבלה של אב טיפוס מול ייצור סגור: הרשאות, סודות, סביבות, ניטור, עלויות, פרטיות ותיעוד.
- בעלים ונוהל תקלות: מי מקבל את ההתראה, ותוך כמה זמן מטפלים.
- מדידה אחרי השקה: אותו מדד מהשלב הראשון, אחרי חודש ואחרי שלושה חודשים.
- הדרכה ותקשורת: עובדים צריכים להבין מה הכלי עושה, מה הוא לא עושה, ומתי לבדוק אותו.
- תאריך בדיקה חוזרת: מודלים, מחירים וכלים משתנים מהר. קובעים מראש מתי בודקים אם עדיין משתלם.
תוכנית עבודה: מרעיון לייצור ב-90 יום
| שלב | מה עושים | תוצר | שער החלטה |
|---|
| שבועות 1 עד 2: מסגור | הגדרת בעיה, בעלים, מדד וערך פתיחה, מיפוי דאטה, לקנות או לבנות, סיווג סיכון | מסמך של עמוד אחד ותקציב משוער לייצור | האם שווה להתחיל? |
| שבועות 3 עד 6: פיילוט | אב טיפוס (גם ב-Vibe Coding), 10 עד 20 משתמשים אמיתיים, מדידה שבועית, בדיקת אבטחה מוקדמת | תוצאות מול המדד, עלות לפעולה, רשימת פערים | האם המדד זז מספיק? |
| שבועות 7 עד 10: הקשחה | בנייה מחדש לפי דרישות ייצור, חיבור למערכות, הרשאות, ניטור, בדיקות, שינוי התהליך והדרכה | גרסת ייצור בסביבת בדיקות, נוהל תקלות | האם אבטחה, משפט ו-IT מאשרים? |
| שבועות 11 עד 13: השקה ומדידה | השקה מדורגת למחלקה אחת, מדידה, תיקונים, העברה לבעלים | דוח תוצאות להנהלה והחלטה על הרחבה | מרחיבים, משנים או עוצרים? |
שני דברים חשובים בתוכנית הזו. הראשון: יש בה ארבעה שערים, ובכל אחד מותר, ואפילו רצוי, לעצור. פרויקט שנעצר בשבוע השני עלה כמעט כלום. השני: שלב ההקשחה לוקח בערך כמו הפיילוט עצמו. מי שמתקצב רק את הפיילוט, מתקצב חצי פרויקט.
מדיניות Vibe Coding לארגון: ירוק, צהוב, אדום
| אזור | מה זה | הכלל |
|---|
| ירוק | כלי אישי, אב טיפוס להדגמה, ניתוח חד פעמי | מותר לכל עובד, בכלים שהארגון אישר ובלי מידע רגיש |
| צהוב | כלי שצוות משתמש בו כל יום, או שנוגע במידע פנימי | רישום אצל IT, בדיקת אבטחה קצרה, בעלים מוגדר |
| אדום | מול לקוחות, מידע אישי, כסף, או חיבור למערכות ליבה | עובר תהליך פיתוח מלא, כולל בדיקות, קוד ריוויו והפרדת סביבות |
המדיניות הזו משאירה לעובדים את החופש לנסות, ומונעת את המצב שבו כלי שנבנה בערב אחד מנהל תהליך קריטי בלי שאיש יודע. למי שרוצה להעמיק בבנייה עצמה, יש לנו פלייבוק לבניית סוכן AI ארגוני.
מה זה אומר לארגון שלכם
הפער בין פיילוט לייצור הוא לא בעיה טכנולוגית, אלא בעיה של ניהול. הארגונים שמצליחים לא מריצים יותר פיילוטים, אלא פחות, ומחליטים עליהם מהר יותר: מגדירים מדד לפני שמתחילים, מכניסים את אבטחת המידע והמשפט מוקדם, מתקצבים את שלב ההקשחה, ונותנים לכל פרויקט בעלים שנשאר אחרי ההשקה.
"ב-2026 לבנות אב טיפוס זה הדבר הקל. כל עובד יכול לעשות את זה בערב אחד, וזה נהדר", אני אומר למנהלים שאני מלווה. "הקושי, והערך, נמצאים בכל מה שבא אחרי: להחליט, להקשיח, לשנות את התהליך ולמדוד. ארגון שבונה את השריר הזה יעביר לייצור פרויקט אחד בכל רבעון. ארגון שלא, יאסוף עוד דמואים יפים."
שלוש שאלות לישיבת ההנהלה הקרובה: כמה פיילוטים פתוחים יש לנו עכשיו, ולכמה מהם יש מדד הצלחה ותאריך החלטה? מי הבעלים של כל אחד מהם אחרי ההשקה? ואילו כלים שנבנו ב-Vibe Coding כבר רצים אצלנו בלי שה-IT יודע?
אם אתם רוצים לדעת איפה הארגון עומד לפני שמתחילים את הפרויקט הבא, נסו את סרגל אימוץ ה-AI הארגוני: 8 שאלות, וכל פער מקבל מדריך שעוזר לסגור אותו. ואם יש לכם פיילוט שתקוע ורוצים להעביר אותו לייצור, או לבנות תהליך שמונע את זה מראש, אפשר לקבוע איתנו שיחת היכרות. עוד דוגמאות למה שמשתבש, ואיך מונעים את זה, תמצאו במקרים מהשטח.
