צ'אטבוט תואם GDPR: מדריך שלב אחר שלב (2026)

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

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

המדריך נבדק מול מקורות רשמיים ב-4 בנובמבר 2026. הוא מציע מסגרת לבדיקה ודוגמאות ליישום; הוא אינו מאשר תאימות של פריסה ואינו מחליף ייעוץ לגבי נסיבותיה המשפטיות המסוימות.

בדיקות לדוגמה, לבחירה

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

בדיקות אלה אינן מעריכות עמידה בדרישות החוק.

רשימת בדיקה בת 10 שלבים להשקת צ׳אטבוט עם פרטיות ואבטחה

מנו אחראי לכל סעיף ושמרו ראיות להחלטה או לבדיקה:

1. הגדירו את תהליך העבודה. הפרידו בין מידע ציבורי, תמיכה ספציפית לחשבון, עסקאות, שיווק ושיפור המודל.
2. מפו נתונים אישיים. כללו הנחיות, תשובות, מטא-נתונים, קבצים, רשומות שאוחזרו, יומנים ומערכות מחוברות.
3. בחרו בסיסים חוקיים. בחנו כל מטרה לפני העיבוד; הוסיפו תהליך הסכמה תקף כאשר נדרשת הסכמה.
4. זהו תפקידים והסכמים. קבעו מי מגדיר מטרות ומי מעבד לפי הוראות. בדקו תנאי עיבוד והעברות החלים עליכם.
5. צמצמו איסוף. הסירו שדות מיותרים והימנעו משליחת רשומות לקוח מלאות כאשר תוצאה מצומצמת מספיקה.
6. הגדירו שמירה וטיפול בזכויות. כללו בדיקות זהות, גישה, תיקון, מחיקה, ניידות כאשר היא חלה, והשלמת הפעולות במערכות המשך.
7. העריכו סיכונים. קבעו אם נדרש תסקיר השפעה על הגנת מידע (DPIA), והשלימו אותו לפני תחילת העיבוד הרלוונטי.
8. אבטחו גישה ושילובים. הפעילו הצפנה, אימות, הרשאות, ניטור ונוהלי אירועים המתאימים למקרה.
9. יידעו משתמשים. פרסמו מידע מדויק על פרטיות, ספקו את הגילוי הנדרש על AI ובחנו בנפרד את האחסון של הווידג׳ט.
10. בדקו והקצו אחריות מתמשכת. תרגלו מקרי כשל, הכשירו עובדים ובחנו מחדש את ההערכה כאשר מטרות, ספקים או תכונות משתנים.

עקרונות GDPR והשפעתם על תכנון צ׳אטבוט

GDPR חל על עיבוד רלוונטי במסגרת פעילותו של מוסד באזור הכלכלי האירופי (EEA). הוא עשוי לחול גם על ארגונים מחוץ לאזור כאשר הם מציעים מוצרים או שירותים לאנשים בו, או מנטרים את התנהגותם בו. המבחן נוגע לעיבוד ולזיקה הטריטוריאלית, ולא רק לאזרחותו של אדם. ה-EDPB מסביר את התחולה הטריטוריאלית ואת עקרונות היסוד.

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

בהפרות מוגדרות מהדרג החמור יותר, הקנס המרבי עשוי להגיע ל-20 מיליון אירו, או, במקרה של עסק, ל-4% מהמחזור השנתי העולמי בשנת הכספים הקודמת, לפי הגבוה מביניהם. האכיפה בפועל תלויה בנסיבות; ראו את הסבר ה-EDPB על סמכויות הפיקוח.

מונחים במדריך

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

הפיכת דרישות GDPR לתהליכים תפעוליים

התחילו במסלול בפועל מהודעת המבקר ועד למחיקתה הסופית. התכנונים הבאים הם דפוסי יישום להמחשה, ולא רשימת תכונות מובנות של Quickchat AI.

מזעור נתונים משלב התכנון

