מודלי שפה גדולים משנים את התפעול הארגוני, אבל הם מציגים משטח תקיפה שרוב צוותי האבטחה מעולם לא נתקלו בו. רק ב-2025, 68% מהארגונים שפרסו LLMs דיווחו על לפחות אירוע אבטחה אחד ספציפי ל-AI, לפי סקר ניהול סיכוני AI של Gartner. וקטורי התקיפה לא מוכרים, השלכות התאימות מתפתחות בזמן אמת, וההימורים גבוהים ככל שיכולים להיות: הנתונים הקנייניים שלכם, המידע האישי של הלקוחות שלכם, והעמידה הרגולטורית של הארגון שלכם.
פרסנו מערכות LLM לייצור עבור ארגונים בתחומי הפיננסים, הבריאות והביטחון. מאמר זה מציג את נוף האיומים, דפוסי הארכיטקטורה שבאמת עובדים, והפרקטיקות התפעוליות שמפרידות בין פריסות AI מאובטחות למלכודות חבות.
מהם וקטורי האיומים החדשים שמציגים LLMs?
אבטחת יישומים מסורתית מתמקדת בקטגוריות מוכרות: הזרקה, אימות, בקרת גישה. LLMs שוברים את הקטגוריות האלה ויוצרים חדשות. דוח OWASP משנת 2025 זיהה prompt injection כפגיעות המנוצלת ביותר במערכות AI פרוסות, קיימת ב-43% מהיישומים שנבדקו.
הזרקת פרומפט (Prompt injection) מתרחשת כאשר קלט עוין מניפולציה על המודל להתעלם מהוראות המערכת שלו. הזרקת פרומפט ישירה מטמיעה הוראות זדוניות בקלט המשתמש. הזרקת פרומפט עקיפה מסתירה הוראות במסמכים, אימיילים או דפי אינטרנט שהמודל מעבד. ביישומי ה-AI שלנו עם גישת אבטחה ראשונה, אנחנו מתייחסים לכל פיסת טקסט שנכנסת למודל כקלט לא מהימן, ללא יוצא מן הכלל.
חילוץ נתונים דרך פלטי מודל הוא האיום שגורם ל-CISOs לאבד שינה. LLM עם גישה למסדי נתונים פנימיים יכול להיות מנוהל לחשוף רשומות רגישות באמצעות שאילתות מנוסחות בקפידה. X-Force של IBM דיווח ש-31% מפרצות ה-AI הארגוניות ב-2025 כללו חשיפת נתונים בלתי מורשית דרך תגובות מודל.
הרעלת מודל (Model poisoning) מכוונת לצינור האימון או הכיוון העדין. אם תוקף יכול להזריק נתונים זדוניים לסט האימון שלכם, התנהגות המודל משתנה בדרכים שקשה מאוד לזהות. סדרת כיוון עדין מורעלת אחת יכולה להכניס דלתות אחוריות שנמשכות דרך ריצות אימון עוקבות.
דליפת PII קורית כשמודלים שוננים ומשחזרים נתוני אימון. מחקר מ-ETH Zurich הדגים שמודלים ברמת GPT יכולים לפלוט קטעים מילה במילה מנתוני אימון, כולל שמות, כתובות ופרטים פיננסיים. עבור ארגונים שמשתמשים במודלים מכוונים על נתונים פנימיים, הסיכון הזה חד.
איך לתכנן ארכיטקטורה של מערכת AI ארגונית לאבטחה?
ארכיטקטורת אבטחה לפריסות LLM דורשת חשיבה מחדש על מספר הנחות. בעבודה שלנו עם ארגונים מוסדרים, אנחנו עוקבים אחרי מודל הגנה-בעומק עם ארבע שכבות: בידוד נתונים, בקרות גישה, רישום ביקורת וממשל מודלים.
בידוד נתונים אומר שהמודל לעולם לא נוגע בנתוני ייצור גולמיים ישירות. אנחנו מיישמים שכבת אחזור שמסננת מראש, מצנזרת ומסווגת נתונים לפני שהם מגיעים לחלון ההקשר של המודל. לפי מסגרת אבטחת ה-AI של Forrester לשנת 2025, ארגונים שמשתמשים בשכבות בידוד נתונים חוו 74% פחות אירועי חשיפת נתונים מאשר אלה שמעבירים נתונים גולמיים למודלים.
בקרות גישה למערכות AI חייבות להיות גרנולריות יותר מ-RBAC מסורתי. בכל פריסה, אנחנו כוללים הרשאות פרומפט מבוססות תפקיד, שבהן לתפקידים שונים יש גישה לפרומפטי מערכת, כלים וטווחי נתונים שונים. מופע LLM של נציג שירות לקוחות לעולם לא צריך לקבל גישה לאותם נתונים או יכולות כמו כלי אנליטיקה של הנהלה.
רישום ביקורת ל-AI הולך מעבר לתיעוד קריאות API. כל פרומפט, כל תגובה, כל הפעלת כלי וכל שאילתת אחזור חייבים להירשם עם הקשר מלא. אנחנו לוכדים מטא-נתונים ברמת טוקן כולל זמן תגובה, גרסת מודל, הגדרות temperature ומקורות אחזור. זה יוצר מסלול פורנזי שהוא חיוני במהלך חקירת אירועים. ארגונים שיישמו רישום ביקורת AI מלא זיהו אירועי אבטחה מהר פי 3.2, לפי נתוני מידוד אבטחת AI של Microsoft לשנת 2025.
ממשל מודלים קובע מי יכול לפרוס מודלים, אילו מודלים מאושרים לאילו תרחישי שימוש, ואילו נתוני כיוון עדין מותרים. ללא ממשל, צוותים פורסים מודלים בקוד פתוח עם מקור לא ידוע, מכוונים על מערכי נתונים לא מסוננים, ויוצרים מערכות AI צל שעוקפות כל בקרה שבניתם.
איך AI נפגש עם תאימות SOC 2, GDPR ו-HIPAA?
מסגרות תאימות לא תוכננו למערכות AI, אבל מבקרים אוכפים אותן על פריסות AI בכל זאת. הפער בין שפת המסגרת למציאות ה-AI יוצר גם סיכון וגם הזדמנות.
SOC 2 -- בקרות סביב עיבוד נתונים, גישה לוגית וניהול שינויים חלות ישירות על מערכות LLM. בקרת CC6.1 (גישה לוגית ופיזית) דורשת שתדגימו מי יש לו גישה לאילו נתונים דרך שכבת המודל, לא רק דרך שכבת מסד הנתונים. בפריסות מותאמות SOC 2 שלנו, אנחנו מייצרים חבילות ראיות אוטומטיות שממפות כל רכיב מערכת AI לקריטריוני שירות האמון הרלוונטיים. סקר AICPA משנת 2025 מצא ש-52% מביקורות SOC 2 כוללות כעת שאילתות ספציפיות ל-AI.
GDPR יוצר אתגרים מיוחדים לפריסות LLM. סעיף 17 (הזכות למחיקה) כמעט בלתי אפשרי לקיים עבור נתונים שנטמעו במשקולות המודל. סעיף 22 (קבלת החלטות אוטומטית) מופעל כאשר פלטי LLM משפיעים על החלטות לגבי אנשים. הגישה שלנו: לעולם לא לכוון עדין על נתונים אישיים, להשתמש בארכיטקטורת RAG (Retrieval-Augmented Generation) כך שניתן למחוק נתונים ממאגר האחזור ללא אימון מחדש, וליישם נקודות ביקורת אנושיות בלולאה לכל החלטה שמשפיעה מהותית על נושא מידע.
HIPAA -- דרישות למידע בריאותי מוגן (PHI) מחייבות הצפנה במנוחה ובמעבר, גישה מינימלית הכרחית, והסכמי שותף עסקי (BAA) עם כל ספק שמעבד PHI. הרצת PHI דרך API של LLM צד שלישי ללא BAA היא הפרה, נקודה. לפי נתוני אכיפה של HHS, תלונות HIPAA הקשורות ל-AI עלו ב-280% בין 2024 ל-2025, והקנס הראשון הספציפי ל-AI תחת HIPAA (1.3 מיליון דולר) הוטל בסוף 2025.
האם לארח LLMs בעצמכם או להשתמש ב-APIs בענן?
זו השאלה שאנחנו שומעים בתדירות הגבוהה ביותר מארגונים מודעי אבטחה, והתשובה תלויה במודל האיומים שלכם, ביכולות הצוות שלכם, ובסביבה הרגולטורית שלכם.
APIs של LLM בענן (OpenAI, Anthropic, Google) מציעים נוחות, ביצועים מהשורה הראשונה ותשתית מנוהלת. פשרת האבטחה היא שהנתונים שלכם עוזבים את הסביבה שלכם. גם עם הסכמים ארגוניים שאוסרים אימון על נתוני לקוח, הנתונים עוברים דרך תשתית צד שלישי. עבור תרחישי שימוש רבים, זה מקובל כשמשולב עם סיווג נתונים וצנזור נכון. לפי דוח State of the Cloud של Flexera לשנת 2026, 61% מהארגונים שמשתמשים ב-APIs של LLM בענן מיישמים צנזור PII לפני שליחה.
מודלים מאורחים עצמאית (Llama, Mistral, Qwen) שומרים את הנתונים לגמרי בתוך המתחם שלכם. הפשרה היא מורכבות תפעולית: אתם צריכים תשתית GPU, מומחיות בהגשת מודלים, עדכוני אבטחה למחסנית ההסקה, וצוות שיכול להעריך בטיחות מודל. מניסיוננו, אירוח עצמי הגיוני כשהנתונים רגישים מדי לכל עיבוד צד שלישי, כשדרישות רגולטוריות אוסרות במפורש שידור חיצוני, או כשנפח ההסקה מצדיק את ההשקעה בתשתית.
הגישה ההיברידית היא מה שאנחנו ממליצים עליו לרוב הארגונים. נתבו עומסי עבודה רגישים למודלים מאורחים עצמאית ועומסי עבודה לא רגישים ל-APIs בענן. זה דורש שכבת סיווג שבוחנת כל בקשה ומנתבת בהתאם. בנינו מערכות ניתוב שמסווגות ומכוונות בקשות בפחות מ-50 אלפיות שנייה, ומוסיפות זמן תגובה זניח תוך שמירה על שליטה מלאה בזרימת הנתונים.
אילו מעקות בטיחות וניטור צריך ליישם?
מעקות בטיחות (guardrails) הם שכבת האכיפה בזמן ריצה שמונעת מהמודל להתנהג מחוץ לגבולות המיועדים. ניטור הוא האופן שבו מאמתים שמעקות הבטיחות עובדים.
מעקות בטיחות קלט מסננים פרומפטים לפני שהם מגיעים למודל. זה כולל זיהוי הזרקת פרומפט (מבוסס דפוסים ומבוסס מסווגים), אכיפת גבולות נושא, וזיהוי PII עם צנזור אוטומטי. מערכת מעקות בטיחות קלט מכוונת היטב חוסמת 96% מניסיונות הזרקת פרומפט, לפי בנצ'מרקים ממסגרת NeMo Guardrails של NVIDIA שנבדקה ב-12 פריסות ארגוניות.
מעקות בטיחות פלט בודקים תגובות מודל לפני שהן מגיעות למשתמש. אנחנו בודקים PII בתגובות, עובדות מהוזות (בהצלבה עם מקורות אחזור), תוכן שחורג מהנושא, ושפה רעילה או מזיקה. אימות פלט מוסיף 100-200 אלפיות שנייה של זמן תגובה אבל מונע מהמודל להפוך לדליפת נתונים או לחבות.
ניטור מתמשך עוקב אחר התנהגות המודל לאורך זמן. אנחנו מקימים זיהוי אנומליות על התפלגויות תגובות, ומסמנים כשהמודל מתחיל לייצר פלטים שחורגים מקווי בסיס מבוססים. זיהוי סטייה תופס דגרדציה של מודל לפני שהיא הופכת לאירוע אבטחה. לוחות המחוונים שלנו לניטור עוקבים אחר שיעורי ניסיונות הזרקת פרומפט, פגיעות זיהוי PII, תדירות הפעלת מעקות בטיחות וציוני איכות תגובה. ארגונים שיישמו ניטור AI מתמשך הפחיתו את זמן הזיהוי הממוצע לאירועים ספציפיים ל-AI מ-14 יום לפחות מ-4 שעות, לפי דוח האיומים של CrowdStrike לשנת 2025.
צוות אדום (Red-teaming) הוא לא אופציונלי. אנחנו מריצים בדיקות יריבות כנגד כל פריסת ייצור בתדירות רבעונית לפחות. זה כולל fuzzing אוטומטי עם כלים כמו Garak ובדיקות ידניות על ידי מהנדסי אבטחה שמבינים גם בדיקות חדירה מסורתיות וגם טכניקות תקיפה ספציפיות ל-LLM.
איך מטפלים בתגובה לאירועים במערכות AI?
ספרי הנהלים המסורתיים לתגובה לאירועים לא מכסים תרחישים ספציפיים ל-AI. כשמודל מתחיל להדליף נתונים או להגיב להזרקות פרומפט, הצוות שלכם צריך לדעת בדיוק מה לעשות, ונהלי "בודד את השרת הפגוע" סטנדרטיים אינם מספיקים.
סיווג אירועים ספציפי ל-AI הוא הצעד הראשון. אנחנו מגדירים רמות חומרה על סמך אופי כשל ה-AI: הזרקת פרומפט שמחזירה תגובה לא בנושא שונה מכזו שמחלצת רשומות לקוחות. כל רמת חומרה ממופה ללוח זמנים לתגובה ונתיב הסלמה. בפריסות שלנו, אנחנו מתחזקים טקסונומיית אירועי AI ייעודית עם 14 סוגי אירועים ברורים וספרי הנהלים מתאימים.
יכולת חזרה למצב קודם (rollback) של מודל היא חיונית. כל גרסת מודל, כל גרסת תבנית פרומפט וכל תצורת מעקות בטיחות חייבים להיות מגורסים וניתנים לפריסה בתוך דקות. כשאנחנו מזהים מודל פגוע או מעקה בטיחות כושל, אנחנו חוזרים לתצורה הידועה האחרונה שעבדה בזמן שהחקירה מתנהלת. צוותים ללא יכולת rollback מגורסת ממוצעים 6.8 שעות לבלימת אירועי AI לעומת 23 דקות לצוותים עם rollback אוטומטי, לפי נתוני Unit 42 של Palo Alto Networks.
פורנזיקה לאחר אירוע למערכות AI דורשת את יומני הביקורת שנדונו קודם. אתם צריכים לשחזר את הרצף המדויק של פרומפטים, אחזורים ותגובות שהובילו לאירוע. ללא רישום ברמת טוקן, אתם חוקרים בחושך.
פרוטוקולי תקשורת צריכים להתחשב באופי הייחודי של אירועי AI. פרצת נתונים דרך LLM עלולה להשפיע על משתמשים שמעולם לא עבדו ישירות עם מערכת ה-AI, אם למודל הייתה גישה לנתונים שלהם דרך צינור אחזור. היקף ההודעה חייב לשקף את חשיפת הנתונים בפועל, לא רק את המשתמשים הישירים של תכונת ה-AI.
שאלות נפוצות
האם ניתן למנוע לחלוטין הזרקת פרומפט?
לא. הזרקת פרומפט היא מהותית בעיה לא פתורה בדור הנוכחי של מודלי שפה כי המודל לא יכול להבחין באופן אמין בין הוראות לנתונים. עם זאת, הגנות שכבתיות -- מסווגי קלט, מאמתי פלט וגישה מוגבלת לכלים -- מפחיתות את משטח התקיפה לרמה נשלטת. בפריסות שלנו, הגנות רב-שכבתיות מפחיתות הזרקת פרומפט מוצלחת מכ-15% מהניסיונות לפחות מ-0.4%.
האם בטוח להשתמש ב-APIs של LLM צד שלישי עבור נתונים ארגוניים רגישים?
זה תלוי בסיווג הנתונים שלכם ובערבויות החוזיות של ספק ה-API. הסכמים ארגוניים מספקים מרכזיים (Anthropic, OpenAI, Google) בדרך כלל כוללים נספחי עיבוד נתונים שאוסרים אימון על נתוני לקוח. עם זאת, הנתונים עדיין עוברים דרך התשתית שלהם. עבור נתונים שמסווגים כרגישים ביותר או מוסדרים (PHI, PCI, מסווגים), מודלים מאורחים עצמאית או פתרונות on-premise הם הבחירה המתאימה.
איך לקיים את הזכות למחיקה של GDPR כשנתונים מוטמעים במשקולות המודל?
הימנעו מכיוון עדין על נתונים אישיים מלכתחילה. השתמשו בארכיטקטורות RAG שבהן נתונים אישיים חיים במאגר אחזור שתומך במחיקה. אם כבר כיוונתם עדין על נתונים אישיים, הגישה האמינה היחידה היא אימון מחדש ממערך נתונים נקי עם הסרת הנתונים הרלוונטיים. זה יקר וגוזל זמן, וזו בדיוק הסיבה שאנחנו דוגלים בארכיטקטורות RAG-first מהיום הראשון.
אילו הסמכות אבטחה צריך לדרוש מספקי AI?
במינימום, דרשו SOC 2 Type II, ואמתו שהיקף הביקורת מכסה במפורש את תשתית הגשת מודלי AI. לבריאות, דרשו BAAs תחת HIPAA. לשירותים פיננסיים, אשרו תאימות עם הדרישות הספציפיות לסקטור שלכם (הנחיות OCC, תקני FFIEC). מעבר להסמכות, בקשו את תיעוד האבטחה הספציפי ל-AI של הספק: אסטרטגיית הפחתת הזרקת פרומפט, מדיניות שמירה ומחיקת נתונים, ונהלי תגובה לאירועים עבור כשלי AI.
כמה פעמים צריך להריץ צוות אדום על מערכות ה-AI?
רבעונית לפחות עבור מערכות ייצור, ולאחר כל עדכון מודל משמעותי, שינוי תבנית פרומפט או שילוב מקור נתונים חדש. בדיקות יריבות אוטומטיות צריכות לרוץ ברציפות כחלק מצינור ה-CI/CD שלכם. צוות אדום ידני מומחה מספק עומק שכלים אוטומטיים מפספסים, במיוחד עבור תקיפות ברמת לוגיקה עסקית ספציפיות לתחום שלכם.