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

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

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

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

מהי הרעלת נתונים?

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

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

OWASP מרחיב את ההגדרה ומתייחס לא רק לנתוני האימון הראשוניים, אלא גם לנתונים המשמשים ל־Fine-Tuning, למאגרי Embeddings ולמקורות מידע המחוברים למערכות Generative AI. מניפולציה של מקורות אלה עלולה להחדיר למערכת חולשות, דלתות אחוריות, הטיות או תוכן מזיק.

עוד על סיכוני אבטחת מידע וסייבר בינה מלאכותית – תקינה ורגולציה AI

• חוק הבינה המלאכותית האירופי באוגוסט 2026: מה משתנה ומה ארגונים צריכים לעשות לקראת EU AI Act?
• AI Literacy – אוריינות בינה מלאכותית – האוריינות החדשה שכל ארגון צריך להכיר
• ISO 42001 תקן לאבטחת מידע בעולמות הבינה המלאכותית – ISO 42001:2023 מערכת לניהול בינה מלאכותית – AIMS
• אבטחת מידע בשימוש בבינה מלאכותית ו-AI: הסיכון האמיתי לארגונים

כיצד מתבצעת הרעלת נתונים?

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

פגיעה בנתוני האימון

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

שינוי תוויות וסיווגים

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

הטמנת דלת אחורית במודל

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

הרעלת מאגרי ידע ו-RAG

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

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

ניצול מנגנוני משוב ולמידה מתמשכת

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

מדוע קשה לזהות את התקיפה?

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

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

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

באילו מערכות ארגוניות עלול להיגרם נזק?

מערכות סייבר וזיהוי איומים

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

מערכות פיננסיות ומניעת הונאות

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

מערכות רפואיות

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

משאבי אנוש וקבלת החלטות

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

שרשרת אספקה ותכנון

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

מה ההבדל בין הרעלת נתונים ל-Prompt Injection?

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

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

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

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

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

1. למפות את מערכות ה-AI ואת מקורות הנתונים

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

2. לנהל את מקור הנתונים ואת שרשרת האספקה

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

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

3. להגביל הרשאות ולתעד שינויים

יש להחיל עקרונות של Least Privilege על מאגרי אימון, מערכות תיוג, מאגרי Embeddings ותהליכי Fine-Tuning. כל שינוי משמעותי בנתונים צריך להיות מתועד, ניתן לאימות ומשויך לבעל תפקיד מזוהה.

4. לבדוק חריגות בנתונים ובתוצאות

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

5. לנהל גרסאות ולאפשר חזרה לאחור

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

6. לבצע בדיקות תקיפה ו-AI Red Teaming

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

7. לשמור על פיקוח אנושי

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

8. להכין תוכנית תגובה לאירוע AI

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

אבטחת AI מתחילה באמינות הנתונים

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

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

כיצד אנחנו באינפוגארד מסייעים לארגונים?

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

הליווי יכול לכלול:

• סקר סיכוני AI באבטחת מידע.
• מיפוי מערכות, נתונים וספקי צד שלישי.
• הגדרת מדיניות שימוש ופיקוח על AI.
• בחינת הרשאות, תהליכי שינוי וניהול גרסאות.
• ביצוע Gap Assessment ובניית תוכנית עבודה.
• שילוב סיכוני AI במערכי GRC, ניהול ספקים ותגובה לאירועים.
• בדיקות אבטחה ותרחישי תקיפה למערכות AI.

עם יותר מ-13 שנות ניסיון באבטחת מידע, סייבר, פרטיות וניהול סיכונים, אנחנו מסייעים לארגונים לאמץ AI באופן שמאפשר חדשנות, בלי לוותר על שליטה, אחריות ואמון.

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

מקורות

ENISA, Securing Machine Learning Algorithms.

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

NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations.

OWASP, LLM04:2025 Data and Model Poisoning.

MITRE, SAFE-AI Framework and MITRE ATLAS.

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה ייעוץ מקצועי, רגולטורי, משפטי או טכנולוגי. כל ארגון נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים.
המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב אבטחת מידע, סייבר ומנהל השיווק של קבוצת חברות עידור (Messagent, Infoguard, Idornext).