הערכת סיכון AI לתעשיות מוסדרות: תבנית עבודה

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

זו תבנית העבודה שאנחנו משתמשים בה להערכות סיכון AI בשירותים פיננסיים, בריאות, וסביבות תעשייתיות מוסדרות. היא ממופה ל-ISO 42001, לדרישות ה-high-risk של חוק ה-AI האירופי, ל-NIST AI RMF, ולהדרכה הסקטוריאלית שרוב התעשיות המוסדרות מפרסמות. התבנית עצמה פשוטה. האתגר הוא למלא אותה בראיות תפעוליות, לא בסיסמאות ובכוונות טובות.

שבעת הסעיפים שכל הערכה ברמת רגולטור צריכה

להערכת סיכון AI טובה יש שבעה סעיפים. אף אחד מהם לא אופציונלי בהקשר מוסדר. הסדר חשוב כי כל סעיף תלוי במה שהקודם ביסס.

1. תיאור המערכת ושימוש מתוכנן

תיאור עובדתי של מה המערכת עושה, מה היא לא עושה, והגבול ביניהם. הצהרת השימוש המתוכנן נושאת משקל יוצא דופן בהקשרים מוסדרים כי היא חוסמת אחריות: פעולות מחוץ לשימוש מתוכנן הן off-label, שזו שיחה אחרת מפעולות בתוך שימוש מתוכנן שייצרו תוצאות לא מכוונות.

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

2. מפת מחזור חיים של נתונים

לכל dataset שנוגע במערכת: מקור, בעלות, בסיס חוקי (GDPR, חוקי נתונים סקטוריאליים), תיעוד provenance, מדידות איכות, מדיניות שמירה, והגבול בין אישי ללא-אישי. אותה רמת ספציפיות כמו השימוש המתוכנן.

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

3. זיהוי סיכון, לפי קטגוריה

הליכה מובנית דרך קטגוריות סיכון, עם קביעה מתועדת לכל קטגוריה. הקטגוריות שאנחנו משתמשים בהן:

• בטיחות ונזק פיזי (איפה שרלוונטי, חובה בהקשרי רפואה, תעשייה, רכב)
• זכויות יסוד ואפליה (חובה תחת חוק ה-AI האירופי, בדרך כלל חל בהחלטות פיננסיות, גיוס, שירותים ציבוריים)
• פרטיות והגנת מידע (תמיד חל כשנתונים אישיים נוגעים במערכת)
• סייבר (תמיד חל, נקודת אינטגרציה עם תוכנית הסייבר)
• תפעול והמשכיות עסקית
• ביצועי מודל תחת distribution shift
• שימוש לרעה ושימוש יריבי
• סיכון צד שלישי ושרשרת אספקה (במיוחד למערכות בנויות על foundation models)

לכל קטגוריה, שלושה דברים חייבים להופיע: סיכונים מזוהים ספציפיים למערכת הזו, קביעת חומרה-סבירות עם הצדקה, והחלטה (mitigate, accept, transfer, avoid). "לא רלוונטי" היא קביעה, אבל היא חייבת להיות מוצדקת.

4. מיפוי בקרות

לכל סיכון שהקביעה היא "mitigate", הבקרה הספציפית שמתמודדת איתו. הבקרות חייבות להיות תפעוליות, לא הצהרתיות. "ניטור מתמשך" היא לא בקרה. "drift detection על שלושה metrics נקובים, מוערך יומית, עם ספים מוגדרים ו-runbook להפרות" כן.

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

5. ביצועים וולידציה

מאפייני הביצועים האמיתיים של המערכת, על הנתונים האמיתיים שהיא תראה בפריסה, מוערכים מול ההחלטות האמיתיות שהיא תיידע. מספרי דיוק גנריים מ-benchmark dataset לא מספיקים. השאלה הרלוונטית היא: בפועל, מה הביצועים שלה במדדים שחשובים לשימוש המיועד?

שני אלמנטים ספציפיים שרגולטורים מחפשים:

