איך מעבירים פרויקט AI מ-POC לפרודקשן (ומה נשבר אחרי הדמו)

בקצרה: POC של AI מוכיח שהמודל יודע לבצע את המשימה על דוגמאות טובות, מול משתמש שרוצה שזה יצליח. ב-Production המערכת צריכה לעשות את זה כל יום, לכל משתמש, בתוך התקציב, וצריך שמישהו יהיה אחראי על כל תשובה. מה שמפריד בין השניים הוא עבודה הנדסית: סט הערכה, מנגנוני הגנה, הרשאות, תיעוד, בקרת עלויות וזמינות גם כשספק המודל נופל. עם היקף מוגדר, אפשר לסגור את הפער בכ-90 יום. מערכת AI מלאה ב-Production אצלנו מתחילה בדרך כלל ב-150,000 ש״ח ויכולה לעבור את 450,000 ש״ח.

למה POC מצליח נתקע אחרי הדמו

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

זה קורה להרבה ארגונים. ביולי 2024 צפתה Gartner שלפחות 30% מפרויקטי ה-GenAI יינטשו אחרי שלב ה-POC עד סוף 2025. הסיבות שמנתה: נתונים באיכות נמוכה, בקרת סיכונים חלשה, עלויות שמטפסות וערך עסקי לא ברור. ביוני 2025 היא הוסיפה שיותר מ-40% מפרויקטי סוכני ה-AI יבוטלו עד סוף 2027, בגלל עלויות, ערך עסקי לא ברור ובקרת סיכונים לא מספקת.

באף אחת מהסיבות לא מופיע ״המודל לא היה מספיק חכם״. כולן דברים שהדמו מסתיר.

POC טיפוסי רץ על 50 דוגמאות שמישהו בחר ביד. משתמש אחד, נלהב, מנסה אותו. המערכת קוראת כל מסמך בתיקייה, כי אף אחד לא הגדיר הרשאות. אף אחד לא ספר כמה עולה כל קריאה למודל. וספק המודל, במקרה, לא נפל באמצע הדמו.

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

עוד לפני ה-POC? התחילו מאיך מריצים POC שעונה על השאלה הנכונה. כאן נעסוק במה שבא אחריו.

מה חייב להיות מוכן לפני שעולים ל-Production

קודם כל: סט הערכה

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

מנגנוני הגנה, הרשאות ותיעוד

רשימת עשרת הסיכונים של OWASP לאפליקציות LLM מציבה את ה-Prompt Injection במקום הראשון, ואת ה-Excessive Agency, סוכן שקיבל יותר מדי סמכויות, במקום השישי. הפתרון נמצא בארכיטקטורה. ה-AI פועל עם ההרשאות של המשתמש ששאל. החיפוש מחזיר רק מסמכים שהמשתמש רשאי לפתוח. כל פעולה שמשנה נתונים עוברת דרך פונקציה צרה ומבוקרת. וכל בקשה וכל תשובה נרשמות ביומן שצוות אבטחת המידע יכול לקרוא.

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

בקרה אנושית איפה שזה חשוב

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

עלות לכל בקשה

מדדו כמה טוקנים, קריאות וצעדים של כלים עומדים מאחורי בקשה טיפוסית אחת, והכפילו בנפח האמיתי. הגדירו תקציב לכל צוות והתראות עוד לפני העלייה לאוויר. יש סיבה ש-OWASP הכניסה לאותה רשימה גם צריכת משאבים בלתי מוגבלת (Unbounded Consumption): לולאה אחת בסוכן, או משתמש כבד אחד, יכולים לשרוף תקציב של חודש ביום.

איך מבטיחים זמינות ו-SLA לאינפרנס AI בפרודקשן

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

Microsoft מציעה ל-Azure OpenAI SLA של 99.9% זמינות. זה נשמע מצוין, אבל 99.9% מתירים כ-43 דקות השבתה בחודש של 30 יום, וההתחייבות עונה רק על השאלה אם ה-Endpoint מחזיר תשובה. איכות התשובה לא מכוסה באף SLA של ספק. בנוסף, לכל ספק יש מגבלות קצב: OpenAI מודדת אותן בבקשות ובטוקנים לדקה, מחזירה שגיאת HTTP 429 כשעוברים אותן וממליצה לנסות שוב בהשהיה שגדלה בכל ניסיון (Exponential Backoff).

