ایجنت‌های مصرف‌کننده به دفتر کل رضایت نیاز دارند، نه صفحه تنظیمات

تغییر از توصیه به اقدام

در بیشتر دهه گذشته، هوش مصنوعی مصرف‌کننده متن تولید می‌کرد. خلاصه می‌کرد، پیشنهاد می‌داد و پیش‌نویس می‌نوشت. کاربر همچنان کنشگر بود: خروجی را می‌خواند، تصمیم می‌گرفت و کلیک می‌کرد. آن مرز از بین رفته است. ایجنت‌های مصرف‌کننده اکنون اعتبارنامه‌ها را در دست دارند، به نمایندگی از کاربر با اشخاص ثالث صحبت می‌کنند و کاربر را به نتایجی متعهد می‌کنند. آن‌ها اشتراک‌ها را لغو می‌کنند، پشت خط منتظر می‌مانند، پیشنهادهای حفظ مشتری را مذاکره می‌کنند، پیام‌ها را می‌خوانند و دسته‌بندی می‌کنند و سفارش ثبت می‌کنند.

این ماهیت شکست را تغییر می‌دهد. وقتی یک مدل پاسخ اشتباه می‌دهد، هزینه یک باور نادرست است که کاربر می‌تواند اصلاح کند. وقتی یک ایجنت اقدام می‌کند، هزینه یک تغییر وضعیت در جهان است که ممکن است برگشت‌ناپذیر باشد. حالت شکست یک پاسخ اشتباه نیست؛ یک اقدام مجاز است که کاربر قصدش را نداشته. اشتراکی که در حساب اشتباه لغو شده، پروازی که با نرخ بدتر دوباره رزرو شده، پیامی که به گیرنده اشتباه فرستاده شده — هر کدام یک تعهد واقعی است که تحت اعتبارنامه‌ای انجام شده که کاربر تحویل داده است.

اختلافات با شواهد رضایت حل خواهند شد. وقتی کاربر می‌گوید «من هرگز نگفتم این کار را بکن»، و طرف مقابل می‌گوید «ایجنت شما با ما تماس گرفت و درخواست کرد»، سؤال این است که کاربر واقعاً چه چیزی را مجاز کرده، در چه دامنه‌ای، برای چه مدتی و به چه کسی. بیشتر استقرارهای امروزی تقریباً هیچ چیزی که به این پاسخ دهد را نگه نمی‌دارند. آن‌ها لاگ‌ها را نگه می‌دارند، که مصنوعات مهندسی هستند، نه سوابق رضایت.

چرا صفحات تنظیمات به عنوان شواهد شکست می‌خورند

صفحه تنظیمات یک ماشین حالت است. ثبت می‌کند که یک کلید در زمان T روشن بوده. دامنه اقدام انجام‌شده در زمان T+n، طرف مقابل درگیر، یا مدتی که آن اختیار معتبر بوده را ثبت نمی‌کند.

الگوی رایج را در نظر بگیرید. کاربر «مدیریت اشتراک‌های من» را در تنظیمات یک ایجنت فعال می‌کند. آن یک بولی واحد اکنون مجموعه‌ای نامحدود از فروشندگان، مجموعه‌ای نامحدود از اقدامات (لغو، تنزل، توقف، مذاکره مجدد) و افق زمانی نامحدود را پوشش می‌دهد. وقتی ایجنت اشتراکی را لغو می‌کند که کاربر می‌خواست نگه دارد، صفحه تنظیمات هیچ راهی برای بازسازی اینکه آن لغو در محدوده مجوز بوده یا نه ارائه نمی‌دهد. کلید می‌گوید کاربر به مدیریت اشتراک رضایت داده است. نمی‌گوید کاربر به لغو این اشتراک با این فروشنده در این زمان رضایت داده است.

رضایت داده‌شده برای یک فروشنده به فروشنده دیگر منتقل نمی‌شود. کاربری که به ایجنت اجازه مذاکره با اپراتور تلفن همراه خود را می‌دهد، به آن اجازه مذاکره با بیمه‌گر خود را نداده است. کلیدهای کلی این تمایز را به‌طور طراحی‌شده پنهان می‌کنند: آن‌ها مجموعه‌ای از مجوزهای مشخص و محدود را در یک سوئیچ انتزاعی فرو می‌ریزند. سوئیچ برای آنبوردینگ راحت و برای قضاوت بی‌فایده است.

