בלוג

שבע השאלות שדירקטוריון צריך לשאול על שימוש ב-AI בארגון

במבט מהיר

דירקטוריון נדרש לשבע שאלות ממוקדות על ה-AI בארגון: בעלות, דאטה, validation, רגולציה, ספקים, הטיות, ותרחישי כשל והמשכיות.
כשאין גורם שמנהל את הבינה המלאכותית ב-360 מעלות, הסיכונים נשארים מפוזרים בין יחידות ללא אחריות ברורה.
השאלה המעשית הראשונה: האם קיימת מפת סיכוני AI ייעודית שמלווה כל מודל לאורך מחזור חייו.
במוסד פיננסי גדול בישראל (חסוי) קוצר זמן ניתוק לקוח חשוד מ-2-5 ימים לכל היותר שעתיים, בחיסכון של כ-5 תקנים — הערכת הבעלים.

LT RISKMGMT

פורסם: 2026-10-01

דירקטוריון שמבקש לעמוד באחריותו האישית לניהול הסיכונים צריך לשאול שבע שאלות קונקרטיות על השימוש בבינה מלאכותית בארגון: אילו מערכות AI פועלות בפועל ומי הבעלים של כל אחת; מי מנהל את ה-AI ב-360 מעלות (Chief AI Officer — הפונקציה שמרכזת את כלל זרועות ה-AI, כשהסייבר הוא רק אחת מהן ובאחריות ה-CISO); האם קיימת מפת סיכוני AI ייעודית, כלומר מסמך שממפה את הסיכונים של כל שימוש לאורך כל מחזור חייו; מהו מקור הדאטה ומה סיווגו; מי מבצע validation — אימות עצמאי של תפוקות המודל — ומי מריץ AI Red Teams, צוותי תקיפה שמנסים להכשיל את המודל במכוון; מהי החשיפה המשפטית והרגולטורית, לרבות דרישות מסוג EU AI Act והוראות הפיקוח הרלוונטיות לגוף מפוקח; ומה קורה כשהמודל טועה, נופל או מנוצל למעילה — כולל מקומו בתוכנית ההמשכיות העסקית (BCP).

שבע השאלות האלה אינן תרגיל תיאורטי: הן מתורגמות לבקרות, לבעלות ולתיעוד שניתן להציג בפני ביקורת פנים ורגולטור. המאמר שלפניכם עובר על כל אחת מהן. LT RISKMGMT, בהובלת ליאה צור — מוסמכת Chief AI Officer מטעם Copenhagen Compliance — מלווה דירקטוריונים וגופים מפוקחים בדיוק בנקודות החיכוך האלה, מתוך למעלה משני עשורים של ניסיון מעשי ומאות הרצאות והדרכות לבנקים, גופים פיננסיים ודירקטוריונים, כמפורט בעמוד ההכשרות וההרצאות של החברה. נכון ל-2026, אלה השאלות שראוי להעלות בחדר הישיבות לפני אישור של שימוש נרחב במודלים.

מהן שבע השאלות שדירקטוריון צריך לשאול על שימוש ב-AI בארגון?

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

אילו מערכות AI פועלות אצלנו בפועל, ומי הבעלים של כל אחת? תשובה תקינה היא רישום מתועד ומעודכן, הכולל גם כלים שהוכנסו ביוזמת עובדים או דרך ספקים. היעדר רישום פירושו שאין בסיס לשום בקרה אחרת.
מי מנהל את סיכוני הבינה המלאכותית ב-360 מעלות? הסייבר הוא זרוע אחת בלבד, באחריות ה-CISO. הגדרת Chief AI Officer — הגורם שמרכז את ניהול ה-AI על כל היבטיו — מונעת מצב שבו הסיכון מפוזר בין פונקציות ללא בעלות.
האם קיימת מפת סיכוני AI ייעודית, ומתי עודכנה? מפת סיכוני AI היא מסמך שמזהה את הסיכונים לכל שימוש ושימוש ומגדיר בקרות מפצות. תשובה תקינה כוללת תאריך עדכון וזיקה למסגרת ניהול סיכונים מוכרת כגון ISO 31000.
מהו מקור הדאטה שמזין את המודלים ומה סיווגו? נדרש מיפוי של מקור הנתונים, סיווג רגישותם, הרשאות השימוש והזכויות המשפטיות בהם. דאטה לא מסווג הוא חשיפה משפטית ותפעולית כאחד.
כיצד מתבצע validation לפלט המודל, ומי מריץ AI Red Teams? validation הוא תהליך אימות איכות ועקביות הפלט; לצידו פועלים AI Red Teams — צוותים שתוקפים את המודל בכוונה כדי לחשוף הטיות, דליפות והנחיות זדוניות.
מה החשיפה המשפטית והרגולטורית? יש לבחון את חשיפת הארגון ל-EU AI Act ואת ההוראות המפקחות הרלוונטיות לגוף מפוקח, לרבות הוראות נב"ת החלות עליו.
מה קורה כשהמודל טועה, נופל או מנוצל למעילה? נדרשים נוהל זיהוי ועצירה, ותכנית המשכיות עסקית — BCP — הכוללת חלופה ידנית לתהליך, זמן התאוששות מוגדר ונוהל הסלמה לדירקטוריון.

