מדיניות שמירת מידע לסוכן AI: מה שומרים, לכמה זמן ומתי מוחקים
# מדיניות שמירת מידע לסוכן AI: מה שומרים, לכמה זמן ומתי מוחקים
המיתוס המסוכן הוא שסוכן AI נעשה טוב יותר ככל ששומרים עבורו יותר מידע. בפועל, זיכרון ללא תאריך תפוגה הופך מהר מאוד למחסן: שיחות ישנות, טיוטות, קבצים כפולים, פרטים אישיים ויומני פעולה שאיש כבר אינו צריך.
סוכן עסקי כן זקוק להקשר. הוא צריך לדעת מה קרה בתהליך, מאיזה מקור הגיעה עובדה ומה כבר הוחלט. אבל מכאן לא נובע שצריך לשמור כל מילה לנצח. מדיניות שמירת מידע טובה קובעת מטרה ותקופה לכל סוג מידע, ואז מוחקת או מצמצמת אותו כשהמטרה הסתיימה.
התזה פשוטה: לא שואלים כמה זמן הסוכן רוצה לזכור. שואלים איזו החלטה עסקית כל פריט מידע עדיין מאפשר, מי זקוק לו, ומה הסיכון אם יישאר אחרי שכבר איבד את תפקידו.
## שיחה, עובדה וראיית ביצוע אינן אותו מידע
נניח שסוכן AI מסייע בהכנת הצעת שירות. הלקוח מתאר את הצורך במייל, מצרף מסמך, נציג מוסיף הערה, והסוכן מכין טיוטה. אחרי אישור נשלחת הצעה ונפתחת משימה להמשך.
קל לשמור את כל החבילה כגוש אחד. זאת בחירה נוחה למערכת וקשה לעסק. לכל רכיב יש תפקיד אחר:
* השיחה המקורית מספקת הקשר, ולעיתים כוללת פרטים שלא נדרשו להצעה.
* עובדות שאומתו, כמו שם החברה או דרישת השירות, עשויות לעבור למערכת העסקית המתאימה.
* הטיוטה היא חומר עבודה זמני. אחרי שנדחתה או הוחלפה, הערך שלה יורד.
* ההצעה שאושרה היא רשומה עסקית שייתכן שצריך לשמור לפי צורכי העסק והדין.
* יומן הפעולה מוכיח מי אישר, איזו גרסה נשלחה ומה השתנה.
אם הכול נשמר באותה תקופה, ברירת המחדל תהיה בדרך כלל התקופה הארוכה ביותר. כך טיוטה זמנית ופרט צדדי מקבלים חיים של מסמך מחייב. במקום זאת, מפרידים את המידע לפי התפקיד שהוא ממלא.
## המבחן הראשון הוא מטרה, לא מספר חודשים
אין תקופת שמירה אחת שמתאימה לכל סוכן ולכל עסק. המשפט "אנחנו שומרים לשנתיים" נשמע כמו מדיניות, אבל הוא רק מספר אם איש אינו יודע מה נשמר ומדוע.
התחלה טובה היא לכתוב ליד כל סוג מידע משפט מטרה. למשל: שומרים את תוכן הבקשה כדי להכין הצעה; שומרים את ההצעה המאושרת כדי לנהל את ההתקשרות; שומרים אירוע אישור כדי שאפשר יהיה לבדוק מי התיר את השליחה; שומרים דוגמאות ערוכות כדי לבדוק את איכות הסוכן.
עכשיו אפשר לשאול מתי המטרה מסתיימת. תוכן בקשה עשוי להפסיק להיות נחוץ כשהפרטים החיוניים הועברו לרשומה מסודרת. טיוטה שנדחתה יכולה להימחק אחרי חלון קצר שמאפשר בדיקת תקלה. יומן אישור עשוי להידרש זמן רב יותר, מפני שהוא קשור לפעולה עסקית שכבר בוצעה.
תקנות הגנת הפרטיות בישראל מחייבות בעל מאגר לבחון אחת לשנה אם המידע שהוא שומר רב מן הנדרש למטרות המאגר. עבור מידע שהועבר לישראל מהאזור הכלכלי האירופי קיימות גם הוראות ייעודיות לגבי מידע שאינו נחוץ עוד. זה אינו תחליף לייעוץ משפטי, אבל הכיוון התפעולי ברור: "אולי נצטרך יום אחד" אינו מטרה טובה מספיק לשמירה בלתי מוגבלת.
## טבלת שמירה צריכה לכלול גם אירוע מחיקה
מדיניות שימושית נכנסת לעמוד אחד. לכל שורה יש סוג מידע, מטרה, מקור, בעלים, תקופת שמירה ואירוע שמתחיל את הספירה. העמודה האחרונה היא זאת שבדרך כלל חסרה.
"למחוק אחרי 90 יום" לא עונה על השאלה מתי היום הראשון. האם סופרים מקבלת ההודעה, מסגירת העסקה, משליחת ההצעה או מסיום ההתקשרות? בלי אירוע ברור, שתי מערכות יחשבו תאריך אחר והמחיקה תישאר בגדר כוונה.
כך יכולה להיראות חשיבה על כמה שכבות מידע, בלי לקבוע לעסק תקופות שאינן מבוססות על צרכיו:
* תמליל גולמי נשמר להבנת הבקשה ולבדיקת תקלה. הספירה מתחילה עם סגירת הטיפול, ובסופה מוחקים או משאירים רק את הפרטים הנחוצים.
* עובדות מאומתות משמשות להמשך הטיפול. כשהרשומה המוסמכת מתעדכנת, הן ממשיכות לפי מדיניות השמירה של מערכת היעד.
* טיוטה שלא אושרה נשמרת לבקרה קצרה. דחייה או החלפה מתחילות את הספירה, ובסופה הטיוטה נמחקת.
* פעולה שאושרה משמשת לתיעוד עסקי ולבדיקת אחריות. תקופת השמירה מתחילה בביצוע ונקבעת לפי סוג הפעולה והחובות שחלות עליה.
* דוגמת איכות נכנסת לערכת בדיקה רק אחרי צמצום והתממה. גם אותה בוחנים מחדש במועד שנקבע.
הטבלה אינה חוק ואינה תשובה משפטית. היא כלי שמכריח את העסק להפסיק לדבר על "הזיכרון של הסוכן" כאילו היה מגירה אחת.
## מחיקה אמיתית עוברת דרך כל העותקים
כפתור מחיקה בממשק אינו מוכיח שהמידע נעלם. אותה שיחה יכולה להופיע בתיבת המייל, במסד נתונים, ברשומת CRM, בקובץ שצורף, ביומן פעולה, במאגר חיפוש ובגיבוי. לפעמים נוצר ממנה גם תקציר שנשמר במקום אחר.
לכן מפת שמירה צריכה לעקוב אחרי מסלול המידע. מאיפה הוא נכנס, היכן נוצר עותק, איזה רכיב מעבד אותו, ואיזו מערכת נחשבת מקור מוסמך. מחיקה מתחילה בבקשה אחת, אך היא צריכה להגיע לכל יעד רלוונטי או להשאיר הסבר ברור מדוע עותק מסוים נשמר.
יש הבדל גם בין מחיקה לבין התממה. אם העסק צריך דוגמה כדי למדוד איכות, ייתכן שאין צורך לשמור שם, טלפון, כתובת או מסמך מלא. אפשר ליצור מקרה בדיקה שמכיל את המבנה המקצועי בלי לאפשר זיהוי סביר של האדם. הרשות להגנת הפרטיות מפרסמת מדריך לטכנולוגיות מגבירות פרטיות, ובין היתר מתארת ערפול, הסרת פרטים מזהים וצמצום רמת הפירוט.
החלק הפחות זוהר הוא גיבויים. מערכת עשויה למחוק מידע מהשימוש השוטף אך להשאיר אותו בגיבוי עד למחזור המחיקה הבא. המדיניות צריכה לתאר גם את זה: כמה זמן הגיבוי נשמר, מי יכול לשחזר אותו, ומה מונע ממידע שנמחק לחזור בשחזור רגיל.
## ההתנגדות: בלי היסטוריה הסוכן יאבד הקשר
נכון, אם מוחקים בלי לחשוב. אבל בחירה בין שמירה מלאה לבין אמנזיה היא בחירה מדומה.
אפשר לשמור מצב עסקי בלי לשמור את כל השיחה. במקום עשרים הודעות על תיאום, שומרים שהפגישה נקבעה למועד שאושר ואת מקור האישור. במקום מסמך מלא, שומרים שדות שנדרשים להמשך הטיפול וקישור למקור שנשמר לפי מדיניות נפרדת. במקום כל ניסוח שהסוכן הציע, שומרים את הגרסה שאושרה ואת אירוע האישור.
ההבחנה החשובה היא בין זיכרון עבודה לבין רשומה עסקית. זיכרון עבודה עוזר לסוכן להשלים משימה פתוחה. רשומה עסקית מתארת את המצב שהעסק החליט לשמר. הראשון יכול להיות עשיר וקצר חיים. השנייה צריכה להיות מצומצמת, מסודרת ובעלת בעלים.
גם יומני פעולה אינם חייבים להכיל את תוכן המידע כולו. כדי להוכיח שסוכן עדכן שדה מסוים, אפשר לשמור מזהה פעולה, זמן, גורם מאשר ותוצאת הבדיקה. העתק מלא של השיחה בתוך כל אירוע תיעוד מגדיל את החשיפה בלי בהכרח לשפר את הבקרה.
## ארבע שאלות שחושפות מדיניות מזויפת
מדיניות שמירה נבחנת ביום שבו צריך לבצע אותה. קחו פריט מידע אמיתי ושאלו:
1. מי יכול להסביר את מטרת השמירה שלו במשפט אחד?
2. איזה אירוע קובע מתי מתחילה תקופת השמירה?
3. באילו מערכות קיימים המקור, העותקים והתקצירים שנגזרו ממנו?
4. כיצד מוכיחים שהמחיקה או ההתממה אכן הושלמו?
אם התשובה לשאלה השלישית היא "כנראה רק במערכת הראשית", עדיין אין מפת מידע. אם אין תשובה לרביעית, יש הבטחת מחיקה ולא תהליך מחיקה.
כדאי להריץ את הבדיקה על מידע רגיש במיוחד, על מידע שגרתי ועל קובץ מצורף. שלושת המסלולים נוטים להתנהג אחרת. קובץ עשוי להישאר באחסון גם אחרי שמחקו את הרשומה שמפנה אליו, ותקציר עשוי לשרוד אחרי שהתמליל המקורי נעלם.
## ההחלטה הנכונה היא מה לא ללמד את המערכת לשמור
הרבה בעיות פרטיות מתחילות לפני המחיקה. הן מתחילות ברגע שבו המערכת אוספת פרט שאין לו תפקיד. אם סוכן נדרש לתאם פגישה, הוא כנראה אינו זקוק לצילום תעודת זהות. אם הוא מסכם בקשת שירות, אין סיבה שיעתיק כל פרט אישי אל שדה הערות פתוח.
לכן מדיניות שמירה טובה מתחברת גם לעיצוב הסוכן: אילו שדות הוא מבקש, מה הוא רשאי להעתיק, אילו פרטים מוסרים לפני שמקרה נכנס לבדיקת איכות, ואיזה מידע אינו נשלח מלכתחילה למערכת שאינה צריכה אותו.
הצעד המעשי הוא לא לכתוב מסמך פרטיות בן עשרים עמודים. בחרו תהליך אחד, עקבו אחרי פריט מידע אחד מתחילתו ועד סופו, ובנו עבורו שורת שמירה שניתן לבצע. אחר כך נסו למחוק אותו בסביבת בדיקה ולראות אילו עותקים נשארו.
אם אתם מתכננים סוכן AI ורוצים למפות את מסלול המידע לפני החיבור למערכות, שלחו ל־AI BUDDY דרך [aibuddy.co.il](https://aibuddy.co.il) תיאור של התהליך ומסמך אחד שעובר בו. נבנה מפת מקורות, עותקים ואירועי מחיקה לתהליך הזה, לפני שהזיכרון הזמני הופך לארכיון קבוע.
### מקורות
* [הרשות להגנת הפרטיות: שאלות ותשובות על תקנות אבטחת מידע](https://www.gov.il/he/pages/data_security_fqa?chapterIndex=1)
* [הרשות להגנת הפרטיות: מידע שהועבר לישראל מהאזור הכלכלי האירופי](https://www.gov.il/he/pages/europe_transfer?chapterIndex=8)
* [הרשות להגנת הפרטיות: מדריך לטכנולוגיות מגבירות פרטיות](https://www.gov.il/he/pages/guide_privacy_technologies2)
* [הרשות להגנת הפרטיות: שאלות ותשובות על תיקון 13](https://www.gov.il/he/pages/tikun13_qa?chapterIndex=6)