אישור אנושי לפוסטים של סוכן AI: איפה בדיוק לשים את נקודת העצירה

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

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

למה "רק לבדוק הכל" זה לא פתרון

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

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

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

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

ארבע שכבות של בקרה

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

שכבה	מה היא עוצרת	איך זה נראה בְּשַׁגֵּר
הרשאות מפתח	פעולות שהסוכן בכלל לא אמור לעשות	מפתח עם read, write או גם publish
בדיקה פנימית	טעויות מסר, טון וקול מותג	העורך בודק טיוטות בממשק
אישור לקוח	פוסטים שהלקוח לא ראה	קישור אישור עם request_approval
בדיקות לפני שליחה	פוסט שהרשת תדחה	כל פוסט נבדק מול חוקי הרשת לפני שהוא יוצא

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

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

מטריצת החלטה: מתי צריך אדם

לא כל פוסט צריך את אותה רמת בקרה. הנה איך אני מחלק:

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

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

איך נראה התהליך בקריאות MCP

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

1. create_post(workspace_id, caption, group_ids, media_ids, per_channel: [...])
   מחזיר post_id של טיוטה

2. request_approval(workspace_id, post_id,
                    reviewer_name: "דנה, מנהלת שיווק",
                    reviewer_email: "...", send_email: true)
   מחזיר approval_url ו whatsapp_url

3. get_post(workspace_id, post_id)
   בודקים את הסטטוס: IN_REVIEW, CHANGES_REQUESTED או APPROVED

4. אם APPROVED:
   schedule_post(workspace_id, post_id, schedule_at: "2026-08-30T10:00:00+03:00")

5. אם CHANGES_REQUESTED:
   מדווחים לעורך, מתקנים, ויוצרים טיוטה מעודכנת

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

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

מתי נותנים לסוכן הרשאת פרסום

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

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

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

איך מנסחים את ההוראה לסוכן

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

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

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

אישור אנושי לא נגמר ברגע הפרסום. בלוח הבקרה של הסוכנים בְּשַׁגֵּר יש יומן של כל קריאה שהסוכן ביצע: מה הוא ביקש, מתי ובאיזו סביבה. מומלץ שמישהו יעבור עליו באופן קבוע, לא רק כשיש תקלה.

מה מחפשים ביומן:

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

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

שאלות נפוצות

האם הלקוח צריך חשבון בְּשַׁגֵּר כדי לאשר פוסטים?

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

מה ההבדל בין הרשאת publish לבין אישור לקוח?

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

איך עוצרים פוסט שכבר תוזמן?

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

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