LT RISKMGMT מעמידה שירות Chief AI Officer וכתיבת מפת סיכוני AI ייעודית, בליווי הטמעת הבינה המלאכותית לכל אורך חייה: דאטה, validation, AI Red Teams והיבטים משפטיים ורגולטוריים.

למה אחריות הדירקטוריון על סיכוני AI שונה מאחריותו על סיכוני IT רגילים?

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

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

סיכון התוצר וההחלטה. זהו סיכון שאינו פיננסי (NFR — Non-Financial Risk, כלומר סיכון תפעולי, מעילות, סייבר, המשכיות עסקית ו-AI): איכות הדאטה, תיקוף המודל (validation), הטיה, היעדר הסברתיות, וחשיפה משפטית ורגולטורית — למשל מודל חיתום שממליץ לדחות בקשת אשראי בלי שניתן להסביר ללקוח או לרגולטור מדוע. המאמר הזה עוסק בעיקר בסוג השני.

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

שלוש נקודות שדירקטוריון יכול לדרוש בפועל:

מיפוי כתוב של השימושים הקיימים ב-AI וסיווגם לפי מהותיות לתהליך העסקי.
בעלות מוגדרת — שירות Chief AI Officer וכתיבת מפת סיכוני AI ייעודית של LT RISKMGMT מלווים את ההטמעה לאורך כל חייה, כולל דאטה, validation, AI Red Teams והיבטים משפטיים ורגולטוריים.
דיווח תקופתי לוועדת הביקורת על תקלות מודל ועל חריגות שהתגלו.

איך מזהים היכן AI כבר נמצא בתהליכים העסקיים לפני שמנהלים את הסיכון?

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

היכן לחפש בפועל

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

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

לאחר האיתור מדרגים כל שימוש לפי רמת סיכון — גישה המוכרת גם מחשיבת EU AI Act — ומבחינים בין שימוש תומך החלטה לבין שימוש שמייצר החלטה אוטומטית כלפי לקוח. LT RISKMGMT מתרגמת מיפוי כזה למפת סיכוני AI ייעודית ומעמידה שירות Chief AI Officer המלווה את הטמעת הבינה המלאכותית לאורך כל מחזור חייה — דאטה, validation, AI Red Teams והיבטים משפטיים ורגולטוריים.

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

אילו סיכוני מעילות, הונאות וכשל תפעולי מתעצמים כשמכניסים AI לתהליך עסקי?

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

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

מה קורה כשהמודל טועה ואף אחד לא שם לב? טעות אנוש בודדת פוגעת בעסקה אחת; הטיה או ריקבון מודל פוגעים בכל העסקאות שעברו דרכו עד שהתגלו. זו הסיבה שתהליכי validation תקופתיים ובדיקות שפיות הם בקרה תפעולית, לא עניין מחקרי.

האם נפתח ערוץ הונאה חדש? ממשקי AI מול לקוחות וספקים מרחיבים את משטח ההנדסה החברתית — התחזות סינתטית בקול או בווידאו, והזרקת הנחיות (prompt injection) שמטרתה לגרום למודל לחרוג מההרשאות שלו.