• ביצועי תת-קבוצות. ביצועים מפורקים לפי תת-קבוצות דמוגרפיות איפה שרלוונטי, עם פערים מתועדים והחלטות שהתקבלו לגבי האם הם מקובלים.
• בדיקות לחץ. ביצועים תחת תנאים בכוונה יריביים, distribution shift, ומקרי קצה שהפריסה תיתקל בהם. "בדקנו על ה-holdout set" לא מספיק.

6. תוכנית ניטור

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

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

7. ממשל וסמכות החלטה

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

בהקשרים מוסדרים סעיף הממשל לעיתים קרובות הוא איפה שאחריות אישית מבוססת. זה לא artefact לאצול. זוהי שרשרת האחריות המתועדת שהרגולטור יבחן אם משהו ילך לא טוב.

מה הופך את זה לראיות במקום תיעוד

התבנית למעלה ישירה. העבודה היא בהשלמתה עם חומר שמחזיק בבדיקה. שלושה דברים מבדילים בין הערכות תפעוליות לכאלה שנעשות לראווה.

לכל טענה יש מקור. "אנחנו מנטרים drift" היא טענה. "אנחנו מנטרים drift על שלושת ה-metrics האלה. הדשבורד נמצא ב-URL הזה. ה-runbook להפרות נמצא ב-URL הזה. אירוע drift האחרון תועד כאן בתאריך הזה" זה ראיות. מבקרים שעשו כמה כאלה יכולים לזהות תוך עשר דקות אם הם מסתכלים על ראיות או על טענות.

הצלבות בין סעיפים נבדקות. סיכון שזוהה בסעיף 3 צריך להופיע כבקרה בסעיף 4 או כקבלה מוצדקת עם מקבל החלטה מתועד. metric ניטור בסעיף 6 צריך למפות לסיכון בסעיף 3. עקביות פנימית היא מה שה-audit מאמת קודם, פערים מיידית גלויים.

ההערכה מתוארכת ועם גרסאות. מערכות AI משתנות. ההערכה חייבת להראות את ההיסטוריה שלה: מתי סעיפים עודכנו לאחרונה, מה גרם לכל עדכון, מי אישר אותו. snapshot עכשווי בלי היסטוריה מטופל על-ידי מבקרים כמסמך מוכן. היסטוריה עם גרסאות מטופלת כ-artefact עובד.

תוספות סקטוריאליות שכדאי לדעת

סקטורים מוסדרים שונים מוסיפים דרישות ספציפיות מעל הבסיס בן שבעה הסעיפים.

שירותים פיננסיים (הדרכת EBA, CFPB, MAS). בדיקה ספציפית על בדיקות adverse-impact להחלטות אשראי והלוואות, תפקידי ממשל מודל מיושרים עם three-lines-of-defence, תדירות דיווח דירקטוריון קשורה לסיווג סיכון.

בריאות (FDA, EU MDR, MHRA). כש-AI הוא חלק ממכשיר רפואי, ההערכה חייבת להשתלב עם מחזור חיים תוכנה IEC 62304 ועם ניהול סיכון ISO 14971. ראיות הערכה קלינית נדרשות.

מערכות high-risk תחת חוק ה-AI האירופי. הערכת תאימות לפי נספח VI או VII, רישום במאגר ה-AI של האיחוד האירופי, ניטור post-market לפי סעיף 72, והודעת אירוע תחת סעיף 73. הערכת סיכון ה-AI הופכת לקלט אחד ל-Annex IV technical file רחב יותר.

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

איפה אנחנו נכנסים

תחום פתרונות ה-AI של פליקן-טק בונה את ההערכות האלה לצד עבודת ההנדסה והממשל, כך שה-artefacts הם ראיות אמיתיות, לא תיעוד רטרוספקטיבי. אנחנו עובדים עם צוות ה-MedTech שלנו להקשרי מכשיר רפואי, ועם צוות ניהול הסיכונים שלנו כשהערכת סיכון ה-AI משתלבת בדיווח סיכון ארגוני רחב יותר.

אם מערכת ה-AI שלכם פרוסה והערכת הסיכון הקיימת לא הייתה שורדת ראיון ראשון של רגולטור מקצועי, זו השיחה שצריך לעשות איתנו לפני שהרגולטור מגיע.