Privacy policy

מדיניות פרטיות — Do4Brain (טיוטת עבודה)

⛔ טיוטה לבדיקת עורך/ת דין — אינה מסמך משפטי ואין להסתמך עליה או לפרסמה. נוצרה: 05/08/2026 · מבוססת על התנהגות המערכת בפועל, לא על ייעוץ משפטי.

גרסת טיוטה: 0.1 · נכתבה על ידי: סוכן AI, כהכנה לעורך/ת דין — לא כתחליף לו/לה. מבוססת על קריאה בפועל של: prisma/schema.prisma · spec/agent/systems/security-privacy.md · packages/domain/src/profile/ (consent.ts, account-deletion.ts, personal-details.ts) · apps/api/src/app/v1/account/ · _bmad-output/implementation-artifacts/launch/store-r05-data-safety-answers.md · _bmad-output/implementation-artifacts/reviews/security-audit.md · _bmad-output/implementation-artifacts/ops/00-server-requirements.md ו-05-retention-policy.md · PROJECT-STATE.md (עדכון 05/08/2026). מצב המערכת נכון למועד הכתיבה: בפיתוח פעיל, טרם הושקה למשתמשי קצה. חלק מהמנגנונים המתוארים כאן כמדיניות מיושמים ברמת התכן/הקוד אך טרם רצים באופן אוטומטי בסביבת ייצור — כל מקרה כזה מסומן במפורש.

0. מי אנחנו

Do4Brain ("השירות", "האפליקציה", "אנחנו") הוא אפליקציית אימון קוגניטיבי יומי למבוגרים, המבוססת על מאגר משימות שחיבר פרופ' יוסי חלמיש. השירות מופעל בידי:

לְמַלֵּא — שם החברה המלא הרשום ברשם החברות · ח.פ./ע.מ. לְמַלֵּא · כתובת רשומה לְמַלֵּא · כתובת לפניות בנושא פרטיות: לְמַלֵּא

מדיניות זו חלה על אפליקציית המובייל (iOS ו-Android). כתובת האינטרנט do4brain.com המיועדת לאתר תדמית טרם נרשמה/הוסדרה נכון למועד הכתיבה (PROJECT-STATE.md) — כשהאתר יעלה לאוויר, ככל הנראה יידרש נספח נפרד למדיניות זו בנושא עוגיות ומעקב באתר, שאינו קיים עדיין ברמת הקוד.

1. אילו נתונים אנחנו אוספים, ומתי

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

1.1 בהרשמה (מסך פרטים אישיים)

1.2 תוך כדי שימוש בשירות

1.3 נוצר אוטומטית על ידי המערכת

1.4 מה אינו נאסף

בבדיקת קוד האפליקציה בפועל (חיפוש אחר ספריות צד-שלישי בקוד הלקוח) לא נמצאה ולו ספריית מעקב/אנליטיקה אחת — לא Sentry, לא Crashlytics, לא Firebase Analytics, לא Mixpanel/Amplitude, לא רשת פרסום, ולא מזהה פרסום כלשהו. בהתאם, האפליקציה אינה אוספת: מיקום (מדויק או מקורב) · אנשי קשר · תמונות/וידאו/אודיו · קבצים · יומן פגישות · היסטוריית גלישה או חיפוש · רשימת אפליקציות מותקנות · פרטי אמצעי תשלום (הרכישה עוברת דרך Apple/Google בלבד — ראו סעיף 7) · מידע רפואי, ביומטרי, גנטי, על נטייה מינית, דעה פוליטית או אמונה דתית · תוכן חופשי שהמשתמש כותב (אין שדה טקסט חופשי באפליקציה כולה — משימה היא טקסט קבוע מראש וכפתור "ביצעתי") · דוחות קריסה או טלמטריית ביצועים.

⚠️ הסתייגות לגבי כתובות IP: תיקון 13 מרחיב את הגדרת "מידע אישי" במפורש לכלול כתובות IP, מיקום גיאוגרפי ומזהי מכשיר/מקוונים. בעוד שאין במסד הנתונים של האפליקציה טבלה או עמודה הרושמת כתובות IP, סביר שברמת התשתית (שרתי הרשת, ספק האחסון) כתובות IP נרשמות ביומני גישה סטנדרטיים לצורכי אבטחה ותפעול שוטף — כפי שנהוג בכל שרת אינטרנט. הדבר לא מופה במפורש במסמכי הפרויקט שנבדקו, ומחייב בדיקה ייעודית לפני פרסום המדיניות (ראו שאלה 3 בסוף המסמך).

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

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

