2026-09-02 · 4 דק' קריאה

"השאירו לנו רק את Copilot": מה מדיניות כלי-יחיד פותרת ומה לא

מה כלי ארגוני מאושר כן נותן?

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

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

למה Copilot חושף הרשאות-יתר פנימיות?

כי Copilot לא ממציא גישה — הוא ממנף את ההרשאות הקיימות של המשתמש. כל קובץ שמשותף רחב מדי ב-SharePoint או ב-OneDrive, שאיש לא מצא כי איש לא חיפש, הופך לתשובה זמינה בשאילתה אחת.

קובץ שכר שהועלה לאתר צוות פתוח, מצגת M&A בתיקייה משותפת — לפני Copilot הם היו קבורים; עכשיו מספיק לשאול. זו לא פרצה של הכלי אלא מראה להרשאות שלכם, והרחבנו על כך במדריך הפרטיות של Copilot. מדיניות כלי-יחיד לא פותרת את זה — היא מאיצה את הצורך בסדר בהרשאות.

למה כלי אחד לא מתאים לכל משימה?

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

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

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

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

נושאמדיניות כלי-יחידהסבר
חוזה ארגוני ו-DPA מול הספקפותרתבסיס משפטי לעיבוד במקום חשבון צרכני
אימון מודלים על המידעפותרת ברובההתחייבות ספק בכלי ארגוני — בדקו את המדיניות העדכנית
הרשאות-יתר פנימיותלא פותרתהכלי חושף כל מה שכבר נגיש למשתמש ב-tenant
התאמה לכל סוגי המשימותלא פותרתכלי אחד לא מכסה מחקר, ניתוח וכתיבה מתמחה — נוצר Shadow AI
מסמכים רגישים בפרומפטיםלא פותרתהתוכן עדיין יוצא לענן הספק; רק ניקוי מראש מונע חשיפה

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

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

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

שאלות נפוצות

האם Copilot בטוח יותר מ-ChatGPT חינמי?

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

מה זה oversharing בהקשר של Copilot?

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

למה עובדים עוקפים מדיניות של כלי-יחיד?

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

האם צריך לנקות מסמכים גם לפני הזנה ל-Copilot?

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

האם מדיניות כלי-יחיד עדיפה על חסימה מלאה?

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