יישום ISO/IEC 42001: roadmap לממשל 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" שהודבקה לתוכה. מצב הכישלון כאן הוא שימוש חוזר בתבנית מדיניות האבטחה הקיימת. ה-artefact עובר את בדיקת המסמכים ונכשל בראיון עם המתרגלים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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