רוב מוצרי ה-LLM לא נכשלים כי אף אחד לא הזכיר safety. הם נכשלים כי ה-safety נשארה על שקף בזמן שהמערכת האמיתית המשיכה לזוז סביבה.
Safety הוא מושג מוצרי, לא רק term של security
במוצרי LLM יש סוגי נזק שונים. תשובה מסוכנת או לא נתמכת. prompt injection. גישה לכלים מעבר למה שהתכוונתם. leakage של מידע שאסור לחשוף. UI שמשדר certainty שאין לה כיסוי.
מי שמנסה לפתור הכול עם שכבה אחת של moderation מקבל גם false comfort וגם false negatives.
Prompt injection היא לא באג מוזר
ברגע שהמערכת צורכת טקסט חיצוני - מסמכים, מיילים, web content, shared notes - prompt injection הופכת למסלול כשל רגיל.
מה שעוזר. הפרדה בין instructions ל-data, צמצום scope של כל tool, allowlists מפורשות, review על צעדים ששונים state, traces שאפשר לקרוא אחר כך.
מה שלא עוזר מספיק. לקוות שהמודל "יבין" מה זדוני, להעמיס עוד warning text בתוך הפרומפט.
Excessive agency יקרה יותר משנראית
מערכות LLM לא צריכות הרבה אוטונומיה כדי להגיע לאזור מסוכן. לפעמים tool אחד לא תחום מספיק כדי לקבל incident מביך.
להפריד בין read, suggest, act. בכל מעבר מ-suggest ל-act לעצור ולשאול אם יש gate אמיתי או רק ניסוח מרגיע.
evals הם חלק ממסלול הבטיחות
בטיחות בלי evals נשארת בעיקר הצהרה ערכית.
לבדוק במפורש unsupported claims, refusal quality, prompt injection cases, tool misuse, format failures בדומיינים רגישים, escalation behavior.
OWASP ו-NIST עוזרים לחשוב על מחלקות הסיכון. ברמת המוצר ה-evals הקטנים שאתם באמת מריצים חשובים יותר מהמסגרת היפה על הקיר.