United закрыла доступ ИИ-агентам к бронированию перед праздниками

Одна из самых понятных историй про ИИ-агентов — «купи мне билет подешевле» — только что упёрлась в первую крупную стену. По данным Bloomberg, United Airlines блокирует сторонних ИИ-агентов: им больше нельзя бронировать рейсы и получать доступ к аккаунтам клиентов. Решение приурочено к началу праздничного сезона, а заявленная причина — риски для приватности.

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

В чём реальная проблема

Представьте типичный сценарий. Пользователь пишет ассистенту: «Найди билет в Денвер на пятницу и купи самый дешёвый». Агент открывает сайт авиакомпании, входит под данными пользователя и оформляет заказ. Со стороны это выглядит удобно.

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

Почему авиакомпании закрываются

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

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

Что делать разработчикам и продактам

Главный вывод простой: схема «агент ходит по сайту под логином пользователя» — это не интеграция, а обход. Она работает, пока владелец сайта не решит иначе. United показал, что решает.

Практически это значит следующее:

• Не стройте критический путь на эмуляции браузера. Если покупка билета — ключевая функция вашего продукта, зависимость от чужого фронтенда станет вашим главным риском.
• Ищите официальные каналы. Это API, партнёрские программы, делегированный доступ с ограниченными правами, когда агент может только искать и бронировать, но не читать профиль целиком.
• Делайте человека частью процесса. Агент подбирает варианты и готовит заказ, а финальное подтверждение и оплата проходят на стороне пользователя или авиакомпании. Это и безопаснее, и устойчивее к блокировкам.
• Читайте условия использования до запуска. Для агентов, которые действуют за пользователя, юридическая часть уже не формальность.

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

Что пока неясно

Мы не знаем, касается ли запрет всех агентов, включая те, что встроены в популярные ассистенты, или только автоматизации «снаружи». Не знаем, готова ли United предложить легальную альтернативу, например собственный API для агентов. И рано утверждать, что остальные авиакомпании пойдут тем же путём: часть из них может, наоборот, открыть двери партнёрам и получить новый канал продаж.

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