טיוטה שימושית עשויה להסתפק בכמה עובדות. ממפים את קלט המודל בפועל, את הפרמטרים לכלים ואת עותקי האבחון לפני שמחברים סוכן AI לרשומות לקוחות.
נכתב בסיוע AI. אלו המלצות מעשיות להגדרת היקף; הדוגמאות הן להמחשה ואינן תוצאות של לקוחות.
מתחילים בבקשה שיוצאת מהמערכת, לא בחלון הצ׳אט
לקוח מבקש להזיז את ביקור השירות של מחר. עוזר יכול להכין תשובה שימושית בלי לקבל את כל היסטוריית החשבון של הלקוח. אבל מחבר שטוען את הרשומה כולה עלול להכניס לבקשה הבאה למודל כתובת, הוראות כניסה והערות פנימיות על תשלום. התשובה הגלויה יכולה להיראות תמימה, בזמן שהעברת המידע שמאחוריה רחבה מצורכי המשימה.
לפני שמחברים סוכן AI למערכות העסק, מבקשים מצוות הפיתוח להראות מה עובר בפועל בכל גבול. איזה שירות מקבל את ההודעה הנכנסת? איזה רכיב בוחר את ההקשר? מה יוצא לנקודת הקצה של המודל, ומה חוזר לכלי ביצוע או לשירות אבחון? תרשים שכתוב בו רק CRM אל AI אינו מפורט מספיק כדי לענות על השאלות האלה.
המדריך מציע תרגיל מעשי למיפוי מסלול מידע באמצעות רשומות מומצאות. הוא אינו מתאר מערכת שנמסרה ללקוח של AgenticShip, אינו קובע מהם תנאי השמירה העדכניים של ספק כלשהו ואינו בדיקת עמידה משפטית. מטרתו להגדיר העברת מידע מצומצמת מספיק כדי להסביר אותה, ומדויקת מספיק כדי לבדוק אותה.
נותנים לכל שדה שמועבר סיבה הקשורה למשימה
עקרונות הפרטיות של W3C ממליצים להגביל מידע שמועבר למה שנחוץ להשגת מטרות המשתמשים או תואם לרצונות ולאינטרסים שלהם. זהו עיקרון תכנון, ולא רשימת שדות מוכנה או הוכחה שתהליך AI מסוים עומד בדרישות משפטיות.
לכל שדה מוצע כותבים מה הסוכן יעשה איתו ומה לא יוכל לפעול בלעדיו. התשובה צריכה להתייחס לשלב המסוים בתהליך. כתובת של איש קשר עשויה להיות נחוצה לפעולת שיבוץ מורשית בהמשך, אבל מיותרת לצורך ניסוח בחירה בין שני מועדי ביקור כעת.
לא נותנים לשלב סיכום כללי לקבוע את גבול החשיפה. אם שולחים קודם את הקובץ המלא למודל כדי להפיק ממנו גרסה קצרה, המקור כבר חצה את גבול המודל הזה. בודקים היכן מתבצעים החילוץ או הסינון לפני שמציגים את הפלט שלהם כמצומצם. משאירים דרך טיפול למקרים שבהם אי אפשר להפריד באופן אמין את העובדות הנחוצות.
משווים שתי חבילות הקשר לאותה בקשת תזמון
משתמשים בבקשה המומצאת Q-73 כתרגיל אפיון. רשומת המקור מכילה שם איש קשר, כתובת דוא״ל, כתובת שירות מלאה, תאריך ביקור, סוג שירות, שפה מועדפת, הערת כניסה והערה פנימית על יתרה. המשימה המיידית היא רק להכין תשובה שמציעה שני מועדים חלופיים שאושרו. בתרגיל הזה לא נשלחת הודעה ולא משתנה ביקור.
החבילה הרחבה שולחת את הרשומה כולה, הודעות קודמות וקבצים מצורפים. בחבילה המצומצמת המוצעת שלנו יש שינוי תאריך מבוקש, שני חלונות זמינים שסיפקה מערכת התזמון, סוג שירות אם הוא משפיע על הניסוח והשפה הנדרשת. היישום משאיר אצלו את ההפניה למקרה ואת מיפוי הנמען לכל שליחה שתאושר בנפרד. התאמה אישית יכולה להשתמש במציין שהיישום ממלא, כאשר השם המדויק אינו נחוץ להסקה.
בודקים גם את הטקסט החופשי של הלקוח. הערת כניסה יכולה להופיע בהודעת דוא״ל מצוטטת גם לאחר שהשדה המובנה שלה הוסר מה־CRM. החבילה המצומצמת מועילה רק אם הבקשה שהורכבה בפועל מקיימת את הכלל בכל המקורות הכלולים בה. הסרת שדה ממסך ניהול אינה הוכחה שהוא נעלם מקלט המודל.
זהו גבול מוצע למשימת ניסוח מצומצמת, ולא כלל אוניברסלי שלפיו מודלים לעולם אינם זקוקים למידע מזהה. אם שלב אחר אכן דורש כתובת או פרט אחר, בוחנים את ההעברה הזאת בנפרד ומתעדים את המקבל, המטרה והבקרות. אין לתאר הפניה פנימית או הסרת שם כהוכחה לכך שהמידע אנונימי.
ממפים גם את העותקים שמסביב לקריאה למודל
משתמשים בטבלה כדי לבדוק לאן כל עותק מגיע במימוש שנבחר. לא כל תהליך משתמש בכל הרכיבים שלהלן. מסמנים רכיב כלא קיים רק אחרי שבודקים את המסלול בפועל, ומשאירים מקבלים או הגדרות לא ידועים במצב לא ידוע במקום להשלים אותם מתוך הצהרת שיווק כללית של ספק.
| הגבול או העותק | איזה מידע צריך להצדיק | ראיה לגבול הזה |
|---|---|---|
| קליטה ורשומת המקור | ההודעה המקורית והעובדות העסקיות המותרות | איזו מערכת מקבלת את החומר הגולמי ומי רשאי לפתוח אותו |
| הרכבת הקשר וקלט למודל | רק השדות שנבחרו עבור שלב הניסוח הזה | הבקשה שהורכבה בפועל, כולל היסטוריה מצוטטת וקבצים |
| פלט המודל וכלי הביצוע | טיוטת תשובה ופרמטרים לפעולה שאושרה בנפרד | האם היישום הוא שקובע את הנמען והרשומה |
| כלי אבחון ובדיקה | ראיות אירוע מוגבלות במקום מלוא המידע הפרטי כברירת מחדל | מה באמת מופיע בתיעוד של הצלחה, כשל וניסיון חוזר |
| אחסון אצל ספק ועותקים נוספים | בקשות, פלטים או חומר נגזר שנשמרים בתצורה שנבחרה | תנאי המוצר הרלוונטי, הגדרות החשבון, היקף השמירה ומגבלות המחיקה |
מפרידים בין תנאי הספק להתנהגות היישום שלכם
שואלים באיזה מוצר מדויק, חשבון ונקודת קצה התהליך משתמש. לאחר מכן בוחנים בתיעוד ובהסכם הרלוונטיים את השמירה, הגישה, מקום העיבוד והשימוש האפשרי בתוכן לשיפור מודל. שומרים את תאריך הראיה ואת היקפה. הצהרה על מוצר צ׳אט צרכני אחד אינה קובעת כיצד פועלים API אחר או סביבת התקנה אחרת.
גם הגבלה מאומתת של ספק אינה מתארת כל עותק שהיישום שלכם יוצר. מסך בדיקה, ייצוא לצורך פתרון תקלה או תור לניסיון חוזר של אינטגרציה עשויים לכלול מסלול אחסון וגישה משלהם. באותו אופן, הפעלת מודל בתוך התשתית שבחרתם אינה מוכיחה שכל כלי מחובר או שירות ניטור נשארים באותו גבול.
לשאלות שלא נפתרו נותנים אחראי ומשמעות תפעולית. אם הצוות אינו יכול לבסס לאן שדה רגיש מגיע, משאירים אותו מחוץ למסלול הפיילוט המוצע או שומרים שלב ידני עד לפתרון הפער. מפת מסלול המידע הטכנית עוזרת לאחראי פרטיות או ליועץ משפטי לבחון את התצורה בפועל; היא אינה מחליפה את הבחינה ואינה מספקת כלל אוניברסלי להסכמה או לשמירה.
מתכננים ראיות אבחון בלי להעתיק את כל השיחה
הנחיות הרישום של OWASP ממליצות להחריג או להגן באופן מתאים על חומר כמו טוקנים לגישה, סיסמאות ומידע אישי רגיש, במקום לרשום אותו ישירות. זו תזכורת לבדוק פלט אבחון, ולא סיבה להסיר כל ראיה תפעולית מועילה.
עבור Q-73, רשומת האירוע המוצעת שלנו מכילה הפניה מוגבלת לבקשה, גרסת תהליך, קטגוריות של השדות שנבחרו, רכיב יעד ומצב הצלחה או כשל. האחראים העסקיים והטכניים צריכים להחליט איזו ראיה נוספת באמת נחוצה ומי רשאי לראות אותה. צילום מסך או ייצוא לתמיכה שמכילים את השיחה הגולמית יוצרים עותק נוסף שצריך להביא בחשבון.
בודקים בנפרד מסלולי כשל. קריאה מוצלחת רגילה עשויה לתעד רק מצב, בזמן שמנגנון טיפול בחריגה שומר את כל הבקשה לצורכי אבחון. גם הודעת שגיאה יכולה לצטט קלט פרטי. כוללים בתרגיל ניסיונות חוזרים ובדיקה של מפעיל, ושומרים גם על גישה מוגבלת לראיות הבדיקה עצמן. לא מסתמכים על המראה הנקי של מסך היישום הראשי.
בודקים את הגבול עם סימונים מומצאים לפני פיילוט חי
יוצרים רשומת Q-73 סינתטית בסביבה מבודדת, כששליחה אמיתית ושינויים תפעוליים מושבתים. מכניסים סימוני בדיקה ייחודיים לשדות ששלב הניסוח אינו אמור לשלוח, כמו הערת הכניסה וההערה הפנימית על יתרה. משאירים את התאריך והחלונות המותרים מציאותיים מספיק כדי שהטיוטה תהיה שימושית. לעולם לא משתמשים בסוד אמיתי של לקוח כסימון בדיקה.
בודקים את קלט המודל שהורכב, את הפרמטרים לכלים ואת עותקי האבחון שזמינים לצוות הבדיקה המורשה. חוזרים על התרגיל עם היסטוריית דוא״ל מצוטטת, קובץ מצורף וכשל מדומה. משווים את השדות והמקבלים שנצפו לטבלה המוסכמת. היעדר סימון בתשובה הסופית לבדו אינו מוכיח שהוא לא הופיע בבקשה קודמת במסלול.
בודקים גם שהבקשה המצומצמת עדיין מפיקה טיוטה מתאימה, ושחוסר במידע נדרש יוצר חריגה גלויה. אחרת הצוות עלול להחזיר בשקט גישה לרשומה מלאה כדי שההדגמה תעבוד. מתעדים את הגבול המוצע, מה נצפה בפועל, מה עדיין לא ידוע ואילו תוצאות עוצרות שחרור. בדיקה סינתטית יכולה להדגים את המסלולים שנבדקו; היא אינה מוכיחה מה קורה בכל עותק נסתר אצל ספק או בכל מצב עתידי.
במימוש ראשון של סוכן AI מגדירים משימה אחת, חבילת הקשר אחת ואחראי מוגדר לשינויים. חוזרים למפה כשמוסיפים כלי, מקור מסמכים, כלי אבחון או נקודת קצה נוספת למודל. שומרים את זהות הביצוע ואת הזיכרון לטווח ארוך כהחלטות נפרדות, כדי שתשובה מועילה לא תרחיב בשקט את המקומות שאליהם מידע לקוחות מגיע.
מחליטים מכוח הסמכות של מי הסוכן פועל
מקורות ראשוניים
ההנחיות למעלה מתארות את הגישה המוצעת של AgenticShip. המקורות הבאים מספקים רקע טכנולוגי להמלצות הרלוונטיות.