ענן פרטי מול ענן ציבורי ל-AI: איפה נשמר המידע ומה מותר לגוף ציבורי
היכן המידע הארגוני שלכם באמת נשמר כשאתם מריצים AI, ואיזה מודל ענן מתאים לגוף ציבורי.
הידעת?
כשמשתמשים בגרסה הארגונית של רוב כלי ה-AI, ההנחיות שלכם לא משמשות לאימון המודל הציבורי. זה בדיוק ההבדל בין החשבון החינמי לחשבון העסקי, והוא קריטי לגוף ציבורי.
כשגוף ציבורי מריץ כלי AI, המידע לא נשאר "אצלכם במחשב", הוא זורם לתשתית של הספק, והשאלה הקריטית היא איזו תשתית. בענן ציבורי ארגוני (קופיילוט, ג'מיני, קלוד בגרסה עסקית) המידע רץ על תשתית משותפת עם בידוד דייר, הצפנה, והסכם שאוסר על אימון המודל על הנתונים שלכם. בענן פרטי או תשתית מקומית המידע נשאר בגבולות שאתם מגדירים. לרוב המשימות ענן ציבורי ארגוני מספיק וחוקי; למידע מסווג או ביומטרי נדרש ענן פרטי או מקומי. המדריך הזה מסביר איפה המידע באמת יושב, ואיך בוחרים נכון.
למה בכלל חשוב איפה המידע נשמר
בגוף ציבורי, ההבדל בין "המידע נשאר אצלנו" ל"המידע עבר לספק בחו"ל" הוא לא ניואנס טכני, הוא שאלה של חוקיות, אמון ציבורי, ולעיתים ביטחון. תושב שמפקיד בידכם מידע אישי מצפה שהוא לא ידלוף, לא יימכר, ולא ישמש לאימון מערכת של חברה זרה. הרגולציה בישראל, ובראשה תיקון 13 לחוק הגנת הפרטיות, מטילה עליכם אחריות ישירה לכל מקום שאליו המידע מגיע.
הבעיה היא שרוב האנשים לא באמת יודעים לאן המידע נוסע כשהם מדביקים טקסט לתוך צ'אט של AI. הם רואים תיבת הקלדה, לא מפת רשת. המדריך הזה נועד לפרק את הערפל: מה קורה מאחורי הקלעים, ומה זה אומר עבור גוף מוסדר.
שלושת מודלי הענן, בשפה פשוטה
יש שלוש דרכים עיקריות שבהן כלי AI יכול לרוץ עבור הארגון שלכם, וההבדל ביניהן הוא בעיקר שאלה של מי הבעלים של השרת ומי עוד יושב עליו.
ענן ציבורי (Public Cloud)
המודל רץ על תשתית ענק של הספק, מיקרוסופט (Microsoft), גוגל, או אמזון. אתם חולקים את אותם שרתים פיזיים עם אלפי ארגונים אחרים, אבל מופרדים מהם בשכבת תוכנה. זה הזול ביותר, המהיר ביותר להטמעה, והחזק ביותר מבחינת ביצועים. כאן רצים קופיילוט (Copilot / Microsoft Copilot), ג'מיני (Gemini) וקלוד (Claude) בגרסאותיהם הרגילות.
ענן פרטי (Private Cloud)
תשתית שמוקצית לארגון שלכם בלבד. אף ארגון אחר לא יושב עליה. לרוב אפשר לקבע אותה לאזור גיאוגרפי מסוים (למשל אזור אירופה או אפילו מרכז נתונים בישראל), ולקבל שליטה הדוקה יותר על מי ניגש ומתי. יקר יותר, אבל נותן שקט נפשי רגולטורי.
תשתית מקומית (On-Premise)
השרתים יושבים פיזית אצלכם, בחדר השרתים של הארגון, ואף ביט לא יוצא החוצה. מתאים למידע הרגיש ביותר. הצד השני של המטבע: אתם אחראים לכל התחזוקה, העדכונים והאבטחה, וזה יקר ומורכב לתפעל.
טבלת השוואה: ציבורי מול פרטי מול היברידי
הטבלה הבאה מסכמת את ההבדלים המעשיים שגוף ציבורי צריך לשקול לפני החלטה.
| קריטריון | ענן ציבורי (ארגוני) | ענן פרטי | מודל היברידי |
|---|---|---|---|
| היכן המידע יושב | תשתית משותפת של הספק, עם בידוד דייר | תשתית ייעודית לארגון, אזור גיאוגרפי מוגדר | מידע רגיש מקומי, שאר המשימות בענן ציבורי |
| עלות | נמוכה, מודל מנוי | גבוהה יותר | בינונית, תלוי בחלוקה |
| מהירות הטמעה | מהירה מאוד | בינונית | בינונית |
| שליטה על מיקום המידע | חלקית (בחירת אזור) | גבוהה | גבוהה למידע הרגיש |
| מתאים למידע רגיש/מסווג | לא למסווג | כן | כן, בחלק המקומי |
| נטל תחזוקה | מינימלי (הספק מתחזק) | בינוני | בינוני עד גבוה |
| מתאים במיוחד ל | רוב המשימות היומיומיות | ארגונים מוסדרים עם דרישת ריבונות | גוף ציבורי עם ערבוב סוגי מידע |
הכלל הפשוט: ככל שהמידע רגיש יותר, כך כדאי לדחוף אותו ימינה בטבלה, לכיוון הפרטי או המקומי. רוב הגופים לא צריכים לפתור הכל בבת אחת, אלא לבחור מודל היברידי שמתאים לפרופיל המידע שלהם.
מה באמת קורה למידע שלכם: הגרסה הארגונית מול החינמית
זו הנקודה החשובה ביותר, וגם המובנת פחות. יש הבדל תהומי בין השימוש בגרסה החינמית של כלי AI לבין הגרסה הארגונית שלו.
בגרסה החינמית (החשבון האישי שכל אחד פותח בבית), הספק שומר לעצמו במקרים רבים את הזכות להשתמש בשיחות שלכם כדי לשפר ולאמן את המודל. במילים אחרות, מה שהזנתם עלול להפוך לחלק ממאגר הידע הכללי. עבור גוף ציבורי, זה קו אדום.
בגרסה הארגונית, לעומת זאת, המצב שונה לחלוטין:
- אין אימון על הנתונים שלכם. ההנחיות והמסמכים שאתם מזינים לא משמשים לאימון המודל הציבורי. זה מעוגן בחוזה.
- הסכם עיבוד נתונים (DPA). הספק חותם על מסמך משפטי שמגדיר בדיוק מה מותר לו לעשות עם המידע.
- בקרות ניהול. מנהל המערכת בארגון שולט מי משתמש, באילו כלים, ומה מותר להזין.
לכן, השאלה הראשונה בכל הטמעה בגוף ציבורי אינה "באיזה כלי נשתמש", אלא "האם אנחנו על החשבון הארגוני שלו". ההבחנה הזו לבדה מסירה חלק ניכר מהסיכון. הרחבנו על עקרונות אלה במדריך הטמעת AI בגוף ציבורי.
בידוד דיירים והצפנה: המנגנונים שמגנים בפועל
כשאומרים "ענן ציבורי בטוח", שני מנגנונים עומדים מאחורי ההבטחה.
בידוד דיירים (Tenant Isolation)
דמיינו בניין משרדים שבו אלפי חברות שוכרות קומות. כולן באותו בניין פיזי, אבל לכל אחת דלת נעולה, מפתח משלה, וכספת נפרדת. כך עובד בידוד דיירים: המידע של הרשות שלכם מבודד לוגית מכל שאר הארגונים על אותה תשתית. גם אם ארגון אחר יושב על אותו שרת פיזי, אין לו שום דרך לגשת לנתונים שלכם.
הצפנה בשתי שכבות
- הצפנה במעבר (in transit): בדרך מהמחשב שלכם לשרת של הספק, המידע מוצפן בפרוטוקול TLS. גם אם מישהו מיירט את התעבורה, הוא רואה ג'יבריש. זה אותו מנגנון שמגן על תעבורה בנקאית.
- הצפנה באחסון (at rest): כשהמידע נשמר על הדיסק בתשתית הספק, הוא מוצפן שם גם כן. גניבה פיזית של דיסק לא תחשוף את התוכן.
שני המנגנונים יחד הם הבסיס לאמון בענן ציבורי ארגוני. הם לא הופכים אותו למתאים למידע מסווג, אבל הם הופכים אותו למתאים לרוב סוגי המידע שגוף ציבורי מטפל בהם ביומיום.
איזה מידע חייב להישאר בבית
לא כל המידע שווה. חלוקה מעשית עוזרת להחליט מה מותר לשלוח לענן ציבורי ומה חייב להישאר מקומי או פרטי.
מידע שלרוב מותר בענן ציבורי ארגוני:
- מסמכים פנימיים כלליים, נהלים, טיוטות.
- ניסוח מכתבים ותשובות לפניות שאינן חושפות פרטים אישיים רגישים.
- ניתוח נתונים מצטברים ואנונימיים.
- סיעור מוחות, תמצות דוחות ציבוריים.
מידע שכדאי להשאיר בענן פרטי או מקומי:
- מידע מסווג או ביטחוני.
- מידע ביומטרי (טביעות אצבע, זיהוי פנים).
- תיקים אישיים מלאים של תושבים עם פרטים רפואיים או פליליים.
- כל מידע שהמכרז או הרגולציה מחייבים במפורש להשאיר בגבולות המדינה.
הגישה הנכונה היא לסווג את המידע לפי רגישות פעם אחת, ואז לגזור מדיניות ברורה: הקטגוריה הזו לענן, הקטגוריה הזו לא. זה בדיוק חלק ממה שנכנס למדיניות AI לארגון, כדי שכל עובד יידע מראש מה מותר להזין ולאן.
אין באמור ייעוץ משפטי; לגבי סיווג מידע והתאמה לרגולציה, התייעצו עם ממונה הגנת הפרטיות או עורך דין.
חמש שאלות שכדאי לשאול ספק לפני החתימה
לפני שגוף ציבורי בוחר כלי AI ומודל ענן, אלה השאלות שמפרידות בין החלטה מושכלת לבין הפתעה מאוחרת:
- היכן פיזית נשמר המידע? באיזה אזור גיאוגרפי יושבים השרתים, והאם אפשר לקבע אותם לאזור מסוים.
- האם הנתונים שלנו משמשים לאימון? דרשו תשובה חד משמעית בכתב, בחוזה, לא בשיווק.
- מהו הסכם עיבוד הנתונים (DPA)? בקשו לראות את המסמך ולבדוק אותו מול הדרישות שלכם.
- איך מתבצע בידוד הדיירים? ודאו שיש הפרדה לוגית ומפתחות הצפנה נפרדים.
- מה קורה למידע כשמסיימים את ההתקשרות? ודאו שיש מנגנון מחיקה מלאה ואישור בכתב.
התשובות לשאלות האלה צריכות להיכנס למפרט המכרז או להסכם ההתקשרות. אם ספק מתחמק מאחת מהן, זה דגל אדום.
דוגמה מהשטח: איך גוף ציבורי מסווג ומחלק
כדי להמחיש איך ההחלטות האלה מתקבלות בפועל, נדמיין רשות מוסדרת (בלי פרטים מזהים) שמתחילה תהליך הטמעה. במקום להתלבט מול כל שימוש בנפרד, היא בונה מפה פשוטה של סוגי המידע ומצמידה לכל אחד מודל ענן.
- מחלקת דוברות ותוכן: מנסחת הודעות לעיתונות, פוסטים ותשובות כלליות לפניות. המידע כאן ציבורי מטבעו. הכל רץ על ענן ציבורי ארגוני, כי אין כאן פרטים אישיים רגישים, והמהירות חשובה.
- מחלקת גבייה ורווחה: מטפלת בתיקים אישיים עם מצב כלכלי, רפואי או משפחתי של תושבים. חלק זה מוגדר מראש כרגיש. עיבוד המידע נשאר על תשתית פרטית או מקומית, ומה שכן עולה לענן עובר קודם אנונימיזציה (הסרת שם, תעודת זהות וכתובת).
- מחלקת כספים: מנתחת נתונים מצטברים ותקציבים. נתונים מאוחדים ולא מזוהים מותרים בענן, אבל קבצי שכר אישיים נשארים בבית.
ההיגיון הזה חוזר על עצמו בכל אגף: קודם שואלים "כמה רגיש המידע", ורק אז מחליטים לאן הוא הולך. פעם שבנו את המפה הזו, ההחלטות היומיומיות הופכות לאוטומטיות, והעובד לא צריך לשקול מחדש בכל פעם. זה בדיוק ההבדל בין הטמעה מבוקרת לבין שימוש פרוע שחושף את הארגון.
מיתוסים נפוצים שכדאי לפרק
סביב הנושא הזה מסתובבות כמה אמונות מוטעות שמעכבות גופים ציבוריים, לחומרה או לקולא. שווה לפרק אותן.
מיתוס: "אם זה בענן, זה אוטומטית לא בטוח." לא נכון. ענן ציבורי ארגוני עם בידוד דייר והצפנה בטוח לרוב המידע, ולעיתים בטוח יותר מחדר שרתים מקומי שלא מתוחזק כראוי. אבטחה היא שאלה של תצורה ותחזוקה, לא של מיקום פיזי בלבד.
מיתוס: "אם זה מקומי, זה בטוח לגמרי." גם לא נכון. שרת מקומי ללא עדכוני אבטחה, ללא גיבוי, וללא בקרת גישה, חשוף יותר מענק ענן שמעסיק צוותי אבטחה ייעודיים. מקומי מעביר אליכם את השליטה, אבל גם את מלוא האחריות.
מיתוס: "כל כלי AI לומד ממה שאני מקליד." נכון רק בחשבונות החינמיים, ולא בהכרח שם. בגרסאות הארגוניות זה מבוטל חוזית. ההבחנה הזו לבדה משנה את כל התמונה.
מיתוס: "מספיק לבחור כלי טוב." הכלי הוא רק חצי מהסיפור. מודל הענן, החוזה, וסיווג המידע הם החצי השני, ולעיתים החשוב יותר עבור גוף מוסדר.
איך זה מתרגם לבחירת כלי בפועל
בשטח, רוב הגופים הציבוריים כבר עובדים בתוך סביבת מיקרוסופט, ולכן קופיילוט הוא לרוב נקודת הפתיחה הטבעית, כי הוא רץ בתוך אותו דייר של Microsoft 365 שכבר מכיל את המידע. אבל זה לא הכלל היחיד, ולכל כלי חוזקות שונות. את ההשוואה המלאה בין הכלים, כולל מתי כל אחד מתאים לארגון, פירטנו במדריך קופיילוט מול ג'מיני מול קלוד לארגון.
העיקרון המנחה זהה בכל מקרה: בוחרים קודם את מודל הענן שמתאים לפרופיל המידע, ורק אז את הכלי הספציפי. לא להיפך. כלי מרשים שרץ על מודל ענן לא מתאים הוא סיכון, לא הזדמנות.
סיכום: המודל ההיברידי הוא ברירת המחדל החכמה
עבור רוב הגופים הציבוריים, התשובה אינה "הכל בענן" או "הכל מקומי", אלא איזון. משימות יומיומיות ומידע כללי רצים בענן ציבורי ארגוני, שנותן ביצועים ומהירות. מידע רגיש ומסווג נשאר על תשתית פרטית או מקומית. סיווג מידע פעם אחת, מדיניות ברורה, וספק עם חוזה תקין, הם שלושת הרכיבים שהופכים את זה לבטוח.
אם אתם מתלבטים איזה מודל ענן מתאים לסוגי המידע שהארגון שלכם מטפל בהם, ואיך לבנות את המדיניות סביבו, זה בדיוק מה שאנחנו עושים בייעוץ AI לארגונים. נשמח ללוות אתכם בבחירה הנכונה.
קורס במתנה עם ברכה אישית מכם — מסירה מיידית או בתאריך שתבחרו, וגישה לכל החיים.