Агент с правом платежа: полномочия, согласие и ответственность

Покупку удобно разделить на пять шагов: найти предложения, сравнить их, уточнить условия, принять предложение продавца и заплатить. Но согласиться купить товар и разрешить списание денег — разные действия. Агент может выполнить их от имени человека или компании. Поэтому нужно сохранить, что именно ему разрешили: какой товар, у какого продавца и за какую сумму.

Например, американский закон E-SIGN, §7001(h), допускает заключение договора через электронного агента. Нужно, однако, установить, что по закону действия программы считаются действиями конкретного человека или компании. Это не означает, что владелец отвечает за любую ошибку модели: важны выданные разрешения, условия договора и действующие законы. Электронная подпись помогает проверить, кто подписал документ и менялся ли он после подписания. Она не доказывает, что человек понял все последствия.

В решении Amazon v. Perplexity от 4 августа 2026 года суд рассматривал доступ к сайту по CFAA — американскому закону о компьютерном мошенничестве и злоупотреблениях (Computer Fraud and Abuse Act). В этом деле речь шла о доступе к компьютерной системе без разрешения. На странице 17 суд ограничил вывод обстоятельствами такого доступа. Это решение не отвечает на вопросы, кто возместит покупку неверного товара и когда покупателю вернут деньги. Главный вопрос этой статьи проще: как проверить, что агент сделал именно то, что ему разрешил человек?

В хронологии важнее смена статуса, чем число анонсов. Спецификация показывает, что стороны договорились о формате сообщений. Объявленная программа показывает намерение её запустить. Отдельная покупка подтверждает работоспособность конкретной интеграции. Ни одно из этих событий само по себе не измеряет размер рынка.

В сентябре 2025 года AP2 описывался через Intent, Cart и Payment. Текущая версия 0.2 использует два типа — Checkout и Payment. Историческую терминологию нельзя подставлять в современную таблицу полей. В апреле 2026 года Amex объявила Agent Purchase Protection; при повторной проверке 27 сентября страница по-прежнему описывает будущую защиту и обещает дополнительные условия.

2 июня Worldline, ING и Mastercard сообщили о покупке концертных билетов в Нидерландах: человек одобрил заказ перед завершением. Это пример реальной покупки с подтверждением человека. В нём нет доказательства, что потребитель делегировал открытый бюджет на неопределённую последовательность покупок.

В сентябре EMVCo вынесла проект технических правил на обсуждение. Проверка агента (KYA) и отметки о его участии в платеже названы возможными направлениями дальнейшей работы. Одновременно консультации Казначейства Великобритании и Банка России затрагивают разные части проблемы. Их сроки перечислены ниже отдельно: закрытие приёма замечаний не равно вступлению новых правил в силу.

Мандат — документ, в котором записано, что агенту разрешено делать. В протоколе AP2 v0.2 есть два типа: Checkout для оформления заказа и Payment для оплаты. Каждый бывает открытым — задаёт границы будущей покупки — и закрытым — описывает конкретный заказ или платёж. Это не три обязательных документа, которые нужно подписывать по очереди. Checkout и Payment помогают связать заказ с разрешением на оплату. Но сами документы ещё не решают, кто будет отвечать за ошибку.

Checkout отвечает на вопрос «что покупаем»: в открытой форме — допустимые товары и продавцы, в закрытой — конкретный заказ с подписью продавца. Payment отвечает на вопрос «как платим»: ограничения суммы и получателей превращаются в разрешение на определённый платёж. Закрытый Payment содержит сумму, валюту, получателя, способ оплаты и ссылку на заказ. Поэтому заказ правильных туфель ещё не разрешает любое списание, а разрешение потратить €120 — не разрешение купить любой товар.

Открытая форма не означает «можно менять всё до подтверждения»: агент выбирает только внутри заранее заданных границ. Закрытая фиксирует выбранное действие. При автономной покупке агент может оформить её сам в пределах выданного разрешения — новое нажатие человека требуется не всегда. Такой переход описан в автономном сценарии AP2.

Одноразовое и регулярное использование — ещё один, отдельный вопрос. Условие повторяемости в Payment задаёт частоту и, при необходимости, число повторений; бюджет ограничивает общий расход. Например, поручение «платить за сервис не больше €20 в месяц, не более 12 раз» может допускать разные суммы. Каждый платёж получает конкретную сумму и получателя. Поэтому «регулярный» не обязательно означает «всегда одинаковая сумма», а «закрытый» — не название фиксированного графика. Проверка товаров и заказа через Checkout сохраняется отдельно.

