הבינה המלאכותית היא תופעה חברתית ותרבותית רחבת היקף. בתוך תופעה זו הבינה המלאכותית היוצרת, GENAI, היא קפיצת דרך מטלטלת מפני שהיא משנה את שאלות היסוד של עבודת הפיתוח: מי כתב את הקוד, מי אחראי עליו, על מה הוא מבוסס, ומה קורה כשהוא שוגה.
חלק א׳: ההיבטים המשפטיים מעצבים את שיטת הניהול
שלוש שכבות שמתחברות זו לזו
השכבה הראשונה: החלטות ניהוליות
ארבע שאלות מעשיות עומדות בבסיס כל שימוש ארגוני בבינה מלאכותית:
• באילו כלים להשתמש?
• מה מותר להזין להם?
• לאיזה צורך מותר להשתמש בהם?
• איך מגינים על הארגון ועל המוצר?
השכבה השנייה: הסיכונים
הפרת זכויות יוצרים, חוסר מוגנות של היצירה שהארגון מייצר, פגיעה בפרטיות, אי-תאימות רגולטורית ומוצר מזיק.
השכבה השלישית: שיטות וארגון
מכאן נגזרות התשתיות הארגוניות: ייעוץ משפטי, פיקוח ניהולי ברמות שונות, הדרכה, תיעוד טכני ותיעוד חוזי – רגולטורי מסודר.
מפת הסיכונים בשימוש יומיומי ב AI
כדי למפות את החשיפה בפועל, נוח לחלק אותה לשני צדדים: מה נכנס לכלי, ומה יוצא ממנו.
בצד הקלט:
- הזנת קוד מקור של צד ג’, מסמכי אפיון, דאטה של לקוחות או מידע חסוי לכלי חיצוני.
- אי הבחנה בין כלי ארגוני מאושר לבין כלי ציבורי פתוח.
בצד הפלט:
- קוד, טקסט, יצירה אמנותית או אחרת, שאולי אינם מוגנים או שייכים לצד ג’.
- הסתמכות על תשובה שגויה או בלתי מבוקרת.
- תוצר שלא ברור מי בדק אותו ועל בסיס מה.
סיכוני הקלט הם בעיקר סיכוני דליפה והפרת פרטיות. סיכוני הפלט הם סיכוני איכות ואחריות, והם מתממשים מאוחר יותר.
חלק ב׳, ציר 1: קניין רוחני ובעלות על תוצרים
בינה מלאכותית אינה יכולה להיות “יוצר” לצרכי זכויות יוצרים. על מנת שיצירה שמשולבת ביצירה פרי AI, תהא מוגנת לפי דיני זכויות היוצרים, חייבת להיות התערבות אנושית משמעותית בתוצר. ככל שהתרומה האנושית דלה יותר, כך נחלשת הטענה לבעלות ולהגנה
Prompt – יכול כשלעצמו להיות יצירה אם הוא פרי מעשה אנושי ואם יש בו דבר מה מקורי ומחוכם, אבל הוא אינו הופך את היצירה שנוצרה בעקבותיו ליצירה אנושית.
תוצר ה- AI יכול להיות “נגוע” ביצירות מוגנות של אחר, או להפר תנאי רישיון קוד פתוח למשל בכך שלא צורף קרדיט או שלא קוימו תנאי רישוי אחרים.
המנוע יכול לייצר תוצר זהה או דומה מאוד לגורמים שונים. משמעות כפולה: מצד אחד, קשה יותר לטעון למקוריות ולהגנה; מצד שני, אפשר להסתבך בטענות הפרה או גניבת עין מול מי שקיבל תוצר דומה.
דרישת המחבר האנושי: הלכת Thaler v. Perlmutter
ד”ר סטיבן ת’אלר ביקש לרשום בארה”ב יצירת אמנות שנוצרה באופן אוטונומי על ידי מערכת AI תוך שהוא מציין את המכונה כמחברת. משרד זכויות היוצרים האמריקאי סירב לרשום את היצירה, בהיעדר מחבר אנושי, ובית המשפט הפדרלי לערעורים במחוז קולומביה אישר את הסירוב במרץ 2025, בקובעו כי מחבר אנושי הוא דרישת סף לפי חוק זכויות היוצרים משנת 1976.
בית המשפט העליון של ארה”ב דחה בחודש מרץ 2026 בקשת רשות ערעור בתיק, ובכך הותיר את ההלכה על כנה.
המשמעות היא ישירה: יש לתעד את התרומה האנושית בכל תוצר. תיעוד שנוצר בזמן אמת שווה הרבה יותר מהסבר שנבנה בדיעבד.
פטנטים: עש”א 33353-05-23 ת’אלר נ’ רשם הפטנטים
במסגרת אותו פרויקט בינלאומי (Artificial Inventor Project) הגיש ת’אלר שתי בקשות פטנט בישראל, כשבמקום המיועד לשם הממציא נרשם כינויה של המכונה DABUS. הבקשות נדחו על ידי רשם הפטנטים, וערעורו נדחה בבית המשפט המחוזי בתל אביב (כב’ השופטת תמר אברהמי, 31.12.2025).
בית המשפט קבע כי לפי סעיף 2 לחוק הפטנטים, התשכ”ז – 1967, מי שזכאי לבקש פטנט הוא “בעל אמצאה”. החוק אינו מגדיר את המונח “ממציא”, אך פרשנותו הטבעית והרגילה מתייחסת לבן אנוש ולא למכונה. מכונה אינה בעלת אישיות משפטית, אין לה זכויות או חובות, ולכן היא גם אינה יכולה לבצע את הפעולה המשפטית של העברת הזכויות באמצאה למבקש הפטנט.
בית המשפט הוסיף שני נימוקים בעלי משקל מעשי: הכרה חד-צדדית של ישראל בבינה מלאכותית כממציאה, בניגוד לרוב מדינות העולם, תיצור א-סימטריה בעייתית שבה אמצאות כאלה יהיו נחלת הכלל בעולם אך מוגנות במונופול בישראל; ושינוי מדיניות מסוג זה מסור למחוקק ולא לבית המשפט.
ההסתייגות החשובה ביותר בפסק הדין: בית המשפט הבהיר במפורש שההכרעה אינה עוסקת בשאלה איזו מעורבות אנושית נדרשת כדי שאדם ייחשב ממציא באמצאה שנעשתה בסיוע מכונה. הפתח לרישום פטנט על אמצאה שנוצרה בידי אדם שנעזר ב-AI נותר פתוח לחלוטין. השאלה עברה ממישור “האם מכונה יכולה” למישור “כמה אדם צריך” וזהו בדיוק השטח האפור שבו פועלים רוב צוותי הפיתוח.
בהתאמה, משרד הפטנטים האמריקאי (USPTO) פרסם בנובמבר 2025 הנחיות מעודכנות בעניין אמצאות בסיוע AI, ולפיהן רק אדם טבעי יכול להיחשב “ממציא”, ומערכות AI נתפסות ככלים (instruments) המשמשים את הממציא האנושי, בדומה לציוד מעבדה, תוכנה או מאגר מידע. ההנחיות מבהירות שאין מבחן משפטי נפרד לאמצאות בסיוע AI, ואותו סטנדרט חל על כלל האמצאות.
מה כן מקנה הגנה והמשמעות בכתיבת קוד
הכלל המנחה: נדרשת התערבות אנושית מהותית לשם עמידה בדרישה.
בקוד תוכנה, ההבחנה נראית כך. כאשר המפתח משתמש בפלט כבסיס, אך בונה סביבו ארכיטקטורה, מוסיף מודולים, משנה את האופן שבו הנתונים מטופלים או משכתב חלקים גדולים, ההגנה תחול על אותו חלק יצירתי שהוא מעשה ידי אדם, ולא על הפלט כפי שהוא. לעומת זאת, העתקה כמעט מילולית של קטע שהמנוע הציע, בליווי שינויי שמות משתנים וסידור שורות, לא תבסס מקוריות אנושית ממשית.
יש דעות לפיהן הדרישה נמוכה יותר ביחס לכתיבת קוד, אם יש מעורבות אנושית ברוב שלבי הפיתוח, בעיקר בשלב היצירתי ובשלב הפינישים. ההיגיון מאחורי הגישה הזו הוא שרף המקוריות בתוכנה נמוך יחסית מלכתחילה: די בכך שהמבנה, הארגון וזרימת הקוד משקפים בחירות תכנוניות של המתכנת. אבל זו עדיין גישה שנשענת על קיומה של תרומה אנושית מזוהה, לא על היעדרה.
כדאי לתרגם זאת לכלל עבודה פשוט: התערבות אנושית משמעותית משמעה = תכנון + בחירה + שכתוב + שילוב יצירתי. לא רק הרצת מודל והעתקת הפלט.
בפועל, זה אומר שהארכיטקטורה, הלוגיקה העסקית וההחלטות הקריטיות צריכות להישאר מעשה ידי אדם; שאין להתייחס לפלט כאל black box שנכנס למערכת כמות שהוא; ושיש להשאיר עקבות: design docs, pull requests, הערות בקוד שמראות בחירות ושיקולים, והיסטוריית commits שמשקפת עבודה ולא הדבקה.
אימון מכונה ביצירות מוגנות
כאן חשוב להפריד בין שתי שאלות שלרוב מתערבבות:
- אימון המודל: האם מותר להשתמש ביצירות מוגנות כדי לאמן?
- השימוש במקורות הקלט: האם ההעתקה עצמה, לצורך בניית סט האימון, לגיטימית?
אלה שאלות נפרדות. אימון לצרכי העתקה, כלומר שימוש שמטרתו לשחזר או להחליף את היצירה המקורית, בעייתי בהרבה מאימון טרנספורמטיבי.
בזירה הגלובלית מתנהלות עשרות תביעות הפרה נגד ספקי AI מצד בעלי זכויות, והפסיקה עדיין מתגבשת. הקו שהתחדד בפסיקה האמריקאית מ-2025 ואילך מבחין בין שני דברים: אימון על חומרים שהושגו כדין, שעשוי לחסות תחת fair use בנסיבות מסוימות, לבין החזקה ושימוש בעותקים פיראטיים, שיוצרים חשיפה נפרדת ומשמעותית.
בישראל, חוות דעת מחלקת ייעוץ וחקיקה במשרד המשפטים (2022) קבעה, כי שימוש ביצירות מוגנות לאימון מודלים עשוי להיחשב שימוש הוגן. אבל זו אינה הגנה גורפת: התוצאה תלויה בנסיבות ובאופי השימוש, למשל האם מדובר בלקט, והאם מדובר בשימוש מתחרה. שימוש ביצירות פרוצות כנראה לא יהיה מוגן.
יש לבדוק אם בעלי הזכויות אסרו על אימון מודלים באמצעות היצירות, למשל בתנאי שימוש של אתר, בקובץ robots, או במנגנון rights reservation. יש לציין שקיימת שאלה עצמאית, האם תנאי כזה חוקי ובר-אכיפה בכל מקרה, אבל מנקודת מבט של ניהול סיכונים, התעלמות מהגבלה מפורשת היא החלטה שצריכה להתקבל במודע ובליווי משפטי, לא כברירת מחדל.
קוד פתוח, רישיונות וסריקת קוד
זהו האזור שבו הסיכון הוא מוחשי לצוותי פיתוח.
כלי AI מאומנים, בין השאר, על קוד פתוח. הפלט עשוי להיות דומה מאוד לקטעים קיימים, לרבות קטעים הכפופים לרישיונות copyleft שמחייבים שחרור קוד נגזר, או לרישיונות המחייבים attribution. הבעיה היא שהפלט מגיע “נקי”, בלי כותרת רישיון, בלי הערת copyright, ובלי אינדיקציה למקור.
לכן אין להניח שתוצר AI הוא נקי. יש לבחון היטב, האם משולב בתוצר קוד פתוח או קוד מוגן של צד ג’, ולבצע סריקת קוד כדי לבדוק אם הוא עומד בתנאי הרישיון.
סריקת קוד לצורך איתור קטעי צד ג’ פועלת בכמה שכבות: סריקה סטטית של עץ הריפוזיטורי; השוואה למאגרי חתימות וקוד ידועים; זיהוי תלויות, קבצי LICENSE והערות copyright; ובדיקה אנושית של כל ממצא משמעותי. התוצר הוא דוח שמסמן מיקומים חשודים, סוג רישיון או מקור אפשרי, רמת סיכון והמלצה, להסיר, להחליף, לייחס, או לקבל רישוי מתאים.
בפועל מקובל לשלב שתי משפחות כלים: כלי SCA וניהול רישיונות (למשל FOSSA, Black Duck, FOSSID, ScanCode) לצד כלי ניתוח סטטי ואבטחה (למשל CodeQL/GitHub code scanning, SonarQube). המפתח אינו בבחירת הכלי אלא בשילובו ב-CI/CD, כך שהבדיקה תהיה רציפה ולא אירוע חד-פעמי לפני שחרור גרסה.
חלק ג׳, ציר 2: אחריות ונזיקין
מי אחראי כשה-AI טועה ונגרם נזק?
יש כמה “חשודים” פוטנציאליים בשרשרת:
- בעלי המנוע: ספק המודל.
- היוצר: מי שפיתח את המוצר.
- המטמיע / האינטגרטור: מי ששילב את המוצר במערכת או בשירות.
- המשתמש הסופי: בבחינת “ייזהר הקונה”.
אין תשובה אחת. האחריות נגזרת מנסיבות העניין: לפי התפקיד החברתי, מידת השליטה בתהליך וצפיות הנזק.
AI יכול לטעות — וכדאי לדעת איך
לפני שדנים באחריות, כדאי להבין את הפתולוגיה. הכשלים האופייניים ל- AI:
- לא מבצע את מה שביקשו ממנו: הפער בין ה-spec לבין המימוש.
- הוזה: ממציא נתונים, פונקציות, פרמטרים, ספריות והנחות שאינן קיימות.
- שגיאות בכתיבה עצמה: תחביר, מבנה, חתימות שגויות.
- איכות ביצוע נמוכה: קוד שעובד אבל לא עומד בסטנדרט.
- חוסר עקביות בקוד.
- לא בודק את עצמו כראוי.
המאפיין המסוכן ביותר הוא שהטעות נמסרת בביטחון גבוה ובניסוח משכנע. קוד שנוצר ב-AI נראה לרוב “נקי” מבחינה ויזואלית תקין, שמות עקביים, מבנה מסודר, ולכן קל להחמיץ כשלים שהיו בולטים יותר בקוד אנושי מרושל. הכלל המעשי: יש להתייחס לפלט כחשוד עד שהוא עובר בדיקה עצמאית.
שלושה מסלולי אחריות
רשלנות מקצועית (Professional Negligence). הסתמכות על פלט שגוי ללא בדיקה עלולה להקים אחריות בגין רשלנות. זהו המסלול הרלוונטי ביותר למי שנותן שירות מקצועי, פיתוח בהזמנה, ייעוץ הנדסי, אינטגרציה.
אחריות מוצר (Product Liability). הרף עולה למי שמשלב GenAI במוצר או בשירות. מי שמודע להתכנות טעויות, וכיום קשה לטעון שאינו מודע, נמצא באחריות למנען.
אחריות המטמיע (Responsibility Integrator). הספק שאחראי למתן פתרון אינו יכול להסתתר מאחורי כלי ה-AI, אלא אם סוכם עם הניזוק על תניית פטור ביחס לכך ובתנאי שהתנייה תקפה משפטית. תניות פטור גורפות אינן תמיד עומדות במבחן, במיוחד מול לקוחות חלשים או במצבים של רשלנות רבתי.
שני מושגים משפטיים ששווה להכיר
“יחסי שכנות”. הגורם הכי קרוב בשרשרת האספקה לגורם שניזוק, “השכן”, הוא בדרך כלל זה שייחשב האחראי כלפי הניזוק, גם אם הגורם הרשלן הישיר הוא ספק משנה של הספק הראשי. לספק הראשי תקום עילה כנגד ספק המשנה, אבל התביעה הראשונה תגיע אליו.
זה חשוב במיוחד בעולם ה – AI, כי אם הגורם הרשלן הישיר הוא ספק המודל, אזי הוא בדרך כלל תאגיד זר עם תנאי שימוש שמגבילים את אחריותם לסכומים זעומים.
חזקת “הדבר המדבר בעד עצמו”. שליטה בתוצר שגרם לנזק מעבירה את נטל ההוכחה אל היוצר. במילים אחרות, מי ששולט בתהליך עשוי להידרש להסביר מדוע הדבר לא נגרם ברשלנותו ולא להיפך.
המורכבות הייחודית של AI: למטמיע יש קושי אמיתי להיזהר, בגלל התלות בספק, הדינמיות של המודל (שמשתנה בין גרסאות לפעמים ללא הודעה), וחוסר השקיפות של המנוע. ייתכן שבפסיקה תתפתח הקלה מסוימת לנוכח הערך התרומי של AI. מנגד, יש נושאים שאפילו מנועים אינם יכולים להתנער מאחריות לגביהם, למשל הפרת פרטיות.
צעדים מעשיים לצמצום חשיפה
במישור החוזי:
- קבעו כללי אחריות מוסכמים מול הלקוח, במיוחד בשירות AI נמשך שבו המודל והתוצאות משתנים לאורך זמן.
- צרו מצגים החושפים את החולשות האפשריות של המוצר. היו שקופים מול הלקוח לגבי רכיב ה-AI ומשמעותו, כדי להסיר טענות עתידיות. גילוי מראש הוא לרוב ההגנה הזולה ביותר.
- הפעילו מנגנוני בקרה שנועדו להקטין את הסיכוי לנזק והציגו אותם כתנאי לאחריות מופחתת.
במישור הפיתוח:
- ייצרו ויישמו מדיניות פיתוח תוכנה ב-AI.
- בצעו ניתוח רגישויות וסיכונים, ובהתאם להם עצבו את הפיתוח והבדיקות.
- בחנו את מאפייני המנוע: באילו תקנים הוא עומד, מה הבטחותיו לגבי רמת אמינות, ומה הצהרותיו ביחס לאבטחת מידע.
- קיימו בדיקה אנושית כמרכיב חובה, לא כהמלצה ולא כ”best effort”.
- פיתוח לפי תקן בינלאומי מוכר שלוקח בחשבון AI יכול לסייע משמעותית, גם ראייתית וגם מעשית.
ביטוח: האם אתם מכוסים לטעויות AI?
ביטוח אחריות מקצועית או ביטוח סייבר אינם בהכרח מכסים טעויות ומעשי AI. פעולות AI לא תמיד יושבות על הגדרות מקרי הנזק בפוליסה. למשל: האם הפצת מידע רגיש החוצה על ידי מנוע היא “פריצה”? כאן יש גורמי נזק ייחודיים שאינם תואמים בהכרח את הקטגוריות הביטוחיות המסורתיות.
בנוסף, חריגים קיימים בפוליסות ישנות עלולים כבר היום להחריג נזקי AI מבלי לקרוא לילד בשמו, למשל חריג בגין “מסירת מידע לצד שלישי” או “שימוש בטכנולוגיה לא מאושרת”, ופוליסות חדשות יכולות להכיל חריגי AI מפורשים.
מה לעשות בפועל:
- ודאו אם קיימים בפוליסה ראשי נזק חדשים וייחודיים ל -AI.
- בדקו את הכיסוי בעת חידוש הפוליסה, ייתכן שנוסף חריג AI.
- נתבו חלק מהחיסכון שה-AI מייצר לרכישת כיסוי ביטוחי מתאים. זו הצדקה כלכלית קלה יחסית להצגה בפני הנהלה.
חלק ד׳, ציר 3: פרטיות, סודיות ומידע
המסגרת הישראלית: טיוטת הנחיית הרשות להגנת הפרטיות
באפריל 2025 פרסמה הרשות להגנת הפרטיות טיוטת הנחיה להערות הציבור בנושא “תחולת הוראות חוק הגנת הפרטיות על מערכות בינה מלאכותית” (הטיוטה המלאה, gov.il). ההנחיה מגדירה לראשונה את יישום הוראות החוק בכל שלבי מחזור החיים של מערכת AI, משלב האימון ועד לשימוש בפועל ומיועדת לשמש בסיס להפעלת סמכויות האכיפה המורחבות שהוענקו לרשות בתיקון 13 לחוק הגנת הפרטיות, שנכנס לתוקף באוגוסט 2025. תיקון 13 העניק לרשות “שיניים” קנסות מנהליים משמעותיים ואף סנקציות פליליות במקרים חמורים. הטיוטה מבטאת גישה נוקשה ומחמירה, והיא בזמן כתיבת מסמך זה עדיין בגדר טיוטה.
עיקרי הדרישות:
בסיס חוקי לעיבוד. כל עיבוד מידע אישי במערכת AI מחייב בסיס חוקי, הסכמה מדעת של נושא המידע או הסמכה בדין, וזאת בכל אחד משלבי מחזור החיים, לרבות בשלב הפיתוח והאימון. גוף ציבורי המעבד מידע אישי במערכת AI חייב להצביע על הסמכה מפורשת בחוק ואינו יכול להסתמך רק על הסכמה.
שקיפות ויידוע מפורט, בהתאם לרמות הסיכון. מעבר לחובת היידוע לפי סעיף 11 לחוק, יש למסור לנושא המידע: איך המערכת עובדת, מטרות העיבוד, סוגי המידע ומקורותיו, זהות מקבלי המידע, שילוב עם מידע נוסף, והסיכונים העשויים לנבוע מהעיבוד. כמו כן יש ליידע כאשר מפעילים בוט לאיסוף נתונים ועיבודם, וכאשר האינטראקציה היא עם מערכת אוטומטית ולא עם בן שיח אנושי.
כריית מידע (scraping). אין להסיק שאדם שמפרסם מידע ברשת חברתית מודע ומסכים לשימוש בו לצורכי AI. פרסום עצמי אינו הסכמה לאימון. הרשות מציינת במפורש שאין להשתמש בשם או בתמונה שפורסמו בפרופיל אישי לצורך אימון אלגוריתם לזיהוי פנים. במקביל, מפעילי רשתות חברתיות ושירותים המאפשרים שיתוף מידע נדרשים להפעיל אמצעים למניעת כריית נתונים וכרייה אסורה עלולה להיחשב “אירוע אבטחה חמור” המחייב דיווח מיידי לרשות.
דיוק והזכות לתקן. בנסיבות מסוימות של מידע לא מדויק, או הסקת מסקנות לא נכונה, נושא מידע יכול לדרוש תיקון מידע ותיקון האלגוריתם שהפיק אותו, ככל שאין דרך אחרת למנוע ממנו להפיק שוב את אותו מידע שגוי. זו דרישה עם השלכות הנדסיות כבדות: היא מחייבת יכולת לאתר, לבודד ולתקן מקור של פלט שגוי.
אבטחת מידע. ניהול מאגרי מידע מבוססי AI כרוך בסיכוני אבטחה ייחודיים, בראשם “מתקפות הסקה” (inference attacks) שנועדו לחלץ שרידי מידע אישי הניתן לזיהוי מתוך האלגוריתם, או להסיק מחדש מידע שאומן עליו. מאגרים כאלה צפויים להיות כפופים לרמת אבטחה בינונית או גבוהה, והרשות שוקלת להחיל עליהם רמת אבטחה גבוהה.
אחריותיות (Accountability). ארגון שמפעיל AI נדרש: ליישם Privacy-by-Design; לגבש הנחיות פנימיות ולהטמיע פרקטיקות; לערוך תסקיר השפעה על הפרטיות (DPIA); ולמנות אחראים, לרבות ממונה הגנת פרטיות, שחובת מינויו לפי תיקון 13 עשויה לחול על גופים שעיסוקם כולל עיבוד מידע רגיש בהיקף ניכר, מצב שעשוי להתקיים באימון מודלים.
עדכון 2026: המלצות לשימוש בסוכני AI
ביולי 2026 פרסמה הרשות להגנת הפרטיות מסמך המלצות בנושא שימוש בסוכני בינה מלאכותית (gov.il). המסמך מתמקד בשימוש אישי, אך הוא רלוונטי ביתר שאת בהקשר הארגוני: כאשר סוכן מחובר ליומנים, לתיבות דוא”ל, למאגרי לקוחות, למערכות מסמכים או למערכות תפעוליות, הסיכונים לפרטיות ולאבטחת מידע מתעצמים.
ההמלצה המרכזית רלוונטית ישירות לארכיטקטורה: צמצום הגישה למידע אישי, להגדיר באופן ספציפי איזה מידע זמין לסוכן, ולהימנע מחיבורו למאגרי מידע שלמים. עדיף לספק לסוכן תת-קבוצה מוגדרת מאשר גישה רחבה שממנה הוא “יאתר לבד” את הרלוונטי.
זהו עקרון least privilege במונחי פרטיות, והוא נכון גם כשהסוכן פנימי לחלוטין.
מה לבדוק כשמזינים מידע
לפני שמאשרים כלי, יש לעבור על רשימה קונקרטית:
- בדקו את הצהרת הפרטיות של המנוע: איך הוא משתף, ואם בכלל, ומה נשמר אצלו בכל מקרה (למשל לוגי כניסה?).
- האם המודל מאמן את עצמו על המידע שלכם, ובאיזה אופן והאם גם מול גופים אחרים?
- היכן נשמר המידע? שאלת ה-data residency והעברת מידע לחו”ל.
- מהו השימוש בו? שימוש משני, שיפור מוצר, בקרת איכות אנושית מצד הספק.
- ודאו שכל שרשרת חובות הפרטיות נשמרת: שמירה, אבטחה, גיבוי, הרשאות והצפנה.
- בדקו באופן מתמיד שהיבטי הפרטיות נשמרים מול פרצות ושינויים בקוד המנוע. בדיקה חד-פעמית בעת ההתקשרות אינה מספיקה המודל וה-pipeline משתנים.
- ודאו שקיימת לכם הרשאה להפעיל מודל באמצעות מידע של צד אחר. זו שאלה נפרדת מההרשאה להחזיק את המידע.
כללי הזנה: מידע אישי, מידע סודי, מידע קנייני
יש להבחין בין שלוש קטגוריות שנוטות להתערבב:
מידע אישי. אין להזין נתוני לקוחות, עובדים או משתמשים ללא בסיס הרשאה מתאים, צורך מצדיק, מזעור מידע ובקרות נדרשות. סביר שברוב המקרים אין הרשאה להעלות מידע אישי למנוע משתף.
מידע סודי של צד ג’. אין להעלות למנוע ציבורי. זה כולל קוד של לקוח, מסמכי אפיון שהתקבלו תחת NDA, ודאטה שסופק למטרה מוגדרת.
מידע קנייני ורגיש של הארגון עצמו. קוד ליבה, אלגוריתמים ייחודיים, מסמכי אסטרטגיה גם כאן נדרשת זהירות, ולעיתים החלטה גורפת שלא להזין אותם לכלים חיצוניים כלל.
נקודה שנוטים לפספס: גם אימון מנוע סגור באמצעות מידע אישי דורש לרוב הרשאה מיוחדת מאת נושא המידע. העובדה שהמנוע פנימי, on-prem, ולא משתף מידע החוצה, מפחיתה סיכון אחד (דליפה) אבל אינה פותרת את השאלה המשפטית האם עצם השימוש במידע האישי לאימון היה מותר מלכתחילה. עיבוד הוא עיבוד, גם כשהוא מתבצע בתוך הארגון.
התממה (אנונימיזציה) ומגבלותיה
אנונימיזציה היא בעלת חשיבות רבה לשם שמירה על פרטיות נושא המידע. אבל צריך להבין את מגבלותיה.
אנונימיזציה נשענת על סבירות שלא ניתן לקשר מידע לאדם, דא עקא ש-AI מוריד את רמת הסבירות הזו. יכולות ההצלבה, ההסקה וזיהוי מחדש שהמודלים מספקים משנות את חישוב הסיכון שנעשה בעבר.
במונחים אירופיים, גישת ה-EDPB European Data Protection Board היא שמודל ייחשב אנונימי רק אם הסיכון לחלץ ממנו מידע אישי, או לקבל פלט המזהה נושאי מידע, הוא זניח. אם לא, העיבוד נשאר כפוף למשטר הגנת המידע.
לכן: אנונימיזציה היא כלי חשוב לצמצום סיכון, אך לא פתרון קסם שמוציא את הפרויקט מתחולת הדין.
חלק ה׳, ציר 4: רגולציה, תקינה וממשל ארגוני
התמונה הגלובלית
ברוב המדינות האסדרה עדיין מפוזרת בין דינים קיימים, הנחיות רגולטוריות ורגולציה סקטוריאלית, בעוד שהאיחוד האירופי חריג בהיקף החקיקה האופקית הייעודית.
EU AI Act: גישה מבוססת סיכון
החוק חל גם על ארגונים מחוץ לאיחוד כאשר התוצר או המערכת מיועדים לשוק האירופי. זהו מנגנון אקסטרה-טריטוריאלי הדומה במבנהו ל-GDPR, והוא הסיבה שחברות תוכנה ישראליות יכולות למצוא עצמן תחת תחולתו גם בלי נוכחות פיזית באירופה.
החוק יוצר מדרג בן 4 שכבות בהתאם לרמת הסיכון החברתי שמנוע ה- AI יוצר.
Unacceptable Risk – מערכות לדירוג חברתי, מעקב המונים, ממניפולציות חשיבתיות והתנהגויות או המיועדות להזיק – אסורות.
High Risk – מערכות בתחום התעסוקה, אכיפת חוק, שירותים ציבוריים, בטיחות, תחבורה – חובת עמידה במבדקים.
Limited Risk – זיהוי ביומטרי, בוטי שיחה, זיהוי רגשות, דיפ פייק – עיקר החובה היא בתחום הגלוי הנאות.
Minimal
דגשים מרכזיים לצוותי פיתוח מתוך החוק האירופאי
ארבעה נושאים שמתורגמים ישירות לעבודה יומיומית:
Transparency – שקיפות. יידוע משתמשים על אינטראקציה עם AI, וסימון תוכן מלאכותי. משמעות הנדסית: UI states, מטא-דאטה, watermarking, ו-API responses שנושאים סימון.
Deployer duties – חובות המטמיע. שימוש לפי ההוראות של הספק, פיקוח אנושי, וניטור.
Record keeping – רישום ולוגים. תיעוד אוטומטי של אירועים לאורך חיי המערכת. משמעות הנדסית: תכנון סכמת לוגים מראש, שמירה על retention מתאים, ויכולת שחזור של החלטה מסוימת בדיעבד.
AI literacy – אוריינות AI. חובה להבטיח רמת ידע מספקת של הצוות המשתמש במערכות ביחס למאפייני הבינה המלאכותית וסיכוניה. משמעות הנדסית וארגונית: הדרכה מתועדת, onboarding, ורענון תקופתי.
Risk – ללא הגבלות משמעותיות. בתוכם נמנים המודלים הכלליים המוכרים לנו.
ISO/IEC 42001
התקן הבינלאומי הראשון למערכת ניהול AI (AIMS).
מטרתו: ליצור תהליכים ארגוניים, מדיניות וממשל תאגידי רחב לשם התמודדות עם סיכוני AI. הוא בר הסמכה, ומספק מסגרת מובנית לניהול סיכונים ובקרות.
התקן מספק מסגרת ניהולית שיכולה לסייע בהיערכות לדרישות רגולטוריות ובניהול סיכוני AI, ובכלל זה ליישום חלק מהוראות ה – EU AI Act. הוא אינו תחליף לציות ואינו מקנה חסינות, אבל הוא מספק שלד ארגוני מוכר ומאפשר להראות תום לב ומאמץ מובנה.
NIST AI Risk Management Framework
מסגרת עבודה גמישה ולא-מחייבת של המכון הלאומי לתקנים וטכנולוגיה של ארה”ב, שמטרתה צמצום סיכונים. היא בנויה מארבע פונקציות:
- Govern – ממשל: מדיניות, תפקידים ותרבות של ניהול סיכונים בארגון.
- Map – מיפוי: זיהוי ההקשר, השימושים והסיכונים של כל מערכת.
- Measure – מדידה: הערכה וכימות של סיכונים, אמינות וביצועים.
- Manage – ניהול: תיעדוף, טיפול וניטור מתמשך של הסיכונים.
זו מסגרת מצוינת לבניית תהליך ניהול סיכונים פנימי ובעיקר, היא מספקת שפה משותפת שמהנדסים, אנשי משפט ואנשי אבטחה יכולים להשתמש בה יחד.
ישראל
נכון להיום אין בישראל חוק AI אופקי כולל בדומה ל-EU AI Act. ההסדרה נשענת על:
- דינים קיימים: פרטיות, נזיקין, חוזים, הגנת הצרכן, קניין רוחני.
- הנחיות רשויות: ובראשן טיוטת הנחיית הרשות להגנת הפרטיות שנדונה לעיל.
- מדריך לניהול סיכונים ושימוש אחראי בכלי בינה מלאכותית במגזר הציבורי של מערך הדיגיטל הלאומי מעין עיבוד ישראלי לעקרונות ה-AI Act, שהחשיבות שלו חורגת מהמגזר הציבורי: הוא מהווה אינדיקציה טובה לציפייה הרגולטורית גם במגזר הפרטי.
- מסמכי מדיניות נוספים, ובהם מסמך משרד החדשנות והמדע, דוח הסקטור הפיננסי ודוח מבקר המדינה.
חלק ו׳: מדיניות AI ארגונית
למה בכלל מדיניות
מדיניות AI ארגונית היא כלי להנהגה נכונה וגם אמצעי הגנה משפטי. שני התפקידים חשובים באותה מידה.
יש לשלב בה אחריותיות, ולתת את הדעת על מניעת הטיות אלגוריתמיות ואי-אפליה כבר בשלבי הפיתוח וההטמעה לא כתיקון בדיעבד. בנוסף, נדרשת הערכת סיכונים טכנולוגית, משפטית ורגולטורית לכל מוצר או שירות מבוסס AI.
במילים אחרות: מדיניות AI היא הגשר בין הדין, הסיכון והפיתוח בפועל.
שלושת עמודי התווך: Trustworthy AI
שלושה עקרונות חוזרים בכל המסגרות מ -NIST ועד הרגולציה האירופית, גם כאשר תחולתם המדויקת תלויה בתפקיד הארגון ובשימוש הספציפי:
פיקוח אנושי (Human Oversight). אין להחליף שיקול דעת מקצועי. התוצר נשאר באחריות הארגון והצוות המאשר. אי אפשר להסתתר מאחורי המנוע.
שקיפות ותיעוד (Transparency). במקרים מסוימים נדרש גילוי על שימוש ב-AI, סימון תוצרים מלאכותיים, ותיעוד שמאפשר traceability.
ניהול סיכונים (Risk Management). הארגון צריך למפות שימושים, להגדיר רמות סיכון, ולחבר בין פיתוח, אבטחה, פרטיות, משפטי וציות.
מה חייב להיות במדיניות ולהיגזר ממנה
רשימת המרכיבים המעשית:
- מיפוי. בצעו הערכת סיכונים בהתאם לאופי המוצר, הנתונים הנדרשים לו, המשתמשים, הכלים הצפויים וכיו”ב.
- קיבוע כלים. קבעו באילו כלי AI מותר להשתמש, ובאיזה אופן, בהתאם לתנאי השימוש שלהם.
- נהלי קלט ופלט. קבעו מה מותר להזין, ומה עושים עם הפלט.
- נהלי תיעוד. Provenance, גילוי ושקיפות.
- בקרה על פלט. Review, בדיקות איכות, סריקות קוד ובחינת רישיונות.
- הכשרה ואכיפה. נהלים ברורים, הדרכה, ומנגנון דיווח חריגות.
- עדכון מסמכים חיצוניים. הסכמים עם לקוחות, מדיניות פרטיות והצהרות שיווק בהתאם.
- שיתוף בעלי תפקידים. שתפו את ה-CISO ואת ה-DPO. שיקלו למנות אחראי AI.
- מדיניות רכש. החליטו אם ואיך להכתיב לספקים שלכם כללי שימוש ב-AI. הסיכון נכנס לארגון גם דרך שרשרת האספקה.
חלק ז׳: מסקנות מעשיות
מסקנה מעשית 1: בדקו את תנאי השימוש ואת ה-AUP של המנוע
Acceptable Use Policy (AUP): מדיניות זו של ספק המודל קובעת את מרחב השימוש המותר במנוע ובתוצריו. ישנן הגבלות אתיות, חוקיות ומסחריות. לעיתים קיים איסור על הפעלת מנוע אחר על המנוע שלנו, נקודה שרלוונטית מאוד למי שבונה pipelines מרובי-מודלים או משתמש במודל אחד לייצור דאטה לאימון מודל אחר.
בדקו גם את עמידת המנוע בתקנים ובחוקים רלוונטיים בהתאם לאופי המוצר וייעודו.
חובה לבדוק את תנאי השימוש של המנוע.
ארבע שאלות שיש לענות עליהן לפני אישור כלי:
- מה המנוע מתיר לבצע באמצעותו?
- למי שייכות זכויות היוצרים בתוצרי המנוע?
- האם יש תנאי רישוי מתמשכים?
- מהם מאפייני הגנת הפרטיות של המנוע?
מערך האחריות: רוב הספקים מתנערים כמעט לחלוטין מאחריות, ומגבילים חבות לסכומים זעומים. הניחו שזו נקודת המוצא, ובנו את ניהול הסיכונים שלכם בהתאם — לא בהסתמך על יכולת חזרה אל הספק.
מסקנה מעשית 2: Provenance וליבת הקניין של החברה
הגדירו מהי ליבת הקניין (Core IP) של המוצר, ומהו תוכן תומך. תוכן שיווקי, דוקומנטציה פנימית או סקריפטים תפעוליים אינם דורשים בהכרח את אותה רמת הגנה כמו האלגוריתם שעליו בנוי המוצר.
קוד ליבה רצוי שייכתב בידי אדם, או ב-AI עם עריכה אנושית מסיבית ומתועדת, אם הבעלות בתוצר חשובה לכם.
צרו מדיניות פיתוח ברורה וכתובה לארגון או למוצר. שיקלו להחתים עובדים על מדיניות הפיתוח כהתחייבות אישית, בהתאם לתרבות הארגונית ולרגישות המוצר.
Provenance: תעדו מקורות ותרומה אנושית בתהליך הפקת הקוד. המבחן הוא האם בעוד שנתיים, מול תביעה או due diligence, תוכלו להסביר מה נעשה, באיזה כלי, באיזה שלב, ומה הייתה תרומת האדם.
סריקת קוד: בחנו היטב האם משולב בתוצר המנוע קוד פתוח או קוד מוגן של צד ג’, והאם הוא עומד בתנאי הרישיון. אין להניח שתוצר AI הוא נקי.
חלק ח׳: צ’קליסט מסכם לצוותי פיתוח
לפני שמאמצים כלי:
- תנאי שימוש ו-AUP נקראו ואושרו.
- ברור למי שייכות הזכויות בפלט.
- ברור האם הספק מאמן על הקלט שלנו, והאם אפשר לכבות זאת.
- האם הסביבה אקסלוסיבית או משותפת. ברור היכן נשמר המידע ולכמה זמן.
- מגבלת האחריות של הספק ידועה ומתומחרת בסיכון.
לפני שמזינים מידע:
- המידע סווג: ציבורי / פנימי / סודי / אישי / סודי של צד ג’.
- קיים בסיס להזנה, או שהמידע מוזער או הותמם.
- הכלי המשמש הוא הכלי המאושר לרמת הסיווג הזו.
לפני שממזגים קוד:
- הקוד נבדק מול ה-spec, ולא רק “נראה נכון”.
- מסלולי קצה נבדקו: null, empty, boundary, error, concurrency.
- כל קריאת API אומתה מול הגרסה האמיתית במניפסט.
- בוצעה סריקת אבטחה ובדיקת secrets.
- בוצעה סריקת רישיונות וקוד צד ג’.
- התרומה האנושית מתועדת ואינה קוסמטית בלבד.
ברמת הארגון:
- לוגים ו-traceability מתוכננים מראש.
- מוגדר human-in-the-loop לנקודות ההחלטה המשמעותיות.
- קיימת יכולת לאתר ולתקן מקור של פלט שגוי.
- ההסכמים עם הלקוחות, מדיניות הפרטיות והמצגים של הארגון עודכנו.
- הכיסוי הביטוחי נבדק ביחס לתרחישי AI.
סיכום
הדרך הנכונה להסתכל על AI בארגון אינה כבחירה בין איסור מוחלט לבין חופש מוחלט, אלא כשימוש מותר וממוסגר: כלים מאושרים, גבולות מידע ברורים, הגדרה של שימושים רגישים, בקרה אנושית מחייבת, ותיעוד של היכן נעשה שימוש ב-AI ובאיזו מידה.
ארבעת הצירים מתכנסים לארבע שאלות שכל ראש צוות צריך לדעת לענות עליהן בכל רגע נתון:
- בעלות: של מי הקוד, המסמך והתכן שנוצרו בסיוע AI, ומה מוכיח זאת?
- אחריות: מי נושא בנזק אם הפלט שגוי, ומה עשינו כדי להקטין את החשיפה?
- מידע: מה נכנס לכלים, על סמך איזה בסיס, ומי אישר?
- ציות: אילו דרישות כבר חלות עלינו, ומתי נכנסות הבאות?
AI הוא מכפיל כוח אמיתי, אבל יש לכוון אותו. מי שלא יגדיר בעלות, אחריות, גבולות מידע וציות, יגלה בסופו של דבר שהכלים קבעו עבורו את הכללים.
המאמר מספק מידע כללי בלבד ואינו מהווה ייעוץ משפטי. יישום בארגון מסוים מחייב בחינה פרטנית של הנסיבות, הדין החל והשווקים הרלוונטיים.
