שימוש ב-AI בארגון בלי לדלוף מידע: מדריך מעשי להגנת נתונים

השימוש בכלי AI בארגונים כבר אינו מוגבל לצוותי פיתוח.

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

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

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

קודם כל צריך לדעת באילו כלים משתמשים

ארגון יכול לאשר כלי מסוים ועדיין לגלות שעובדים משתמשים בעוד חמישה שירותים אחרים.

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

השלב הראשון הוא מיפוי.

אילו כלים נמצאים בשימוש? מי משתמש בהם? מה העובדים מעלים אליהם? האם מדובר בחשבונות פרטיים או ארגוניים? האם הכלים מחוברים למערכות פנימיות?

בלי תשובות לשאלות האלה, קשה לבנות מדיניות יעילה.

לא כל מידע דורש אותה רמת הגנה

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

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

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

חוזה לא חתום, קוד מקור, קובץ שכר ורשימת לקוחות אינם שקולים לפסקה שכבר פורסמה באתר החברה.

כאשר הסיווג ברור, אפשר לקבוע אילו כלים מאושרים לכל סוג מידע.

גם מידע שהמערכת מסיקה יכול להיות רגיש

הסיכון אינו מוגבל לטקסט שהעובד מעתיק ומדביק.

מערכת AI יכולה להסיק מידע מתוך מסמכים, שילובים של נתונים או הקשרים שונים.

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

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

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

חשבון פרטי וחשבון ארגוני אינם אותו דבר

אותו שירות יכול להציע תנאים שונים למשתמש פרטי וללקוח עסקי.

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

ארגון לא צריך להסתפק בשם המותג.

צריך לבדוק את המסלול הספציפי שהוא רוכש.

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

צ'אטבוט שמקבל טקסט מהמשתמש שונה מאוד מסוכן AI שמחובר ל-Google Drive, לדואר, ל-CRM או ל-ERP.

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

סוכן שצריך לקרוא מסמך מסוים לא בהכרח צריך לקבל גישה לכל התיקייה.

סוכן שמייצר טיוטת הודעה לא בהכרח צריך להיות רשאי לשלוח אותה ללא אישור.

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

צריך לחשוב גם על המידע שמגיע מבחוץ

מערכות AI אינן מקבלות הוראות רק מהעובד.

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

זהו אחד ההקשרים שבהם עולה הסיכון של Prompt Injection.

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

DLP הוא שכבת הגנה, לא פתרון יחיד

מערכות Data Loss Prevention נועדו לזהות ולצמצם פעולות שעלולות לחשוף מידע רגיש.

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

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

אבל גם DLP אינו מחליף מדיניות, הרשאות, הדרכה ובדיקה של ספקי AI.

מערכת אבטחה יכולה לזהות התנהגות מסוימת. היא אינה מחליטה עבור הארגון איזה מידע באמת מותר להעביר מלכתחילה.

עובדים צריכים מדיניות קצרה שהם באמת יכולים להבין

מסמך של עשרות עמודים אינו בהכרח הדרך הטובה ביותר למנוע טעויות.

עובדים צריכים לדעת באופן פשוט:

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

דוגמאות מעשיות עוזרות יותר מכללים כלליים.

למשל: האם מותר לסכם חוזה? האם מותר להעלות קורות חיים? האם מותר להדביק קוד? האם מותר להזין רשימת לקוחות?

התשובה יכולה להשתנות מארגון לארגון, אבל היא צריכה להיות ברורה.

ניטור חשוב גם אחרי האישור

אישור של מערכת אינו סוף התהליך.

צריך לדעת מי משתמש בה, לאילו מערכות היא מחוברת, אילו פעולות מתבצעות ומה השתנה מאז האישור המקורי.

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

לכן כדאי לבצע בדיקה מחודשת כאשר משתנה היקף השימוש.

מה עושים כאשר מידע כבר נחשף?

ארגון צריך להכין את התשובה לפני המקרה הראשון.

מי מקבל את הדיווח? האם ניתן למחוק את השיחה או הקובץ? האם נדרש להחליף מפתח API? האם צריך לבדוק לוגים? האם קיימת חובה להודיע לגורם נוסף?

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

מדיניות שמטרתה רק להעניש עלולה דווקא לדחות דיווחים.

לפני שמחברים AI למידע ארגוני

כדאי לוודא שיש תשובה ברורה לשאלות הבאות:

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

הטמעה בטוחה אינה דורשת בהכרח לחסום AI.

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