Введение
ИИ-агент на базе языковой модели заходит на сайт почти так же, как человек: открывает страницу, ищет товар, заполняет форму, нажимает кнопку. Пока это работало без помех, владельцы сайтов не задумывались о том, кому открывают доступ. В октябре 2026 года картина заметно изменилась. По данным The Verge, которые пересказал Хабр 19 октября 2026 года, в последние недели пользователи сервисов Muse (разработчик Meta), Grok (xAI), Dots (OpenAI) и Instinct столкнулись с блокировками: их агенты не могли выполнять задачи на ряде сайтов.
Для бизнеса это не просто новость о чужих проблемах. Если ваш сайт закрыт для агентов, часть клиентов, которые поручили ассистенту купить, записаться или сравнить предложения, до вас не дойдёт. Если сайт открыт без правил, вы рискуете нагрузкой, утечкой данных и потерей контроля над ценами. Поэтому тему нужно разбирать как управленческое решение, а не как заметку о технологиях.
Что произошло и кто закрывает доступ
Из материала The Verge следуют несколько конкретных случаев. Yelp открывает свой сайт только тем агентам, владельцы которых оплачивают программу лицензирования данных. Авиакомпания Delta Air Lines препятствует покупке билетов через ИИ-агентов. Банк JPMorgan Chase и финансовая компания Charles Schwab подтвердили, что блокируют агентов из соображений безопасности. Сайты Cars.com и Amtrak также закрыты для ИИ-систем.
Отдельная история связана с Amazon и Perplexity. Amazon заблокировала функцию покупок с помощью ИИ в сервисе Perplexity и подала на стартап в суд, заявив, что неоднократно требовала прекратить использование агентов для покупок на платформе. Суд первой инстанции обязал Perplexity ограничить активность своих агентов на сайте Amazon, но в августе апелляционный суд это решение отменил. Amazon подала обновлённый иск с уточнениями, и он ещё рассматривается. Проблемы с доступом к Amazon, по сообщению того же материала, возникли и у Grok, Instinct, Dots и Muse.
Всё это касается крупных игроков, но логика одна и та же для компаний любого размера: доступ агентов становится предметом решения владельца сайта, а не технической мелочью. Подробный обзор ИИ-новостей за тот же месяц есть в нашем материале Новости ИИ-агентов для бизнеса: октябрь 2026.
Почему владельцы сайтов ограничивают агентов
Причины, которые назвали участники истории, различаются, но их можно сгруппировать.
Первая причина связана с безопасностью. Банки и финансовые сервисы не хотят, чтобы автоматический сценарий совершал операции без понятного контроля. Вторая причина связана с деньгами. Если данные сайта ценны для других компаний, их доступ логично продавать или лицензировать, как это делает Yelp. Третья причина связана с трафиком и рекламой. Amazon считает, что агенты, которые «бродят» по платформе, мешают ей показывать рекламу живым пользователям. Perplexity отвечает, что агент действует как продолжение самого пользователя и что компания, по сути, запрещает клиенту нанимать помощника. Четвёртая причина связана с контролем над продажами: компания хочет сама определять, как и на каких условиях оформляется покупка.
Эксперт по оценке безопасности ИИ Крис Канал, которого цитирует The Verge, связывает ситуацию с ожиданиями рынка. По его мнению, разработчики обещают, что агенты смогут выполнять любые действия, доступные человеку в интернете. Если компании активно этому препятствуют, круг полезных задач для агентов неизбежно сужается. Иными словами, блокировки влияют не только на отдельные сайты, но и на то, какие сценарии вообще станут массовыми.
Как агент взаимодействует с сайтом
Чтобы решить, что открывать, полезно понимать механику. Агент получает содержимое страницы: HTML-структуру, текст или снимок экрана. Затем он определяет, какие элементы можно нажать или заполнить, и выполняет действия по шагам. Для этого ему нужны те же доступы, что и человеку: каталог, корзина, форма записи, личный кабинет.
Такой способ работы называют имитацией браузера. Он быстро даёт результат, но создаёт проблемы. Защитные системы сайтов умеют распознавать автоматические сценарии по частоте запросов, поведению и техническим признакам. Ложные срабатывания при этом бьют и по обычным пользователям, и по легитимным агентам. Поэтому блокировка через «браузерный» путь не всегда означает злой умысел, но почти всегда означает потерю контроля.
Альтернатива — официальный интерфейс. API, фид с ценами и остатками или протокол взаимодействия агентов дают предсказуемый доступ с ключами, лимитами и журналом. Один из таких протоколов описан в материале Что такое MCP. Для владельца сайта это способ открыть нужные сценарии без передачи всего интерфейса чужому автомату.
Какую проблему бизнеса это решает
Вопрос зависит от роли компании. Если вы продаёте товары или услуги через сайт, проблема в том, что клиенты начинают поручать покупку или запись ассистенту, а ваш сайт для ассистента недоступен или работает плохо. Тогда вы теряете заказы, которые не видны в обычной аналитике, потому что до сайта они не доходят.
Если вы используете агентов для собственных задач, например для мониторинга цен конкурентов, сбора остатков у поставщиков или сверки данных в чужих кабинетах, проблема другая. Ваш процесс зависит от правил чужой платформы. Завтра платформа может закрыть доступ, потребовать оплату или изменить интерфейс, и процесс остановится.
Обе ситуации сводятся к одному: нужно заранее определить, какие сценарии агентов допустимы, по какому каналу, с какими лимитами и кто за них отвечает. Более общий разбор того, где ИИ-агенты уже работают в бизнесе, есть в статье ИИ-агенты для бизнеса.
Какие процессы затрагивает
Блокировки агентов касаются нескольких типов процессов, и риск у каждого свой.
Оформление заказов и записей — самый чувствительный процесс. Здесь важны подтверждение оплаты, наличие товара, согласие клиента и корректность данных. Открывать его агентам стоит только через API с аутентификацией и журналом операций.
Информирование о товарах, ценах и наличии — менее рискованный процесс. Часто его можно отдать через публичный фид или структурированные данные, которые агенты читают без имитации действий пользователя.
Ответы на типовые вопросы клиентов — процесс, который обычно не требует доступа к учётным записям. Достаточно того, что на сайте есть понятные страницы с условиями доставки, возврата и гарантии.
Сверка данных в личных кабинетах партнёров и поставщиков — процесс, где риск выше всего. Доступ к чужому кабинету часто запрещён условиями использования. Такие сценарии лучше согласовывать с владельцем платформы напрямую.
Сценарии для разных компаний
Интернет-магазин может выделить каталог и наличие в отдельный канал данных, обновляемый по расписанию. Агенты получают актуальные цены без обращения к витрине, а магазин контролирует, что именно видно. Заказ при этом оформляется через API с подтверждением покупателя.
Сервис записи, например салон, клиника или студия, может описать слоты бронирования через API с лимитом запросов на один ключ. Так агент не блокирует расписание, а клиент получает подтверждение от системы записи.
Компания с закрытым B2B-порталом не должна открывать личный кабинет агентам без договора. Разумнее предложить партнёрам API с правами доступа, которые выдаются по письменному соглашению.
Небольшой бизнес на старте может обойтись публичным прайсом в понятном формате и формой заявки с подтверждением. Агенты смогут прочитать предложение и передать заявку, а дальнейшее общение останется за человеком.
Пошаговый план действий
Ниже план для компании, которая хочет понять, что делать с агентами, и не зная заранее результата. Сроки ориентировочные и зависят от сложности системы.
Первый шаг — аудит. Посмотрите серверные логи и выясните, какие страницы запрашивают автоматические клиенты, и какие действия они пытаются выполнить. Аналитика пользователей показывает не всё: часть автоматических запросов в неё не попадает, поэтому опирайтесь на логи. Оценка займёт от нескольких дней до недели в зависимости от объёма трафика.
Второй шаг — политика. Определите, какие сценарии агентов допустимы, какие запрещены и какие требуют договора. Зафиксируйте это в условиях использования сайта и в файле robots.txt. Важно помнить, что robots.txt — это декларация правил, а не технический запрет: её соблюдение зависит от добросовестности агента.
Третий шаг — канал. Для каждого допустимого сценария выберите API, фид или публичную страницу. Если бизнес уже работает с готовой системой, уточните, есть ли у неё интерфейс для внешних систем.
Четвёртый шаг — защита. Выдайте отдельные ключи, ограничьте права и лимиты запросов, включите журналирование и оповещения о необычной активности. Ключи храните в секретах окружения, а не в коде.
Пятый шаг — пилот. Запустите один сценарий на ограниченной аудитории, измерьте долю заказов, ошибки и обращения в поддержку, и только после этого расширяйте доступ. Если вы рассматриваете внешнего подрядчика, полезно заранее описать требования к интерфейсу и приёмке. Практические шаги выбора исполнителя разобраны в материале Как заказать ИИ-агента.
Требования к данным и инфраструктуре
Для открытого канала нужны точные данные: актуальные цены, остатки, сроки доставки, условия возврата. Агент, который получает устаревшие данные, создаёт споры, поэтому источником должна быть та же система, что и для сотрудников.
Нужна документация интерфейса: описание методов, форматов, ошибок и лимитов. Нужна инфраструктура журналирования, чтобы можно было разобрать спорный заказ. Нужен владелец процесса, который отвечает за решения о доступе и за отключение ключа при нарушении.
Сложность внедрения зависит от системы. Если данные лежат в одной CRM или в одной базе товаров, работа проще. Если в нескольких учётных системах без единого справочника, сначала придётся навести порядок в данных. Точную оценку может дать только аудит на данных конкретной компании.
Экономический эффект
Эффект от открытия канала для агентов зависит от доли заказов, которые придут через него. Пока эта доля для большинства компаний неизвестна, поэтому считать её стоит на пилоте.
Ориентировочно расчёт выглядит так: доля заказов через агентов, умноженная на средний чек и маржу, минус стоимость разработки интерфейса, поддержки и инфраструктуры. Если итог отрицательный, сценарий не окупается и лучше ограничиться информационным каналом.
Отдельно стоит учесть возможную плату за данные. Yelp сделал доступ платным через программу лицензирования. Если ваши данные окажутся ценными для агентов, вы тоже можете рассматривать лицензирование как источник дохода. Но это решение требует юридической проверки и не должно приниматься в спешке.
Риски и ограничения
Юридический риск самый заметный. Спор между Amazon и Perplexity показывает, что вопрос доступа агентов к чужой платформе может дойти до суда, и решения бывают разными на разных инстанциях. Для собственного сайта риск обычно меньше, но условия использования должны описывать правила понятно.
Технический риск связан с тем, что защита сайта и агенты развиваются параллельно. Правило, которое сегодня работает, завтра может блокировать и обычных посетителей. Поэтому нужна регулярная проверка журналов и тестовые сценарии.
Репутационный риск возникает, если агент совершит ошибочную операцию: купит не тот товар, отправит заявку без согласия клиента или выведет чужие данные. Отвечать за такой случай будет владелец сайта, поэтому подтверждение действия человеком для финальных операций остаётся обязательным.
Есть и ограничение данных самих материалов. Информация о блокировках основана на сообщениях The Verge, пересказанных Хабром, и на текущем состоянии судебных дел. Решения могут измениться, поэтому перед внедрением проверяйте актуальные условия платформ и статус дел.
Безопасность и защита данных
Агенты получают доступ к данным клиентов, поэтому принцип минимальных прав здесь обязателен. Ключ должен давать только тот набор операций, который нужен сценарию. Персональные данные не стоит передавать агенту без правового основания и понятной цели. Если агент работает с перепиской или заявками, учитывайте требования к обработке персональных данных и храните журнал доступа.
Отдельное внимание нужно уделить подтверждению действий. Оплата, возврат, изменение адреса доставки и удаление записи должны требовать подтверждения человека или отдельного защищённого шага. Это снижает последствия ошибки в рассуждении модели и даёт юридически понятную цепочку ответственности.
Сравнение с альтернативами
Есть четыре основных варианта, и выбирать между ними стоит по задаче.
Официальный API даёт предсказуемость, журнал и управляемые лимиты. Его стоимость выше на старте, но он устойчив к блокировкам.
Фид с данными подходит для информационных сценариев: каталога, цен и наличия. Он проще API и почти не создаёт нагрузки, но не позволяет оформлять заказы.
Полный запрет агентам защищает сайт, но теряет часть клиентов. Этот путь уместен для закрытых сервисов и для компаний, где ошибка агента слишком дорога.
Открытый доступ без правил сохраняет максимальный охват и даёт наибольший риск по нагрузке, данным и суду. В большинстве случаев его стоит избегать.
Для собственных задач компании часто используют локальные модели, которые работают внутри инфраструктуры и не зависят от чужих правил доступа. Подробнее об этом варианте в материале Локальные ИИ-агенты.
Вывод и следующий шаг
Блокировка агентов сайтами — признак того, что доступ автоматических систем перестаёт быть техническим вопросом. Он становится частью стратегии: какие данные открыть, какие действия разрешить и на каких условиях. Компании, которые решат это заранее, получат предсказуемый канал для клиентов и агентов. Компании, которые откладывают решение, рискуют либо потерять заказы, либо обнаружить, что их сайт используется без их согласия.
Следующий шаг простой: откройте логи сервера за последний месяц, выпишите сценарии, которые пытаются выполнить агенты, и разделите их на три группы — разрешить, разрешить через API, запретить. Этого достаточно, чтобы обсудить решение с разработчиком. Материалы по теме собраны в категории ИИ-агенты блога W1DO.
