חוק האחריות לסוכני AI: מי נושא בסיכון?

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

מי אחראי לטעות: ספק המודל, החברה שמפעילה את הסוכן או האדם שלחץ על ״התחל״?

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

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

מה ההצעה אומרת בפועל

ההודעה של מרפי מתארת שלושה שינויים:

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

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

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

הספק, החברה המטמיעה או המשתמש?

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

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

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

הרשאות אמיתיות, לא בקשות בשיחה

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

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

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

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

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

תעדו את ההחלטה, לא רק את השיחה

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

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

רשומת אירוע קטנה להמחשה יכולה להיראות כך:

{
  "time": "2026-10-02T09:00:00Z",
  "run_id": "run-184",
  "parent_run_id": "run-180",
  "requested_by": "user-42",
  "model_revision": "pinned-model-version",
  "tool_revision": "deploy-tool-v3",
  "action": "deployment.update",
  "resource": "billing-production",
  "policy_version": "staging-only-v7",
  "approval_id": null,
  "decision": "deny",
  "executed": false
}

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

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

בנו כפתור עצירה שבאמת עוצר עבודה

כפתור עצירה שרק סוגר את חלון הצ׳אט הוא קישוט.

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

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

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

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

השיקו עם ראיות לכך שהבקרות עובדות

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

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

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

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

מקורות

• הסנאטור האולי: ההכרזה על AI Agent Accountability Act, ‏1 באוקטובר 2026
• הסנאטור מרפי: תקציר ההצעה, 1 באוקטובר 2026
• OWASP: ‏LLM06:2025 Excessive Agency
• NIST: מסגרת ניהול סיכוני AI, גרסה 1.0, ובפרט MANAGE 2.4

תמונת פתיחה: United States Supreme Court Building, July 21, 2020, צילום המיוחס ל-Senate Democrats, דרך Wikimedia Commons, ברישיון CC BY 2.0. הוקטנה מ-6720 על 4480 ל-1920 על 1280 פיקסלים, ללא עריכות נוספות. זוהי תמונת ארכיון להמחשת אחריות משפטית. היא אינה מתעדת דיון או פסק דין בנוגע להצעה.