למה AI Solutions Architect הופך להיות תפקיד כל כך מבוקש

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

לא רק תפקיד טכני

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

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

תוכנה מסורתית היא בדרך כלל דטרמיניסטית | אילוסטרציה

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

קודם הבעיה, אחר כך הטכנולוגיה

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

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

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

לא כל בעיה צריכה Agent

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

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

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

פתרון שלא משתמשים בו הוא פתרון שנכשל

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

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

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

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

זה לא רק ניהול פרויקט

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

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

מערכת היחסים בין האדם למכונה

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

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

מערכת היחסים בין האדם למכונה | אילוסטרציה

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

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

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

אבל איך יודעים שזה באמת עובד?

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

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

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

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

למה חשוב להתחיל עם ניצחונות קטנים

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

ניצחונות מהירים זה חשוב | אילוסטרציה

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

להישאר בחזית בלי לרדוף אחרי ההייפ

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

לנהל את ההייפ מול המציאות | אילוסטרציה

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

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

למידה מתמדת לא נועדה רק לדעת מה לאמץ. היא גם מאפשרת לדעת מתי ולמה להגיד לא.

טכנולוגיה היא אמצעי, לא המטרה

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

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

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

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

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

לפרטים נוספים לחצו כאן >>

ואולי יום אחד גם הארכיטקט יצטרך להשתנות

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

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

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