איך בוחרים חברת AI בישראל לעסקים

שלושה ספקים, שם אחד

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

שבע שאלות, בסדר הזה

1. מה יימדד לפני שמתחילים?אם אין תשובה ברורה, לא תהיה דרך לדעת בעוד חצי שנה אם הפרויקט הצליח או לא, וכל תוצאה – מכל סוג – תוכל להיות מוצגת כהצלחה.
2. מה היה גורם לכם לומר לנו לא לעשות את זה?הצעה שאין לה תשובה אמיתית לשאלה הזו מגיעה רק למסקנה אחת אפשרית, כלומר המסקנה לא נובעת מהעבודה עצמה אלא הייתה שם מראש.
3. מה קורה כשהמערכת טועה, ומי שם לב?אם התשובה היא ש"מישהו יבדוק", אז אופן השימוש במערכת לא תוכנן ברצינות, והתלות היא בבקרה ידנית מתמשכת.
4. האם הנתון יוצא מהארגון, ולאן?בכתב.
5. האם המודל רואה יותר ממה שהמשתמש רשאי לראות?זה הכשל השקט שלא נראה כתקלה מערכתית, ויכול להישאר חבוי לאורך זמן.
6. מי בדיוק יעשה את העבודה, והוא פנוי עכשיו?האנשים שמופיעים בפגישת המכירה הם ברוב המקרים לא האנשים שילוו את הפרויקט בפועל.
7. מי חותם על העברית?בשם ובאחריות מקצועית. לא תשובה כללית בסגנון «יש לנו דובר עברית».

אף אחת מהשבע איננה שאלה טכנית. ברוב הפרויקטים שנצפו, הטכנולוגיה כמעט אף פעם איננה מה שנשבר – הבעיות צצות בהחלטות, בביצוע ובתיאום הציפיות.

הדגמה: מה לבקש במקום מה שמציעים

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

שלוש בקשות פשוטות הופכות הדגמה למקור מידע שימושי:

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

ארבעה סעיפים שייחודיים לפרויקט AI

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

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

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

מה הקשר הישראלי מוסיף

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

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

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

איך אני עובד על זה

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

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