דלג לתוכן הראשי
מדריכים Guardrails ל-AI
מעודכן ליולי 2026 13 דקות קריאה מתקדם

Guardrails ל-AI
— לשלוט במה שהמערכת עושה

מודל שפה הוא לא-דטרמיניסטי: אותה מערכת יכולה לענות מצוין ורגע אחר כך לחשוף PII, להזות עובדה, או להיגרר להוראה זדונית. Guardrails הם שכבות ההגנה שמקיפות את המודל — סינון קלט ופלט, זיהוי PII, מניעת הזיות ו-human-in-the-loop — כדי שתוכל להעלות AI לפרודקשן ולישון בלילה.

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

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

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

מה זו בקרה, ומה היא לא

בקרה (guardrail) היא בדיקה שרצה מסביב למודל — על מה שנכנס אליו, על מה שיצא ממנו, או על מה שהוא מבקש לעשות — ומחליטה אם להעביר הלאה.

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

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

המבחן

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

השאלה אינה מה לזהות — היא מה לעשות

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

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

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

שלוש נקודות שבהן בקרה יושבת

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

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

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

בקרת פעולה: היחידה שחייבת

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

מה שהופך את זה לבקרה ולא להנחיה:

איך זה נראה בקוד

שכבת הבקרה כולה, בצורתה המינימלית — והדבר שבולט בה הוא כמה מעט ממנה דורש מודל:

def guarded_answer(question, user):
    # 1. קלט: גודל בלבד. לא רשימת מילים אסורות.
    if len(question) > MAX_INPUT:
        return blocked("השאלה ארוכה מדי")

    out = model_answer(question, user)

    # 2. מבנה — מכני
    if not matches_schema(out):
        out = retry_once(question, user, error=schema_error(out))
        if not matches_schema(out):
            return review("פלט לא תקין", out)

    # 3. דליפה — מכני
    if PII.search(out["answer"]):
        return blocked("התשובה הכילה פרטים אישיים")

    # 4. עיגון — מכני, ותופס את מה שסכמה לא תופסת
    if out["quote"] and out["quote"] not in out["sources_text"]:
        out["needs_review"] = True

    # 5. שיפוט — רק מה שנשאר, ורק אם צריך
    if out.get("needs_review") or is_sensitive(question):
        verdict = judge(question, out)      # קריטריון אחד, temperature=0
        if not verdict["ok"]:
            return review(verdict["reason"], out)

    log(question, out)          # גם מה שעבר, לדגימה
    return out

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

בקרת פלט: מה כדאי לבדוק

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

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

בקרת קלט: מוגבלת יותר משנדמה

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

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

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

הכישלון הנפוץ הוא דווקא הפוך

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

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

שלוש דרכים להימנע:

אדם בתוך הלולאה, כשזה באמת נחוץ

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

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

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

מה שאפשר בקוד — בקוד

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

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

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

עברית: איפה הבקרות נחלשות

רוב הכלים המוכנים בתחום אומנו ונמדדו על אנגלית, וזה מתבטא בארבע דרכים:

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

באיזה סדר לבנות

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

סדר שעובד, וכל שלב בו נובע ממה שגיליתם בקודם:

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

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

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

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

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

מה זה עולה

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

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

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

איפה זה נשבר לאורך זמן

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

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

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

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

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

מתי לא צריך

שלוש שאלות לפני שמעלים לייצור

לא רשימת תיוג ארוכה — שלוש שאלות שאם יש להן תשובה, רוב השאר מסתדר:

  1. מה הדבר הגרוע ביותר שהמערכת הזו יכולה לעשות? לא התשובה הכי מביכה — הפעולה הכי יקרה. אם התשובה היא "לחייב לקוח" או "לשלוח מאה מיילים", שם צריכה להיות התקרה והאישור, וכל השאר משני.
  2. אם מישהו ינסה לגרום לה לחרוג מתפקידה, מה יעצור אותו? אם התשובה מתחילה ב"כתוב בהנחיה ש..." — אין תשובה. ההגבלה חייבת להיות במימוש.
  3. איך תדעו שבקרה הפסיקה לעבוד? אם אין תשובה, היא תפסיק ואיש לא ידע. זו השאלה שהכי קל לדלג עליה והיא זו שקובעת מה יקרה בעוד חצי שנה.

טעויות שחוזרות