Сдвиг от совета к действию
Почти всё последнее десятилетие потребительский ИИ производил текст. Он резюмировал, предлагал и составлял черновики. Действующим лицом оставался пользователь: он читал вывод, принимал решение и нажимал кнопку. Эта граница исчезла. Потребительские агенты теперь хранят учётные данные, говорят с третьими сторонами от имени пользователя и связывают пользователя обязательствами. Они отменяют подписки, висят на линии, ведут переговоры об удержании, читают и сортируют сообщения, оформляют заказы.
Это меняет природу сбоя. Когда модель даёт неверный ответ, цена — ошибочное убеждение, которое пользователь может исправить. Когда агент действует, цена — изменение состояния в мире, которое может быть необратимым. Режим отказа — не неверный ответ, а санкционированное действие, которого пользователь не имел в виду. Подписка, отменённая не на том аккаунте, рейс, перебронированный по худшему тарифу, сообщение, отправленное не тому получателю, — каждое из них является реальным обязательством, принятым под учётными данными, которые пользователь передал.
Споры будут разрешаться доказательством согласия. Когда пользователь говорит «я никогда не просил это делать», а контрагент говорит «ваш агент позвонил нам и попросил», вопрос в том, что именно пользователь санкционировал, в каком объёме, на какой срок и кому. Большинство сегодняшних внедрений почти ничего не сохраняют, что отвечает на это. Они сохраняют логи — инженерные артефакты, а не записи о согласии.
Почему страницы настроек не годятся как доказательство
Страница настроек — это конечный автомат. Она фиксирует, что переключатель был включён в момент T. Она не фиксирует объём действия, совершённого в момент T+n, участвующего контрагента или срок, в течение которого эти полномочия были действительны.
Рассмотрим распространённый шаблон. Пользователь включает «управление моими подписками» в настройках агента. Этот единственный булев флаг теперь покрывает неограниченное множество продавцов, неограниченное множество действий (отмена, понижение, пауза, пересмотр условий) и неограниченный временной горизонт. Когда агент отменяет подписку, которую пользователь хотел сохранить, страница настроек не даёт возможности восстановить, была ли эта отмена в пределах предоставленных прав. Переключатель говорит, что пользователь согласился на управление подписками. Он не говорит, что пользователь согласился на отмену этой подписки у этого продавца в это время.
Согласие, данное для одного продавца, не переносится на другого. Пользователь, который санкционирует агенту переговоры с его мобильным оператором, не санкционировал переговоры со своей страховой компанией. Общие переключатели скрывают это различие по замыслу: они сводят набор конкретных, ограниченных разрешений к одному абстрактному переключателю. Переключатель удобен для онбординга и бесполезен для вынесения решения.
Третьим сторонам нужен проверяемый артефакт, а не скриншот экрана предпочтений. Служба поддержки продавца, процесс оспаривания в банке или регулятор не могут проверить скриншот. Им нужно нечто, что связывает действие с предоставлением прав: кто действовал, от чьего имени, с какими полномочиями и когда. Текущий вариант по умолчанию — тикет в поддержку и обещание — не масштабируется и не выдержит столкновения с регулированием.
Проектирование реестра согласий
Реестр согласий — это запись предоставлений и отзывов прав, доступная только на добавление. Каждая запись фиксирует минимальный набор, необходимый для восстановления намерения постфактум:
- Действующее лицо: идентичность агента, включая версию и использованные учётные данные.
- Контрагент: конкретный продавец, сервис или эндпоинт, к которому применяются полномочия.
- Класс действия: глагол — отменить, купить, отправить, прочитать, вести переговоры — из закрытого словаря.
- Объём: ограниченные параметры. Для покупки — максимальная сумма и категория продавца. Для сообщения — набор получателей. Для отмены — конкретный идентификатор подписки.
- Срок действия: момент, после которого предоставление прав недействительно, или событие, которое его аннулирует.
- Высказывание о предоставлении: точное высказывание пользователя, которым оно было предоставлено, дословно, с каналом и отметкой времени. Это якорь. Именно его читает человек, когда приходит спор.
Записи доступны только на добавление и подписаны. Отзыв — это новая запись, никогда не удаление. Это не стилистическое предпочтение; это свойство, которое делает реестр доказательством. Запись, которую можно отредактировать постфактум, ничего не доказывает о том, что было верно во время действия. Подпись каждой записи и связывание записей в цепочку так, что удаление одной разрывает цепочку, придаёт реестру то же свойство защиты от подделки, что и журналу прозрачности.
Реестр доступен для запросов пользователем и, где это уместно, может быть предъявлен контрагенту или регулятору. Пользовательское представление — это история простым языком: что агент сделал, что ему было разрешено делать и какое высказывание предоставило полномочия. Представление для контрагента — это ограниченная выдержка: доказательство того, что конкретное действие покрывалось конкретным предоставлением прав, без раскрытия несвязанной истории.
Конкретный механизм: когда агент готовится действовать, он формирует предлагаемую запись и проверяет её против активных предоставлений прав для этого контрагента и класса действия. Если ни одно предоставление не покрывает действие — не тот продавец, истёк срок, сумма вне объёма — действие отклоняется, и отказ также регистрируется как запись в реестре. Запись об отказе важна. Она показывает, что слой принудитель
Взаимодействие с существующими механизмами контроля
Ограниченные расходы и учётные данные с ограниченной областью действия подключаются к реестру как принудительное исполнение; реестр обеспечивает половину, отвечающую за аудит. Виртуальная карта с лимитом на продавца обеспечивает соблюдение границы. Реестр фиксирует, почему граница была установлена, каким предоставлением прав и когда. Принудительное исполнение без аудита оставляет вас неспособными ответить на вопрос «было ли это в рамках политики?». Аудит без принудительного исполнения оставляет вас способными ответить на вопрос только после ущерба.
Оба должны использовать одну схему. Если область действия учётных данных выражена иначе, чем область действия в реестре, аудиторский след не будет согласовываться с решением о принудительном исполнении, и разрыв в согласовании — это то место, где живут споры.
Политика хранения — это продуктовое решение с юридическими последствиями: то, что забыто, не может быть доказано. Реестр, который удаляет записи через тридцать дней, — это реестр, который не может защитить чарджбэк, поданный на сорок пятый день. Реестр, который хранит всё вечно, — это обязательство другого рода. Честный компромисс в том, что не существует срока хранения по умолчанию, правильного для всех классов действий. Отмены могут требовать длительного хранения; предоставления прав на чтение могут требовать короткого. Срок хранения принадлежит схеме, для каждого класса действий, определяется осознанно.
Более сложный компромисс — трение. Реестр, требующий явного, ограниченного согласия для каждого действия, будет корректным и непригодным к использованию. Реестр, который выводит широкие предоставления прав из одного высказывания при онбординге, будет пригодным к использованию и бесполезным как доказательство. Работоспособная середина — это небольшой набор постоянных предоставлений прав с узкой областью действия и явным сроком действия, плюс шаг подтверждения для всего, что выходит за их пределы. Шаг подтверждения записывает запись; это не модальное окно, которое исчезает.
Публикуйте схему. Иначе контрагенты изобретут несовместимые. Если каждый поставщик агентов и каждый продавец определяет свой собственный формат согласия, результат — набор реестров, которые нельзя сравнить, и проблема разрешения споров просто перемещается на уровень выше. Опубликованная схема — действующее лицо, контрагент, класс действия, объём, срок действия, высказывание, подпись — даёт каждой стороне общую цель. Ей ещё не нужно быть стандартом. Ей нужно быть публичной, версионированной и достаточно стабильной, чтобы контрагент мог строить под неё.
Что строить в первую очередь
Минимально жизнеспособный реестр согласий невелик. Определите схему записи. Подписывайте каждую запись. Сделайте её доступной только на добавление. Выведите читаемую пользователем историю. Добавьте проверку принудительного исполнения, которая отклоняет действия вне активных предоставлений прав и регистрирует отказ. Начните с классов действий, несущих наиболее необратимые последствия, — отмен, платежей, исходящих сообщений — и расширяйтесь оттуда.
Страница настроек может остаться. Это хороший способ настраивать постоянные предоставления прав. Это не запись о том, что было санкционировано. Это разные артефакты с разным временем жизни, и их смешение — ошибка, которую сейчас совершает большинство внедрений потребительских агентов.