Human Override Protocols — נקודת עצירה אנושית בתוך זרימת סוכן אוטונומית

מאת צוות מדיה דיל · 12.08.2026 · AI Security · 5 דק׳

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

Agent שמנהל תהליך גבייה אוטומטי מזהה, לפי כללים שהוגדרו לו, שחשבון לקוח חורג מתנאי התשלום ומתחיל תהליך השעיית שירות. באמצע התהליך, נציג שירות לקוחות אנושי, שמדבר עם אותו לקוח בדיוק ברגע הזה בטלפון על הסדר תשלומים חדש, מבין שההשעיה תהרוס משא ומתן שכמעט נסגר. השאלה הקריטית: האם יש לנציג הזה דרך לעצור את התהליך באמצע, בלי לחכות שה-Agent "יסיים" ובלי לבנות Ticket שמישהו יטפל בו מחר? אם התשובה היא לא, המערכת בנויה נכון מבחינה טכנית אך שגויה מבחינה תפעולית - כי אין בה נקודת עצירה אנושית אמיתית באמצע זרימה אוטונומית. זהו בדיוק התפקיד של Human Override Protocol.

למה זה שונה מ-Kill Switch

קל לבלבל בין השניים, אבל ההבדל מהותי. Kill Switch הוא מנגנון חירום גס: עוצר פעילות שלמה, לרוב במצב חריג בלתי צפוי שדורש תגובה מיידית וקיצונית. Human Override הוא עדין ונקודתי הרבה יותר: התערבות בזרימה תקינה לגמרי מבחינת ה-Agent - הוא לא עושה שום דבר שגוי לפי הכללים שלו - אבל יש מידע אנושי (הקשר, ניואנס, נסיבות) שהאלגוריתם פשוט לא יכול לדעת. Kill Switch שואל "האם להפסיק הכל". Override שואל "האם הצעד הבא הזה, הספציפי, נכון כרגע, בהינתן משהו שאני יודע ואתה לא". מערכת בוגרת צריכה את שני המנגנונים, כל אחד למטרה שונה לגמרי.

המבחן הקשה: Override שה-Agent לא יכול "לשכנע" מסביבו

הכשל הארכיטקטוני הנפוץ ביותר הוא לבנות מנגנון Override שחי בתוך לולאת ההחלטה של ה-Agent עצמו - למשל, "שאל את ה-Agent אם הוא רוצה לעצור". זה כשל מובנה, כי אם ה-Agent הוא זה שמחליט אם לכבד את בקשת העצירה, כל תרחיש שבו הוא "משוכנע" (בין אם בגלל הזרקה, ובין אם בגלל טעות פרשנות רגילה) שההמשך נכון - יעקוף את ה-Override בפועל, גם אם בכוונה טובה. הפתרון הנכון הוא ערוץ עצירה שקיים מחוץ ללולאת ההחלטה של ה-LLM לגמרי - ברמת התשתית שמריצה את ה-Agent, לא ברמת הפרומפט. כשמגיע אות Override, שכבת הריצה עוצרת את הפעולה הבאה באופן דטרמיניסטי, בלי לשאול את המודל בכלל אם הוא מסכים - בדיוק כמו Interrupt ברמת מערכת הפעלה, לא כמו בקשה מנומסת בתוך תהליך.

async function nextStep(agentState) {
  if (await overrideSignal.check(agentState.taskId)) {
    return pauseForHuman(agentState); // נאכף ברמת התשתית, לא נשאל המודל
  }
  return agentState.decide();
}

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

Override בכל שלב הופך את ה-Agent לבלתי שימושי - חוזר לתהליך ידני לגמרי עם עטיפת AI. Override באף שלב מבטל את כל התועלת של מעורבות אנושית. הכלל המעשי הוא למקם נקודות עצירה טבעיות במקומות שבהם הפיכות הפעולה נמוכה או שבהם ידוע מראש שמידע אנושי חיצוני עשוי להיות רלוונטי - בדיוק כמו הדוגמה של הגבייה: לא כל שלב בתהליך הגבייה זקוק לנקודת עצירה, אבל הרגע שבו מתקבלת החלטת השעיה בפועל כן. העיקרון הזה משלים את הדיון בLeast Agency: אם כבר הוגדר שפעולה מסוימת חיה ברמת Act-then-Report ולא Propose-then-Approve, נקודת Override היא רשת הביטחון שמכסה בדיוק את המרחב הזה - מאפשרת אוטונומיה כברירת מחדל, אך משאירה פתח התערבות אמיתי לרגעים שבהם היא נחוצה.

מי מורשה ל-Override, ואיך זה נרשם

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

המחיר הנסתר: חביון (Latency) שנוצר מהעצירה עצמה

נקודת Override שדורשת אישור אנושי סינכרוני עוצרת את כל התהליך עד שמישהו מגיב - וזה יכול לקחת דקות או שעות, בזמן שהמצב הממתין לפעולה ממשיך להתפתח. לא תמיד ברור מה עדיף: לחכות לאישור אנושי גם במחיר עיכוב משמעותי, או להגדיר Timeout שאחריו הפעולה מתבצעת כברירת מחדל (Fail Open) או נעצרת כברירת מחדל (Fail Closed). התשובה הנכונה תלויה בכיוון הטעות הזול יותר עבור אותה פעולה ספציפית: לתהליך גבייה, Fail Closed (השהה במקום להשעות באופן שגוי) בדרך כלל בטוח יותר; לתהליך אבטחה שבו אי-פעולה עצמה מסוכנת (למשל חסימת גישה חשודה), ייתכן שדווקא Fail Open לפעולה השמרנית יותר הוא הבחירה הנכונה. אין ברירת מחדל אוניברסלית - ההחלטה חייבת להיקבע מראש, פעולה-פעולה, ולא להישאר כברירת מחדל טכנית של הפלטפורמה שאף אחד לא בחר במודע.

Override חלקי: לתקן במקום רק לעצור

הגרסה הבסיסית ביותר של Override היא בינארית - עצור או המשך. גרסה בשלה יותר מאפשרת גם תיקון: לא רק לעצור את הפעולה הבאה, אלא להזריק מידע חדש לתוך ה-Context של ה-Agent ולתת לו להמשיך עם ההקשר המעודכן - במקרה של הגבייה, לא רק "עצור" אלא "עצור, והנה: יש הסדר תשלומים בתהליך, המשך בהתאם". זה דורש שה-Agent יידע לקבל תיקון אמצע-ריצה כקלט לגיטימי, לא רק אות עצירה גולמי, ושהתשתית תדע להזריק את התיקון הזה באופן מבוקר, בלי לפתוח מחדש את כל שאלת האמון שדנו בה במדריכי הזרקת תוכן - כלומר, התיקון עצמו חייב להגיע מערוץ מאומת (אותה שכבת הרשאה כמו כל Override אחר), לא כטקסט חופשי לא מסונן שמוזרק ישירות לשיחה.

מדידת הצלחה: לא "כמה פעמים עצרו" אלא "כמה נזק נמנע"

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

תגיות: Human Override · human in the loop · agent interrupt · fail open fail closed · autonomous agent oversight · AI governance

← חזרה לבלוג · צור קשר