תיקון 13 לחוק הגנת הפרטיות והאפליקציה שה-AI בנה
מאת חן רז · פורסם:
בשנה האחרונה חוזר אליי אותו סיפור בגרסאות שונות: לעסק יש טופס, אזור אישי או אפליקציה קטנה שנבנו ברובם בעזרת כלי AI. זה עובד. לקוחות ממלאים שם שם מלא, טלפון, מייל, לפעמים גם מספר תעודת זהות או פרטי הזמנה. ואז מגיעה השאלה שאף אחד בצד של העסק לא יודע לענות עליה: מה בעצם קורה למידע הזה אחרי שלוחצים "שלח"?
עד לא מזמן זו הייתה שאלה טכנית שאפשר היה לדחות. מאז שתיקון 13 לחוק הגנת הפרטיות נכנס לתוקף ב-14 באוגוסט 2025, היא גם שאלה של חשיפה משפטית.
הפוסט הזה לא מסביר את החוק. את זה עושים משרדי עורכי דין, והם עושים את זה טוב ממני. אני רוצה לענות על מה שנופל בין הכיסאות: אם המידע של הלקוחות שלכם יושב במערכת שנכתבה ברובה על ידי מודל שפה, מה צריך להיות שם בפועל, איפה מערכות כאלה נוטות ליפול, ומה אפשר לבדוק בלי לדעת לקרוא קוד.
הבהרה חשובה: אני מפתח, לא עורך דין. כל מה שכתוב כאן הוא הסבר הנדסי של דרישות טכניות. שאלות כמו האם החוק חל עליכם, באיזו רמת אבטחה אתם מסווגים ומה החשיפה שלכם בפועל הן שאלות משפטיות, ויש להפנות אותן לעורך דין שמתמחה בפרטיות ובהגנת מידע.
מה בעצם השתנה בתיקון 13 לחוק הגנת הפרטיות?
זו הנקודה שהכי הרבה בעלי עסקים מפספסים: החובה לאבטח מאגר מידע אישי היא לא חדשה. תקנות הגנת הפרטיות (אבטחת מידע) קיימות מאז 2017, והן כבר אז דרשו ניהול הרשאות, תיעוד, נהלים וגיבוי. מה שהשתנה הוא לא רשימת הדרישות, אלא מה קורה כשלא עומדים בהן.
תיקון 13, שאושר בכנסת ב-2024 ונכנס לתוקף באוגוסט 2025, נותן לרשות להגנת הפרטיות סמכויות פיקוח, בירור ואכיפה מנהלית, ובראשן היכולת להטיל עיצומים כספיים. במילים פשוטות: לתקנות שקיימות כבר שנים יש עכשיו שיניים.
וזה לא תיאורטי. ביולי 2026 הטילה הרשות להגנת הפרטיות עיצום כספי ראשון מסוגו מאז כניסת התיקון לתוקף, בסך של כ-256 אלף ש"ח, על גוף שגילה תקלה שאפשרה חשיפת מידע רגיש ולא דיווח עליה מיד. שימו לב מה בדיוק הוליד את העיצום: לא הפריצה עצמה, אלא הפער בין הרגע שבו הבעיה התגלתה לרגע שבו היא דווחה.
לגבי הסכומים והמדרגות עצמם - הם נגזרים מסוג ההפרה, מהיקף המידע וממחזור הפעילות, וזו בדיוק הנקודה שבה צריך עורך דין ולא מפתח. אני לא הולך לצטט כאן טבלת קנסות.
על מי זה חל, וגם על עסק קטן?
כדאי להפריד בין שתי שכבות שנוטות להתערבב בשיח:
שכבה ראשונה: חובות רישום ומינוי ממונה. החובה למנות ממונה על הגנת הפרטיות (DPO) והחובה לרשום מאגר חלות על גופים ציבוריים, על גופים שסוחרים במידע אישי בהיקף גדול ועל מי שמעבד מידע רגיש בהיקף ניכר. עסק קטן טיפוסי עם רשימת לקוחות לא נמצא שם.
שכבה שנייה: חובות אבטחת המידע. אלה חלות על מי שמחזיק מאגר מידע אישי, בלי קשר לגודל העסק. זו השכבה שרלוונטית כמעט לכל עסק שיש לו טופס באתר, מערכת הזמנות או אזור לקוחות. זו גם השכבה שנוגעת ישירות בקוד.
התקנות מגדירות רמות אבטחה, מהמאגר שמנוהל בידי אדם יחיד ועד רמה גבוהה, וככל שהרמה עולה הדרישות מחמירות. הסיווג מושפע מסוג המידע (מידע רפואי, פיננסי או ביומטרי מעלה את הרמה), ממספר האנשים שהמאגר מכיל וממספר בעלי ההרשאה במערכת. באיזו רמה אתם נמצאים זו שאלה משפטית, לא הנדסית, ואת התשובה עליה תקבלו מעורך דין או מיועץ פרטיות.
מה שכן אפשר לומר בביטחון: בכל אחת מהרמות, הדרישות מתורגמות למשהו שצריך להיות קיים בתוך המערכת עצמה.
| הדרישה בתקנות | איך זה נראה במערכת בפועל |
|---|---|
| מסמך הגדרות המאגר | מיפוי כתוב: איזה מידע נאסף, מאיפה הוא מגיע, לאן הוא עובר, ומי אחראי עליו |
| נוהל אבטחת מידע | מסמך שמגדיר מי רשאי לגשת למה, ומה עושים כשמשהו משתבש |
| הרשאות גישה לפי תפקיד | לכל משתמש רק ההרשאות שהתפקיד שלו באמת מחייב, עם מרשם מעודכן של מי מורשה |
| בקרה ותיעוד גישה | רישום אוטומטי של מי ניגש למידע, מתי, ומה עשה. ברמות הבינונית והגבוהה התקנות דורשות לשמור את הרישום הזה תקופה ממושכת |
| תיעוד אירועי אבטחה | תיעוד של כל אירוע חריג, ודיווח מיידי לרשם על אירוע חמור |
| גיבוי ושחזור | גיבוי תקופתי שבאמת בדקתם שאפשר לשחזר ממנו |
| הפרדת מערכות | המאגר מופרד באופן סביר משאר מערכות המחשוב של העסק |
קראו את העמודה הימנית ואז תסתכלו על המערכת שלכם. כמה מהשורות האלה קיימות שם?
למה דווקא קוד שנכתב בעזרת AI נופל בדרישות האלה?
חשוב לומר את זה בלי דרמה: קוד שנכתב בעזרת מודל שפה הוא לא קוד גרוע מטבעו. אני עצמי משתמש בכלים האלה בעבודה יומיומית, והם חוסכים זמן אמיתי. הבעיה היא לא איכות הקוד, אלא מה שנעלם מהתהליך.
מודל שפה מייצר קוד שעונה על מה שביקשתם. ביקשתם טופס שמקבל פרטי לקוח ושומר אותם - תקבלו בדיוק את זה, והוא יעבוד. מה שלא ביקשתם, ולרוב גם לא ידעתם לבקש, לא יופיע: בדיקת הרשאה בכל נקודת קצה, הפרדה בין מה שמשתמש אחד רשאי לראות למה שמשתמש אחר רשאי, רישום גישה, מסלול מחיקה, ניהול מסודר של מפתחות. המודל לא יודע איזה מידע אתם שומרים בפועל, באיזו מדינה אתם פועלים או איזו רגולציה חלה עליכם, והוא לא יעצור באמצע כדי לשאול.
בפיתוח רגיל, מישהו בשרשרת שואל את השאלות האלה. כשהשרשרת מתקצרת לאדם אחד שמנסח בקשה בשפה חופשית, השאלות פשוט לא נשאלות.
זו לא הערכה שלי בלבד. העיתונות הישראלית כיסתה את הנושא לא מעט. אתר אנשים ומחשבים דיווח על פרויקט מחקר שעוקב אחרי חולשות אבטחה שמקורן בקוד שנוצר בכלי AI ומצא עשרות חולשות מתועדות (CVE) בחודש בודד, כשהחוקרים עצמם מעריכים שהמספר האמיתי גבוה בהרבה, פשוט משום שרוב הקוד הזה לא נבדק בכלל. הכיסוי הישראלי בנושא מצביע שוב ושוב על אותם דפוסים: מפתחות שנשארים בתוך הקוד, נקודות קצה פתוחות, ופרויקטים שלמים שעולים לאוויר בלי שאף אחד קרא אותם.
איפה בדיוק אפליקציות שנבנו בעזרת AI נוטות ליפול?
אלה הדפוסים שאני פוגש הכי הרבה בפועל. לא כולם יופיעו אצל כולם, אבל אם משהו ברשימה מרגיש לכם מוכר, שווה לבדוק.
מפתחות וסיסמאות בתוך הקוד
מפתח API, סיסמת מסד נתונים או טוקן של שירות חיצוני שנכתבו ישירות בתוך קובץ הקוד במקום בקובץ הגדרות מוגן. אם הקוד הועלה אי פעם למאגר ציבורי, אלה פרטים שנחשפו. גם מאגר פרטי הוא בעיה, כי כל מי שקיבל גישה זמנית לפרויקט קיבל איתה את המפתחות.
נקודות קצה בלי בדיקת הרשאה
זה הכשל השקט והנפוץ ביותר. למערכת יש כתובת שמחזירה רשימת לקוחות או פרטי הזמנה. במסך היא מוצגת רק אחרי התחברות, אבל הכתובת עצמה לא בודקת מי שואל. מי שמנחש או מגלה אותה מקבל את המידע בלי להתחבר. בהדגמה שרצה על מחשב אחד זה לא מפריע לאף אחד, ולכן זה גם לא נבנה אחרת.
הרשאה רחבה מדי למסד הנתונים
האפליקציה מתחברת למסד הנתונים עם משתמש שיש לו הרשאות מלאות, כולל מחיקת טבלאות, גם כשהיא רק צריכה לקרוא ולכתוב שורה. זה נוח בפיתוח וזה בדיוק מה שהתקנות מבקשות למנוע כשהן דורשות הרשאות לפי תפקיד.
אין תיעוד גישה
אין רישום של מי צפה במידע ומתי. זו לא רק דרישה בתקנות ברמות מסוימות, זו גם הסיבה שאפשר בכלל לענות על השאלה "מה נחשף ולמי" כשקורה אירוע. בלי רישום, גם אחרי שגיליתם בעיה אין דרך לדעת את היקפה.
אין מסלול למחיקה או לתיקון
לקוח מבקש שתמחקו את הפרטים שלו. אתם מוחקים אותו מהמסך. הוא נשאר בטבלת ההזמנות, ביומן המערכת, ברשימת הדיוור ובגיבוי מלפני שבוע. מערכות שנבנו במהירות כמעט אף פעם לא נבנות עם מסלול מחיקה אמיתי, כי אף אחד לא ביקש אחד.
מידע שעובר לשירותים חיצוניים
טופס ששולח את התוכן שלו לשירות מייל, לכלי אנליטיקה, למערכת דיוור או למודל שפה חיצוני. כל אחד מהם הוא עוד גורם שמחזיק את המידע של הלקוחות שלכם. השאלה הראשונה היא האם אתם בכלל יודעים מי הם, והשנייה היא מה נשלח לשם בפועל.
אין גיבוי, ואין תהליך לאירוע
שתי שאלות שאפשר לשאול עכשיו: מתי בפעם האחרונה מישהו שחזר מהגיבוי כדי לוודא שהוא עובד, ומי מקבל הודעה כשהמערכת נשברת בשתיים בלילה. אם התשובה לשתיהן היא שקט, אין תהליך. וכפי שהעיצום מיולי 2026 ממחיש, ההיבט של הדיווח והתגובה הוא לא פחות חשוב מההיבט של המניעה.
מה אפשר לבדוק לבד בעשר דקות?
אף אחד מהבדיקות האלה לא דורש לדעת לקרוא קוד. הן לא מספיקות, אבל הן מוצאות הרבה.
- חפשו סודות בקוד. בקשו גישה לקוד וחפשו בו את המחרוזות
api_key,apiKey,password,secret,token. אם משהו מהם מופיע עם ערך אמיתי לידו ולא כהפניה לקובץ הגדרות, זו נורה אדומה. - בדקו אם המאגר ציבורי. אם הקוד יושב ב-GitHub או בשירות דומה, ודאו שהוא מוגדר כפרטי, ושאלו מי עוד יש לו גישה אליו היום.
- פתחו את כתובת המידע בחלון גלישה בסתר. בקשו את הכתובת שממנה המסך מושך את רשימת הלקוחות, והדביקו אותה בחלון פרטי בלי להתחבר. אם קיבלתם נתונים, יש לכם נקודת קצה פתוחה.
- בקשו רשימת בעלי הרשאה. מי בדיוק יכול לגשת היום למסד הנתונים ולממשק הניהול. כולל ספקים, פרילנסרים ומי שעזב.
- שאלו על מחיקה. "לקוח ביקש שנמחק את כל הפרטים שלו. מה התהליך, ומה נשאר אחריו?" תשובה מגומגמת היא תשובה.
- שאלו על גיבוי. מתי בוצע הגיבוי האחרון, איפה הוא נשמר, ומתי בפעם האחרונה מישהו שחזר ממנו בהצלחה.
- בדקו HTTPS. כל עמוד שיש בו טופס חייב להיטען בכתובת
httpsעם מנעול סגור בדפדפן. זו הבדיקה הקלה ביותר ברשימה והיא עדיין נכשלת לפעמים.
מה אי אפשר לבדוק לבד, ולמה?
זה החלק שחשוב לומר בכנות, כי הרשימה למעלה עלולה ליצור תחושת ביטחון מוגזמת.
- האם נקודת קצה מסוימת דולפת בין משתמשים. לפעמים ההרשאה קיימת אבל שגויה, כך שמשתמש אחד רואה נתונים של אחר. את זה מגלים רק בקריאת הלוגיקה או בבדיקה מכוונת.
- חולשות הזרקה. שדה טופס שמאפשר לשלוח פקודה למסד הנתונים במקום טקסט. זה לא נראה שונה מבחוץ.
- ספריות צד שלישי פגיעות. כל פרויקט נשען על עשרות רכיבים חיצוניים, וחלקם מתיישנים לחולשות ידועות. את זה בודקים בכלים, לא בעין.
- מה באמת נשלח החוצה. ההבדל בין "אנחנו שולחים את המייל לשירות הדיוור" ל"אנחנו שולחים את כל תוכן הטופס" מתגלה רק כשמסתכלים בתעבורה.
- האם התיעוד שקיים עונה על הדרישה. יש הבדל בין קובץ לוג שנכתב אגב לבין רישום גישה מסודר שנשמר לתקופה הנדרשת.
מה לבקש ממי שבנה לכם את המערכת?
זו הרשימה שאני ממליץ לשלוח כמו שהיא, בין אם בנה אתכם פרילנסר, סוכנות, או שאתם עצמכם בניתם עם כלי AI ורוצים לדעת מה חסר:
- מיפוי כתוב של המידע האישי: איזה שדות נאספים, איפה הם נשמרים, וכמה זמן.
- רשימת נקודות הקצה של המערכת, ולצד כל אחת מי מורשה לגשת אליה ואיך נאכפת ההרשאה.
- אישור שאין סודות בקוד, ושכל המפתחות עברו לניהול מוצפן מחוץ למאגר.
- פירוט ההרשאות שאיתן האפליקציה מתחברת למסד הנתונים.
- מנגנון תיעוד גישה: מה נרשם, איפה, ולכמה זמן.
- נוהל מחיקה ותיקון: מה קורה בפועל כשלקוח מבקש שיסירו את פרטיו, כולל בגיבויים.
- רשימת השירותים החיצוניים שהמערכת שולחת אליהם מידע, ומה בדיוק נשלח לכל אחד.
- הוכחת שחזור מגיבוי, לא רק אישור שקיים גיבוי.
- מי מקבל התראה כשהמערכת נופלת או מתנהגת חריג, ותוך כמה זמן.
אם התשובות לרוב הסעיפים האלה הן "צריך לבדוק", זה בסדר גמור כנקודת פתיחה. זה פחות בסדר כמצב קבע.
שאלות ותשובות
האם מותר בכלל לבנות מערכת עסקית בעזרת AI?
כן. אין שום דבר בחוק שאוסר על הכלי שבו נכתב הקוד. החוק מתייחס לתוצאה: איך המידע האישי מאובטח בפועל. אפשר להגיע לתוצאה תקינה עם כלי AI, בדיוק כמו שאפשר להגיע לתוצאה גרועה בלעדיהם. ההבדל הוא האם מישהו בדק.
יש לי רק טופס יצירת קשר. גם זה מאגר?
אם הפרטים שנשלחים בטופס נשמרים אצלכם באופן מסודר, בין אם במסד נתונים, בגיליון או במערכת דיוור, אתם מחזיקים מידע אישי. האם זה עונה להגדרת "מאגר מידע" ואילו חובות נגזרות מכך היא שאלה משפטית. מבחינה הנדסית, השאלות באותה רשימה למעלה רלוונטיות בדיוק אותו הדבר.
המערכת מתארחת בשירות ענן. האחריות לא עליהם?
ספק האחסון אחראי על התשתית שלו: השרתים, הרשת, האבטחה הפיזית. הוא לא אחראי על כך שנקודת קצה באפליקציה שלכם מחזירה רשימת לקוחות לכל מי ששואל, ולא על כך שהסיסמה למסד הנתונים נמצאת בתוך הקוד. החלוקה הזו מפתיעה הרבה בעלי עסקים.
מה נחשב אירוע אבטחה שצריך לדווח עליו?
ההגדרה נמצאת בתקנות, והיישום שלה על מקרה ספציפי הוא שאלה משפטית. מה שכן ברור מהמקרה שהסתיים בעיצום ביולי 2026: ההמתנה בין הגילוי לדיווח היא עצמה ההפרה. אם התגלה אצלכם משהו שנראה כמו חשיפת מידע, זה הרגע לפנות לעורך דין, לא הרגע לחכות ולראות.
כמה זמן לוקח לתקן מערכת שנבנתה בעזרת AI?
זה תלוי לגמרי בגודל המערכת ובכמה מהדפוסים למעלה קיימים בה. חלק מהתיקונים, כמו הוצאת מפתחות מהקוד או סגירת נקודת קצה, הם עניין של שעות. הוספת תיעוד גישה מסודר או מסלול מחיקה אמיתי היא עבודה גדולה יותר. אני תמיד ממליץ להתחיל בבדיקה ובתעדוף, ורק אז להחליט מה מתקנים ומתי.
אני צריך למנות ממונה על הגנת הפרטיות?
רוב העסקים הקטנים לא. החובה מכוונת לגופים ציבוריים, לגופים שסוחרים במידע בהיקף גדול ולמי שמעבד מידע רגיש בהיקף ניכר. אבל שימו לב שאי-חובת מינוי לא פוטרת מחובות אבטחת המידע. את התשובה המדויקת למקרה שלכם תקבלו מעורך דין.
סיכום
תיקון 13 לא המציא דרישות חדשות מאפס, הוא הפך דרישות קיימות לניתנות לאכיפה. במקביל, יותר ויותר עסקים מחזיקים מידע אישי במערכות שנבנו מהר, בעזרת כלים חדשים, ובלי שאף אחד בצד שלהם קרא את הקוד. הצירוף של השניים הוא הסיכון האמיתי, וגם הסיבה שהפוסט הזה קיים.
השורה התחתונה פשוטה: אתם לא צריכים להבין קוד, אתם צריכים לדעת אילו שאלות לשאול ולקבל עליהן תשובות בכתב. התחילו בשבע הבדיקות שאפשר לעשות לבד, שלחו את רשימת הבקשות למי שבנה, וקחו את השאלות המשפטיות לעורך דין. אם קראתם על סיכוני בינה מלאכותית בעסק בהקשר רחב יותר, הפוסט שלי על בינה מלאכותית לצרכים עסקיים נוגע בנושא הרגולציה כחלק מתמונה כללית יותר. כאן העמקנו דווקא בצד ההנדסי שלו.
ואם אתם רוצים שמישהו יסתכל על הקוד עצמו: אני מציע בדיקה ממוקדת לאפליקציות ולמערכות שנבנו בעזרת כלי AI. אני עובר על הקוד ועל התשתית, ומחזיר מסמך ממצאים כתוב, מסודר לפי חומרה, שבו לכל ממצא מופיע מה הוא חושף, מה נדרש כדי לסגור אותו והערכת מאמץ. אתם לא מחויבים שאני אתקן: אפשר לקחת את המסמך למי שבנה לכם את המערכת ולבקש שיטפל. אם תרצו שאני אטפל, זה שלב נפרד ובהסכמה.
עבודה ישירה מולי, בלי סוכנות ובלי מתווכים. אפשר לקרוא עוד על פיתוח והטמעה של פתרונות AI לעסקים, או פשוט לפנות אליי ולספר מה בניתם ובאיזה כלי. אשמח לומר לכם בשיחה קצרה אם יש כאן בכלל מה לבדוק.