רוב מוצרי ה-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 הקטנים שאתם באמת מריצים חשובים יותר מהמסגרת היפה על הקיר.
מה שייך ל-critical path ומה לא
לא כל check חייב להיות על המסלול הסינכרוני. טעות נפוצה.
ב-critical path. gates לכלי מסוכן, בדיקות policy קשיחות, validation של format כשיש לזה מחיר, abstain או escalate כשאין מספיק בסיס.
ב-monitoring בדיעבד. drift, עלייה איטית ב-latency, ירידה באיכות trace, pattern חדש של שימוש שצריך להכניס ל-evals.
הממשק עצמו יכול להיות בעיית safety
UI חלש מגדיל סיכון גם אם ה-backend מתאמץ. תשובה זורמת מדי בלי סימון מגבלות. טעויות שנראות כמו certainty. state loading שמרגיש כמו אמת מוגמרת. streaming מוקדם מדי במשטחים רגישים.
UI טוב לבטיחות הוא לרוב UI שמודה בגבולותיו.
המינימום שאני רוצה לראות
בטיחות במוצרי LLM לא צריכה להיראות חגיגית. שתשתלב בתוך delivery, approvals ו-observability עד שהיא מפסיקה להרגיש כמו שכבה נפרדת. שם בדרך כלל מתחיל מוצר שאפשר לסמוך עליו קצת יותר.