אדם בלולאה: איפה בן אדם חייב להישאר בתהליך אוטומטי, ואיך לא להפוך אותו לחותמת גומי

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

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

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

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

פעולות שבן אדם חייב לראות לפני

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

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

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

ארבע רמות בקרה: אוטומטי, דגימה, אישור, חסימה

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

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

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

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

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

כשיש יותר מדי לאשר, וכשהמודל לא בטוח

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

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

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

מי אישר מה, ומתי

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

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

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

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

איך זה נראה ב-n8n וב-Make

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

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

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

מה עושים עם זה מחר בבוקר

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

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

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