הגדירו סכמת required_fields לכל משימה. בירור על תור עשוי לדרוש שעה מועדפת ודרך ליצירת קשר; שאלה ציבורית על שעות פתיחה אינה אמורה לחייב פרופיל לקוח.

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

בדקו מעבר לטופס הגלוי. חיפוש ב-CRM עלול לאחזר רשומה שלמה גם כשהתשובה דורשת רק סטטוס הזמנה. הגבילו את השדות המוחזרים ואת הנתונים המועברים למודל. השאירו פרטי גישה ומידע לא רלוונטי על לקוחות מחוץ להנחיות.

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

הסכמה ובסיסים חוקיים אחרים

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

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

אישור כפול יכול לסייע בביסוס ראיות בנסיבות מסוימות. הוא אינו דרישה כללית של GDPR. הנחיות ה-EDPB בנושא הסכמה מבחינות בין הסכמה רגילה למפורשת, ומתארות אימות דו-שלבי כשיטה אפשרית אחת.

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

טיפול בבקשות גישה, מחיקה וניידות

הציעו דרך נגישה להגשת בקשות ומנו אדם או צוות האחראים להשלמתן. פקודה מותאמת כגון /my_data או /delete_my_data יכולה לפתוח בקשה, אך אף אחת מהן אינה תכונה מובנית מאומתת של Quickchat AI. אישור בשיחה אינו ראיה לכך שהבקשה הושלמה.

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

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

למסלולי המחיקה ב-Quickchat AI יש השפעות שונות. מחיקת AI Agent הופכת את שיחותיו לבלתי נגישות, אך אינה מוחקת אותן. מחיקת חשבון מוחקת בתהליך רקע את שיחות הסוכנים הקיימים שלו; התיעוד מציין חריגים כגון שיחות של סוכנים שנמחקו קודם, קבצים מצורפים, יצוא, אינדקסי חיפוש ורשומות חיצוניות. פנו לתמיכה לגבי תהליך המחיקה המתאים. ניתוק ערוץ Meta מפסיק עיבוד מורשה עתידי, אך אינו מוחק אוטומטית שיחות היסטוריות.

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

הגבלת אחסון ותזמון שמירה

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

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

function scheduleRetention(record, policy) {
  return {
    recordId: record.id,
    purpose: record.purpose,
    reviewOrDeleteAt: policy.dateFor(record),
  };
}

function processDueRecord(item) {
  if (requiresRetentionReview(item)) {
    return queueManualReview(item);
  }
  queueErasureAcrossRecordedSystems(item);
  recordVerificationPending(item.recordId);
}

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

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

סעיף 22 ובדיקה אנושית משמעותית

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

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

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

אמצעי אבטחה המתאימים לסיכוני צ׳אטבוט

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

הצפנה בתעבורה ובאחסון

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

TLS מגן על חיבור בתעבורה; הצפנה באחסון מגינה על נתונים מאוחסנים. אמצעים אלה אינם מוכיחים כשלעצמם הצפנה מקצה לקצה, שבה גורמי ביניים אינם יכולים לקרוא את התוכן. שירות המעבד תוכן הודעות עשוי להידרש לפענח אותו. הימנעו מהצגת TLS 1.3 או AES-256 כדרישות חובה של GDPR או כהוכחת תאימות.

אימות, תפקידי גישה ושילוב מערכות זהות

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

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

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

אבטחת API והרשאות מצומצמות לשילובים

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

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

ניטור, יומנים ותגובה לאירועים

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

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

אלה חובות וספים שונים; הנחיות רשות הגנת המידע האירית בנושא הפרות מסבירות את ההבחנה. השינויים המוצעים ל-GDPR במסגרת Digital Omnibus אינם סיבה להשתמש כעת במועד דיווח אחר.

רשימת בדיקה להערכת אבטחה

ניהול סיכוני צ׳אטבוט ייחודיים ל-AI

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

הזרקת הנחיות ובדיקות עוינות

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

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

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

הזיות ואימות תשובות

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

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