Кто подписывает документы? По правилам AP2 Checkout, агент готовит данные, доверенный интерфейс показывает их пользователю, а продавец подписывает данные конкретного заказа. AP2 допускает передачу полномочий через учётные данные пользователя или доверенного поставщика агента. Система должна проверить, кто кому передал разрешение и какие ограничения сохранились. У Visa Trusted Agent Protocol (TAP) другая задача: подпись запроса помогает узнать агента и проверить данные запроса. Она не заменяет согласие владельца карты на покупку.

Шесть полей в таблице — моя рамка проектирования: сумма, продавцы и товар, срок, режим, допустимые компромиссы, отзыв. В разных протоколах они представлены неравномерно. Особенно важно различать истечение срока и отзыв: короткая жизнь разрешения сокращает окно риска, но не даёт немедленно остановить уже выданное разрешение. Отзыв токена также не возвращает уже исполненный платёж.

Из этого следует практическое требование к интерфейсу: до включения автономии показать человеку не только общий бюджет, но и исключения. Например, допустима ли замена модели товара, входит ли доставка в потолок и можно ли продлить поручение без нового согласия. Если спецификация не предоставляет подходящего поля, приложение должно либо реализовать проверяемое ограничение отдельно, либо честно исключить такую гарантию из обещаний.

Частота подтверждений и объём разрешённых действий — разные параметры. Предварительный поиск низкой цены может длиться неделями, но покупка останется подтверждаемой, если перед списанием требуется новое разрешение. Именно так Google описывает Buy for me. У Amazon Auto Buy условие цены запускает покупку без нового подтверждения; компания описывает окно отмены 24 часа и срок поручения до шести месяцев.

Перевёрнутая U на схеме — иллюстрация теоретической модели Turan. В условиях этой модели дополнительные проверки сначала помогают, а затем утомление может ухудшить контроль. Это не измеренная зависимость для покупателей и не установленное оптимальное число нажатий. Для конкретного продукта надо отдельно измерять понимание ограничений, долю замеченных отклонений, ошибочные подтверждения и время выполнения.

Мой вывод для проектирования: подтверждение должно показывать проверяемое действие — товар, продавца, итоговую сумму, доставку и условия возврата. Пересказ агента не должен быть единственным источником этих данных. Изменение существенного условия после одобрения требует повторной проверки применимого разрешения, а при выходе за его границы — нового согласия. Окно отмены полезно после ошибки, но оно не заменяет проверку до списания.

У вопроса «кто платит за ошибку» несколько адресатов. Банк, выпустивший карту, рассчитывается с банком продавца; продавец отвечает перед покупателем; платёжный сервис — перед клиентом; разработчик — перед заказчиком. Например, правила Visa, §1.7.6.1, требуют от банка покупателя оплатить банку продавца действительную операцию. Это не обещание вернуть покупателю деньги, если агент выбрал неверный товар. Раздел §4.1.24.10 правил Visa описывает ответственность владельца карты. При этом правила сети не могут отменить права, которые закон обязательно предоставляет покупателю.

В ЕС платёжная директива PSD2 отдельно рассматривает согласие на платёж, списание без разрешения и возврат некоторых разрешённых платежей. Статьи 76–77 допускают возврат при определённых условиях, когда платёж инициировал получатель денег или он прошёл через него. Это не право вернуть любую неудачную покупку. В США Regulation E, §1005.2(m), определяет, какие переводы считаются неразрешёнными, а Regulation E, §1005.11 описывает исправление ошибок. Для кредитных карт действует отдельный набор правил — Regulation Z, §1026.13. Поэтому формула «не подтвердил — вернут; подтвердил — ничего не добиться» слишком груба.

Если агент выбрал неудачный товар, но соблюдал все ограничения, это ещё не значит, что деньги списали без разрешения. Если же он превысил лимит, нужно выяснить, на что человек согласился и кто пропустил нарушение. Способ вернуть деньги зависит от страны, способа оплаты и обстоятельств. Новая директива ЕС об ответственности за дефектную продукцию тоже не обещает возврат за любую ошибочную покупку: пункт 24 не относит одни лишь денежные потери к самостоятельному виду возмещаемого ущерба. Статья 6 перечисляет виды вреда, которые покрывает директива, а статья 22 — сроки её применения.

Amex описывает будущую добровольную защиту, а не уже доступную универсальную компенсацию. В опубликованных условиях обозначены подходящие карты США, зарегистрированный агент, переданное Amex подтверждённое намерение и отклонение от него. Сначала следует попытаться вернуть покупку продавцу, когда это возможно; субъективные ожидания не равны проверяемой инструкции. Полные условия и начало действия ещё нужно проверить при запуске.

