Intent Mandates — הוכחת כוונת המשתמש לפני רכישה אוטונומית

מאת צוות מדיה דיל · 12.08.2026 · Agentic Commerce · 5 דק׳

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

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

למה "המשתמש אישר" לא מספיק יותר

בעולם הדיגיטלי המסורתי, הוכחת הסכמה מבוססת על אירועים עקיפים: לחיצה על כפתור, קוד אימות ב-SMS, סיסמה שהוקלדה. כל אלה עובדים היטב כשההסכמה וההוצאה קורות באותו רגע. אבל ברגע שהסכמה ניתנת מראש (Human Not Present) והביצוע קורה מאוחר יותר, בתנאים שהשתנו — מחיר אחר, ספק אחר, כמות אחרת מזו שהמשתמש דמיין — צריך מסמך שמתעד לא רק "כן" אלא את התוכן המלא של מה שאושר: מה, כמה, עד כמה, ובאילו תנאים. זה בדיוק הרעיון ש-AP2 פותר עם מנגנון המנדטים, המתואר במלואו ב-מדריך AP2, כשה-Intent Mandate הוא הרכיב שמתעד את הכוונה הראשונית עוד לפני שנמצא מוצר ספציפי.

מבנה מנדט כוונה: מה חייב להיות בפנים

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

{
  "mandate_type": "intent_mandate",
  "user_id": "usr_55210",
  "description": "flight to NYC, price drop alert",
  "constraints": {
    "max_price": 280000,
    "currency": "ILS",
    "valid_until": "2026-10-15T00:00:00Z",
    "category": "flights",
    "destination": "JFK"
  },
  "signature": "ed25519:41ab...d02"
}

הבדל קריטי בין "רשות" ל"הוראה"

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

ביטול ותוקף: מה קורה כשהמשתמש מתחרט

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

למה זה קריטי דווקא לעולם ה-WhatsApp וממשקי שיחה

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

שגיאות נפוצות בהטמעת מנדטים

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

סיכום

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

תגיות: Intent Mandates · AP2 · Agentic Commerce · AI Agents · Authorization · WhatsApp

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