דליפת נתונים, אימון והשחרה

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

השאלות המשפטיות הנפוצות של Quickchat AI מציינות שחומר של לקוחות אינו משמש לאימון מודלי LLM, ושטיהור מידע מזהה אישית (PII) זמין לפי בקשה. אין בכך הבטחה שכל הודעה מטוהרת או שכל הנתונים האישיים מזוהים. אשרו את התצורה שנבחרה ואת תנאי הספק.

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

ראיות להסברים ולנתיבי ביקורת

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

התכונה Why AI said that ב-Inbox של Quickchat AI יכולה להציג מקורות שאוחזרו וראיות לביצוע. היא מסייעת לחקור תשובה; היא אינה תיאור סיבתי מלא של פעולת המודל הפנימית ואינה תחליף לבחינת חובות ההסבר בתהליך של קבלת החלטות משמעותיות.

עיבוד בינלאומי ומיקומי שרתים

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

אחסון באזור הכלכלי האירופי ועיבוד מחוצה לו

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

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

סעיפים חוזיים סטנדרטיים ומסגרת פרטיות הנתונים בין האיחוד האירופי לארה״ב

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

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

אל תבלבלו בין מעמד ספק הענן למעמד ספק הצ׳אטבוט. השאלות הנפוצות של Quickchat AI מתארות תהליך התאמה מתמשך ל-DPF, ולא השתתפות מאומתת.

דוגמה מספק: בקרות הנתונים של OpenAI API

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

Zero Data Retention ו-Modified Abuse Monitoring מחייבים אישור וכפופים למגבלות של נקודות קצה. אשרו את החשבון, נקודת הקצה, ההסכם ומיקומי העיבוד בפועל. בקרות היסטוריה ב-ChatGPT לצרכנים אינן קובעות את הגדרות שילוב ה-API. תנאי ספק כלליים אלה אינם מוכיחים שבחשבון Quickchat AI מסוים אין שמירת נתונים.

הסכמי עיבוד ואחריות ספקים

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

תנאי עיבוד נדרשים ושאלות AI נוספות

בדקו שההסכם מכסה:

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

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

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

נקודות למשא ומתן עם ספקי AI

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

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

התאמה אישית ומזעור נתונים

התחילו במידע המועט ביותר הדרוש למענה על השאלה הנוכחית. פרופילים מתמשכים מחייבים מטרה והערכה משלהם.

פרטיות דיפרנציאלית ועיבוד במכשיר

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

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

תשובות לפי פלח ויצירת פרופיל אישי

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

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

צ׳אטבוטים בענפים מפוקחים

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

בריאות: נתונים רגישים וחובות HIPAA רלוונטיות

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

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

פיננסים: שמירת רשומות ובקרות על החלטות

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

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

שירותים ציבוריים: הערכה ומידע נגיש

גופים ציבוריים זקוקים בדרך כלל לממונה הגנת מידע (DPO), בכפוף לחריגים הרלוונטיים, בעוד הצורך ב-DPIA מסוים תלוי בסיכוני העיבוד. צ׳אטבוט ציבורי לשאלות נפוצות ומערכת המשפיעה על זכאות לקצבאות מחייבים בדיקות שונות.

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

הערכת ספקי צ׳אטבוט וטכנולוגיה

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

מה מוכיחים ISO 27001, SOC 2 ו-Cyber Essentials

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

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

Cyber Essentials היא תוכנית בריטית המכסה בקרות טכניות בסיסיות נגד איומי אינטרנט נפוצים. אף אחד מאלה אינו מוכיח לבדו תאימות ל-GDPR בשימוש שלכם. השאלות המשפטיות הנפוצות של Quickchat AI מתארות תהליך לקראת SOC 2; אל תתייחסו לניסוח זה כאל דוח שכבר הושלם.

15 שאלות לספקים פוטנציאליים

