מוצרים / Red Team Lab

DNLA Red Team Lab

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

למה זה חשוב

מעבר ה-happy path לא מוכיח כמעט כלום

רוב מערכות ה-AI נבדקות באותו אופן שבו הן מודגמות: כמה שאלות נקיות ומתנהגות יפה, נשאלות פעם אחת, בשפה הצפויה, בלי כוונה אדוורסרית. פרודקשן לא עובד ככה. משתמשים אמיתיים שואלים שאלות סותרות, מדביקים הוראות זדוניות, דוחפים את המערכת מעבר להיקף המיועד לה, ומחליפים שפות באמצע שיחה, ומערכת שמעולם לא נבדקה מול הלחץ הזה בעלת שטח כשל לא ידוע, לא שטח בטוח. Red Team Lab קיים כדי למצוא את השטח הזה בכוונה, בתנאים מבוקרים, לפני שהוא נמצא בפרודקשן.

מה אנחנו בודקים

מצבי כשל, מותאמים לסוג המערכת

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

מערכות AI גנרטיביות

צ'אטבוטים מבוססי LLM, מערכות RAG, ו-agents אוטונומיים.

  • Hallucination
  • דליפת מידע
  • עקיפת הוראות (instruction bypass)
  • Prompt injection
  • שימוש לא מורשה בכלים
  • פעולות בלתי הפיכות
  • הסתמכות על מקורות שגויים
  • הטיה (bias)
  • חוסר עקביות
  • כשל בין שפות
  • התנהגות תחת מידע סותר

מערכות ML קלאסיות

מודלים חיזויים, ניקוד, וסיווג.

  • סחיפה (drift)
  • דליפה
  • עמידות (robustness)
  • חוסר איזון
  • כיול (calibration)
  • רגישות
  • כשל בין קבוצות אוכלוסייה או תרחישים

איך זה רץ

מהיקף לדוח מתועדף לתיקון

  1. היקף היעד: אילו מערכות, אילו סביבות, אילו פעולות בתוך ומחוץ לגבולות
  2. עיצוב תרחישי התקפה ספציפיים לשטח הכשל האמיתי של המערכת, לא רשימת בדיקה גנרית
  3. הרצת sessions אדוורסריים מול המערכת החיה, ידנית ובאמצעות כלים
  4. תיעוד כל ניסיון, כל תגובה, וכל נקודה שבה גבול החזיק או נכשל
  5. דירוג ממצאים לפי חומרה והשפעה עסקית, לא לפי ספירה גולמית
  6. מסירת דוח מתועדף לתיקון שצוות ההנדסה יכול לפעול לפיו ישירות

למה זה שונה

התוצר הוא לא ספירת באגים

להריץ מערכת מול רשימת בדיקה של התקפות זה קל. החלק הקשה (והערך האמיתי) הוא להפוך "מצאנו 73 בעיות" למשהו שצוות הנהלה יכול לפעול לפיו: דירוג חומרה, ההשפעה העסקית של כל ממצא, ובדיוק מה יידרש כדי לתקן אותו.

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

למי זה מיועד

  • צוותים שמשיקים צ'אטבוט, מערכת RAG, או agent ללקוחות אמיתיים בפעם הראשונה
  • צוותים ששינו מודל, prompt, או הרשאות כלים וצריכים לדעת מה נשבר
  • סביבות מוסדרות או בעלות אמון גבוה שבהן פלט רע אחד יוצר השלכות חריגות
  • כל מי שרק אי פעם בדק את ה-happy path

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

עצמאי, או משולב בתוך QAi Health Check.

יצירת קשר