במבט מהיר
- מנהל מחלקה צריך לשאול ספק AI שבע שאלות ליבה: איפה נשמר המידע, מי ניגש אליו, והאם הוא מאמן מודלים.
- שאלות המשך קריטיות: שמירה ומחיקה של נתונים, בידוד בין לקוחות, תיעוד גישה, ספקי משנה ומסלול יציאה.
- אייג'נטים ארגוניים — מערכות AI אוטונומיות שמבצעות משימות בארגון — מחייבים בדיקת הרשאות נפרדת מזו של צ'אט רגיל.
- קורס אסטרטגיית AI למנהלים של הכשרת המנהלים באוניברסיטה העברית מעניק תעודת ניהול AI מבית הספר למנהל עסקים.
Huji AI for Managers Course
פורסם:
מנהל מחלקה — במשאבי אנוש, כספים, תפעול או פיתוח — חייב לשאול ספק AI שבע שאלות אבטחה לפני שמסמך ארגוני אחד עולה למערכת: היכן נשמרים הנתונים פיזית ולוגית, האם הקלט שלי משמש לאימון מודלים, מהי מדיניות השמירה והמחיקה בפועל, מי בצד הספק יכול לגשת לתוכן, כיצד מובטח בידוד בין לקוחות, איזה תיעוד גישה ואודיט אני מקבל, ואילו ספקי משנה מעורבים בשרשרת העיבוד. שאלה שמינית, שמנהלים נוטים לדלג עליה, היא שאלת היציאה: מה קורה למידע, לאינדקסים ולהגדרות כשהחוזה נגמר. אלה אינן שאלות למחלקת ה-IT בלבד — מנהל פונקציונלי הוא זה שמחזיק את המידע הרגיש, ולכן הוא זה שחייב לדעת לנסח את הדרישה ולזהות תשובה מתחמקת.
שאלה כללית כמו "האם אתם מאובטחים?" אינה מספיקה. ניסוח מדויק יותר הוא "האם ההנחיות, הצרופות והפלטים שלי נשמרים מחוץ למרחב האימון של המודל, ולכמה זמן?", והוא מחייב את הספק להשיב בפרטים שניתן לעגן בחוזה. הדרישה הזו חשובה במיוחד כשמדובר בהטמעת AI ברמת תהליך — לא שימוש מזדמן בצ'אט אלא הזרמת חוזים, תלושי שכר, נתוני לקוחות או קוד קנייני אל שכבת מודל חיצונית, ובוודאי כשהארגון מתחיל להריץ אייג'נטים, כלומר מערכות AI אוטונומיות שמבצעות משימות בתוך הארגון ופועלות בהרשאות של עובד ולא של משתמש שואל. בשנת 2026, מנהלים שמכניסים AI לתהליכי העבודה נדרשים להגדיר מודל אחריות, גבולות מידע וקריטריונים לבחירת ספק. קורס אסטרטגיית AI למנהלים של הכשרת המנהלים באוניברסיטה העברית בנוי סביב ההתנסות המעשית הזו: מנהלים מתנסים בהטמעת כלי AI בארגונם ובבניית מערכת AI פנים-ארגונית, ובסיום מוענקת תעודת ניהול AI מבית הספר למנהל עסקים של האוניברסיטה העברית.
אילו שאלות אבטחה קריטיות חייב מנהל מחלקה לשאול ספק AI לפני החתימה?
שאלות האבטחה שמנהל מחלקה חייב לשאול ספק AI לפני החתימה מצטמצמות לסוגיה אחת: מה בדיוק קורה למידע הארגוני מרגע שהוא נכנס למודל. הסעיף הזה אינו עוסק בכלל בבחירת ספק או בתמחור, אלא רק בסעיפי הנתונים והבקרה שחייבים להופיע בהסכם — במיוחד כשמדובר באייג'נטים, כלומר מערכות AI אוטונומיות שמבצעות משימות בתוך הארגון ולכן מקבלות גישה רחבה יותר ממה שממשק שיחה רגיל דורש.
אילו מאפייני אבטחה יש למפות מול הספק?
| מאפיין | מה לשאול / ערכים אפשריים | למה זה משנה למנהל המחלקה |
|---|---|---|
| שימוש בנתונים לאימון | אימון כברירת מחדל / opt-out / איסור חוזי מלא | מסמכים רגישים שנכנסו לאימון אינם ניתנים לשליפה חזרה |
| שמירת מידע (retention) | ללא שמירה / חלון קצר / שמירה בלתי מוגבלת | קובע את היקף החשיפה בעת אירוע אבטחה אצל הספק |
| מיקום עיבוד ואחסון | בישראל / באיחוד האירופי / ענן ציבורי גלובלי | משפיע על עמידה בדרישות הגנת פרטיות ועל חקירות משפטיות |
| הפרדת דיירים | סביבה משותפת / לוגית / ייעודית | מונע דליפה בין ארגונים החולקים את אותה תשתית |
| הרשאות האייג'נט | קריאה בלבד / כתיבה / ביצוע פעולות במערכות ליבה | אייג'נט עם הרשאות עודפות הופך טעות מודל לנזק תפעולי |
| תיעוד ובקרה | לוגים מלאים ונגישים ללקוח / חלקיים / אין | בלי תיעוד אי אפשר לשחזר מי שאל מה ומה הוחזר |
| מחיקה ויציאה | מחיקה מאומתת בתוך זמן מוגדר / ללא התחייבות | מגדיר את עלות המעבר לספק אחר |
| תקינה חיצונית | ISO 27001, SOC 2, עמידה ב-GDPR | מעבירה חלק מנטל הבדיקה לביקורת בלתי תלויה |
לצד הטבלה, שתי שאלות פתוחות מחדדות את התמונה: מי נושא באחריות כשהמודל מייצר פלט שגוי שמשפיע על לקוח, והאם הספק מאפשר להריץ את היישום בסביבה סגורה. סביבה סגורה כזו היא ההסדר שמאפשר לעבוד עם מידע רגיש בלי להעלות אותו למודל ציבורי, ואבטחת מידע באמצעות אייג'נטים פנים-ארגוניים היא אחד הנושאים שקורס אסטרטגיית AI למנהלים של הכשרת המנהלים באוניברסיטה העברית עוסק בהם.
כיצד מוודאים היכן מאוחסנים הנתונים, מי ניגש אליהם ולכמה זמן הם נשמרים?
כדי לוודא היכן מאוחסנים הנתונים, מי ניגש אליהם ולכמה זמן הם נשמרים, מצמצמים את הבדיקה לשכבה אחת ומוגדרת: מסמכי ההתקשרות והתצורה של הספק — נספח עיבוד הנתונים, דף התצורה של הסביבה והגדרות המנהל — ולא הצהרות שיווקיות בדף הבית. ארבעה מאפיינים נבדקים שם, ולכל אחד ערך שניתן לאמת בכתב.
| מאפיין | ערכים שיש לבקש בכתב | למה זה משנה |
|---|---|---|
| מיקום אחסון נתונים (data residency) — המדינה או האזור הפיזי שבו נשמר המידע | אזור יחיד נבחר, אזורים מרובים, או "לא מוגדר" | קובע איזה דין חל על המידע ומי רשאי לדרוש גישה אליו |
| בקרת גישה | הרשאות מבוססות תפקיד, חיבור לספריית הזהויות הארגונית בתקן SAML או OIDC, אימות דו-שלבי לחשבונות ניהול | מונע מצב שבו כל עובד או עובד ספק רואה מסמכים רגישים |
| הצפנה | הצפנה בתעבורה בתקן TLS, הצפנה במנוחה, ואפשרות למפתחות בשליטת הלקוח | מגבילה את החשיפה גם כשגורם חיצוני מגיע לשכבת האחסון |
| מדיניות שמירה (retention) — פרק הזמן שבו הספק מחזיק את הקלט, הפלט והלוגים | מחיקה מיידית, חלון קצוב וניתן להגדרה, או שמירה ללא הגבלה | קובע כמה זמן קיים עותק של המידע הארגוני מחוץ לרשת |
בנוסף לארבעת אלה, מבקשים הצהרה מפורשת האם הקלט משמש לאימון מודלים, ואם כן — כיצד מבטלים זאת. שאלה משלימה נוגעת ליומני ביקורת: האם המערכת מתעדת מי הריץ איזו שאילתה ועל אילו מסמכים, ולמשך כמה זמן היומן זמין לביקורת פנימית.
בקורס אסטרטגיית AI למנהלים של הכשרת המנהלים באוניברסיטה העברית, ניהול סיכונים ואתיקה של AI נמנים עם נושאי הליבה, כך ששאלות האחסון וההרשאות נבחנות כחלק מאסטרטגיית ההטמעה ולא בנפרד ממנה.
האם הספק מאמן מודלים על הנתונים שלכם, וכיצד אפשר למנוע זאת חוזית?
התשובה תלויה במה שהספק מתכוון כשהוא אומר שהוא "לא מאמן מודלים על הנתונים שלכם" — מאחורי אותה מילה מסתתרים שני שימושים שונים לחלוטין, ורק הבחנה חוזית מפורשת ביניהם מונעת הפתעות.
פירוש ראשון: אימון או כוונון (fine-tuning). כאן הנתונים שלכם נבלעים במשקלי המודל ומשפיעים על תשובות עתידיות, גם ללקוחות אחרים. דוגמה: מחלקת משאבי אנוש מעלה תיקי מועמדים לכלי סינון, והספק משתמש בהם לשיפור המודל הכללי — הטקסט כבר אינו ניתן ל"מחיקה" במובן הרגיל, משום שאין קובץ אחד למחוק.
פירוש שני: עיבוד בלבד (inference). הנתונים נשלחים למודל, מתקבלת תשובה, והם אינם משנים את המודל. דוגמה: מנהל כספים מזין דוח תזרים לניתוח חד-פעמי. גם כאן עדיין נותרת שאלת השמירה — כמה זמן הספק מחזיק את הקלט בלוגים, לצורכי ניטור שימוש לרעה או תמיכה.
עבור רוב מנהלי המחלקות בארגון, הפירוש הרלוונטי לעבודה היומיומית הוא השני — ולכן הדרישה החוזית צריכה לכסות גם עיבוד וגם שמירה, לא רק אימון:
| סעיף חוזי | מה הוא חוסם |
|---|---|
| איסור מפורש על אימון וכוונון | שימוש בקלט הלקוח לשיפור מודלים, כלליים או ייעודיים |
| אפס שמירת נתונים או חלון שמירה קצוב | החזקת קלטים ופלטים בלוגים מעבר לזמן מוגדר |
| בעלות וסודיות על קלט ופלט | טענת רישיון של הספק לתוכן שהעליתם |
| רשימת קבלני משנה וזכות התנגדות | העברה שקטה לספק תשתית או מודל נוסף |
| מחיקה מאומתת בסיום ההתקשרות | שאריות נתונים אצל הספק לאחר הפסקת השירות |
מנהלים שמבקשים לצמצם את החשיפה מלכתחילה בוחרים בארכיטקטורה פנים-ארגונית — כך שהשאלה איזה מידע בכלל יוצא החוצה נבחנת עוד לפני ניסוח החוזה.
אילו תקנים ואישורים כמו SOC 2, ISO 27001 ו-GDPR כדאי לדרוש וכיצד מאמתים אותם?
דרישת תקנים כמו SOC 2 ו-ISO 27001, לצד עמידה מוכחת ב-GDPR, היא נקודת הפתיחה של כל שיחת רכש מול ספק בינה מלאכותית. SOC 2 Type II הוא דוח ביקורת של רואה חשבון בלתי תלוי הבוחן את אפקטיביות בקרות האבטחה של הספק לאורך תקופה מוגדרת, ולא ברגע אחד. ISO/IEC 27001 הוא תקן בינלאומי להסמכת מערכת ניהול אבטחת מידע, כלומר לתהליכי הניהול עצמם. GDPR הוא רגולציית הגנת הפרטיות האירופית, שהביטוי המעשי שלה בחוזה הוא הסכם עיבוד נתונים (DPA) ורשימת קבלני משנה.
משמעות הדבר עבור מנהל מחלקה פשוטה: אם דורשים תקן, חייבים גם לדעת לקרוא את ההוכחה. לוגו באתר הספק אינו אישור.
| התקן | מה הוא באמת מוכיח | איך מאמתים |
|---|---|---|
| SOC 2 Type II | שהבקרות פעלו בפועל לאורך תקופת הביקורת | לבקש את הדוח המלא תחת NDA ולקרוא את פרק החריגים ותאריכי התקופה |
| ISO/IEC 27001 | שקיימת מערכת ניהול אבטחת מידע מוסמכת | לבדוק את הצהרת ההיקף, תוקף התעודה וזהות גוף ההסמכה המוסמך |
| GDPR / DPA | מסגרת חוזית לעיבוד מידע אישי | לוודא מיקום אחסון הנתונים, רשימת קבלני משנה וסעיף מפורש של אי-אימון מודלים על נתוני הלקוח |
שלוש שאלות ההמשך שמפרידות בין אישור פורמלי לרלוונטי: האם היקף התעודה מכסה את השירות הספציפי שאתם רוכשים, האם תקופת הביקורת חופפת לשנה הנוכחית, ומה קורה לנתונים בעת סיום ההתקשרות.
היכולת לנהל את הדיון הזה נלמדת. בקורס אסטרטגיית AI למנהלים של הכשרת המנהלים באוניברסיטה העברית הסגל משלב אקדמיה ותעשייה — ד"ר יוחנן ביגמן, חבר סגל בבית הספר למנהל עסקים המלמד אסטרטגיה עסקית ואתיקה עסקית, לצד אבי ויזל, מנהל קשרי אקדמיה ב-IBM ישראל לפי רישום של משרד החינוך.
מה ההבדל בסיכון בין שירות AI ציבורי, ענן פרטי ומודל מקומי בארגון?
ההבדל בסיכון בין שירות AI ציבורי, ענן פרטי ומודל מקומי נמדד בשלושה משתנים: היכן הנתונים נחים, מי מחזיק במפתחות ההצפנה ומי אחראי לתיעוד הגישה. לפני שמשווים חלופות פריסה, כדאי להגדיר את קריטריוני ההערכה ולשקלל אותם לפי רגישות המידע במחלקה שלכם.
קריטריוני ההשוואה, לפי סדר משקל מומלץ:
- שליטה בנתונים — האם הפרומפטים והמסמכים נשמרים אצל הספק, ולכמה זמן. זהו הקריטריון הכבד ביותר כשמדובר בנתוני עובדים, מטופלים או תושבים.
- משטח חשיפה — מספר הגורמים שיכולים לגעת במידע: הספק, ספקי משנה, ומודלים שהוכשרו מחדש.
- מורכבות תפעולית — האם נדרש צוות פנימי לתחזוקה, ניטור ועדכוני מודל.
- עלות — לא רק מחיר השימוש, אלא גם עלות הבקרה, הביקורת והאנשים.
| מודל פריסה | שליטה בנתונים | משטח חשיפה | מורכבות תפעולית | פרופיל עלות |
|---|---|---|---|---|
| שירות ציבורי (למשל ChatGPT בגרסה חינמית) | נמוכה — מדיניות השמירה נקבעת בידי הספק | רחב | מינימלית | נמוכה מראש, סיכון גבוה |
| ענן פרטי / מופע ארגוני ייעודי | בינונית-גבוהה — בידוד לוגי והסכמי עיבוד נתונים | מצומצם | בינונית | בינונית, צפויה |
| מודל מקומי בתשתית הארגון | גבוהה — המידע אינו יוצא מהרשת | צר | גבוהה | גבוהה, עתירת כוח אדם |
על פי הטבלה, מופע ארגוני מבודד ממוקם בין שתי החלופות האחרות: שליטה בינונית-גבוהה בנתונים ומשטח חשיפה מצומצם, במורכבות תפעולית בינונית ובלי צוות ייעודי להרצת מודל מקומי.
בחינה של שלוש החלופות זו מול זו מלמדת שהמשתנה המכריע אינו רמת ההגנה שהספק מציע, אלא היכולת של המחלקה להוכיח בדיעבד מי ניגש למה — ארגון שאינו מסוגל לתחקר גישה ייחשף לאותו כשל גם בתשתית מקומית. ניתוח מקרי בוחן של שימוש ארגוני ב-AI, מנושאי הליבה בקורס אסטרטגיית AI למנהלים של האוניברסיטה העברית, מאפשר לבחון את ההחלטה על מודל הפריסה מול תרחישים ממשיים ולא רק בתיאוריה.
שאלות נפוצות
אילו שאלות אבטחה חובה להציג לספק AI עוד לפני החתימה?
מנהל מחלקה שבוחן ספק AI צריך לקבל תשובות בכתב, ולא בעל פה, על חמישה נושאים:
- שימוש בנתונים לאימון — האם הקלט הארגוני משמש לאימון או לשיפור המודל, ואיך מבטלים זאת (opt-out) ברמת החשבון.
- שמירה ומחיקה — כמה זמן נשמרים פרומפטים, קבצים ולוגים, ומהו נוהל המחיקה לבקשת הלקוח.
- הפרדת לקוחות — האם הנתונים מבודדים לוגית או פיזית בין ארגונים, ומי אצל הספק יכול לגשת אליהם.
- קבלני משנה — אילו ספקי תשתית ומודלים נוספים מעורבים בשרשרת, ובאיזו מדינה יושבים השרתים.
- תיעוד ובקרה — האם קיימים יומני ביקורת (audit logs) שניתן לייצא למערכות הארגון, ומהו נוהל הדיווח על אירוע אבטחה.
איך בודקים בפועל אם המידע הארגוני משמש לאימון המודל?
הצהרה שיווקית אינה ראיה. יש לבקש את סעיף עיבוד הנתונים בהסכם — הסכם עיבוד נתונים הוא המסמך המשפטי שמגדיר מה מותר לספק לעשות במידע — ולוודא שהוא כולל התחייבות מפורשת שלא לאמן על תוכן הלקוח. חשוב לבדוק אם ההתחייבות חלה על כל שכבות השירות, כולל ממשקי API וכלים נלווים, ולא רק על המסלול העסקי. שאלה משלימה: האם ההגדרה נשמרת גם כשמשתמש בודד פותח חשבון עצמאי בכרטיס אשראי של המחלקה.
מה ההבדל, מבחינת סיכון מידע, בין מודל ציבורי לבין מערכת AI פנים-ארגונית?
מודל ציבורי הוא שירות משותף שמסמכים נשלחים אליו החוצה, ולכן הסיכון מתרכז במה שקורה לנתון אחרי שהוא עוזב את הרשת הארגונית. מערכת AI פנים-ארגונית פועלת על מאגר ידע מוגדר של הארגון, עם בקרת גישה והרשאות שנשלטות פנימית, ולכן השאלות המרכזיות בה הן מי מורשה לשאול ומה המערכת רשאית להחזיר. קורס אסטרטגיית AI למנהלים של הכשרת המנהלים באוניברסיטה העברית מתרגל את ההבחנה הזו בפועל: המשתתפים מתנסים בהטמעת כלי AI בארגונם ובבניית מערכת AI פנים-ארגונית, כפי שמתאר סיקור השוואת הקורסים של TechMonster.
אילו הרשאות צריך להגביל לאייג'נט שפועל בתוך הארגון?
אייג'נטים הם מערכות AI אוטונומיות שמבצעות משימות בתוך הארגון — ולכן הן צריכות להיבחן כמו משתמש בעל הרשאות, לא כמו כלי עזר. יש להגדיר מראש לאילו מקורות מידע האייג'נט ניגש, אילו פעולות מותר לו לבצע בלי אישור אנושי (שליחת דוא"ל, עדכון רשומה, ביצוע תשלום), ואיפה נדרש אישור מפורש. בנוסף כדאי לדרוש מהספק הסבר על אופן ניהול המפתחות והאסימונים שהאייג'נט מחזיק, ועל האפשרות לנתק אותו מיידית ממערכות הליבה.
מי בארגון אחראי לאשר ספק AI, ומה תפקידו של מנהל המחלקה?
האישור הפורמלי לרוב נמצא אצל גורמי אבטחת מידע, משפט ורגולציה, אך מנהל המחלקה הוא זה שמגדיר את התרחיש העסקי ואת סוג המידע שייכנס לכלי — ולכן הוא זה שקובע בפועל את רמת החשיפה. מנהל משאבי אנוש שמזין תלונות עובדים, או מנהל כספים שמעלה דוחות לא מפורסמים, נדרש להצהיר על סיווג המידע לפני שהספק נבחן. בלי הגדרה כזו, ביקורת האבטחה בודקת מערכת בלי להכיר את הנתון שיזרום דרכה.
איך מנהל שאינו טכנולוג לומד לשאול את השאלות האלה?
השאלות האלה אינן דורשות ידע תכנותי; הן דורשות יכולת לתרגם סיכון עסקי לדרישה טכנית מהספק. קורס אסטרטגיית AI למנהלים באוניברסיטה העברית עוסק ביכולת הזו: הוא מיועד למנהלים בכירים, מנכ"לים ובעלי עסקים, מתקיים בפורמט היברידי — פרונטלי בהר הצופים או אונליין — ומסתיים בתעודת ניהול AI מבית הספר למנהל עסקים, על פי רישום הקורסים העצמאי study.co.il. הסגל משלב את שני הצדדים של השאלה: ד"ר יוחנן ביגמן, חבר סגל בבית הספר למנהל עסקים של האוניברסיטה העברית, מלמד אסטרטגיה עסקית ואתיקה עסקית, ולצדו אבי ויזל, שעל פי מקור עצמאי של משרד החינוך משמש מנהל קשרי אקדמיה ב-IBM ישראל, מביא את הפרספקטיבה של ספק התשתית.
על המאמר הזה
Huji AI for Managers Course מפרסמת מאמר זה בשמה והיא אחראית לדיוקו. המאמרים נחקרים ונכתבים בסיוע בינה מלאכותית ומאושרים על ידי Huji AI for Managers Course לפני הפרסום; תאריכי הפרסום והעדכון משקפים עריכות מהותיות, לא רענונים אוטומטיים. עודכן לאחרונה: 2026-09-14