כמה באמת עולה פרויקט AI ואיך מחשבים החזר השקעה

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

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

במדריך הזה נסביר:

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

ממה מורכבת העלות האמיתית של פרויקט AI

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

נתונים

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

תשתית

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

אינטגרציה בתהליכים הקיימים

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

תחזוקה וניטור

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

אנשים

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

יציאה מהפרויקט

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

שלוש רמות עלות להטמעת מודל AI

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

רמה ראשונה: מודל מוכן בלי אימון נוסף

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

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

יש שתי דרכים מוכחות להוזיל את השימוש, ורק לעיתים רחוקות מכניסים אותן לתקציב. הראשונה היא שמירה במטמון (prompt caching) של החלק שחוזר על עצמו בכל בקשה, כמו הנחיות המערכת או קטע קבוע מבסיס הידע: אצל ספקים מובילים קריאה מהמטמון זולה בערך פי עשרה. השנייה היא שליחה במנות (Batch API) למשימות שלא דורשות תשובה מיידית, למשל סיכום שיחות בסוף היום, תמורת הנחה של כחצי מהמחיר. בנפחים גדולים שתי ההגדרות האלה משנות את התמונה.

רמה שנייה: עבודה על הנתונים של העסק

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

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

רמה שלישית: תשתית עצמאית

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

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

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

תחזוקה אחרי ההשקה: מי אחראי ומי משלם

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

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

כמה זה עולה

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

מה סוגרים לפני ההתחלה

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

איך מודדים את האפקט של פרויקט AI

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

חיסכון בזמן

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

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

איכות ופחות טעויות

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

מהירות התהליך

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

קו בסיס

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

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

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

מעריכים בטווח ולא במספר אחד

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

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

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

עכשיו שלושת התרחישים:

• אופטימי: זמן הטיפול יורד ל-3.5 דקות, מתפנות כ-330 שעות בחודש, בערך שתי משרות. העסק מוותר על שני גיוסים מתוכננים. הפרויקט מחזיר את עצמו תוך חמישה-שישה חודשים.
• ריאלי: הזמן יורד ל-4.5 דקות, מתפנות כ-200 שעות. העסק מחלק מחדש את העומס ומסתדר בלי עובד נוסף אחד. ההחזר לוקח בערך שנה.
• פסימי: הזמן יורד לחמש דקות, מתפנות כ-130 שעות, אבל העסק לא מחליט מה לעשות עם הזמן הזה: כמות הפניות לא גדלה והצוות לא משתנה. אין חיסכון כספי, והפרויקט ממשיך לעלות כסף על תחזוקה.

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

ניתוח רגישות

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

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

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

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

מפרידים אפקטים שאי אפשר לתרגם לכסף

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

מה חשוב לקחת בחשבון בישראל

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

עברית ועלות הטוקנים

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

פרטיות ואבטחת מידע

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

היכן נשמרים הנתונים

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

דולר, מע"מ ותקציב שנתי

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

למה פרויקטי AI לא מגיעים לשימוש שוטף

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

אין בעלים לתהליך בצד העסקי

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

הנתונים קיימים רק בתיאוריה

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

אין במה למדוד את האפקט

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

הצוות מתנגד לשינוי

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

טעויות שחוזרות בפרויקטים שונים

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

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

צ'ק-ליסט: מה לבדוק לפני שמאשרים תקציב לפרויקט AI

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

1. האם יש קו בסיס של התהליך: כמה זמן הוא לוקח היום, כמה הוא עולה וכמה טעויות יש בו?

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

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

4. האם יש בעלים לתהליך בצד העסקי, אדם שאחראי עליו ויכול להעריך איך העבודה שלו תשתנה?

5. האם נבדקו הנתונים שהפרויקט יעבוד איתם: הם זמינים בכמות ובאיכות הנדרשות?

6. האם הפרויקט משתלם גם בתרחיש הפסימי?

7. האם הוגדרו תנאי עצירה: ברור באילו תוצאות מפסיקים ומי מקבל את ההחלטה?

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

איך RJL Studio עוזרת להטמיע AI שמשתלם

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

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

רוצים לבדוק אם פרויקט ה-AI שלכם יחזיר את ההשקעה? השאירו פרטים ונחזור אליכם עם הצעה לשלב ראשון.

שאלות נפוצות על עלות פרויקט AI

כמה עולה להטמיע AI בעסק קטן?

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

מה זה ROI של פרויקט AI ואיך מחשבים אותו?

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

כדאי להתחיל מפיילוט?

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

מה ההבדל בין מודל מוכן לבין מודל על תשתית עצמאית?

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

כמה עולה התחזוקה של מערכת AI?

אמת מידה מקובלת היא 15–20% מעלות הפיתוח בשנה, ועוד חלק מזמן העבודה של עובד שאחראי על המערכת. התחזוקה כוללת ניטור איכות התשובות, עדכון בסיס הידע ותגובה לשינויים בגרסאות המודל. כדאי להגדיר אותה בהסכם עם הספק עוד לפני ההשקה.