اشخاص ثالث به یک مصنوع قابل تأیید نیاز دارند، نه اسکرین‌شاتی از یک صفحه ترجیحات. تیم پشتیبانی یک فروشنده، فرآیند اختلاف یک بانک، یا یک نهاد نظارتی نمی‌تواند یک اسکرین‌شات را تأیید کند. آن‌ها به چیزی نیاز دارند که یک اقدام را به یک مجوز گره بزند: چه کسی اقدام کرد، به نمایندگی از چه کسی، با چه اختیاری و چه زمانی. پیش‌فرض فعلی — یک تیکت پشتیبانی و یک قول — مقیاس‌پذیر نیست و در برخورد با مقررات دوام نخواهد آورد.

طراحی یک دفتر کل رضایت

دفتر کل رضایت یک سابقه فقط-افزودنی از مجوزها و لغوها است. هر ورودی حداقل مجموعه مورد نیاز برای بازسازی قصد پس از واقعه را ثبت می‌کند:

• کنشگر: هویت ایجنت، شامل نسخه و اعتبارنامه‌ای که استفاده کرده.
• طرف مقابل: فروشنده، سرویس یا نقطه پایانی مشخصی که اختیار به آن اعمال می‌شود.
• کلاس اقدام: فعل — لغو، خرید، ارسال، خواندن، مذاکره — برگرفته از یک واژگان بسته.
• دامنه: پارامترهای محدود. برای یک خرید، حداکثر مبلغ و دسته فروشنده. برای یک پیام، مجموعه گیرندگان. برای یک لغو، شناسه اشتراک مشخص.
• انقضا: لحظه‌ای که پس از آن مجوز باطل است، یا رویدادی که آن را باطل می‌کند.
• گفته مجوز: گفته دقیق کاربر که آن را اعطا کرده، عیناً، با کانال و برچسب زمانی. این لنگر است. این چیزی است که یک انسان وقتی اختلاف می‌رسد می‌خواند.

ورودی‌ها فقط-افزودنی و امضاشده هستند. لغو یک ورودی جدید است، هرگز حذف نیست. این یک ترجیح سبکی نیست؛ این خاصیتی است که دفتر کل را به شواهد تبدیل می‌کند. سابقه‌ای که می‌تواند پس از واقعه ویرایش شود هیچ چیزی درباره آنچه در زمان اقدام درست بود اثبات نمی‌کند. امضای هر ورودی، و زنجیره‌کردن ورودی‌ها به‌گونه‌ای که حذف یکی زنجیره را می‌شکند، به دفتر کل همان خاصیت دست‌نخورده‌بودن را می‌دهد که یک لاگ شفافیت دارد.

دفتر کل توسط کاربر قابل پرس‌وجو است و در جایی که مرتبط باشد، قابل ارائه به طرف مقابل یا نهاد نظارتی است. نمای کاربرپسند یک تاریخچه به زبان ساده است: ایجنت چه کرد، مجاز به چه بود، و کدام گفته اختیار را اعطا کرد. نمای طرف مقابل یک استخراج دامنه‌دار است: اثبات اینکه یک اقدام مشخص توسط یک مجوز مشخص پوشش داده شده، بدون افشای تاریخچه نامرتبط.

یک مکانیزم مشخص: وقتی ایجنت آماده اقدام می‌شود، یک ورودی پیشنهادی می‌سازد و آن را در برابر مجوزهای فعال برای آن طرف مقابل و کلاس اقدام بررسی می‌کند. اگر هیچ مجوزی اقدام را پوشش ندهد — فروشنده اشتباه، منقضی‌شده، مبلغ خارج از دامنه — اقدام رد می‌شود و رد نیز به عنوان یک ورودی دفتر کل ثبت می‌شود. سابقه رد اهمیت دارد. نشان می‌دهد لایه اجرا کار کرده، که دقی

تعامل با کنترل‌های موجود

