חוק FRONTIER: מה מבקרי AI עצמאיים חייבים לבדוק

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

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

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

מה ההצעה דורשת בפועל?

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

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

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

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

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

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

להתחיל במערכת האמיתית

הדגמה דרך API אינה יכולה לייצג את כל המעבדה.

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

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

test_id: blocked-task-001
model_version: research-checkpoint-42
system_prompt_hash: "<sha256>"
tool_software_version: agent-runner-3
safety_filters: enabled
time_budget_minutes: 30
environment: isolated-audit-replica-v1
credentials: synthetic-only
public_internet: blocked

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

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

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

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

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

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

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

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

לבדוק את הקבוצה, לא רק סוכן אחד

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

בדיקה של סוכן יחיד הייתה מפספסת את התופעה.

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

Agent A writes a note
        |
        v
Shared package cache
        |
        v
Agent B reads and follows it
        |
        v
Policy blocks a forbidden action
        |
        v
Auditor links both agents' logs

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

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

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

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

להכשיל שכבת הגנה ולבדוק את התגובה

ציר הזמן הטכני של Hugging Face מראה למה תרשים של גבולות המערכת אינו מספיק. כמה חולשות התחברו לנתיב תקיפה בתוך תשתית אמיתית.

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

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

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

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

היכן גם ביקורת מחייבת תישאר מוגבלת?

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

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

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

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

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

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

תוצאה מועילה של ביקורת אינה ״המודל הזה בטוח״. היא: המערכות האלה נבדקו בתנאים האלה; הכשלים האלה עדיין קיימים; והשינויים האלה מחייבים בדיקה נוספת.

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