AI-агенты входят в клиентский путь: как подготовить данные, сайт и процессы

07 Август 2026

Время чтения: 41 минута

AI-ответ дает пользователю информацию или рекомендацию. AI-агент может выполнить следующий шаг — например, заполнить форму или оформить запись. Если ваш бизнес принимает заявки, бронирования и заказы онлайн, статья поможет оценить готовность к такому клиентскому пути.

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

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

Но сначала давайте договоримся о терминах.

AI-ответ — текст, подборка или рекомендация, после которой пользователь продолжает путь самостоятельно.
AI-агент — система, которая может спланировать несколько шагов, выбрать доступные инструменты и выполнить разрешенное действие от имени пользователя.
Готовность к агентам — способность бизнеса дать агенту понятный и безопасный путь от запроса пользователя до результата.
Инструмент агента — функция, API, база знаний, поиск или другой подключенный механизм, который агент может вызвать во время задачи.
Браузерный агент — агент, который открывает обычный веб-интерфейс и взаимодействует с кнопками, полями, ссылками и другими элементами страницы.

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

Бизнес конкурирует за завершенное действие

Представьте, что девушка по имени Анна просит AI-агента найти ближайшую клинику и записать ее к терапевту на вечер.

В первом сценарии система собирает несколько подходящих клиник и дает ссылки. Дальше Анна сама проверяет врачей, расписание и форму записи.

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

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

Этот сценарий уже существует на российском рынке. Яндекс сообщает, что агент «Бронирование» в Алисе AI доступен более чем для 30 тысяч ресторанов и примерно 40 тысяч организаций сферы услуг. Если ресторан подключен к бронированиям через Яндекс Еду, бронь подтверждается автоматически. Когда запись доступна только на сайте заведения, агент заполняет форму и отправляет заявку.

Способ взаимодействия с агентом определяется двумя решениями

Единой архитектуры для всех агентных систем нет. В начале проекта полезно разделить два вопроса: через какой канал агент получает данные и выполняет действие, а также в чьем контуре он работает. Эти параметры могут сочетаться.

Канал выполнения

Браузерный агент открывает обычный сайт, ищет нужный товар или услугу, заполняет поля и нажимает кнопки. Такой путь возможен без специального API.

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

Контур агента

Собственный агент работает со стороны компании: общается с посетителем, уточняет запрос, подбирает продукт, обращается к внутренним данным и передает результат в CRM или другую систему. Бизнес контролирует его базу знаний, инструменты, правила ответа и границы действий. AI-консультант относится к агентам, если он вызывает инструменты и выполняет действия в системах компании.

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

У сценария два независимых параметра: канал выполнения действия и контур, в котором работает агент.

Сценарий стоит выбирать до технологии

Сначала определите клиентскую задачу, которую агент должен довести до измеримого финала. Если направлений много, соберите 5–15 частых и коммерчески значимых сценариев, сравните их по ценности и сложности, затем выберите один для пилота. Например:

для интернет-магазина — подобрать товар и проверить доставку к нужной дате;
для клиники — подобрать врача и доступное время;
для B2B-сервиса — выбрать тариф по размеру команды и требованиям клиента.

Для каждого сценария заранее зафиксируйте:

Ожидаемый результат. Что должно появиться в системе: черновик записи, корзина, расчет, лид в CRM.
Данные. Какие сведения нужны для решения задачи и откуда агент их получает.
Ограничения пользователя. Бюджет, город, даты, количество сотрудников, совместимость и другие условия выбора.
Разрешенные действия. Что агент может сделать сам: сравнить варианты, заполнить поля, подготовить черновик.
Точки подтверждения. Какие шаги требуют явного согласия пользователя или сотрудника.
Получатель результата. Куда попадает итог: CRM, система бронирования, корзина, чат менеджера.

Для каждого сценария заранее фиксируют результат, источники данных, ограничения, разрешенные действия и точки подтверждения.

Граница автоматизации. Она зависит от риска действия. Агент клиники может помочь выбрать услугу и время, затем отправить запись в систему. Медицинское заключение остается задачей специалиста. В B2B-сценарии агент может подготовить счет или черновик договора, а финальное согласование проходит по правилам компании.

Критические данные нужно привязать к надежным источникам

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

Минимальный набор зависит от отрасли, но обычно включает:

идентификацию — точное название и ID товара, услуги, филиала или специалиста;
финансовые условия — цену, валюту и правила расчета;
доступность — остаток, свободный слот, географию или другой текущий статус;
ограничения — минимальный заказ, возрастные требования, совместимость, условия оказания услуги;
актуальность — источник значения и время его последнего обновления.

