United ограничит ИИ-агентов поиском билетов: завершить покупку им не дадут

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

По сообщению The Verge со ссылкой на The Wall Street Journal, United не позволит сторонним персональным ИИ-ассистентам покупать билеты от имени пассажиров. Показывать рейсы они смогут. Завершать транзакцию — нет. Компания объясняет решение опасениями за персональные данные, риском непреднамеренных покупок и необходимостью соблюдать правила информирования пассажиров.

Где заканчивается поручение агенту

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

Вместе с ними возникают подтверждения, которые нельзя бездумно свести к очередному клику. В материале упоминается, например, подтверждение пассажиром отсутствия взрывчатых веществ в багаже. United опасается, что автоматическое прохождение оформления может обходить обязательные уведомления и процедуры.

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

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

За безопасностью виден вопрос посредника

У решения есть и коммерческая сторона. Глава United Скотт Кирби заявил, что не хочет создавать ещё одного посредника. Эта позиция важна для основателей: даже безопасный агент может встретить сопротивление компании, которая хочет сохранять прямые отношения с покупателем.

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

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

Что менять в продукте уже сейчас

Для команды, которая строит туристического ассистента, практический вывод — заранее спроектировать передачу оформления человеку. Агент собирает подходящие рейсы, объясняет различия и сохраняет выбранный вариант. Затем пользователь продолжает покупку у перевозчика. Насколько плавным получится переход, зависит от доступных интерфейсов; обещать сохранение всех полей без проверки интеграции нельзя.

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

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