⚠️ הערה לגבי שדה המגדר: הרשימה הסגורה של "מידע רגיש" באפל (Sensitive Info) אינה כוללת מגדר, אך הסיווג של אפל אינו קובע את החובה המשפטית הישראלית. תחת חוק הגנת הפרטיות (גם לפני וגם אחרי תיקון

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

המטרה שלשמה הוא נאסף כאן צרה ומוגדרת (התאמת נוסח פנייה בעברית בלבד) — ראו שאלה 4 בסוף המסמך.

3. איך ההסכמה מתועדת

בניגוד לתבנית נפוצה של "וי בודד" (accepted_terms: true/false), המערכת בפועל כורכת כל הסכמה למזהה מדויק של מסמך — סוג (תנאי שימוש / מדיניות פרטיות), גרסה ושפה — ולא רק לעצם ה"הסכמתי". ההסכמה נכתבת באותה טרנזקציה עם יצירת החשבון, כך שלא יכול להיווצר חשבון פעיל ללא רשומת הסכמה תואמת. אם המשתמש מחזיק מסך פתוח בזמן שגרסת המסמך מתעדכנת, המערכת מזהה זאת ומציגה לו את הנוסח העדכני לפני יצירת החשבון — כלומר לעולם אינו "נכרך" בשוגג לנוסח שאינו בתוקף.

כרגע נדרשת הסכמה מפורשת לשני מסמכים בלבד בעת ההרשמה: תנאי שימוש ומדיניות פרטיות. הצהרת הנגישות (המסמך השלישי) היא הצהרה עצמאית שאינה טעונה אישור/הסכמה בתיבת סימון, כמקובל.

⚠️ פער שזוהה: לא נמצא מנגנון "הסכמה מחדש" יזום למשתמשים קיימים כאשר נוסח מדיניות מתעדכן לאחר שכבר נרשמו. מנגנון ההסכמה-לגרסה חל בפועל בעת ההרשמה בלבד. ראו שאלה 7.

4. תקופת שמירת המידע

⚠️ הערה חשובה: האפיון המוצרי מחייב שלכל טבלת יומן (התראות, יומני SMS, יומני ביקורת) תהיה מדיניות שמירה מוגדרת, אך אינו קובע את המספרים עצמם — קביעתם הוגדרה במפורש כהחלטת פרטיות שצריכה להתקבל ולהופיע במדיניות זו. הטבלה שלהלן משקפת הצעה פנימית של צוות הפיתוח (ops/05-retention-policy.md), שטרם אושרה לא על ידי יניב ולא על ידי ייעוץ משפטי, ומובאת כאן כנקודת מוצא לדיון:

⛔ פער תפעולי מהותי, שחייב להיסגר לפני שהמדיניות מתפרסמת בפועל: בדיקת קוד שבוצעה בפרויקט מצאה שאף אחת משלוש טבלאות היומן הרגישות ביותר (יומני SMS, יומני ביקורת, היסטוריית התראות) אינה כפופה כרגע למחיקה אוטומטית בקוד הרץ — המספרים לעיל הם הצעה שטרם מומשה כתהליך פועל. אין להתחייב במדיניות הפרטיות למספר שאינו נאכף בפועל. ראו גם סעיף 8 להמשך הפער המקביל במחיקת חשבונות.

5. מחיקת חשבון

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

1. מיידי: החשבון הופך לבלתי-נגיש למשתמש; כל טוקני ההתראות והחיבורים הפעילים מבוטלים באותה

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

1. חלון חרטה של 30 יום: הנתונים אינם נמחקים פיזית באותו רגע אלא מסומנים כ"מחוקים" (מחיקה רכה),

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

1. טיהור סופי: לאחר 30 יום, כל הנתונים אמורים להימחק לצמיתות ממסד הנתונים.
2. תיעוד בקשת המחיקה עצמה: נשמרת רשומה שבקשת מחיקה הוגשה במועד מסוים — ללא כל פרט מזהה (לא

טלפון, לא שם, לא אימייל) — כך שהשירות יכול להוכיח עמידה בחובת התיעוד מבלי לסתור את הבטחת המחיקה המלאה.

1. הרשמה מחדש עם אותו מספר טלפון לאחר מחיקה מתאפשרת מיידית ואינה ממתינה לחלון ה-30 יום.

⛔ פער קריטי שחייב טיפול לפני השקה, ולפני שההבטחה הזו מתפרסמת למשתמשים: בדיקת קוד מצאה שהפונקציה שמבצעת את הטיהור הסופי לאחר 30 יום קיימת ונבדקת, אך אינה מופעלת על ידי שום תהליך רץ בפועל — כלומר נכון למועד הכתיבה, המערכת מבטיחה למשתמש תאריך טיהור סופי, אך שום דבר לא באמת מוחק את הנתונים בפועל במועד המובטח. זהו פער תפעולי (חסר "קורא" לפונקציה קיימת), לא פער בעיצוב — אך הוא אומר שהנוסח בסעיף זה אינו נכון עדיין במציאות התפעולית, ואסור לפרסם התחייבות זו למשתמשים לפני שהוא נסגר. ראו דיווח מרוכז בתשובתי ליניב.

6. זכויותיכם, ואיך מממשים אותן בפועל באפליקציה

חשוב: קובץ הייצוא של "זכות העיון" אינו כולל טוקני גישה (טוקן פוש, טוקן רענון, גיבוב קוד האימות) — משום שאלה אמצעי גישה טכניים ולא "מידע על" המשתמש, וחשיפתם הייתה עלולה לשמש להשתלטות על החשבון ולא לממש את הזכות.

7. עם מי המידע משותף

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

כל אחד מהגורמים לעיל הוא "ספק שירות" המעבד מידע בשמנו לפי הוראותינו, ולא צד שמקבל מידע לשימושו העצמאי. חתימת הסכמי עיבוד נתונים (DPA) מול כל ספק טרם אומתה במסמכי הפרויקט — ראו שאלה 9.

8. העברת מידע אל מחוץ לישראל

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

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

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

• סביבת הייצור המתוכננת אמורה לעבור לשרת שבניהול החברה עצמה ("שרת החברה") — **מיקומו הפיזי

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

• Firebase Cloud Messaging (גוגל) מפעילה תשתית גלובלית; טוקן ההתראה ותוכן ההודעה עוברים דרך

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

• 019 (ספק ה-SMS) הוא ספק ישראלי — לא צפויה סוגיית העברה בין-לאומית ביחס אליו.

מסקנת ביניים (טעונה אישור עורך/ת דין): נדרשת הבהרה מפורשת בגוף המדיניות לגבי מיקום האחסון בפועל ברגע הפרסום, ולגבי מנגנון ההעברה הנשען עליו (החלטת נאותות / הסכם / הסכמה) — ראו שאלה 10.

9. אבטחת מידע

תיאור זה מוגבל למה שאומת בפועל בביקורת קוד שבוצעה בפרויקט (05/08/2026), ואינו כולל הבטחות שלא אומתו:

מה שכן מיושם ואומת:

• כל תעבורת הרשת בין האפליקציה לשרת מתבצעת דרך HTTPS בלבד; השרת שולח כותרת אבטחה (HSTS) בכל

תשובה, ואינו מכיל אף כתובת לא-מוצפנת (http://) בקוד המקור.

• קוד האימות אינו נשמר בטקסט גלוי — הוא נשמר כגיבוב (hash) קריפטוגרפי עם "פלפל" (pepper) בצד השרת.
• כל נתיב API דורש אימות; משתמש רואה אך ורק את נתוניו שלו; לכל בקשת אדמין יש בדיקת הרשאה מול תפקידו,

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

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

⚠️ מה שעדיין לא ניתן לאשר כמיושם, ולכן לא ייכלל כהבטחה במדיניות עד לבירור:

• הצפנה "במנוחה" (at rest) של מסד הנתונים והגיבויים — לא אותרה הגדרה מפורשת לכך בתשתית שנבדקה.

נוסח קיים באפליקציה כיום (טרם פורסם) כולל את הביטוי "מוצפן... באחסון" — ביטוי זה אינו מאומת ואין לכלול אותו במדיניות הסופית ללא אימות טכני.

• גיבויים אוטומטיים — לא אותר בפועל מנגנון גיבוי רץ; זו עדיין עבודת תשתית פתוחה שתלויה בהחלטת

אירוח סופית.

• הצהרת "בדיקת אבטחה עצמאית מול תקן גלובלי" — לא בוצעה, ואין לרשום אותה כאילו בוצעה.

10. קטינים

השירות מיועד לגילאי 18 ומעלה בלבד, ובפועל מתוכנן ובנוי לקהל 60+. בעת ההרשמה נאכף טווח גיל של 18–110 שנים, מבוסס על שנת הלידה שהמשתמש מזין (ללא אימות מסמך מזהה חיצוני). ראו שאלה 5 לגבי מידת מספיקותה המשפטית של הצהרה עצמית בלבד.

11. עוגיות ומעקב

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

12. רישום מאגר מידע ומינוי ממונה

שני נושאים חוקיים מובהקים, שדורשים הכרעת עורך/ת דין ואינם ניתנים להכרעה הנדסית:

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

הרישום צומצמה לגופים ציבוריים ולמאגרים של 10,000+ נפשות שמטרתם העיקרית היא העברת מידע לאחרים (מתווכי מידע). Do4Brain, ככל שידוע, אינו גוף ציבורי ואינו מתווך מידע — אך יש לאשר זאת רשמית מול עורך/ת דין, בפרט אם/כאשר בסיס המשתמשים חוצה 10,000.

1. חובת מינוי ממונה על הגנת הפרטיות (PPO) — חלה על גופים ציבוריים, מתווכי מידע, וגופים שמעבדים

מידע רגיש בהיקף משמעותי. לפי המיפוי בסעיף 1, לא זוהה איסוף של קטגוריות "מידע רגיש" המובהקות (בריאות, ביומטריה, גנטיקה, נטייה מינית, דעה פוליטית). ככל שכן יידרש בסיס משתמשים גדול מספיק, ייתכן גם שיחול חיוב נפרד ושונה: מינוי "ממונה אבטחת מידע" לפי תקנות אבטחת מידע 2017 (רמת אבטחה "בינונית" — 10,000+ רשומות או מידע רגיש). שני המינויים שונים במהותם ובתנאי ההפעלה שלהם.

13. עדכונים למדיניות זו

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

14. פניות, תלונות ורשות הגנת הפרטיות

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

שאלות לעורך/ת הדין

1. פרטי החברה — מהו השם המשפטי המלא, ח.פ./ע.מ., והכתובת הרשומה שיש לציין כ"מפעיל השירות"? (כל

מקום המסומן __לְמַלֵּא__ במסמך)

1. חובת רישום מאגר מידע (סעיף 12.1) — האם הפעילות המתוארת כאן פטורה מרישום בוודאות, לפי המצב

המשפטי הנוכחי, גם כשמספר המשתמשים יגדל משמעותית?

1. כתובות IP ברמת התשתית (סעיף 1.4) — עד כמה יש למפות ולתעד את שרשרת רישום כתובות ה-IP ביומני

השרת/הרשת, ולקבוע לה מדיניות שמירה נפרדת, לאור ההרחבה המפורשת של תיקון 13 להגדרת "מידע אישי"?

1. סיווג שדה המגדר (סעיף 2) — האם יש לסווגו כ"מידע רגיש" בהקשר הישראלי (להבדיל מהסיווג של אפל),

ואם כן — אילו חובות אבטחה/גילוי מוגברות חלות עליו בפועל?

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

כדי לבסס הגבלת גיל 18+, נוכח קהל היעד המוצהר (60+)?

1. משכי שמירת המידע (סעיף 4) — אילו משכים סופיים נכונים לכל שורה בטבלה, לאור עקרון "לא יותר

מהנדרש למטרה" שבתיקון 13? בפרט: יומן ההתראות (הנושא תוכן הודעה בפועל) ויומן הביקורת.

1. הסכמה מחדש למשתמשים קיימים (סעיפים 3, 13) — כאשר מדיניות הפרטיות/תנאי השימוש מתעדכנים

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

1. ספק הדוא"ל התפעולי (Postmark) — האם יש לוודא ולקבוע במדיניות פנימית שדוחות/ייצואים המכילים

נתוני משתמשי-קצה ברמת הפרט לעולם לא ייצאו דרך ערוץ דוא"ל זה, כדי לשמור על הקביעה ש"אין דוא"ל למשתמשי קצה"?

1. הסכמי עיבוד נתונים (DPA) — האם יש/צריך להיות הסכם עיבוד נתונים חתום מול כל אחד מהספקים

(019, Google/Firebase, Postmark), כתנאי להצהרה שהמידע "אינו משותף" עם צד שלישי במובן החוקי?

1. מיקום שרת הייצור והעברת מידע לחו"ל (סעיף 8) — כיצד יש לנסח את הסעיף כל עוד מיקום שרת הייצור

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

1. זכות העיון ללא מסך באפליקציה (סעיף 6) — האם קיום הזכות ברמת ה-API בלבד (ללא ממשק משתמש

ייעודי) מספק מבחינה משפטית, או שנדרש להוסיף מסך לפני שהמדיניות מפורסמת?

1. הפער בטיהור הנתונים אחרי 30 יום (סעיף 5) — עד כמה מותר/נכון לפרסם מדיניות שמבטיחה טיהור

תוך 30 יום, כאשר נכון לכתיבת מסמך זה התהליך האוטומטי שמבצע את הטיהור אינו מופעל בסביבת הייצור? (זהו סעיף שיניב מטפל בו כפער תפעולי בנפרד — אך יש חשיבות לדעת אם מבחינה משפטית מותר להתחייב לפני שהמנגנון פעיל בפועל, או שיש לנסח בזהירות רבה יותר עד לסגירתו)

1. רמת אבטחה לפי תקנות 2017 (סעיף 12.2) — איזו רמת אבטחה (בסיסית/בינונית/גבוהה) חלה על המערכת

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