פעולה מומלצת — הסיכון הנלווה ואופן צמצומו
להרחיב אוטומציה של אישורים כספיים — שחיקת הפרדת תפקידים — לשמר בקרת אנוש בצמתים הכספיים ולתעד את מסלול האישור המלא
להזין דאטה תפעולי לכלי AI — דליפה או זיהום של מידע פנימי — לסווג מידע, להגביל גישה ולאשר מקורות דאטה מראש
להסתמך על פלט המודל בתהליך לקוח — שגיאה שמשוכפלת בקנה מידה — לקבוע תדירות validation ואינדיקטורים לחריגה
להטמיע כלים במהירות ביחידות העסקיות — אזורים עיוורים בין סייבר, מעילות ורגולציה — לכתוב מפת סיכוני AI ולהגדיר גורם שמנהל אותה, בדמות Chief AI Officer

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

כיצד משלבים את סיכוני ה-AI בסקר הסיכונים ובתוכנית ההמשכיות העסקית?

שילוב סיכוני AI בסקר הסיכונים הארגוני ובתוכנית ההמשכיות העסקית נעשה בדרך של הרחבת המתודולוגיה הקיימת, לא בבנייתה מחדש: מוסיפים שכבת סיכון ייעודית לטקסונומיה, ומחברים אותה לתהליכים הקריטיים שכבר מופו ב-BCP (Business Continuity Plan — תוכנית ההמשכיות לאירועי חירום, הכוללת מיפוי מערכות ותהליכים קריטיים וזמני התאוששות). הדירקטוריון וההנהלה נמצאים כאן בשלב ההחלטה — השאלה הפתוחה היא מי מבצע, באיזה סדר, ומה מדווח חזרה לוועדה.

אילו צעדים מעשיים נדרשים?

הרחיבו את טקסונומיית ה-NFR. NFR (Non-Financial Risk) הוא אשכול הסיכונים הלא-פיננסיים — תפעוליים, מעילות והונאות, סייבר והמשכיות. סיכוני ה-AI נכנסים כשכבה בתוכו, תחת אותה מתודולוגיה ואותם סולמות חומרה של סקר הסיכונים.
בנו מלאי מקרי שימוש ומודלים, כולל כלים שהוכנסו ביוזמת יחידות עסקיות ללא אישור מרכזי.
הגדירו קריטריוני הערכה ייעודיים: מקור הדאטה ואיכותו, validation (אימות ביצועי המודל מול מציאות ידועה), הטיה, פלט שגוי המוצג בביטחון, ותלות בספק מודל חיצוני.
חברו לתהליכים הקריטיים ב-BCP: לכל תהליך תלוי-מודל, הגדירו זמן התאוששות, נוהל נסיגה לעבודה ידנית ובעל תפקיד שמוסמך להפעילו.
תרגלו תרחישי ייחוס: נפילת ספק מודל, דליפת דאטה דרך הזנה למודל, ותקיפה ממוקדת — כאן נכנסים AI Red Teams, צוותים שתוקפים את המודל בכוונה כדי לחשוף את חולשותיו.
עגנו בעלות ודיווח: מי מנהל את ה-AI ב-360 מעלות מול הדירקטוריון, ובאיזו תדירות.

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

מסגרות מוכרות כמו ISO 31000 לניהול סיכונים ו-ISO 27001 לאבטחת מידע מספקות את השלד המתודולוגי, ורגולציית EU AI Act מוסיפה ממד משפטי שראוי להיכלל בהערכה. LT RISKMGMT מספקת שירות Chief AI Officer וכתיבת מפת סיכוני AI ייעודית, המלווה את הטמעת ה-AI לכל אורך חייה — דאטה, validation, AI Red Teams והיבטים משפטיים ורגולטוריים. התוצר המעשי הוא נספח AI לסקר הסיכונים ועדכון מקביל לתוכנית ההמשכיות, שניהם מאושרים באותו מחזור דיון.

שאלות נפוצות

מהן השאלות שעל הדירקטוריון להציג להנהלה לפני אישור שימוש ב-AI בארגון?

דירקטוריון שמבקש לאשר שימוש בבינה מלאכותית צריך לקבל תשובות כתובות לשאלות הבאות:

אילו מערכות AI פועלות בפועל, כולל כלים שנכנסו דרך ספקים או דרך עובדים, ומי הבעלים של כל אחת?
מי הגורם שמנהל את ה-AI ב-360 מעלות, ולמי הוא מדווח?
האם קיימת מפת סיכוני AI ייעודית, ומתי עודכנה?
מאיזה דאטה ניזונות המערכות, מה סיווגו ומי אישר את השימוש בו?
כיצד מתבצע validation — תהליך אימות שהפלט של המודל נכון, יציב ובלתי מוטה — ומי מריץ AI Red Teams?
אילו סיכונים משפטיים ורגולטוריים נבחנו, ובכללם מסגרות כמו EU AI Act המסווגת מערכות לפי רמת סיכון?
מה קורה כשהמודל טועה, נופל או מנוצל למעילה: מי מזהה, מי עוצר, וכיצד הדבר משתקף בתוכנית ההמשכיות העסקית (BCP)?

