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

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

נבדק לאחרונה: ספטמבר 2026. המידע כללי ואינו ייעוץ משפטי.

למה פרויקטי GenAI נתקעים בבנקים ובחברות ביטוח

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

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

מה ההוראות אומרות

בנקים: הוראות ניהול בנקאי תקין של בנק ישראל

• [הוראה 362, "מחשוב ענן"](https://www.boi.org.il/media/y3thgmut/362.pdf) (עודכנה לאחרונה ביוני 2026). בנקים רשאים להשתמש בשירותי ענן, גם למערכות מהותיות. הדירקטוריון מאשר מדיניות ענן, כל שירות ענן עובר הערכת סיכונים לפני ההתקשרות, והמידע מוצפן בתעבורה ובאחסון, לפחות המידע שסווג כרגיש. מידע רגיש עובר לענן מחוץ לישראל רק אחרי שהבנק וידא שהספק עומד ברמת ההגנה של ה-GDPR. ההוראה לא חלה על "ענן פרטי": תשתית שמוקצית לשימוש בלעדי של בנק אחד, בחצריו או מחוצה להם.
• [הוראה 364, "ניהול סיכוני טכנולוגיית המידע, אבטחת המידע והגנת הסייבר"](https://www.boi.org.il/media/0vvpnqtw/h2799.pdf). פורסמה בנובמבר 2024 ונכנסה לתוקף במאי 2026, במקום הוראות 357, 361 ("ניהול הגנת הסייבר") ו-363. סעיף 43 מחייב לסווג פעילויות, תהליכים ונכסי מידע לפי קריטיות ורגישות. סעיף 61.7 מחייב נתיב ביקורת שמתעד מי ניגש, מאיפה, מתי ולאיזה מידע.
• [הוראה 369, "ניהול סיכוני מודלים"](https://www.boi.org.il/media/mcyfqkkp/h2792.pdf). בתוקף מאוגוסט 2025. היא חלה גם על מודלים שמשתמשים בבינה מלאכותית או מבוססים עליה, וגם על מודלים של ספקים. לגבי מודלי AI היא מדגישה הוגנות והטיה, אחריותיות שמותאמת למידת המעורבות האנושית, יכולת הסבר ותיעוד מלא, כולל הנתונים ששימשו לפיתוח המודל ולתיקופו.

חברות ביטוח וגופים מוסדיים: רשות שוק ההון, ביטוח וחיסכון

• [חוזר גופים מוסדיים 2016-9-14, "ניהול סיכוני סייבר בגופים מוסדיים"](https://www.gov.il/BlobFolder/dynamiccollectorresultitem/2016-9-14/he/2016-9-14.pdf) מכפיף שימוש בענן לכללי מיקור החוץ ודורש הערכת סיכונים ייעודית לפני שמתחילים. מידע רגיש ונתוני לקוחות יכולים להיות מאוחסנים בענן בחו״ל רק אצל ספק שנבדק מול תקנות הגנת הפרטיות והדירקטיבה האירופית, ומידע רגיש חייב להיות מוצפן שם. במערכות Multi-tenant החוזר דורש הצפנה, מיסוך נתונים או טוקניזציה.

כל מי שמחזיק מידע אישי

• [תיקון 13 לחוק הגנת הפרטיות](https://www.gov.il/BlobFolder/reports/guide_tikon13_professional/he/tikun%2013%20_170825.pdf) בתוקף מ-14 באוגוסט 2025. בנקים וחברות ביטוח חייבים למנות ממונה על הגנת הפרטיות וממונה על אבטחת מידע. את הצד ההנדסי פירטנו במדריך שלנו לתיקון 13.
• טיוטת ההנחיה של הרשות להגנת הפרטיות, "תחולת הוראות חוק הגנת הפרטיות על מערכות בינה מלאכותית" (אפריל 2025), קובעת שתסקיר השפעה על הפרטיות לפני שימוש ב-AI על מידע אישי הוא הדרך המומלצת להוכיח עמידה בדין. היא גם מבקשת מדיניות לשימוש עובדים בכלי GenAI חיצוניים: מי רשאי להשתמש, איזה מידע מותר להזין, כמה זמן נשמרות השאילתות ואיך מסרבים לאימון על המידע.

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

שלוש ארכיטקטורות, זו מול זו

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

• את "האזור הישראלי" צריך לבדוק. Amazon Bedrock פועל באזור תל אביב של AWS מספטמבר 2025, אבל Cross-Region inference שולח בקשות לעיבוד באזורים אחרים. בכל ענן, בדקו את סוג הפריסה של כל מודל ותעדו איפה רצה כל בקשה.
• קראו את תנאי הספק. Anthropic מצהירה שכברירת מחדל היא לא מאמנת מודלים על קלט ופלט מהמוצרים המסחריים שלה, כולל ה-API (מרכז הפרטיות של Anthropic). אצל כל ספק, בדקו כמה זמן נשמר המידע ומי קבלני המשנה. הוראה 362 מחייבת שהספק יישאר אחראי כלפי הבנק, גם כשהוא נעזר בספק משנה.

גם העוזר הארגוני שלנו, Enterprise AI Assistant, בנוי לפי העמודה האמצעית: הוא רץ בתוך ה-Tenant של הלקוח ב-Azure, והשירותים שלו מדברים ביניהם דרך Private Endpoints.

קודם מסווגים את המידע, אחר כך בוחרים מודל

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

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

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

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

RAG או Fine-tuning?

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

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

נתיב ביקורת ואדם בתהליך

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

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

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

למעורבות אנושית אנחנו בונים שלוש רמות:

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

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

ניהול סיכוני מודלים ל-LLM

התייחסו לכל מקרה שימוש ב-LLM כמו שהוראה 369 מתייחסת לכל מודל:

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

הטמעה בשלבים

1. מוכנות. רשימת מקרי שימוש, סיווג מידע, ארכיטקטורה לכל מקרה, מדיניות לשימוש עובדים ב-GenAI ומלאי מודלים. הערכת מוכנות ל-AI אצלנו מתחילה ב-15,000 ש״ח ויכולה להגיע ל-45,000 ש״ח.
2. עוזר פנימי על מידע שאינו של לקוחות. RAG על נהלים, כניסה אחידה (SSO), שליפה לפי הרשאות ותיעוד מלא. עוזר RAG שמחובר למערכת אחת או שתיים מתחיל ב-45,000 ש״ח ויכול להגיע ל-150,000 ש״ח.
3. כלים לעובדים על נתוני לקוחות. מיסוך, DLP, סטים של בדיקות ותיקוף לפי הוראה 369.
4. טיוטות ללקוחות. מכתבים, סיכומי תביעות ותשובות שירות, כל אחת באישור של אדם.
5. סוכנים ותמיכה בהחלטות. פתרון AI מלא ב-Production מתחיל ב-150,000 ש״ח ויכול לעבור את 450,000 ש״ח, עם תיקוף מלא ונקודות אישור.

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

שאלות נפוצות

האם בנקים בישראל יכולים להשתמש ב-LLM בענן? כן, לפי הוראה 362: מדיניות ענן באישור הדירקטוריון, הערכת סיכונים לפני כל התקשרות בענן, הצפנה, ורמת הגנה של GDPR למידע רגיש שמעובד מחוץ לישראל. הוראות 364 ו-369 חלות גם הן.

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

האם חברת ביטוח חייבת LLM על שרתים משלה בשביל נתוני לקוחות? חוזר 2016-9-14 מתיר שימוש בענן לפי כללי מיקור החוץ, וקובע תנאים למידע רגיש ולנתוני לקוחות בענן בחו״ל. אם שרתים פנימיים שווים את העלות, זה תלוי בסוג המידע ובמקרה השימוש.

RAG או Fine-tuning לבנק? התחילו ב-RAG כשהידע משתנה, כשהתשובה צריכה מקור וכשהגישה תלויה בהרשאות. Fine-tuning מתאים למשימות צרות ויציבות, ואת נתוני האימון שלו מתעדים לפי הוראה 369.

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