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

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

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

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

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

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

מדוע פיצול כלי הבינה המלאכותית אינו עומד להיעלם

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

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

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

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

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

הבעיה האמיתית אינה מספר הכלים, אלא מספר הגרסאות של האמת

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

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

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

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

תשתית ידע משותפת: השכבה שמחברת בין הכלים

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

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

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

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

ממשל תוכן אינו פרויקט ניקיון

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

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

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

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

גם כלי ללא קוד זקוקים לגבולות ברורים

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

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

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

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

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

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

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

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

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

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

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

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

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

תרחיש מעשי: אותה מדיניות, שלושה עוזרים

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

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

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

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

איך מתחילים בלי להקים תוכנית ענקית

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

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

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

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

סיכום: מהו המענה לכל סוג של פיצול

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

חמש שאלות שכל הנהלה צריכה לשאול

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

הכאוס אינו גזירת גורל

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

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

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

אם אתה מעוניין במידע נוסף בנושא Low Code - No Code Mail Thumb

צור קשר ונוכל להמליץ לך בחינם על ספקים מובילים בתחום