Статические сведения — например, описание услуги или базовые характеристики модели — можно хранить в CMS или базе знаний. Динамические данные лучше получать из системы, которая отвечает за них в момент операции: CRM, ERP, WMS, системы расписаний и биллинга или синхронизированного фида.

Если сведения о компании расходятся между сайтом, презентациями и внешними профилями, сначала стоит привести их к единой версии. Подробнее мы писали об этом в статье «Контентная гигиена: как проверить факты о компании в AI-ответах». Факт-матрица полезна для эталонных сведений и владельцев данных; оперативные остатки и слоты должны приходить из рабочей системы, которая за них отвечает.

Для сущностей на сайте также полезна корректная структурированная разметка. Она помогает машинам распознать компанию, продукт, филиал или специалиста и связать сведения между собой, но сама по себе не гарантирует попадание в AI-ответ. Ее роль и ограничения мы подробно разбирали в статье «Разметка Schema.org для AI-поиска: что внедрить на сайт».

Браузерному агенту нужен устойчивый интерфейс

Представим, что агент уже открыл нужную страницу. Обнаружение URL, robots.txt, серверные ответы, индексацию и извлечение текста мы разбирали отдельно в статье «Как открыть сайт для AI: что делают маркетолог, SEO и разработчик». В этой статье нас интересует следующий этап: сможет ли агент пройти интерфейс.

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

В 2026 году Chrome также добавил в Lighthouse новую категорию Agentic Browsing. Она проверяет часть требований к доступности, стабильность интерфейса и интеграцию с WebMCP. Сейчас это информационный набор проверок с предупреждениями и статусами прохождения, без итогового рейтинга готовности сайта.

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

Для основного клиентского пути проверьте:

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

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

Надежность операции зависит от канала интеграции

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

Веб-интерфейс

Браузерный агент действует через существующие формы и элементы страницы. Этот путь позволяет использовать сайт без отдельного API и уже применяется в сценариях записи и бронирования.

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

API и инструменты

Компания открывает агенту ограниченный набор функций. Например, get_available_slots возвращает доступные окна, create_booking создает запись, get_order_status показывает статус заказа.

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

В российской инфраструктуре такой подход уже доступен разработчикам: Yandex AI Studio поддерживает подключение внешних и внутренних систем через MCP. Протокол дает единый способ подключать разные инструменты; при необходимости платформа также позволяет использовать кастомные функции поверх существующих API.

Инфраструктура внешней платформы

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

Отдельное развивающееся направление — WebMCP. Chrome описывает его как предлагаемый веб-стандарт, который позволяет явно объявлять инструменты для браузерных агентов через HTML и JavaScript. Летом 2026 года WebMCP доступен в рамках origin trial начиная с Chrome 149. Его можно использовать для прототипов и ранних проверок в поддерживаемых браузерных сценариях.

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

Полномочия агента нужно ограничить заранее

Агент с доступом к внутренним функциям может создавать записи и заявки, менять корзину и статус заказа, инициировать оплату. Для каждой операции стоит заранее задать уровень самостоятельности.

Автоматически. Безопасные и обратимые действия: поиск вариантов, чтение расписания, подготовка черновика.

После подтверждения. Действия с последствиями для пользователя: финальное бронирование, отправка контактов, платеж или отмена заказа.

Только сотрудником. Операции, которые компания относит к высокому риску или оставляет за ответственным специалистом.

До запуска нужно определить, что агент может читать, какие действия требуют подтверждения и какие операции остаются за сотрудником.

Базовый принцип — минимально необходимые права. Microsoft рекомендует задавать агенту отдельную учетную запись, ограничивать область доступа, разрешенные инструменты и действия, вести аудит и предусматривать отзыв прав.

Если агенту нужно только читать расписание, право удаления или изменения записей ему не требуется. Для создания лида достаточно отдельной функции с нужными полями; доступ ко всей CRM для этого избыточен.

Неоднозначность тоже нужно закладывать в сценарий. Запрос «перенесите меня на вечер» при нескольких свободных днях требует уточнения. Агент должен запросить недостающие условия до выполнения действия.

Безопасность проектируется вместе со сценарием

Чем больше данных и инструментов получает агент, тем важнее заранее определить границы доверия. Для агентных систем особенно опасны инструкции из внешнего контента, которые могут попытаться изменить поведение модели.

Это называется промпт-инъекции — инструкции во внешнем содержимом, которые пытаются заставить агента выполнить действие без запроса пользователя. Такая инструкция может находиться на веб-странице, в документе или письме.

