ביקורת GDPR ויומן גישה

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

יומן הגישה

טבלה ייעודית מתעדת, עבור כל גישה cross-tenant:

• חותמת הזמן (ברזולוציית מיקרושנייה)
• הארגון היעד (שתוכנו נקרא)
• הארגון הקורא (בדרך כלל ה-vendor)
• התפקיד / הסוכן / המשתמש שקרא
• סוג הישות (אוצר מילים סגור: exchange_text, knowledge_chunk, audio_segment…)
• מזהה הישות
• הקשר השימוש (משימה, כרטיס, הצעה)

אוצר המילים של הישויות סגור ברמת מסד הנתונים (CHECK constraint) וסגור ברמת הקוד (whitelist אפליקטיבית). הוספת סוג = מיגרציה חדשה + עדכון whitelist. אין רשומות לא צפויות.

זכות הגישה (סעיף 15)

כל ארגון יכול לעיין בלוגי הגישה שלו בלבד דרך:

GET /api/admin/me/content-reads

פילטרים זמינים: תקופה, סוג ישות, מזהה ישות, זהות הקורא. ייצוא CSV / Excel לשיתוף עם ממונה הגנת המידע.

אין גישה cross-org לביקורת: ה-vendor לעולם אינו רואה את לוגי הביקורת של הלקוח.

זכות המחיקה (סעיף 17)

שלוש רמות מחיקה נתמכות:

1. מחיקת משתמש — משתמש קצה מבקש מחיקת נתוניו בארגון לקוח. הארגון מפעיל את המחיקה דרך ממשק הניהול או ה-API admin.
2. מחיקת ארגון — ארגון עוזב את betool. כל המשאבים שלו נמחקים: טבלאות מסוננות לפי org_id, תיקיית קבצים, סודות מנוקים. תקופת חסד חוזית כברירת מחדל: 30 יום לחזרה בהם, לאחר מכן מחיקה בלתי-הפיכה.
3. מחיקה משפטית — בצו, מחיקת רכיבים ספציפיים מבלי לגעת בשאר. מתועדת בביקורת עם הפניה לבסיס המשפטי.

Opt-in ו-opt-out לקריאה cross-tenant

כברירת מחדל, ה-opt-in לקריאה cross-tenant הוא FALSE. ארגון יכול להפעילו בניהול → פרטיות → קריאה cross-tenant.

שלושה מצבים:

• סירוב מוחלט — ברירת מחדל. ה-vendor אינו יכול לגשת לאף תוכן של ארגון זה. תוצאה: לא ניתן לקיים תמיכה cross-org על דברים הקשורים לתוכן (הארכיטקטורה נשארת, דגלים עסקיים — כן).
• opt-in זמני — הרשאה לחלון זמן מוגדר, ניתן לביטול.
• opt-in קבוע — ללקוחות שרוצים תמיכה יזומה (נדיר בבנקאות, שכיח ב-SaaS סטנדרטי).

ה-vendor אינו יכול להפעיל opt-in זה עבור הלקוח. זהו מבחן יסודי: אם ה-vendor יכול לעשות toggle ללא פעולת לקוח — הארכיטקטורה שבורה.

ערבות כנגד פעולות הרסניות

כל פעולה שמשמידה או מחליפה תוכן (DELETE, REPLACE-IN-PLACE) נדחית בשלב הוולידציה אם הארגון היעד לא הפעיל את ה-opt-in לקריאה. הסיבה: ללא נראות, המפעיל מציע בעיוורון payload שעלול לדרוס את הקיים.

סירוב מדורג אם הביקורת אינה זמינה

אם מסד נתוני הביקורת אינו זמין (אירוע תשתיתי), כל קריאה cross-tenant נדחית. מדיניות מחמירה: אין קריאה ללא עקבה.

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

עוגיות הסכמה

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