יישום ISO/IEC 42001: מפת דרכים לממשל AI שלא נתקע

ISO/IEC 42001 פורסם בסוף 2023 כסטנדרט הבינלאומי הראשון למערכת ניהול AI. שנתיים אחר כך, הוא הפך למסמך שאומר אם ארגון באמת מנהל את ה-AI שלו או רק טוען לזה. שלא כמו פריימוורקים וולונטריים (NIST AI RMF, עקרונות OECD ל-AI), הוא בנוי לבדיקות הסמכה, מה שאומר שהפער בין "יש לנו מדיניות AI" לבין "אנחנו יכולים להציג ראיות שהמדיניות הייתה פעילה" קובע אם ההסמכה תחזיק.

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

מה 42001 באמת דורש שאתם כנראה לא עושים

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

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

A.6 — ארגון פנימי. ספציפית מסגרת האחריות ל-AI: מי מחליט אילו מערכות AI נפרסות, מי בודק את אלה שב-high-risk, למי יש סמכות לעצור פריסה. כאן הסטנדרט מתחיל לחשוף פערים ארגוניים שעד עכשיו טוייחו בעזרת הסדרים לא רשמיים.

A.7 — משאבים למערכות AI. כולל את משאבי הנתונים — provenance, איכות, גבולות שימוש מתוכנן. עבודת התאימות כאן בסוף עושה את עבודת היגיינת הנתונים התפעולית שצוות הנדסת ה-AI היה צריך לעשות בכל מקרה.

A.8 — הערכת השפעה של מערכות AI. תהליך הערכת ההשפעה הנדרש צריך להיות תפעולי, לא לראווה. אנחנו רואים יותר מדי תוכניות שבהן הערכת ההשפעה היא טופס של עמוד אחד שמולא בפריסה ואף פעם לא חוזרים אליו.

A.9 — מחזור חיים של מערכת AI. קונקרטי: פיתוח, פריסה, הפעלה, פרישה, עם artefacts נדרשים בכל מעבר. זה התחום שרוב התוכניות מזלזלות בו.

אם חמשת אלה תפעוליים, 42001 בהישג יד. אם איזשהו מהם תיאטרון, הסטנדרט יחשוף את זה.

הצורה של 90 ימי יישום אמיתי

אנחנו עובדים לפי צורה של 90 ימים ליסוד ואז 6 חודשי הרצה תפעולית. עבודת היסוד היא מה שרוב היועצים מותחים ל-engagement של 9 חודשים. לא ראינו מקרה שבו זה באמת נדרש.

יום 0–30: מצאי AI ו-scope

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

סיווג הסיכון הוא איפה ש-42001 מתחבר לתאימות לחוק ה-AI האירופי. שכבות הסיכון של החוק (prohibited / high-risk / limited-risk / minimal-risk) יכולות להזין חלק משדות הערכת ההשפעה שהסטנדרט דורש, אבל הן דורשות מיפוי נפרד ולא תרגום אוטומטי. עשיית העבודה הזו פעם אחת, נכון, מייצרת ראיות הניתנות לשימוש בשני המשטרים.

טעות נפוצה היא לחכות עד שהמצאי יהיה מושלם לפני להמשיך. אנחנו ממליצים על אותה משמעת כמו במצאי נכסי אבטחה: מצאי 70% נכון שמשמש להחלטות ממשל שווה יותר ממצאי 100% נכון שמתעדכן פעם בשנה.

יום 30–60: הקמת ממשל תפעולי

שלושה artefacts נבנים בחלון הזה:

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

2. תהליך הערכת ההשפעה. לא טופס של עמוד אחד. הערכה מובנית שכוללת שימוש מתוכנן, שימוש לרעה צפוי, אוכלוסיות מושפעות, provenance של נתונים, מדדי ביצועים תחת לחץ, תוכנית ניטור, וסמכות החלטה לפרישה. נבנה פעם, ואז מיושם לכל מערכת.

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

יום 60–90: מחזור שנתי ראשון, בצורה מקוצרת

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

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

איפה התאימות לחוק ה-AI האירופי חופפת ואיפה לא

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

• מצאי AI עם סיווג סיכון
• מבנה ממשל מתועד
• תהליך הערכת השפעה
• תוכנית ניטור למערכות פרוסות
• רשומות החלטות ואירועים

החוק מוסיף דרישות ש-42001 לא (בעיקר, הערכת תאימות למערכות high-risk, רישום במאגר ה-AI של האיחוד האירופי, תיעוד ספציפי לפי נספח IV). 42001 מוסיף דרישות שהחוק לא (בעיקר, מבנה מערכת הניהול של יעדים, ביקורת פנימית, ושיפור מתמשך).

הסדר שעובד: בנו את מערכת הניהול של 42001 קודם, ואז הוסיפו עליה את התוצרים הספציפיים לחוק על המצאי והערכות ההשפעה. הנדסה הפוכה של 42001 מתיעוד מונע-חוק מייצרת מערך תאימות שבירה שנכשלת ב-audit של מערכת הניהול.

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

תחום פתרונות ה-AI של פליקן-טק בונה תוכניות 42001 לצד עבודת הנדסת ה-AI עצמה (הערכת מודל, תשתית ניטור, תהליך הערכת ההשפעה), כך ש-artefacts התאימות הם ראיות אמיתיות, לא תיעוד רטרוספקטיבי. אנחנו עובדים יחד עם צוות ניהול הסיכונים שלנו כשממשל ה-AI חופף לסיכון סייבר (מה שבדרך כלל קורה למערכות high-risk), ועם פרקטיקת הרגולציה ל-MedTech שלנו כשה-AI יושב בתוך מכשיר רפואי תחת MDR או scope של FDA.

אם אתם 8 חודשים בתוך יישום 42001 שהפיק תיעוד מדיניות נרחב אבל מינימום ראיות תפעוליות, זו השיחה שצריך לעשות איתנו לפני ביקורת ההשגחה הראשונה.