הלוסינציות של AI בעולם הרגולציה - סיכון אמיתי שצריך לנהל

יש מושג בעולם ה-AI שנקרא Hallucination (הזיות).

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

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

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

מה בדיוק קורה כש-AI הוזה בהקשר רגולטורי

הזיות רגולטוריות מגיעות בכמה צורות:

  • ציטוט סעיפים שלא קיימים: AI יכול לכתוב "לפי ISO 13485:2016 סעיף 7.5.12..." כשסעיף כזה לא קיים בתקן, או קיים אבל עם תוכן שונה לחלוטין. הניסוח נשמע מדויק, המספר נשמע אמיתי.

  • שיבוש תוכן של דרישות קיימות: הסעיף קיים, אבל הניסוח מה-AI מוסיף או מחסיר דרישות. "ISO 13485 מחייב ביקורת ספקים אחת לשנה" אינו מה שהתקן אומר. התקן מחייב הערכה מבוססת סיכון, ותדירות הביקורת תלויה ברמת הסיכון ובמה שנקבע בהסכם עם הספק.

  • בלבול בין רגולציות ובין גרסאות: AI יכול לערבב דרישות MDR ו-IVDR, לבלבל בין 21CFR Part 820 הישן ל-QMSR החדש, לתאר מסמך הנחיה שהוחלף בגרסה חדשה יותר.

  • יצירת מסמך הנחיה שלא קיים: ראיתי AI מפנה ל-"MDCG 2021-14 on AI/ML" כשמסמך כזה לא קיים. בדיוק בגלל שניסוחו נשמע כמו כל MDCG אמיתי, קל לפספס.

למה זה קורה טכנית

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

הבעיה: הנכונות הסטטיסטית אינה שווה לנכונות עובדתית.

מודל שראה אלפי טקסטים על ISO 13485 יכול לייצר משפטים שנשמעים נכונים, גם כשהם לא.

מקרים שראיתי בשטח

אציג שלושה מצבים אמיתיים (עם פרטים אנונימיים):

  1. מקרה א: חברת סטארטאפ הכינה הערכת פערים של מערכת האיכות למול דרישות ISO 13485 בעזרת AI. המסמך היה מפורט ומנוסח מצוין. בבדיקה שלי, מצאתי שלוש מקומות שבהם הדרישה שצוינה לא תאמה את נוסח התקן. אחד מהם היה הבדל מהותי בדרישות לבקרת תכנון ופיתוח.

  2. מקרה ב: יועץ שלח ללקוח רשימת דרישות MDR לתיעוד טכני שנוצרה ב-AI. הרשימה הייתה מדויקת ברובה, אבל החסירה דרישות מ-Annex II Section 4 לגבי תוצאות ניהול הסיכונים, ובמקביל הוסיפה דרישה שלא קיימת ב-MDR.

  3. מקרה ג: נוהל CAPA שנכתב ב-AI הזכיר "דרישת ה-FDA ל-CAPA תחת 21CFR 820.100 לביצוע ניתוח סיבת השורש תוך 30 יום". אין דרישה כזאת בסעיף. הסעיף מחייב תהליך CAPA מוגדר, אבל לא קובע מסגרת זמן ספציפית.

הסיכון האמיתי: מי לא יזהה את זה?

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

לקוח שאינו מומחה בטח לא יזהה.

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

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

  • כלל 1 - אין ציטוטים בלי אימות: כל טקסט שמתיימר לייצג דרישה של תקן, CFR, MDR, Guidance, נבדק מול המקור. זה לא מיותר. זה הכרחי.

  • כלל 2 - AI כניסוח, לא כסמכות: השתמשי ב-AI לנסח בצורה ברורה מה שאת יודעת. לא לגלות מה אמור להיות.

  • כלל 3 - Grounding: ב-AI מתקדם יש אפשרות לספק מסמכים כ-Context (להעלות את ה-PDF של התקן, ה-Guidance, ה-CFR). כשה-AI מחובר למסמך המקורי, איכות התשובות עולה משמעותית. אבל גם זה לא מאה אחוז, ואימות עדיין נדרש.

  • כלל 4 - אל תנסחי שאלות שמובילות לתשובות: "מה דרישות ISO 13485 לבקרת ספקים"? שאלה כזו מובילה לתשובה גנרית. "לפי ISO 13485:2016 סעיף 7.4, האם נדרש ביקור פיזי אצל הספק"? זו שאלה שמובילה לתשובה שיכולה להיבדק.

לסיום: לא להפחיד, אבל כן להיות מדויקים

המטרה של המאמר הזה היא לא להרחיק אנשים מ-AI. המטרה היא לשים גבולות ברורים.

AI הוא כלי מצוין, חוסך זמן, ומסייע לניסוח.

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

היא סיכון שצריך לנהל. בדיוק כמו כל סיכון אחר בתחום שלנו.