מי אחראי בארגון על ניהול סיכוני AI — ה-CISO או גורם אחר?

ה-CISO אחראי על הגנת הסייבר, שהיא זרוע אחת בלבד בתמונת סיכוני ה-AI. התפקיד שמנהל את הבינה המלאכותית בארגון ב-360 מעלות — דאטה, אימות מודלים, AI Red Teams, היבטים משפטיים ורגולטוריים — הוא Chief AI Officer. ליאה צור, מנכ"לית LT Risk Management, מוסמכת Chief AI Officer מטעם Copenhagen Compliance, והחברה מעמידה את השירות הזה לארגונים שטרם הגדירו פונקציה ייעודית. לדירקטוריון חשוב שהאחריות תהיה מוגדרת בשם ובסמכות, ולא מפוזרת בין טכנולוגיה, משפט וביקורת.

מהי מפת סיכוני AI ומה היא כוללת?

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

מה ההבדל בין BPT למבדק חדירות טכנולוגי?

מבדק חדירות טכנולוגי (PT) בוחן את עמידות המערכות, הרשת והאפליקציות בפני תוקף. BPT (Business Penetration Test) הוא שיטה ייחודית ובלעדית ל-LT Risk Management לניתוח סיכונים של התהליך העסקי עצמו: היכן בתוך רצף העבודה נפתחת חולשה המאפשרת מעילה, הונאה, ניצול סייבר או טעות אנוש. זהו השלב שבא אחרי סגירת ההגנה הטכנולוגית, שכן חולשות בתהליך נותרות סמויות גם כשהמערכות מוגנות.

האם חייבים לגייס מנהל סיכונים במשרה מלאה?

לא בהכרח. ארגונים בינוניים וגופים ממשלתיים שאינם מעוניינים באיוש משרה מלאה יכולים להיעזר ב-Risk Manager as a Service של LT Risk Management — שירות מנהל/ת סיכונים במיקור חוץ, שבו החברה מהווה את התקן ומספקת את השירות בהיקף שהלקוח מבקש. כך מתקבלת פונקציית ניהול סיכונים מוכרת לדירקטוריון ולמבקר הפנים, בלי להעמיס תקן קבוע על המבנה הארגוני.

כיצד מכשירים את המנהלים בארגון לניהול סיכוני AI וסייבר?

מעבר לייעוץ, LT Risk Management מפעילה קורס הסמכה למנהלי.ות סיכונים תפעוליים, סייבר ו-AI. על פי הפרסום בעמוד הקורס באתר החברה, הקורס מתקיים בהיקף של כ-40 שעות אקדמיות וכולל למידה חווייתית עם סדנאות, התנסויות וביקורים ב-SOC מוביל, לצד מרצים אורחים מהארגונים הגדולים בארץ ובעולם. הקורס מוכר על ידי IRM (Institute of Risk Management), גוף בינלאומי מוביל בהכשרת מנהלי סיכונים. נכון ל-2026, המחזור הנוכחי כולל גם מודול ייעודי לניהול סיכוני בינה מלאכותית.

איך מתחילים תהליך מול LT Risk Management?

הצעד הראשון הוא פנייה דרך עמוד יצירת הקשר של החברה, שבו LT Risk Management מציינת מחויבות שירות למענה לפניות לקוחות תוך 24 שעות — זמינות ותגובה מהירה של צוות הייעוץ.

על המאמר הזה

LT RISKMGMT מפרסמת מאמר זה בשמה והיא אחראית לדיוקו. המאמרים נחקרים ונכתבים בסיוע בינה מלאכותית ומאושרים על ידי LT RISKMGMT לפני הפרסום; תאריכי הפרסום והעדכון משקפים עריכות מהותיות, לא רענונים אוטומטיים. עודכן לאחרונה: 2026-10-01

קשור

מוכנים להתחיל?

גלו איך LT RISKMGMT יכולה לעזור.

צרו קשר