בטיחות למוצרי LLM בלי תיאטרון

1. Safety הוא מושג מוצרי, לא רק security term

במוצרי LLM יש כמה סוגי נזק שונים:

• תשובה מסוכנת או לא נתמכת
• prompt injection
• גישה לכלים מעבר למה שהתכוונתם
• leakage של מידע לא נכון לחשוף
• UI שנותן למשתמש תחושת certainty שאין לה כיסוי

אם מנסים לפתור הכול עם שכבה אחת של moderation, מקבלים גם false comfort וגם false negatives.

2. Prompt injection היא לא באג מוזר

ברגע שהמערכת צורכת טקסט חיצוני, מסמכים, מיילים, web content או shared notes, prompt injection היא מסלול כשל רגיל למדי.

מה שעוזר באמת:

• הפרדה בין instructions לבין data
• צמצום scope של כל tool
• allowlists ברורות
• review על צעדים שמשנים state
• traces שאפשר לקרוא אחר כך

מה שלא עוזר מספיק:

• לקוות שהמודל “יבין” מה זדוני
• להעמיס עוד warning text בתוך הפרומפט

3. Excessive agency יקרה יותר משהיא נראית

מערכות LLM לא צריכות הרבה אוטונומיה כדי להיכנס לאזור מסוכן. לפעמים מספיק tool אחד לא תחום כדי לקבל incident מביך.

לכן כדאי להפריד בין:

• read
• suggest
• act

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

4. evals הם חלק ממסלול הבטיחות

בטיחות בלי evals נשארת הצהרה ערכית.

צריך לבדוק במפורש:

• unsupported claims
• refusal quality
• prompt injection cases
• tool misuse
• format failures בדומיינים רגישים
• escalation behavior

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

5. מה שייך ל-critical path ומה לא

לא כל check חייב להיות על המסלול הסינכרוני. זאת טעות נפוצה.

ב-critical path צריכים לשבת הדברים שעוצרים נזק ממשי:

• gates לכלי מסוכן
• בדיקות policy קשיחות
• validation של format כשיש לזה מחיר אמיתי
• abstain או escalate כשאין מספיק בסיס

לעומת זאת, monitoring בדיעבד יכול לטפל ב:

• drift
• עלייה איטית ב-latency
• ירידה באיכות trace
• pattern חדש של שימוש שצריך להכניס ל-evals

6. ממשק עצמו יכול להיות בעיית safety

UI חלש מגדיל סיכון גם אם ה-backend מתאמץ.

דוגמאות:

• תשובה זורמת מדי בלי סימון מגבלות
• טעויות שנראות כמו certainty
• state loading שמרגיש כמו אמת מוגמרת
• streaming מוקדם מדי במשטחים רגישים

לעיתים קרובות safety UI טוב הוא פשוט UI שמודה בגבולותיו.

7. המינימום שאני רוצה לראות

סיכום

בטיחות במוצרי LLM לא צריכה להיראות חגיגית. היא צריכה להיות משולבת בתוך delivery, approvals ו-observability עד כדי כך שהיא מפסיקה להרגיש כמו שכבה נפרדת.

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