1. היכן מאוחסנים ומעובדים הנחיות, תשובות, קבצים, יומנים וגיבויים, ומי יכול לגשת אליהם מרחוק?
2. אילו תפקידים ופעילויות עיבוד מכסה ה-DPA המוצע?
3. כיצד מופרדת גישה לנתוני לקוח אחד מנתוני לקוח אחר?
4. אילו חיבורים ורשומות מאוחסנות מוצפנים, וכיצד מנוהלים המפתחות?
5. אילו כללי שמירה ומחיקה חלים על כל קטגוריית נתונים?
6. כיצד נתמכות ומאומתות בקשות גישה, תיקון, מחיקה וניידות?
7. אילו מעבדי משנה מעורבים, וכיצד מודיעים על שינויים?
8. האם נתוני לקוחות משמשים לאימון, להערכה או למשוב, ובאילו תנאים?
9. כיצד נחקרים אירועים וכיצד מדווחים על הפרות רלוונטיות?
10. אילו תעודות או דוחות הבטחה עדכניים מכסים את השירות המסוים?
11. אילו מנגנוני אימות, תפקידים ושילובי זהות זמינים בפועל?
12. אילו ראיות מתייחסות להזרקת הנחיות, לפעולות בלתי מורשות ולדליפת נתונים?
13. אילו אפשרויות פרטיות ואבטחה הן ברירות מחדל, הגדרות הניתנות לשינוי או הסדרים ארגוניים?
14. לאילו יומנים וראיות למקורות ולפעולות יכולים לקוחות לגשת, ומה מגבלותיהם?
15. כיצד נוכל לבדוק ראיות לתאימות, לייצא נתונים ולאמת את תהליך סיום השירות?

טבלת השוואה בין ספקים

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

הורידו רישום של זרימות הנתונים בפריסה

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

1. ב-components.csv, רשמו את הדפדפן, היישום, מאגר הידע, ספק המודל, השירותים המחוברים, הלוגים והגיבויים שרלוונטיים בפועל. תעדו בנפרד מיקומי עיבוד ואחסון, וכן שימוש לאימון, שמירה, היקף מחיקה ואחריות לגישה. השאירו עובדות שאינן ידועות ללא הכרעה.
2. ב-data-flows.csv, חברו את מזהי הרכיבים ותארו את המטרה, קטגוריות הנתונים ותנאי הגישה של כל זרימה. רשמו קטגוריות והפניות למסמכים, לא תמלילים פרטיים או פרטי גישה.
3. ב-evidence-register.csv, קשרו כל טענה למקור מתוארך ולהיקפו. הבדילו בין הצהרות ספקים, חוזים ותצורה לבין תוכניות בדיקה ורישומים של בדיקות שנצפו. בדיקה מתוכננת נשארת not_run. הקצו אחראי לשאלות הפתוחות.

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

תוכנית מעשית לצוותים קטנים יותר

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

פשרות בין תוכנה באירוח עצמי ל-SaaS

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

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

בקרות שניתן להטמיע במשאבים מוגבלים

השתמשו בתוכנה מתוחזקת, בתעבורה מאובטחת, באימות מתאים ובגישה מוגבלת. השאירו פרטי גישה מחוץ להנחיות ורשומות מיותרות מחוץ ל-Knowledge Base. הגדירו תיבת פניות למימוש זכויות עם אחראי, ומרשם שמירה המשקף את המערכות בפועל.

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

שלוש דוגמאות יישום היפותטיות

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

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

חוק ה-AI של האיחוד האירופי לצד GDPR

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

חובות שקיפות עדכניות ומועדי תחולה לסיכון גבוה

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

ה-AI Omnibus שאומץ נכנס לתוקף ב-27 ביולי 2026. דרישות הסיכון הגבוה הרלוונטיות חלות כעת מ-2 בדצמבר 2027 על מערכות שבנספח III, ומ-2 באוגוסט 2028 על מערכות הקשורות למוצרים שבנספח I. הסיווג תלוי בשימוש המיועד ובקריטריונים שבדין; צ׳אטבוט בענף מפוקח אינו מסווג אוטומטית בסיכון גבוה רק בשל הענף שלו.

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

