סוכן שירות לקוחות שיכול לקרוא היסטוריית חשבון, לסכם פנייה ולנסח תשובה עשוי לחסוך שעות בכל שבוע. אם הוא חושף מידע מוגבל, טוען טענה לא מבוססת או פועל בלי תיעוד אישור, החיסכון הזה עלול ליצור בעיה תפעולית גדולה יותר. תהליכי עבודה AI מוכנים לרגולציה סוגרים את הפער הזה כשהם ממקמים את ה-AI בתוך תהליכים עסקיים מבוקרים, במקום להתייחס אליו כאל ממשק צ'אט עצמאי.
עבור מנהלי תפעול, השאלה אינה אם מודל יכול להפיק תשובה שימושית, אלא אם תהליך העבודה יכול באמינות להשתמש בנתונים הנכונים, להחיל את הכללים הנכונים, לנתב חריגים לאדם הנכון ולהפיק ראיות למה שקרה. זה ההבדל בין הדגמה מרשימה לבין אוטומציה שיכולה לפעול בסביבה מפוקחת, רגישה מבחינה חוזית או עם דרישות אחריותיות גבוהות.
תהליכי עבודה AI מוכנים לרגולציה מתחילים בתכנון התהליך
עמידה ברגולציה אינה יכולת שמוסיפים אחרי שפיילוט AI הצליח. היא דרישת תכנון שמעצבת מההתחלה את התהליך, את ארכיטקטורת הנתונים, את הרשאות המשתמשים ואת תוכנית השחרור.
התחילו מההחלטה העסקית שהופכת לאוטומטית או שמקבלת סיוע. בפעילות ביטוח, זה עשוי להיות חילוץ שדות מהצעות והכנת סיכום חיתום. בכספים, זה עשוי להיות סיווג חשבוניות וזיהוי חריגים. בתמיכה, זה עשוי להיות ניסוח תשובות על בסיס תוכן מדיניות מאושר. כל מקרה שימוש נושא סיכונים שונים, ולכן כל אחד צריך מודל בקרה משלו.
צעד ראשון מועיל הוא למפות את תהליך העבודה מהטריגר ועד התוצאה. זהו את מערכות המקור, את שדות הנתונים המעורבים, את הפעולה של המודל, את המערכת שמקבלת את התוצאה ואת האדם או הכלל שיכולים לעצור את התהליך. כך נחשפות הנחות שנשארות לעיתים קרובות סמויות בפרויקטי AI מוקדמים. לדוגמה, תהליך עבודה עשוי להיות מורשה לסכם חוזה אבל לא לפרש סעיף כייעוץ משפטי. הוא עשוי להיות מורשה ליצור טיוטת רשומה ב-CRM אבל לא לשנות סטטוס תשלום.
עקרון התכנון האפקטיבי ביותר פשוט: השתמשו ב-AI איפה ששיקול הדעת יכול לקבל סיוע, ובתוכנה דטרמיניסטית איפה שכללים חייבים להיאכף. מודל יכול לחלץ מידע ממסמך לא מובנה, להסביר למה רשומה סומנה או לדרג תור. מנוע כללים, שירות אימות או שער אישור צריכים לשלוט בבדיקות ספים, בשדות חובה, בהרשאות ובפעולות בלתי הפיכות.
הגדירו את גבולות הנתונים לפני שמחברים מערכות
תהליכי עבודה AI נכשלים לעיתים קרובות בבדיקת הרגולציה כי הצוותים מחברים גישה רחבה לנתונים לפני שהחליטו מה תהליך העבודה באמת צריך. סוכן שירות לא צריך גישה בלתי מוגבלת לכל רשומת לקוח. תהליך לעיבוד מסמכים לא צריך לשמור קבצים גולמיים ללא הגבלת זמן. צמצום נתונים הוא גם פרקטיקת אבטחה וגם משמעת הנדסית.
סווגו את המידע שנכנס לתהליך העבודה. הפרידו בין תוכן ציבורי, מידע עסקי פנימי, נתוני לקוחות, נתונים פיננסיים, מידע רפואי, הרשאות גישה וקטגוריות מוגבלות אחרות. לאחר מכן הגדירו מה תהליך העבודה יכול לקרוא, מה הוא יכול לכתוב, איפה הנתונים נשמרים וכמה זמן. התשובה עשויה להשתנות בין תחומי שיפוט, חוזי לקוחות ויחידות עסקיות.
העבודה הזו צריכה לכסות גם את הנתונים שיוצאים מתהליך העבודה. סיכום שנוצר ונשמר ב-CRM, ב-ERP או במערכת קריאות הופך לחלק מהרשומות של החברה. אם הפלט כולל מידע אישי, טענות לא מבוססות או סיווג שגוי, הסיכון לא נעלם רק כי מערכת AI יצרה אותו.
מחברים מאובטחים חשובים כאן. אינטגרציות צריכות להשתמש בהרשאות גישה מוגבלות היקף, בחשבונות שירות, בתעבורה מוצפנת ובגישת הרשאות מינימליות. הימנעו מבניית סוכן כללי עם גישה רחבה למערכות פנימיות רק כי זה נוח בשלב אב הטיפוס. אינטגרציה מוגדרת בצמצום קלה יותר לבדיקה, לניטור ולהגנה בביקורת.
התייחסו למקורות ידע כאל מערכות מבוקרות
AI מבוסס שליפה (retrieval) יכול לבסס תשובות על מדיניות פנימית, תיעוד מוצר ונהלים מאושרים. אבל מאגר ידע שימושי רק כשהבעלות והגרסאות ברורות. אם סוכן שולף מדיניות מיושנת, הוא עלול להפיק תשובה כתובה היטב אך שגויה.
הגדירו בעלים למקורות ידע בעלי השפעה גבוהה. קבעו כללי פרסום, לוחות זמנים לרענון ונהלי ארכוב. כשמתאים, דרשו מתהליך העבודה לציין את ההפניה למקור הפנימי בפלט או ברשומת הביקורת. כך הבדיקה מהירה יותר, והצוותים יכולים לזהות אם טעות נבעה מהמודל, מתוכן המקור או מהלוגיקה של תהליך העבודה.
הציבו בקרות סביב החלטות, לא רק סביב פרומפטים
הנחיות בפרומפט יכולות לכוון מודל, אבל פרומפטים לבדם אינם בקרות. אפשר לשנות אותם, לפרש אותם לא נכון או לעקוף אותם בעזרת קלטים בלתי צפויים. תהליכי עבודה בפרודקשן צריכים מעקות בטיחות טכניים סביב המודל.
התחילו מקלטים ופלטים מובנים. במקום לבקש מהמודל להחזיר תשובה חופשית בתהליך קליטת תביעות, דרשו ממנו למלא שדות מוגדרים כמו מספר פוליסה, תאריך האירוע, קטגוריה, ציון ביטחון ומידע חסר. אמתו את השדות האלה מול הפורמטים הצפויים והכללים העסקיים לפני שכותבים אותם למערכת הבאה.
לאחר מכן, הגדירו ספי ביטחון וסיכון. סיווג ברמת ביטחון גבוהה ובהשפעה נמוכה יכול להתקדם אוטומטית. חילוץ ברמת ביטחון נמוכה, סטייה כספית גדולה או תשובה שכוללת לשון מפוקחת צריכים לעבור לבדיקה אנושית. המטרה אינה להוציא אנשים מהתהליך, אלא למקד את תשומת הלב שלהם בהחלטות שבהן שיקול הדעת שלהם חשוב ביותר.
הבדיקה האנושית חייבת להיות מעשית, לא טקסית. הבודקים צריכים את הקלט המקורי, את הפלט שנוצר, את ההקשר הרלוונטי מהמקור ופעולה ברורה לאישור, עריכה, דחייה או הסלמה. המשוב שלהם צריך לחזור להערכה ולשיפור תהליך העבודה. אם הבודקים מתקנים שוב ושוב את אותו סוג פלט, הצוות מצא בעיה הנדסית ספציפית לפתור.
מעקות הבטיחות צריכים להתייחס גם לשימוש בכלים. לסוכן שיכול לשאול את ה-CRM, לשלוח אימייל או לעדכן את ה-ERP צריכות להיות הרשאות פעולה מפורשות. גישת קריאה וגישת כתיבה הן סיכונים שונים. בתהליכי עבודה רגישים, דרשו אישור לפני תקשורת חיצונית או שינוי רשומות, ושמרו את רשומת האישור לצד הפעולה.
בנו תיעוד ביקורת שמסביר את התוצאה
כשמנהל תפעול, לקוח, מבקר או בודק פנימי שואלים למה תהליך עבודה נתן המלצה מסוימת, הצוות צריך יותר מתשובה סופית. הוא צריך היסטוריית אירועים.
תיעוד ביקורת שימושי רושם את גרסת תהליך העבודה, תצורת המודל, מסמכי המקור או מזהי הרשומות, טרנספורמציות הנתונים, גרסאות הפרומפטים או ההנחיות, הפניות לידע שנשלף, הפלט, אותות הביטחון, תוצאות האימות, פעולות הבודקים והעדכונים במערכות הבאות. תקופת השמירה המתאימה תלויה בתהליך ובחובות החלות, אבל הרשומות צריכות להיות ניתנות לחיפוש ומוגנות מפני שינויים לא מורשים.
רישום דורש שיקול דעת. שמירה של כל פרומפט ומסמך גולמיים עלולה ליצור חשיפה מיותרת, במיוחד כשמעורב מידע רגיש. במקרים מסוימים, הפניות מבוססות טוקנים, תוכן מושחר, גיבובים (hashes) או מטא-דאטה של אירועים מספקים יכולת מעקב מספקת בלי לשכפל מידע מוגבל. התכנון צריך לאזן בין הצורך בראיות לבין צמצום נתונים.
יכולת המעקב חיונית גם לתגובה לאירועים. אם מדיניות משתנה או שמתגלה פגם, הצוות צריך להיות מסוגל למצוא את המקרים שהושפעו, להשהות את תהליך העבודה הרלוונטי, לתקן רשומות לפי הצורך ולתעד את התיקון. בלי לוגיקת תהליך עם ניהול גרסאות ויומנים שימושיים, המשימה הזו הופכת לניחוש יקר.
בדקו מצבי כשל לפני פרודקשן
בדיקות תוכנה מסורתיות נשארות הכרחיות, אבל תהליכי עבודה AI דורשים הערכה נוספת. הפלט יכול להשתנות, תוכן המקור יכול להשתנות ומשתמשים עשויים לשלוח קלטים חלקיים או עוינים. תהליך עבודה שמצליח בכמה דוגמאות נקיות אינו מוכן לפרודקשן.
בנו סט בדיקות מייצג מתרחישים תפעוליים אמיתיים, עם הגנה על מידע רגיש כנדרש. כללו מקרים רגילים, מקרי קצה, מסמכים עמומים, שדות חסרים, נתונים סותרים, ידע מיושן וקלטים שנועדו לדחוף את תהליך העבודה אל מחוץ להיקף המיועד שלו. העריכו דיוק, שלמות, איכות ציטוט המקורות, התנהגות הניתוב ושיעור העקיפות האנושיות.
קריטריוני הקבלה צריכים להיות תפעוליים. צוות עשוי לדרוש שכל שינויי התשלום יקבלו אישור, ששדות הקליטה המחייבים יעמדו ברמת דיוק חילוץ מוגדרת, או שתהליך העבודה לעולם לא ישלח הודעות ללקוחות בלי התאמת חשבון מאומתת. הסטנדרטים האלה ברורים יותר מהשאלה אם ה-AI מרגיש שימושי.
אחרי השחרור, נטרו סחיפה (drift). שינויים במערכות המקור, בפורמטים של מסמכים, בספקי המודלים, במדיניות או בהתנהגות הלקוחות יכולים להשפיע על התוצאות. ניטור הפרודקשן צריך לעקוב אחר שגיאות, שיעורי עקיפה, זמני תגובה, אינטגרציות שנכשלו, קריאות חריגות לכלים וחריגים שלא נפתרו. סקירות קבועות הופכות את האותות האלה לשיפורים קונקרטיים.
הפכו את הממשל לחלק מהאספקה
ממשל (governance) עובד הכי טוב כשהוא מובנה באספקה, ולא מועבר לצוות נפרד בסוף. בעלי המוצר מגדירים את התוצאה העסקית ואת הסיכון המקובל. צוותי התפעול מספקים את החריגים מהעולם האמיתי. צוותי האבטחה והרגולציה קובעים את ציפיות הבקרה. ההנדסה מממשת את הארכיטקטורה, כיסוי הבדיקות, הניטור ובקרת השינויים.
רמת הממשל צריכה להתאים להשפעה של תהליך העבודה. עוזר ניסוח פנימי בסיכון נמוך עשוי להזדקק לבקרות גישה בסיסיות, למקורות ידע מאושרים ולהנחיות למשתמשים. תהליך עבודה שמשפיע על חיתום, טיפול פיננסי, זכאות או התחייבויות כלפי לקוחות צריך אימות חזק יותר, שערי בדיקה, ראיות בדיקה וניהול שינויים פורמלי. מדיניות אחת לא צריכה לטשטש את ההבדלים האלה.
Invatechs ניגשת לעבודה הזו כאל אספקת תוכנה: שלב האפיון (discovery) מבהיר את התהליך ואת דרישות הבקרה, פיילוט מוכיח את תהליך העבודה מול מקרים אמיתיים, והיישום בפרודקשן מוסיף אינטגרציות, QA, נראות ותמיכה. המטרה היא אוטומציה קונקרטית, לא הייפ AI כללי.
הצעד הנכון הבא הוא לבחור תהליך אחד בנפח גבוה ומוגדר היטב, ולמפות את ההחלטות, הנתונים, החריגים והאישורים שלו לפני שבוחרים מודל. התרגיל הזה מגלה לעיתים קרובות איפה AI יכול ליצור ערך בבטחה, ואיפה בקרות תוכנה קונבנציונליות צריכות להישאר בשליטה מלאה.
