מוצרים / Incident Review
DNLA Incident Review
כאשר מערכת AI גורמת לנזק, מקבלת החלטה שגויה, או מפעילה תקרית תפעולית, DNLA מריצה חקירה בלתי תלויה: המקבילה ב-AI ל-Root Cause Analysis, בנויה עבור מערכות שבהן "שורש הבעיה" יכול להיות מודל, prompt, מקור נתונים, אינטגרציה, או כשל תהליכי.
למה עצמאות חשובה
הצוות שבנה את המערכת הוא לרוב לא הצוות הנכון לחקור אותה
לא בגלל חוסר תום לב, אלא בגלל תמריצים. האנשים שבנו או מפעילים מערכת הם הכי פחות סביר שיהיו אובייקטיביים לגבי האם הכשל היה חד-פעמי, סימפטום לבעיה ארכיטקטונית עמוקה יותר, או סיכון צפוי שאף אחד לא סימן בזמן. חקירת תקרית צריכה לשרוד ביקורת מדירקטוריון, רגולטור, מבטח, או בית משפט, מה שאומר שהיא צריכה להגיע ממקום שאין לו מה להגן עליו.
התהליך
עשרה שלבים, בסדר
- שחזור התקרית
- שימור ראיות ולוגים
- בניית ציר זמן
- זיהוי המודל וגרסת ה-prompt המעורבים
- בחינת הנתונים וההקשר שהיו במשחק
- איתור נקודת הכשל
- ייחוס גורם: מודל, נתונים, אינטגרציה, משתמש, תהליך, או ממשל
- הערכת השפעה
- הגדרת אמצעי מניעה
- קביעת תנאים להחזרת המערכת לשירות
התוצר אינו הטלת אשמה; זהו תיאור ניתן להגנה של מה שקרה, למה, והתנאים הספציפיים שצריכים להתקיים לפני שהמערכת חוזרת לפרודקשן.
מי מזמין את זה
- הנהלה שזקוקה לתמונה ישרה לפני שמחליטים איך להגיב פומבית או חוזית
- צוותי משפט או ציות שזקוקים לרשומה ניתנת להגנה של מה קרה ולמה
- דירקטוריונים ומבטחים שזקוקים לממצא בלתי תלוי, לא לגרסה של הספק על עצמו
- הנהלת הנדסה שחושדת בגורם אך זקוקה להוכחה לפני התחייבות לתיקון
כבר קרה משהו לא בסדר?
ככל שראיות ולוגים נשמרים מוקדם יותר, כך החקירה יכולה לשחזר יותר.