הליך Digital Omnibus הנפרד בנושא GDPR ו-ePrivacy עדיין היה תלוי ועומד כשנבדק ב-4 בנובמבר 2026. אין להתייחס לשינויים המוצעים לכללים אלה כאל הדין הנוכחי.

ISO/IEC 42001 וממשל AI

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

לוח זמנים ליישום ומטריצת אחריות

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

תוכנית ל-90 ימים עם נקודות בדיקה

• ימים 1-30: בירור. הגדירו משימות, זרימות נתונים, בסיסים, תפקידים ודרישות ענפיות. בדקו צורך ב-DPIA, זהו אחראים להחלטות ואספו ראיות מהספקים.
• ימים 31-60: יישום. הסכימו על תנאי העיבוד הרלוונטיים; הגדירו הודעות, גישה, שילובים ושמירה. בנו את תהליכי הזכויות והאירועים הנדרשים. השלימו את עבודת ההערכה ככל שהתכנון נעשה קונקרטי.
• ימים 61-90: אימות. בדקו משימות רגילות, בקשות בלתי מורשות, תשובות שגויות, היקף מחיקה והתאוששות. הכשירו את הצוות, הסדירו אמצעי הגנה נחוצים ובחנו כל DPIA נדרש לפני תחילת העיבוד הרלוונטי. גם פיילוט מצומצם מחייב הגנות מתאימות.

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

דוגמת RACI עם ייעוץ DPO עצמאי

R הוא האחראי לביצוע העבודה, A הוא בעל האחריות הארגוני לפרויקט, C הוא גורם שמתייעצים איתו, ו-I הוא גורם שמיידעים אותו. הדוגמה התפעולית אינה מעבירה אחריות חוקית מבעל השליטה או מהמעבד.

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

לפני אישור הפריסה

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

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

שאלות נפוצות על פרטיות בצ׳אטבוטים

האם צ׳אטבוט מבוסס GPT יכול לעמוד ב-GDPR?

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

כיצד למחוק נתוני משתמש לפי בקשתו?

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

באיזו שיטת אימות צ׳אטבוט צריך להשתמש?

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

לכמה זמן אפשר לשמור יומני צ׳אט לפי GDPR?

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

האם נדרש DPA כשאני מארח את המודל בעצמי?

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

האם צ׳אטבוט יכול לקבל החלטות אוטומטיות לחלוטין לפי סעיף 22?

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

מה צריכה לכלול הודעת פרטיות של צ׳אטבוט?

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

כיצד להפחית סיכון להזרקת הנחיות?

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

האם ווידג׳טים של צ׳אט דורשים הסכמה לעוגיות?

בחנו כל פעולת אחסון או גישה ואת מטרתה לפי היישום הרלוונטי של ePrivacy. הנחיות ה-EDPB מכסות יותר מעוגיות. פעולות הנחוצות בהחלט לשירות שהמבקר מבקש במפורש עשויות להיות פטורות; פעולות אחרות עשויות לדרוש הסכמה מראש. הווידג׳ט של Quickchat AI משתמש באחסון המקומי של הדפדפן להמשכיות שיחה ולהעדפות. אל תניחו שכל אחסון של ווידג׳ט פטור או שחייבים לחסום כל ווידג׳ט במלואו לפני בחירת הסכמה.

האם חוק ה-AI של האיחוד האירופי מחליף את GDPR לצ׳אטבוטים?

לא. GDPR ממשיך להסדיר עיבוד רלוונטי של נתונים אישיים, וחוק ה-AI מוסיף חובות לפי המערכת, התפקיד והשימוש. חובות השקיפות לפי סעיף 50 כבר חלות מ-2 באוגוסט 2026. בדקו את לוח הזמנים המתוקן העדכני לדרישות סיכון גבוה, במקום להסתמך על הציפיות המקוריות לשנים 2025/2026.

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