В использованных источниках нет достаточно широкой подборки споров об ошибках агентов-покупателей. Это не значит, что исков нет или покупатели всегда проигрывают. Возможно, такие случаи пока не выделяют в статистике, продавцы решают жалобы возвратом, материалы споров закрыты или поиск охватил не всё. По этим данным нельзя уверенно сказать, как часто возникают споры и чем они заканчиваются.

Ограничения должны проверяться вне модели. Агент может предложить операцию, но отдельный исполнитель сверяет разрешение, получателя, сумму, срок и остаток бюджета. Подпись без такой проверки оставляет возможность подписать неправильное действие. AP2 исходит из потенциально враждебного поведения агентов; это полезное основание для разделения предложения и исполнения.

Разберём вымышленную покупку. Человек поручил купить одну пару зелёных туфель размера 38 у продавца A или B, не дороже €120 вместе с доставкой, до 18:00 пятницы. Допустимы заранее перечисленные модели; заменить цвет нельзя. Это пример архитектуры, а не описание готовой интеграции или обещание юридического результата.

1. Интерфейс показывает человеку ограничения и связывает одобрение с их точной версией. В реализации на AP2 оформляются соответствующие открытые Checkout и Payment через выбранную модель авторизации. Продавец подписывает конкретный заказ; участник с нужными полномочиями превращает открытые разрешения в документы на конкретную покупку. Хеши — цифровые отпечатки документов — позволяют проверить, что при покупке использовали именно одобренные версии.

2. Перед списанием исполнитель проверяет подписи, срок, идентификаторы товара и получателя, итог с доставкой и отсутствие уже исполненного заказа. Резервирование бюджета и защита от повторного исполнения должны выдерживать два одновременных запроса: две покупки по €100 не могут пройти через один остаток €120. Недоступность проверяющего сервиса должна останавливать исполнение, а не превращать ограничение в совет.

3. В первом исходе куплены разрешённые зелёные туфли за €110, но они оказались неудобными. Проверка полномочий прошла; субъективное недовольство не доказывает нарушения мандата. Сохраняются условия возврата продавца и другие применимые права. Во втором исходе списано €130 или куплены красные туфли. Если это видно в проверяемых данных заказа, исполнитель должен был отклонить действие. Если заказ обещал зелёные, а доставлены красные, ошибку допустил продавец при выполнении заказа. Один и тот же внешний результат требует разных доказательств.

4. Для спора нужны исходное одобрение, версия ограничений, цепочка подписей, снимок заказа, результат проверки, квитанция платежа и история доставки или возврата. Остановить будущие операции можно отдельным отзывом полномочий и токена; завершённый платёж требует отдельной процедуры. Журнал должен позволять восстановить решение без хранения лишних персональных данных. По правила Visa, §4.1.24.8 подтверждение заказа должно быть доступно держателю карты как минимум 120 дней; это не универсальный срок хранения всех данных.

Пример показывает, что именно система умеет проверять. Электронная подпись помогает установить, какой документ одобрили. Проверка по заданным правилам — соблюдены ли цена, цвет и другие ограничения. Ни то ни другое не гарантирует качество товара и не определяет автоматически, кто возместит ущерб. Для этого нужно разобраться в обязанностях участников и правилах рассмотрения спора.

Агента можно склонить к выбору, не взламывая платёжный токен. Порядок предложений, привлекательная метка или текст продавца действуют раньше, когда формируется корзина. Эксперименты полезны именно для поиска таких слабых мест; они не измеряют долю обманутых покупателей на реальном рынке.

В исследовании ACES нельзя смешивать визуальные витрины и прямой программный интерфейс. В нашей таблице приведены только результаты для моделей, которые читают текст и изображения (VLM). Авторы описывают эти результаты в таблице 2 и пояснении к ней в версии v3 исследования ACES. Метка Overall Pick («Лучший выбор») повышает вероятность выбора товара, а Sponsored («Реклама») — снижает по сравнению с витриной без этих меток. Перенос эффекта на новые модели, реальный ассортимент или иное число вариантов требует нового эксперимента.

В Magentic Marketplace эффект первого ответившего различается по моделям, а если модель не смогла выполнить задачу, это ещё не значит, что она устойчива к такому влиянию. Практический вывод — проверять качество выбора при перестановке предложений, смене меток и задержках ответа. Это тест устойчивости решения, который дополняет проверку полномочий: агент способен ошибиться, формально оставаясь в пределах бюджета.

