AI לעסקים ולארגונים: איך בוחרים פתרון ומתחילים בפיילוט מדיד

מה הבעיה העסקית שה-AI אמור לפתור?

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

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

אילו תהליכים מתאימים לפיילוט ראשון?

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

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

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

מוצר קיים או פתרון AI מותאם?

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

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

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

איזה מידע מותר לפתרון לראות?

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

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

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

איך בודקים איכות בעברית ובתהליך האמיתי?

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

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

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

איך יודעים שהפיילוט הצליח?

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

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

מה משפיע על העלות ועל לוח הזמנים?

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

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

מה צריך להישאר בארגון אחרי ההטמעה?

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

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