מי נותן הוראות לעוזר השיווק שלכם — אתם או המקור שהוא קורא?

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

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

דוגמה: שלושה מתחרים, מקור אחד שמנסה להשפיע

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

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

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

לפני שמשפרים את הפרומפט, ממפים את ההרשאות

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

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

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

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

מה כדאי לבקש מהעוזר עצמו

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

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

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

טיוטה אינה אישור לשלוח, לפרסם או לשנות תקציב

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

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

בדיקה מתוכננת: האם התהליך גם בטוח יותר וגם שימושי?

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

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

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

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

מקור יכול לתמוך בהחלטה, לא להעניק הרשאה

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

המקורות הרשמיים נבדקו ב־22 בספטמבר 2026 לפי UTC, 23 בספטמבר בבנגקוק.