Sponsored Agents в анонсе OpenAI — другой наблюдаемый формат: человек переходит к общению с агентом бренда. Это не доказательство, что реклама уже продаётся автономным покупающим агентам. Возможность платного продвижения в машинных каналах остаётся отдельным прогнозом. Для её проверки нужны интерфейс размещения, коммерческие условия и наблюдаемое влияние на выбор агента, а не просто слово «агент» в названии рекламы.

Покупка API-вызова и заказ обуви различаются предметом, исполнением и возможным спором. Машинный платёж может оплачивать доступ к данным или вычислениям, но обозначение M2M (machine-to-machine, «между машинами») ничего не говорит о том, что разрешено агенту: программа может тратить строго фиксированную сумму или выбирать покупки в пределах бюджета. Поэтому машинные расчёты показаны отдельным контекстом, а не следующей ступенью автономии.

Чтобы посчитать средний чек, нужно разделить сумму платежей на число операций за тот же период. В сохранённой записи панели x402 указаны $24,24 млн и 75,41 млн операций. Если они относятся к одному набору платежей, получается около $0,3214 за операцию. Но повторно получить эти значения на обновляемой панели не удалось. Это проверка арифметики, а не подтверждённый средний чек рынка. Для надёжной оценки нужен архив с датами и пояснением, что считали операцией и как исключали повторы и переводы самому себе.

Прогнозы в таблице — сценарные оценки авторов, не измеренные продажи. Bain исключает покупки, где AI использован только для поиска, но включает влияние агентов на дальнейший путь. McKinsey оценивает более широкое участие агентов в организации покупки. Даже одинаковый год не делает методики одинаковыми. Сравнивать эти числа напрямую нельзя: сначала нужно проверить, что совпадают годы, страны и то, какие покупки учтены.

Отсутствие раскрытых сопоставимых объёмов означает, что масштаб пока нельзя надёжно оценить из этой выборки. Оно не означает отсутствия рынка. Для следующей проверки нужны отдельно: покупки с рекомендацией AI, покупки с подтверждённым агентским оформлением, списания без нового согласия и машинная оплата ресурсов. Иначе рост переходов из чата легко принять за рост автономных платежей.

В России полезно разделять документ регулятора, предлагаемую инфраструктуру и доступный покупателю продукт. Концепция платформы коммерческих смарт-контрактов обсуждает автоматическое выполнение условий сделки с цифровыми рублями. Лимиты отправителя и условные расчёты похожи на ограничения для агента, но не являются готовым режимом согласия или ответственности для любого AI-покупателя.

Нет основания утверждать, что постоянное поручение появится только после конкретной функции цифрового рубля: технически оно может использовать и другие платёжные инструменты. Так же нельзя подменять данные о реальных платежах опросом готовности делегировать или тестом нескольких сценариев. Проценты намерений не дают долю рынка, а успешные покупки в тесте не показывают оборот.

Таблица объединяет четыре разных процесса, а не четыре одинаковые реформы. На дату проверки 27 сентября все указанные сроки ещё впереди. Они закрывают приём замечаний, но не гарантируют публикацию итогов в тот же день. Окончательные тексты и даты их применения нужно анализировать отдельно; проекты не следует читать как принятые требования.

Моя лестница измеряет объём разрешённых решений, от чтения до самостоятельного распределения бюджета. Это инструмент проектирования, не юридическая классификация и не рейтинг зрелости компаний. У одного продукта могут одновременно быть разные уровни для разных действий: он сам выбирает момент покупки, но требует подтверждения смены адреса.

Самое важное при переходе вверх — не убрать ещё одно нажатие, а показать, какое новое решение разрешено программе. Для бюджета это выбор нескольких операций и расходование общего остатка. Такой режим требует проверки совокупного расхода, а не только потолка одного платежа. Поле в протоколе позволяет записать ограничение. Это ещё не означает, что продукт с такой функцией доступен всем.

Для продуктовых прогнозов область проверки — публичные страницы и условия продуктов из этой статьи плюс новые запуски, найденные при повторном поиске. Положительный пример подтверждает существование продукта; отсутствие найденного примера остаётся ограниченным результатом поиска. Поэтому статус «не установлено» нужен наряду с подтверждением и опровержением. Статистика споров полезна для оценки риска, но сама по себе не доказывает выход продукта из пилота.

Для работающей системы нужны четыре вещи: человек понимает, что разрешает; система сохраняет это разрешение; отдельный сервис проверяет действие перед оплатой; журнал хранит записи на случай спора. А кто и при каких условиях вернёт деньги, нужно выяснять отдельно по договору и закону. Даже правильно подписанный платёж не гарантирует компенсацию за неудачную покупку.