هزینه دامنه‌دار و اعتبارنامه‌های محدود به دامنه به عنوان اجرا به دفتر کل متصل می‌شوند؛ دفتر کل نیمه حسابرسی را تأمین می‌کند. یک کارت مجازی با محدودیت هر فروشنده مرز را اجرا می‌کند. دفتر کل ثبت می‌کند چرا مرز تعیین شده، با کدام مجوز و چه زمانی. اجرا بدون حسابرسی شما را ناتوان می‌کند از پاسخ به «آیا این در سیاست بود؟» حسابرسی بدون اجرا شما را قادر می‌کند فقط پس از خسارت به سؤال پاسخ دهید.

این دو باید یک طرح‌واره مشترک داشته باشند. اگر دامنه اعتبارنامه متفاوت از دامنه دفتر کل بیان شود، رد حسابرسی با تصمیم اجرا تطبیق نخواهد یافت، و شکاف تطبیق جایی است که اختلافات زندگی می‌کنند.

سیاست نگهداری یک تصمیم محصول با پیامدهای قانونی است: آنچه فراموش می‌شود قابل اثبات نیست. دفتر کلی که ورودی‌ها را پس از سی روز منقضی می‌کند دفتر کلی است که نمی‌تواند از یک برگشت هزینه ثبت‌شده در روز چهل و پنجم دفاع کند. دفتر کلی که همه چیز را برای همیشه نگه می‌دارد یک بدهی از نوع دیگر است. معامله صادقانه این است که هیچ دوره نگهداری پیش‌فرضی وجود ندارد که برای همه کلاس‌های اقدام درست باشد. لغوها ممکن است به نگهداری طولانی نیاز داشته باشند؛ مجوزهای دسترسی خواندن ممکن است به کوتاه نیاز داشته باشند. دوره نگهداری به طرح‌واره تعلق دارد، به ازای هر کلاس اقدام، و باید آگاهانه تصمیم‌گیری شود.

معامله سخت‌تر اصطکاک است. دفتر کلی که برای هر اقدام رضایت صریح و دامنه‌دار می‌خواهد درست و غیرقابل استفاده خواهد بود. دفتر کلی که مجوزهای گسترده را از یک گفته آنبوردینگ استنتاج می‌کند قابل استفاده و بی‌ارزش به عنوان شواهد خواهد بود. میانه قابل کار مجموعه کوچکی از مجوزهای دائمی با دامنه باریک و انقضای صریح است، به‌علاوه یک مرحله تأیید برای هر چیزی خارج از آن‌ها. مرحله تأیید یک ورودی می‌نویسد؛ یک مودالی که ناپدید می‌شود نیست.

طرح‌واره را منتشر کنید. در غیر این صورت طرف‌های مقابل طرح‌واره‌های ناسازگار اختراع خواهند کرد. اگر هر فروشنده ایجنت و هر فروشنده کالا فرمت رضایت خود را تعریف کند، نتیجه مجموعه‌ای از دفترهای کل است که قابل مقایسه نیستند، و مشکل حل اختلاف به سادگی یک لایه بالاتر می‌رود. یک طرح‌واره منتشرشده — کنشگر، طرف مقابل، کلاس اقدام، دامنه، انقضا، گفته، امضا — به هر طرف یک هدف مشترک می‌دهد. لازم نیست هنوز یک استاندارد باشد. باید عمومی، نسخه‌دار و به اندازه کافی پایدار باشد که یک طرف مقابل بتواند بر اساس آن بسازد.

اول چه چیزی بسازیم

حداقل دفتر کل رضایت قابل دوام کوچک است. طرح‌واره ورودی را تعریف کنید. هر ورودی را امضا کنید. آن را فقط-افزودنی کنید. یک تاریخچه قابل خواندن برای کاربر نمایان کنید. بررسی اجرا را اضافه کنید که اقدامات خارج از مجوزهای فعال را رد می‌کند و رد را ثبت می‌کند. با کلاس‌های اقدامی شروع کنید که بیشترین پیامدهای برگشت‌ناپذیر را دارند — لغوها، پرداخت‌ها، پیام‌های خروجی — و از آنجا گسترش دهید.

صفحه تنظیمات می‌تواند بماند. روش خوبی برای پیکربندی مجوزهای دائمی است. سابقه آنچه مجاز بوده نیست. آن‌ها مصنوعات متفاوتی با طول عمرهای متفاوت هستند، و درهم‌آمیختن آن‌ها اشتباهی است که بیشتر استقرارهای ایجنت مصرف‌کننده همین حالا مرتکب می‌شوند.