После определения полномочий добавьте технические меры:

Проверка прав при каждом вызове. Рабочая система проверяет идентичность, область доступа и разрешение на конкретное действие. Одних ограничений в инструкции модели для этого недостаточно.
Контроль внешних ссылок. Проверка домена полезна, но ее недостаточно. OpenAI показывает риск редиректов и передачи чувствительной информации прямо в параметрах URL.
Защита от повторной операции. Платеж, заказ или бронирование должны выдерживать повторный запрос без двойного списания или дубля записи. Для этого применяют идемпотентные операции и уникальные идентификаторы; в HTTP API повторный запрос можно распознавать по ключу идемпотентности.
Журнал действий. Система фиксирует идентичность агента и пользователя, вызванную функцию, результат и ошибки. Чувствительные значения маскируются или исключаются согласно политике хранения данных.
Проверка атакующих сценариев. Перед запуском команда тестирует вредоносные инструкции, неожиданные входные данные, сбои внешних сервисов и попытки выполнить запрещенное действие.
Остановка и отзыв доступа. Microsoft советует предусматривать системный механизм остановки агента и детерминированные ограничения для запрещенных операций.

Клиентский путь должен сохранять контекст после действия агента

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

Показывайте точный статус. Фразу «Вы записаны» можно показывать только после подтверждения со стороны системы бронирования. Если создана заявка на обработку, пользователь должен увидеть именно этот статус.
Передавайте контекст сотруднику. Если агент переводит диалог менеджеру, вместе с обращением должны приходить основные условия запроса и этап, где возникла проблема. Тогда пользователю не придется повторять весь путь.
Сохраняйте выбранные параметры. Если человек уже выбрал филиал, услугу и время, переход на сайт или в приложение должен по возможности продолжать этот сценарий с теми же параметрами.

Аналитика должна охватывать весь агентный маршрут

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

Минимальная последовательность событий:

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

На основе этих событий можно оценивать четыре группы показателей.

Техническая доступность — доля попыток, в которых агент получил данные и начал нужный маршрут.
Качество выбора — соответствие предложенного варианта исходному запросу пользователя. Его можно проверять по подтверждениям пользователя, исправлениям и ручной оценке выборки.
Прохождение маршрута — переходы между выбором, стартом, подтверждением и завершением операции.
Бизнес-результат — заявки, записи, заказы, средний чек, доля операций без оператора и другие метрики конкретного процесса.

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

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

Если задача касается внешних AI-платформ и их вклада в продажи, подход к атрибуции отличается. Прямые и косвенные сигналы мы подробно разбирали в статье «Лиды из ChatGPT и Perplexity: как отследить AI-трафик и другие показатели».

Пилот лучше начинать с одного сценария

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

Шаг 1. Выберите частый сценарий с измеримым финалом, например создание черновика записи.

Шаг 2. Соберите 10–20 вариантов пользовательских формулировок: короткие, разговорные, с опечатками, неполными датами и неоднозначными условиями.

Шаг 3. Зафиксируйте итог пилота, критерии успеха и условия, при которых агент должен остановиться или передать задачу человеку.

Шаг 4. Проверьте источники данных и назначьте владельцев для критических сведений.

Шаг 5. Настройте один основной маршрут: через сайт, API или внешнюю платформу. Для каждой ошибки подготовьте понятное сообщение и дальнейший маршрут.

Шаг 6. Ограничьте права и добавьте подтверждения для действий с последствиями.

Шаг 7. Проведите функциональные проверки и тесты безопасности, затем откройте пилот небольшой аудитории и наблюдайте за ошибками.

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

Приоритет подготовки зависит от зрелости процессов

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

Высокий приоритет для проверки:

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

Средний приоритет:

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

Низкий приоритет:

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

В последнем случае полезнее сначала привести в порядок данные и процессы. Эта работа пригодится людям и будущим агентным интеграциям.

Готовность к агентам означает управляемость процесса

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

Хороший минимальный набор выглядит так:

один понятный пользовательский сценарий с измеримым финалом;
определенные источники статических и динамических данных;
устойчивый веб-интерфейс или структурированный инструмент для операции;
минимально необходимые права и точки подтверждения;
понятные статусы, отмена и передача сотруднику при сбое;
аналитика действий и технический журнал операций.

Этого достаточно, чтобы начать небольшой пилот и увидеть реальные ограничения. Дальше инфраструктуру стоит расширять там, где агентный сценарий приносит пользу и остается контролируемым.