כלומר, את ה-SLA שלכם בונים בארכיטקטורה שלכם. אלה השכבות שאנחנו מקימים:

1. יעד לכל תרחיש (SLO). צ׳אט ללקוחות צריך תשובה תוך שניות. עיבוד מסמכים בלילה יכול לחכות שעה. יעדים שונים דורשים תכנון שונה.
2. מודל גיבוי. הריצו את סט ההערכה גם על מודל שני, רצוי מספק אחר או מאזור אחר, כדי שהמעבר אליו יהיה בטוח כשהמודל הראשי נופל.
3. ניתוב בין ספקים. שכבת ניתוב דקה שולחת כל בקשה למודל תקין, עם Timeout, ניסיונות חוזרים ו-Circuit Breaker שמפסיק לפנות לשירות שקורס.
4. Cache. שאלות זהות, Embeddings ותוצאות חיפוש אפשר להגיש מהזיכרון. זה מקצר את זמן התגובה, חוסך כסף ומשאיר חלק מהתשובות זמינות גם בזמן תקלה.
5. מגבלות קצב משלכם. מכסה לכל משתמש ולכל צוות שומרת על המגבלות שקיבלתם מהספק, כך שתהליך כבד אחד לא חוסם את כולם.
6. תור לכל מה שיכול לחכות. עיבוד מסמכים, סיכומים ודוחות עוברים דרך תור, שסופג עומסים ומנסה שוב בבטחה.
7. ירידה מסודרת ביכולות. החליטו מראש מה המשתמש רואה כשה-AI לא זמין: תוצאות חיפוש בלי סיכום, העברה לנציג, או הודעה שהתשובה תגיע במייל. התהליך העסקי ממשיך לרוץ.

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

ניטור ו-Drift

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

בענן, ב-Tenant שלכם או On-prem?

בישראל, תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף באוגוסט 2025 והעלה את הרף לטיפול במידע אישי. מפו איזה מידע ה-AI נוגע בו לפני שאתם בוחרים. מאותה סיבה, עוזר ה-AI הארגוני שלנו רץ בתוך ה-Tenant של הלקוח ב-Azure.

אימוץ: החלק שמהנדסים שוכחים

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

מצב צל (Shadow Mode) בונה את האמון הזה. במערכת לניהול רמזורים מבוססת AI שבנינו לחברת טכנולוגיות תנועה ישראלית, ה-AI רץ בהתחלה בלי לשלוט בכלום, תיעד כל החלטה והושווה לתזמון הקבוע. הוא קיבל שליטה רק אחרי שעקף את תוכניות הבסיס במדידות. וגם אז, הבחירות שלו הוגבלו ל-10 תוכניות רמזור שהרגולטור כבר אישר: מנגנון הגנה שנבנה לתוך התכנון.

תוכנית של 30/60/90 יום מ-POC ל-Production

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

ימים 31 עד 60: בונים את המסלול ל-Production. אינטגרציות, מנגנוני הגנה, ניתוב בין ספקים ומודל גיבוי, ניטור ומסך בקרה לאנשים. מריצים במצב צל או עם קבוצת פיילוט קטנה.

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

רוב מערכות ה-AI שאנחנו בונים עולות ל-Production תוך 2 עד 3 חודשים, לפי מוכנות הנתונים והמורכבות.

כמה זה עולה

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

שאלות נפוצות

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

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

כמה עולה להעביר POC של AI ל-Production? הערכת מוכנות ל-AI מתחילה ב-15,000 ש״ח ויכולה להגיע ל-45,000 ש״ח. פתרון AI מלא ב-Production מתחיל בדרך כלל ב-150,000 ש״ח ויכול לעבור את 450,000 ש״ח, לפי המורכבות והנתונים. עלויות האינפרנס והאחסון נפרדות.

להריץ את המודל בענן או On-prem? תלוי במידע. API ציבורי מתאים למידע לא רגיש. מודל בתוך ה-Tenant שלכם בענן מתאים לרוב המידע הארגוני. מודל Open-weight על השרתים שלכם מתאים למידע שאסור לו לצאת מהרשת.

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

אנחנו בונים תוכנה כבר 16 שנה, ביותר מ-200 פרויקטים, וצוות פתרונות ה-AI והסוכנים החכמים שלנו לוקח AI מהדמו לעבודה של כל יום. יש לכם POC שעובד בדמו? בואו נתכנן יחד את הדרך ל-Production.