המדריך נבדק ביום 29.07.2026 מול חוק הגנת הפרטיות לאחר תיקון 13, תקנות אבטחת מידע, עמדות הרשות להגנת הפרטיות, מערך הסייבר הלאומי, בנק ישראל ותקן PCI DSS העדכני. יש לבדוק אותו מחדש עד 27.10.2026, ובמוקדם יותר אם ספק משנה אזור אחסון, תנאי שימוש, מדיניות אימון AI, ממשק סליקה או גרסת תקן.
ספק טוב יכול לחסוך לעמותה זמן, כסף וטעויות. הוא אינו מעביר אליו את אחריות העמותה למידע. כאשר ספק ענן, CRM, דיוור, סליקה או AI מקבל גישה למידע אישי, צריך לבדוק את הסיכון לפני ההתקשרות, להגביל את השימוש, להסדיר את היחסים בכתב, לפקח במהלך השירות ולהיערך ליציאה.
המדריך נותן מסלול עבודה מעשי. הוא אינו מאשר ספק מסוים, אינו קובע שהסמכת ISO או PCI לבדה מספיקה ואינו מחליף בדיקה משפטית או מקצועית למערכת ולמאגר המסוימים.
שלוש שכבות שחשוב לא לערבב
- חובה בדין — דרישה בחוק או בתקנות, לפי תפקיד הצדדים, סוג המידע, רמת האבטחה ונסיבות העיבוד.
- עמדת רשות או הנחיה רשמית — פרשנות או כלי יישום של רשות מוסמכת. צריך לבדוק אם המסמך סופי, טיוטה או המלצה.
- בקרה תפעולית מומלצת — דרישה שרצוי להציב לספק כדי לצמצם סיכון, להבטיח רציפות ולהוכיח פיקוח, אך אין להציג אותה כחובה אחידה לכל עמותה.
מי הוא מי בהתקשרות
- בעל השליטה במאגר הוא בדרך כלל העמותה שקובעת למה וכיצד יעובד המידע.
- מחזיק או מעבד הוא גורם חיצוני שמעבד מידע בעבור בעל השליטה.
- ספק משנה יכול להיות חברת ענן, מוקד תמיכה, שירות גיבוי, שירות דיוור, מנוע AI או ספק תשלומים שהספק הראשי מפעיל.
- נושא המידע יכול להיות תורם, עובד, מתנדב, חבר, ספק יחיד או מקבל סיוע.
- העברה לחו״ל אינה רק שליחת קובץ. גם אחסון באזור זר או מתן גישת תמיכה לגורם מחוץ לישראל דורשים מיפוי ובדיקה.
שער כניסה: לא מעלים נתוני אמת לפני שיש תיק החלטה
לפני הדגמה או תקופת ניסיון, פותחים תיק ספק אחד ובו:
- מטרה ובסיס חוקי — מה בדיוק רוצים להשיג, איזה מידע נחוץ, האם קיימת הסכמה תקפה או סמכות בדין, ומה נמסר לנושאי המידע.
- מפת מידע — שדות, מקורות, נמענים, אינטגרציות, קבצי יצוא, גיבויים, לוגים, אזורי אחסון, מוקדי תמיכה וספקי משנה.
- סיווג סיכון — מידע בעל רגישות מיוחדת, מספר האנשים, מספר בעלי ההרשאה, השפעה על זכויות, ונזק אפשרי מחשיפה, אובדן או שגיאה.
- דרישות כתובות — פרטיות, אבטחה, תפעול, שירות, יציאה, מחיר ובעלות על המידע.
- ראיות ספק — מענה לשאלון, תרשים ארכיטקטורה, רשימת ספקי משנה ואזורים, דוח ביקורת או הסמכה עדכניים, בדיקת שחזור ותוכנית אירועים.
- חוזה ונספחים — הסכם השירות, נספח עיבוד מידע, נספח העברה לחו״ל לפי הצורך ונספח רמת שירות.
- אישור והגדרה טכנית — חשבון ארגוני בבעלות העמותה, אימות רב־שלבי, הרשאות מזעריות, לוגים, יצוא, מחיקה ובדיקה עם מידע מלאכותי.
הרשות ממליצה לבצע הערכת סיכוני פרטיות לפני מאגר חדש, טכנולוגיה חדשה או שינוי בדרך השימוש במידע. הכלי הרשמי הוא כלי עזר ואינו תחליף לתסקיר מלא או לחוות דעת משפטית.
Q-090 — מה צריך לבדוק לפני שמעלים מידע אישי לענן או מעבירים אותו לספק בישראל או בחו״ל?
התשובה הקצרה
לא מעלים מידע אישי לפני שיודעים מה מטרת העיבוד ומה הבסיס החוקי, מה המידע המינימלי הנחוץ, מי יקבל גישה, איפה הוא יישמר, לאילו ספקי משנה יעבור, כיצד יאובטח וכיצד יוחזר או יימחק. לפני גישת ספק יש לבצע בדיקת סיכון ולהסדיר את ההתקשרות; בהעברה או בגישה מחו״ל צריך גם לזהות עילה לפי תקנות ההעברה ולקבל התחייבויות מתאימות בכתב.
שלב 1: מצמצמים לפני שמעבירים
מסמך הגדרות המאגר צריך לתאר את פעולות האיסוף והשימוש, המטרות, סוגי המידע, עיבוד בידי מחזיק, העברה או שימוש מחוץ לישראל והסיכונים העיקריים. אחת לשנה צריך לבדוק אם נשמר מידע רב מן הדרוש. לכן השאלה הראשונה אינה „איזה ענן זול יותר”, אלא „האם כל שדה וקובץ דרושים למטרה”.
יש להעדיף, לפי העניין:
- שדות מובנים במקום הערות חופשיות;
- נתונים מצומצמים במקום צילום מסמך מלא;
- מידע מותמם או מלאכותי להדגמה ולבדיקות;
- הרשאת צפייה זמנית במקום העתקה;
- קישור מאובטח במקום קובץ מצורף;
- מחיקה מתוזמנת במקום שמירה ללא הגבלה.
מחיקת שם בלבד אינה בהכרח התממה. אם אפשר לזהות אדם באמצעות קוד, צירוף מאפיינים או טבלת התאמה, יש להתייחס למידע כמידע אישי ולשמור את המפתח בנפרד ובהרשאה מצומצמת.
שלב 2: ממפים את המסלול האמיתי, לא את כתובת החברה
מבקשים מהספק תרשים פשוט שעונה על השאלות האלה:
| נקודה | מה חייבים לדעת | | --- | --- | | קליטה | מאיזה טופס, API, דוא״ל או קובץ מגיע המידע | | עיבוד | אילו שירותים ורכיבים קוראים, משנים, מדרגים או מעשירים אותו | | אחסון | אזור ראשי, גיבויים, לוגים, מטמון ומכשירי תמיכה | | גישה | עובדי העמותה, עובדי הספק, קבלנים, תמיכה וספקי משנה | | יצוא | דיוור, הנהלת חשבונות, סליקה, BI, AI וממשקי צד שלישי | | מחיקה | מידע פעיל, גרסאות, גיבויים, לוגים והעתקים אצל ספקי משנה | | יציאה | פורמט היצוא, זמן ההעמדה, עלות, סיוע ואישור השמדה |
הבטחה ש„השרת באירופה” או ש„החברה ישראלית” אינה עונה לבדה על השאלות. צריך לבדוק את כל אזורי העיבוד, גישת התמיכה, ספקי המשנה והעברות ההמשך.
שלב 3: בודקים עילה והתחייבות להעברה מחוץ לישראל
בהעברה לחו״ל צריך לוודא שמתקיים תנאי מתאים בתקנה 1 או אחת העילות בתקנה 2 לתקנות ההעברה. בכל העברה לפי התקנות נדרשת התחייבות בכתב של המקבל לאמצעים מספיקים להגנת הפרטיות ולהגבלת העברה לאחר. אישור העמותה להעברת המשך אינו „כרטיס חופשי”: ההעברה הנוספת צריכה להיות חוקית גם אילו יצאה ישירות מישראל, ואם היא למדינה נוספת נבדקים שוב תנאי ההעברה.
כאשר מסתמכים על התחייבות חוזית לפי תקנה 2(4), ההסכם צריך לשמר, בין היתר, צמידות מטרה, זכויות עיון ותיקון או מחיקה, סודיות ואבטחה. אם המקבל בחו״ל הוא מחזיק שמעבד בעבור העמותה, הרשות מבהירה שחלים עליו מלוא דיני האבטחה הרלוונטיים למחזיק, נוסף על תקנה 15 החלה על ההתקשרות.
אין לבחור עילה אוטומטית. יש לתעד בתיק הספק:
- איזה מידע יוצא ומדוע;
- לאיזו מדינה ואיזה גורם משפטי מקבל אותו;
- מהי העילה המדויקת להעברה;
- אילו התחייבויות נחתמו;
- מי רשאי לאשר ספק משנה או מדינה נוספת;
- איך נושא מידע יממש זכויות;
- כיצד תיעצר ההעברה אם התנאים משתנים.
שלב 4: בודקים אבטחה לפי השימוש בפועל
מבקשים ראיות, לא תשובת „כן” כללית:
- הפרדה בין לקוחות והגנת סביבת הייצור;
- MFA לחשבונות ניהול ותמיכה, SSO אם נדרש, וחסימת חשבונות משותפים;
- הרשאות לפי תפקיד, תהליך אישור וביטול מהיר בסיום תפקיד;
- הצפנה בתעבורה ובאחסון וניהול מפתחות מתאים;
- לוגים של כניסה, שינוי, יצוא, מחיקה ופעולות מנהל;
- עדכוני אבטחה, טיפול בחולשות ומערכות נתמכות;
- גיבויים, בדיקות שחזור, RPO ו־RTO המתאימים לפעילות;
- הפרדה בין פיתוח לייצור ושימוש במידע מלאכותי בבדיקות ככל האפשר;
- נוהל אירועים ויכולת למסור לעמותה מידע בזמן לדיווח ולטיפול;
- מחיקה מכלל הסביבות ואישור השבה או השמדה בסיום.
שאלון שרשרת האספקה של מערך הסייבר מספק בסיס מועיל לדרישת ראיות מספק, אך צריך להתאימו למידע ולשירות; הוא אינו תעודת כשרות אוטומטית לספק.
תנאי עצירה לפני העלאת מידע
לא מעלים נתוני אמת כאשר מתקיים אחד מאלה:
- לא ברור מי הישות החוזית או מי בעל חשבון המנהל;
- אין רשימת אזורים וספקי משנה;
- הספק רשאי להשתמש במידע למטרותיו, לפרסום או לאימון בלי גבול ברור;
- אי אפשר להגביל הרשאות או להפעיל MFA;
- אין דרך יצוא מלאה ושמישה או דרך מחיקה;
- הספק מסרב להתחייב לדיווח אירוע ולשיתוף ראיות;
- ההעברה לחו״ל אינה ממופה או שאין לה עילה מתועדת;
- ההדגמה דורשת מידע אמיתי אף שאפשר להשתמש במידע מלאכותי.
Q-186 — אילו סעיפים חייבים להופיע בהסכם עם ספק CRM, דיוור, ענן או סליקה?
התשובה הקצרה
בהתקשרות לפי תקנה 15 ההסכם הכתוב צריך להגדיר במפורש את המידע והמטרות המותרות, המערכות והפעולות המותרות, משך ההתקשרות והחזרת המידע או השמדתו, יישום חובות האבטחה, סודיות בעלי ההרשאה, ספקי משנה, דיווח שנתי לפחות ודיווח אירוע. במקביל על העמותה לבדוק סיכון לפני ההתקשרות ולפקח על הספק לפי הסיכון.
שמונת רכיבי תקנה 15 בהסכם
| רכיב | ניסוח מעשי שיש להשלים בהסכם | | --- | --- | | מידע ומטרה | רשימת סוגי המידע שהספק רשאי לעבד ומטרה מותרת לכל סוג; איסור שימוש למטרה אחרת | | מערכות | שמות המערכות, הסביבות והממשקים שאליהם מותרת גישה | | פעולות | צפייה, קליטה, שינוי, יצוא, תמיכה או מחיקה; כל פעולה שלא הותרה אסורה | | משך וסיום | תאריך או אירוע סיום, פורמט ומועד השבה, מחיקה מכל מערכת וגיבוי לפי לוח מוסכם ואישור ביצוע | | אבטחת מידע | דרך יישום חובות המחזיק ובקרות נוספות שקבעה העמותה | | עובדי הספק | התחייבות לסודיות, שימוש רק לפי ההסכם ויישום אמצעי האבטחה | | ספקי משנה | אישור מראש או מנגנון הודעה והתנגדות, ורצף מלא של אותם תנאים אצל כל ספק משנה | | דיווח ופיקוח | דיווח עמידה לפחות אחת לשנה, הודעה על אירוע אבטחה וראיות שמאפשרות פיקוח |
יש לכלול את הנושאים הרלוונטיים גם בנוהל אבטחת המידע של המאגר, עם הפניה להסכם ולנוהל הספק. היקף הפיקוח אינו אחיד: הוא צריך להתאים לסיכון של השירות, המידע והגישה.
סעיפים תפעוליים מומלצים מעבר לרשימת התקנה
אלה בקרות חוזיות מומלצות; אין להציג כל אחת מהן כחובה סטטוטורית אחידה:
- חלון דיווח אירוע קצר שמאפשר לעמותה לעמוד בחובותיה, עם איש קשר זמין ופרטי מינימום לדיווח.
- שיתוף פעולה בחקירה — לוגים, ציר זמן, גורם שורש, פעולות containment ושימור ראיות.
- שינוי מהותי — הודעה לפני שינוי אזור, ספק משנה, תנאי שימוש, מטרת עיבוד, מודל AI או מדיניות שמירה.
- זמינות והמשכיות — SLA, תחזוקה, גיבוי, RPO, RTO, בדיקת שחזור ותוכנית חירום.
- זכויות נושאי מידע — איתור, יצוא, תיקון, הגבלה ומחיקה בפרקי זמן שתואמים את חובות העמותה.
- יציאה וניידות — פורמט מתועד, יצוא מלא כולל קבצים וקשרים, סיוע מעבר, מחיר ותקופת הורדה.
- בעלות ושליטה — המידע, החשבון הראשי, הדומיין, המפתחות והגדרות הייצוא בשליטת העמותה.
- ראיות וביקורת — דוחות עצמאיים עדכניים, סיכום בדיקות, תוכנית תיקון וזכות לבקש מידע סביר לפי סיכון.
- אחריות ושיפוי — חלוקת אחריות שמתאימה לסיכון ואינה מרוקנת את חובות הספק מתוכן.
- ביטוח — לפי הסיכון והיקף השירות, לאחר בדיקה שהכיסוי רלוונטי ולא רק הצהרה כללית.
הסמכת ISO, דוח SOC או הצהרת PCI יכולים להיות ראיה אחת. הם אינם מוכיחים שהשירות המסוים, ההגדרות של העמותה, ספקי המשנה והחוזה עומדים בכל הדרישות. מדריך היישום הרשמי הוותיק לתקנות מסייע בבקרות טכניות, אך יש לקרוא אותו לצד נוסח החוק וההנחיות המעודכנות לאחר תיקון 13.
תוספת להסכם כאשר יש עיבוד בחו״ל
נספח ההעברה צריך לזהות את העילה המשפטית, המדינה והישות המקבלת, המטרות, אמצעי הפרטיות, התחייבויות המקבל, ספקי משנה והעברות המשך. הסכמה כללית ל„ספקים ברחבי העולם” אינה תחליף למיפוי ולהתחייבויות. אם מסתמכים על הסכמה של נושא המידע, היא צריכה להיות מדעת וחופשית, והיידוע צריך להסביר באופן ברור את המטרות וסוגי המקבלים; תיאור עמום כגון „חברות טכנולוגיה” עלול שלא להספיק.
ומה עם ספק שהוא אדם יחיד?
תקנה 15 מנסחת את ההסדר לגורם חיצוני שאינו יחיד. אין מכאן פטור משאר חובות החוק, האבטחה והסודיות. גם עם פרילנסר יחיד נכון להסדיר בכתב מטרה, הרשאות, סודיות, מכשירים, דיווח אירוע, מחיקה וסיום גישה, לפי הסיכון.
בדיקה שנתית שאינה „וי” בלבד
לפחות פעם בשנה, ובכל שינוי מהותי, אוספים:
- הצהרת עמידה מפורטת ועדכנית;
- רשימת ספקי משנה ואזורים והשינויים שחלו;
- רשימת בעלי גישה חריגה או תמיכה;
- אירועים, כמעט־אירועים וחולשות מהותיות;
- תוצאות שחזור, זמינות ותרגיל יציאה;
- סטטוס ליקויים ומועדי תיקון;
- אישור שהמטרה, השדות ותקופת השמירה עדיין נחוצים.
Q-191 — מה צריך לבדוק לפני בחירת מערכת CRM, דיוור, סליקה או אחסון לענן?
התשובה הקצרה
בוחרים לפי תרחישי עבודה וראיות, לא לפי מצגת. מגדירים מראש נתונים, תפקידים, אינטגרציות, אבטחה, פרטיות, זמינות, יציאה ועלות כוללת; מדרגים כל ספק באותה מטריצה; בודקים עם מידע מלאכותי; ורק אחר כך חותמים ומעלים נתוני אמת.
תהליך בחירה בשבעה צעדים
- כותבים חמישה עד עשרה תרחישי אמת: קליטת תורם, שינוי הסכמה, ביטול הרשאה, החזר תשלום, יצוא מלא, שחזור ומחיקת אדם.
- מסמנים לכל תרחיש אילו נתונים נדרשים ומי רשאי לראותם.
- קובעים דרישות „חובה”, „חשוב” ו„יתרון” לפני פנייה לספקים.
- שולחים לכל ספק את אותו שאלון ודורשים מסמכים תומכים.
- עורכים הדגמה עם נתונים מלאכותיים ומבקשים מהספק לבצע את התרחישים, לא רק להציג שקפים.
- בודקים חוזה, נספח פרטיות, אזורים, ספקי משנה, תנאי יציאה ועלות כוללת.
- מפעילים פיילוט מוגבל, בודקים לוגים, הרשאות, יצוא ושחזור ורק אז מחליטים על מעבר.
מטריצת דרישות משותפת
| תחום | שאלות מכריעות | | --- | --- | | התאמה מקצועית | האם המערכת תומכת בתהליכי העמותה בלי לנהל מידע קריטי בהערות חופשיות או גיליונות צד | | בעלות וניהול | מי בעל החשבון הראשי, מי שולט בדומיין, מי יכול לייצא או למחוק, ומה קורה כשעובד עוזב | | הרשאות | תפקידים, הפרדה בין צפייה לעריכה/יצוא, MFA, SSO, גישה זמנית ותהליך ביטול | | תיעוד | לוגים לפעולות מנהל, יצוא, שינוי, מחיקה, כניסה וכשל; משך שמירה ויכולת מסירה | | פרטיות | מטרות, צמצום שדות, תקופת שמירה, זכויות, אזורים, ספקי משנה ומדיניות שימוש משני | | אבטחה | הפרדת לקוחות, הצפנה, חולשות, עדכונים, תמיכה, אירועים וראיות עצמאיות | | אינטגרציות | API, סודות, הרשאות אפליקציה, Webhooks, הגבלת IP, סביבת בדיקות ותיעוד שינויים | | רציפות | SLA, גיבוי, שחזור, RPO/RTO, יצוא בזמן השבתה ותוכנית ידנית חלופית | | יציאה | יצוא מלא וקריא, קבצים וקשרים, API, עלות, זמן, עזרה במעבר ואישור מחיקה | | מחיר | משתמשים, אחסון, הודעות, API, תמיכה, יצוא, סליקה, מטבע, הצמדה ועלות מעבר |
תקנות אבטחת המידע דורשות תחזוקה של מערכות, ניהול הרשאות, אימות, תיעוד ובקרות לפי רמת המאגר. המדריך הרשמי לתקנות ושאלון שרשרת האספקה יכולים להפוך את הטבלה לשאלון טכני מפורט, אך יש להתאים אותו לשירות.
דגשים ל־CRM ולמערכת דיוור
- הפרידו בין פרטי קשר, היסטוריית תרומה, העדפות דיוור, מידע רגיש והערות טיפול.
- ודאו שאפשר לתעד מקור מידע, מועד הסכמה, נוסח היידוע, הסרה והגבלת שימוש.
- בדקו הרשאות ליצוא המוני, חיפוש, פילוח וחיבור אפליקציות.
- בדקו אם ספק הדיוור או רכיב AI משתמשים בתוכן, ברשימות או בהתנהגות לצרכים שלהם.
- ודאו שאפשר למחוק או לתקן אדם בכל המערכות המקושרות ולא רק ב־CRM הראשי.
- אל תשתמשו בחשבון אישי של עובד כבעלים היחיד של המערכת.
אם מטרת העיבוד או סוג המקבלים משתנים מהותית, אין להניח שהסכמה ישנה מכסה את השימוש החדש. שתיקה אינה הסכמה, והיידוע צריך להיות ברור, נגיש וספציפי מספיק.
דגשים לענן ולאחסון קבצים
- הגדירו מראש בעלי תיקיות, קבוצות והרשאות ברירת מחדל.
- חסמו קישור ציבורי כברירת מחדל וקבעו תוקף לקישורים חיצוניים.
- בדקו היסטוריית גרסאות, שחזור, מחיקה, שיתוף חיצוני ולוגים.
- הפרידו תיקיות שכר, עובדים ומקבלי סיוע ממסמכים כלליים.
- ודאו שהגיבוי אינו רק סנכרון שמעתיק גם מחיקה או כופרה.
- בדקו איזה מידע נשאר במכשירי קצה, במטמון ובתיבות דוא״ל.
דגשים לסליקה
העדיפו, ככל שמתאים, הפניה או דף תשלום מאוחסן אצל ספק תשלומים על פני קליטת נתוני כרטיס במערכות העמותה. אל תשמרו מספר כרטיס מלא או CVV ב־CRM, בהערה חופשית, בדוא״ל או בטופס תמיכה. טוקן תשלום צריך להיות מוגבל למטרה, והגישה להחזרים ולביטולים צריכה להיות נפרדת ומתועדת.
יש לברר עם הסולק, ספק התשלומים והגורם שמקבל את דיווח ה־PCI מהו היקף PCI DSS המדויק ומהו שאלון ה־SAQ המתאים. גם בדף תשלום מוטמע יכולות לחול דרישות הגנה על סקריפטים בדף העמותה; הפניה מלאה לספק עשויה לשנות את ההיקף, אך מיקור חוץ אינו מבטל אוטומטית את כל החובות.
בנק ישראל תיאר סיכוני אבטחה, סייבר והמשכיות עסקית שנוצרים מריבוי הגורמים והקישוריות בשרשרת כרטיסי החיוב, וקרא לשחקנים לאמץ סטנדרטים משותפים. זהו אות סיכון רשמי חשוב, לא אישור לכך שספק מסוים מתאים לעמותה.
בדיקת סליקה צריכה לכלול גם:
- זהות הישות שמחזיקה כספים ומועד הזיכוי;
- התאמה בין עסקה, תרומה, קבלה, עמלה, זיכוי והחזר;
- תמיכה ב־3DS ובמנגנוני מניעת הונאה לפי הצורך;
- הרשאות לביטול, זיכוי ושינוי חשבון בנק;
- Webhooks חתומים, מניעת כפילות ויכולת התאוששות;
- זמינות בזמן קמפיין ותהליך ידני חלופי;
- יצוא לצורך הנהלת חשבונות וביקורת.
פונקציות AI „חבויות” בתוך מערכת אחרת
סיכום שיחה, דירוג תורם, כתיבת דיוור או חיפוש חכם הם עיבוד נוסף גם אם כפתור ה־AI נמצא בתוך ה־CRM. דרשו לדעת איזה מודל וספק משנה מופעלים, איזה מידע נשלח, האם נשמר לאימון או לבקרה אנושית, באיזה אזור, כיצד מכבים את הרכיב וכיצד מוחקים את הקלט והפלט. אל תאפשרו הפעלה אוטומטית על נתוני אמת בלי החלטה נפרדת.
דגלים אדומים בבחירה
- „כולם משתמשים בנו” במקום תשובה וראיה;
- אין חשבון ארגוני או אין MFA למנהלים;
- אין יצוא מלא לפני סיום חוזה;
- הספק רשאי לשנות מטרות או ספקי משנה בלי הודעה מעשית;
- הסמכה מוצגת בלי היקף, תאריך או שם השירות;
- נתוני לקוחות משמשים כברירת מחדל לאימון או לפרסום;
- אין התחייבות למחיקה מגיבויים או למסירת אישור;
- מחיר נמוך שמסתיר עלות API, יצוא, תמיכה או מעבר;
- פיילוט מחייב נתוני תורמים אמיתיים ללא צורך.
Q-195 — האם מותר להזין מידע אישי של תורמים, עובדים או מוטבים לכלי בינה מלאכותית?
התשובה הקצרה
אין היתר גורף ואין איסור גורף לכל מצב. מותר לעבד מידע אישי רק כאשר יש בסיס חוקי מתאים, המטרה והשימוש תואמים את מה שנמסר לאדם, המידע מצומצם לנדרש, הספק והעברה לחו״ל הוסדרו, והאבטחה והבקרה מתאימות לסיכון. מדיניות ברירת המחדל הבטוחה לעמותה היא: לא מזינים מידע אישי מזוהה או בעל רגישות מיוחדת לכלי AI שלא אושר ארגונית. לצורך ניסוח, סיכום או בדיקה משתמשים קודם במידע ציבורי, מלאכותי או מותמם.
רמזור מעשי לפני כל הזנה
| צבע | דוגמאות | פעולה | | --- | --- | --- | | ירוק | מידע ציבורי, טקסט כללי, תרחיש מלאכותי או מידע שהותמם באמת | אפשר להשתמש בכלי מאושר לפי מדיניות הארגון, בלי סודות | | צהוב | מידע מצומצם או מקודד שעדיין ניתן לקשר לאדם, או כלי ארגוני עם חוזה ובקרות | נדרש אישור בעל תפקיד, בדיקת מטרה, ספק, העברה, שמירה ופלט | | אדום | שם ומזהה, פרטי קשר, בריאות ורווחה, שכר, חשבון בנק, כרטיס, סיפור מוטב, תיק עובד, סיסמה או מידע חסוי | לא מזינים לכלי ציבורי או לא מאושר; בוחרים חלופה או תהליך מאושר ומוגן |
מידע מקודד אינו בהכרח אנונימי. אם העמותה או הספק יכולים לקשר את הקוד לאדם, הוא עדיין דורש הגנה. גם פלט AI יכול ליצור מידע אישי חדש באמצעות הסקה או הערכה.
שש שאלות שמכריעות אם השימוש מותר ומתאים
- מה המטרה? האם AI נחוץ, או שאפשר להשיג אותה בלי מידע אישי?
- מה הבסיס החוקי? האם קיימת הסכמה מדעת שמכסה את המטרה והמסירה, או סמכות אחרת בדין?
- מה המינימום? אילו פרטים אפשר להסיר, להכליל או להחליף במידע מלאכותי?
- מי הספק? האם החשבון ארגוני, האם הקלט משמש לאימון, מי בודק אותו, כמה זמן נשמר והאם אפשר למחוק?
- לאן המידע מגיע? אזורים, ספקי משנה, מודלים, תמיכה והעברות המשך.
- מה ייעשה בפלט? מי בודק דיוק והטיה, היכן הוא נשמר והאם הוא משפיע על זכות או החלטה מהותית?
אם אין תשובה מתועדת לאחת השאלות — לא מזינים נתוני אמת.
הסכמה ישנה אינה אישור אוטומטי ל־AI
הסכמה צריכה להיות מדעת, ברורה וחופשית. יש להציג את המטרות ואת סוגי המקבלים באופן שמאפשר להבין מה ייעשה במידע; ניסוח כללי מדי כגון „ספקי טכנולוגיה” עלול לא להספיק. שימוש חדש ומהותי, ובפרט טכנולוגיה חדשה בעלת סיכון, עשוי לחייב יידוע והסכמה חדשים כאשר זו העילה לעיבוד.
חובת היידוע בעת איסוף כוללת, בין היתר, האם המסירה חובה או רצונית ותוצאת אי־ההסכמה, זהות בעל השליטה ודרכי הקשר, המטרות, למי יימסר המידע ולאיזו מטרה, וזכויות עיון ותיקון. כלי הערכת הפרטיות הרשמי מדגיש גם צמידות מטרה, צמצום מידע ובדיקה של מערכות AI היכולות להשפיע על זכויות.
כלי צרכני הוא ספק חיצוני, לא „מחברת פרטית”
פתיחת חשבון אישי בכלי AI אינה הופכת אותו למערכת פנימית. לפני שימוש ארגוני צריך לבדוק:
- תנאי שימוש והסכם עיבוד נתונים;
- שמירת קלט, פלט ולוגים ומחיקה;
- שימוש לאימון, הערכת איכות או בדיקה אנושית;
- אפשרות לבטל אימון ושימוש משני באופן מחייב;
- אזורי עיבוד, ספקי משנה והעברה לחו״ל;
- הרשאות מנהל, MFA, SSO ויכולת ביקורת;
- טיפול באירוע, יצוא וסיום;
- הפרדת נתוני העמותה ממשתמשים אחרים.
אם הכלי מעבד מידע בעבור העמותה, חלות בדיקות הספק והחוזה; אם העיבוד בחו״ל, מתווספת בדיקת ההעברה.
איך מכינים טקסט ל־AI בלי לחשוף אדם
במקום:
„סכם את מצבה של רחל לוי, ת״ז..., אם חד־הורית מרחוב..., עם אבחנה..., שקיבלה מאיתנו...”
כותבים, אם ההקשר מאפשר:
„נסח סיכום כללי למקרה מלאכותי של הורה יחיד המבקש סיוע זמני. אל תוסיף עובדות. ציין אילו פרטים חסרים לבדיקה אנושית.”
מסירים שמות, מספרי זהות, כתובות, טלפונים, דוא״ל, מספרי חשבון וכרטיס, תאריכים מדויקים, מעסיק, מוסד, אבחנה, צירוף נדיר של מאפיינים וטקסט חופשי שמזהה בעקיפין. אחר כך בודקים שהשילוב שנותר אינו מאפשר זיהוי מחדש.
בקרה אנושית אינה רק הגהה
פלט AI עלול להיות שגוי, מומצא, מפלה או לחשוף מידע מהקלט. לפני שימוש:
- בודקים כל עובדה מול מקור עצמאי;
- לא מעתיקים פלט אוטומטית לתיק אדם;
- לא מאפשרים לכלי להכריע לבדו בזכאות לסיוע, קבלה לעבודה, משמעת, שכר או דירוג תורם;
- נותנים לאדם מוסמך אחריות ברורה והיכולת לדחות את ההמלצה;
- מתעדים כלי, גרסה, מטרה, קטגוריית מידע, אישור ובדיקה — בלי לשמור שוב מידע עודף;
- מדווחים מיידית על חשש לדלף או פלט שמכיל מידע אישי לא צפוי.
המדריך הממשלתי לשימוש אחראי ב־AI מציע משילות, סיווג סיכון, תיעוד, בקרה אנושית ותהליך תקריות. הוא נכתב למגזר הציבורי ולכן משמש כאן מקור לבקרות מומלצות, לא מקור לחובה אוטומטית על כל עמותה.
טיוטת הרשות להגנת הפרטיות מ־2025 מתייחסת במפורש להחלת הדין על מידע אישי שנקלט או נוצר במערכות AI, אך היא עדיין מסומנת „טיוטה”. לכן אין לבסס עליה לבדה קביעה מחייבת; החובות במדריך נשענות על החוק, התקנות, גילוי הדעת הסופי בנושא הסכמה וכלי הפרטיות העדכני. הטיוטה משמשת רק לאיתור סיכונים ולזהירות פרשנית.
מדיניות ארגונית מינימלית ל־AI
- רשימת כלים מאושרים ושימושים מותרים לכל כלי;
- איסור ברור על מידע אדום בכלי לא מאושר;
- בעל תפקיד שמאשר שימוש צהוב ושומר תיק החלטה;
- תהליך בדיקת ספק, חוזה והעברה לפני חיבור למערכת;
- חובת צמצום והתממה לפני קלט;
- בקרה אנושית והצלבת עובדות;
- תיעוד אירועים וערוץ דיווח;
- סקירה חוזרת עם שינוי מודל, תנאים, ספק משנה או מטרה;
- יכולת לעצור את השימוש ולמחוק מידע.
תיק החלטה קצר שאפשר להעתיק לכל ספק
| שדה | מה לרשום | | --- | --- | | בעלים עסקי | מי אחראי על המטרה, התקציב והתוצאה | | בעלים למידע | מי מאשר סוגי מידע, הרשאות ושמירה | | שירות ומטרה | מה המערכת עושה ומה היא אינה רשאית לעשות | | נושאי מידע | תורמים, עובדים, מתנדבים, חברים או מוטבים | | סוגי מידע | שדות רגילים, מידע בעל רגישות מיוחדת, קבצים וטקסט חופשי | | בסיס עיבוד | הסכמה, סמכות בדין או בסיס מתאים אחר | | זרימה | קליטה, עיבוד, אחסון, יצוא, גיבוי ומחיקה | | ספקים ואזורים | ספק ראשי, משנה, תמיכה, מודל ואזורים | | סיכון ובקרות | נזק אפשרי, צמצום, הרשאות, הצפנה, לוגים ורציפות | | חוזה | נספח מידע, העברה, אירוע, יציאה ופיקוח | | בדיקות | תרחישים מלאכותיים, יצוא, מחיקה, שחזור ולוגים | | החלטה | מאושר, מאושר בתנאים, פיילוט מוגבל או נדחה | | סקירה הבאה | תאריך ואירועים שמקדימים סקירה |
תוכנית יישום ל־30, 60 ו־90 יום
בתוך 30 יום
- עוצרים העלאת נתוני אמת לכלי ניסיון ו־AI לא מאושרים.
- ממפים ספקים, חשבונות מנהל, אזורים, ספקי משנה ואינטגרציות.
- מזהים מערכות שבהן נשמרים פרטי כרטיס, סיסמאות או מידע רגיש בהערות.
- ממנים בעלים עסקי ובעלים למידע לכל מערכת.
- מפעילים MFA ומבטלים חשבונות משותפים ככל האפשר.
בתוך 60 יום
- מדרגים ספקים לפי סיכון ומתחילים מהמערכות הרגישות.
- משלימים שאלוני ספק ונספחי תקנה 15.
- בודקים עילות והתחייבויות להעברה לחו״ל.
- מגדירים הרשאות, לוגים, שמירה ומחיקה.
- מתרגלים יצוא מלא ושחזור ומתקנים פערים.
בתוך 90 יום
- משלימים חוזים, ספקי משנה ותוכנית פיקוח.
- מעבירים סליקה למבנה שמצמצם חשיפה לנתוני כרטיס, לפי היקף PCI שאומת.
- מפרסמים מדיניות AI ומדריכים עובדים ומתנדבים.
- בודקים תהליך יציאה אמיתי מספק אחד לפחות.
- קובעים סקירה שנתית ומנגנון סקירה מיידית בשינוי או באירוע.
מקורות רשמיים ומקצועיים
- חוק הגנת הפרטיות (תיקון 13) ותחילתו: .
- תקנות הגנת הפרטיות (אבטחת מידע): .
- שאלות ותשובות רשמיות על תקנות אבטחת מידע: .
- כלי הרשות להערכת סיכוני פרטיות: .
- שאלות ותשובות על תיקון 13: .
- המדריך ליישום תקנות אבטחת מידע: .
- מדריך תקנה 15 המעודכן לאחר תיקון 13: .
- גילוי דעת סופי בנושא הסכמה: .
- גילויי דעת להעברה לחו״ל לפי תקנות 2(4) ו־3: .
- שאלון ספקים של מערך הסייבר הלאומי: .
- טיוטת הנחיית פרטיות ו־AI, המשמשת רק כרקע לא מחייב: .
- מדריך ממשלתי לשימוש אחראי ב־AI, כבקרת סיכון מומלצת: .
- הודעת בנק ישראל על סטנדרטים בשרשרת כרטיסי חיוב: .
- ספריית PCI DSS 4.0.1 והבהרת SAQ A לדפי תשלום: .
מתי חייבים בדיקה פרטנית
פונים לייעוץ משפטי, פרטיות, אבטחת מידע או סליקה כאשר נשקל שימוש במידע בעל רגישות מיוחדת בהיקף משמעותי, מאגר ברמת אבטחה בינונית או גבוהה, העברה מורכבת בין מדינות, שינוי מטרה, כלי AI המשפיע על זכויות, סליקה שבה אתר העמותה נוגע בנתוני כרטיס, מחלוקת עם ספק על מחיקה או אירוע, או התקשרות שלא ניתן לתקן בה את תנאי הספק.