הזרקת פרומפטים וממשל AI

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

בינה מלאכותית אחראית נשענת על ארבעה עקרונות: הגינות, שקיפות, פרטיות ואחריותיות. במאמר נסקור את הסיכון של הזרקת פרומפטים (Prompt Injection), את האתגר של מערכות לא דטרמיניסטיות, את החוק האירופי, ואת צעדי הממשל שאפשר ליישם כבר היום ב-Microsoft 365 וב-Power Platform.

הזרקת פרומפטים: כשעוזר ה-AI סוטה מהתסריט

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

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

למה זה עובד

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

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

מהר יותר מטעות אנוש

המעבר ממועיל למזיק הוא מיידי, והנזק לא נעצר בתיבת דואר אחת. הצעה פגומה הופכת למפל של טעויות, עצות רעות מזינות החלטות ותוויות שגויות מפיצות הטיה במהירות של מכונה. ההגנה היא רב-שכבתית: מסננים אוטומטיים, למידת חיזוק וסוקרים אנושיים שבודקים מה שחומק. מומלץ לבחון Copilots חדשים בסביבות סגורות ומבוקרות כדי להכיל את "רדיוס הפיצוץ" לפני החשיפה למשתמשים ולנתונים אמיתיים, ולשלב צוותי תקיפה (Red Teaming) שבודקים את המערכת באופן קבוע. ההנחיה: לצפות, לבדוק, לזכור, להכיל.

דטרמיניסטי מול לא דטרמיניסטי: המתג הנסתר

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

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

אוטומציה קלאסית מול Copilots גנרטיביים

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

סחף (Drift) והאמון שנשחק

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

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

חוק ה-AI של האיחוד האירופי: אסטרואיד בדרך

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

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

מה החוק דורש בפועל

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

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

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

כלי הממשל ב-Microsoft 365 וב-Power Platform

הרשת כבר מובנית בספינה, וצריך רק להפעיל אותה. Microsoft 365 ו-Power Platform כוללים כלי ממשל שלעיתים נשארים בלתי מורגשים, אבל הם לא הגדרות בונוס אלא כלי הישרדות.

ניטור, תיעוד והסברתיות

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

בצד השקיפות, Microsoft מציעה את Responsible AI Standard שלה ואת Responsible AI Dashboard. הם נותנים דוחות הסברתיות, הערות ביצועים ובחירות עיצוב אחראיות, ומראים אילו משתנים הניעו את החלטת המודל, כך שאפשר לשקול אם התוצאה הייתה הוגנת. ספקים אחרים מציעים פתרונות מקבילים, למשל AWS עם כרטיסי שירות AI וכלי SageMaker Clarify. בסביבת Microsoft תמצאו גם בקרות מדיניות ויומני ביקורת שחוסמים ניסיונות קלט זדוניים ומסננים תוצאות.

הגנת נתונים ויומני ביקורת

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

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

סביבות מבודדות ולוחות בקרה

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

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

ועדת ממשל: השכבה החושבת

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

מי יושב בוועדה

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

מה הוועדה עושה

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

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

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

טעויות נפוצות ואבני נתקל

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

טייקאווים מעשיים

• צרו מלאי של מקרי שימוש ב-AI ודרגו אותם לפי סיכון.
• הפעילו את ההגנות שכבר קיימות בפלטפורמה: ניטור, תיעוד החלטות, DLP, יומני ביקורת.
• הטמיעו לוגים והסברתיות כבר בפריסה.
• בדקו Copilots חדשים בסביבות מבודדות ומבוקרות לפני חשיפה לנתונים אמיתיים.
• שלבו צוותי תקיפה (Red Teaming) שבודקים את המערכת באופן קבוע.
• הקימו ועדת ממשל רב-תחומית עם מבקר עצמאי.
• הגדירו מדדי הוגנות, דיוק וסטייה וקבעו לוח זמנים לביקורות.
• הגדירו מי אחראי לכל תוצאה, ושמרו על בני אדם במעגל.

סיכום

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