Тендеры и лиды
Информация
Автор: Иван Манжетов, Portfolio Manager KODE, AI-эксперт
Российский ритейл уже сложно назвать отраслью, которая только примеряется к искусственному интеллекту. По данным, которые IT Channel News приводил в сентябре 2026 года, ИИ-инструменты занимают около 26% цифровых экосистем российских ритейлеров, а за год их использование выросло на 22%. STAQ оценивает здесь распространённость ИИ-инструментов внутри цифровой среды ритейлеров, а не долю ИТ-бюджета. Подробную методику расчёта компания в открытых материалах не раскрывает, поэтому цифру корректнее воспринимать как оценку проникновения ИИ в цифровую экосистему бизнеса. Примерно 60% прироста приходится на прикладные задачи: обслуживание оборудования, работу с заявками, помощь сотрудникам и другие операционные процессы.
На пилоте всё часто выглядит убедительно. В одном магазине модель хорошо прогнозирует спрос, в одной категории агент за минуты собирает то, на что раньше уходили часы, внутренний помощник отвечает сотрудникам на вопросы по регламентам. После удачного теста бизнес хочет распространить решение на 500 магазинов, и на этом этапе начинается уже другой по сложности проект. В соседнем формате сети может быть иначе устроен ассортиментный справочник, часть магазинов работает на другой версии учётной системы, остатки обновляются с разной частотой, а у когда-то приобретённого бизнеса сохранился собственный ИТ-контур. Для одного источника есть современный API, для другого старый сервис, для третьего только выгрузка. Сам ИИ при этом продолжает решать задачу так же хорошо. Меняется среда, в которую его нужно встроить.
По данным Strategy Partners, до промышленной эксплуатации на российском рынке ИИ-агентов доходят примерно 7–10% пилотов. Около 30–40% проектов закрываются, ещё порядка 40% надолго остаются в тестировании, а 43% компаний масштабируют меньше пятой части запущенных пилотов. Эти данные относятся не только к ритейлу, поэтому переносить их напрямую на торговые сети было бы неправильно. Но они хорошо показывают разрыв между работающим прототипом и промышленной системой.
По исследованию аналитического центра IBS, ERP и HRM используют 90% исследованных ритейлеров, CRM используют все лидеры отрасли, Big Data — 80%. Среда кажется почти идеальной для ИИ, однако за годы цифровизации у крупных ритейлеров накопились десятки и сотни систем, созданных в разное время, разными командами и под разные задачи.
У MAGNIT TECH, например, речь идёт более чем о 800 информационных системах и сервисах. Одному агенту подключение ко всем им, конечно, не понадобится. Но помощнику категорийного менеджера могут быть нужны каталог, продажи, остатки, цены, промо и поставки. Агенту директора магазина потребуются графики сотрудников, оборудование, заявки, списания и внутренние регламенты. Закупочный агент использует ещё один набор источников. При запуске нескольких AI-продуктов быстро выясняется, что они постоянно обращаются к одним и тем же корпоративным системам.
После слияний и поглощений ситуация становится ещё сложнее. Показательный российский пример — объединение «Ленты Онлайн» и «Утконоса». Условия были относительно благоприятными: backend «Ленты Онлайн» был форком backend «Утконоса», а модели данных во многом совпадали. Несмотря на это, отдельной задачей стала унификация систем, создание общего хранилища и общей инфраструктуры данных. На технологическое объединение отвели три месяца, включая общие метрики и инфраструктуру. После M&A ритейлер вместе с новыми магазинами, покупателями и выручкой получает ещё один технологический слой, который затем приходится соединять с остальной компанией.
Для AI-агентов это особенно важно. Им часто требуется одновременно получить информацию из нескольких систем, сопоставить её, а затем выполнить действие. В результате значительная часть стоимости промышленного AI-проекта приходится уже не на модель, а на инфраструктуру вокруг неё.
Представим крупную сеть. Сначала она запускает помощника категорийного менеджера, затем агента закупок, помощника директора магазина, аналитического агента коммерческого блока и клиентского shopping-ассистента. Продукты разные, но всем в какой-то момент нужно найти товар, узнать цену, проверить остаток, посмотреть продажи или получить данные о поставке.
Если каждый проект начинается с нуля, команда каждый раз выясняет, где находятся нужные данные, как устроена авторизация, какой запрос отправлять, как обрабатывать ошибки и что делать при недоступности источника. Для первого пилота такой подход вполне приемлем. Когда похожая работа повторяется в пятом проекте, она уже становится отдельной статьёй расходов.
Возьмём условный расчёт. Подключение одного AI-сценария к каталогу, остаткам и ценам занимает четыре недели интеграционной работы. Если для пяти агентов эта работа практически повторяется, компания получает около 20 командо-недель на подключение разных продуктов к одним и тем же возможностям. Если доступ к каталогу, ценам и остаткам однажды оформлен как переиспользуемый инфраструктурный слой, следующая команда может больше времени потратить на бизнес-логику своего продукта. Поэтому полезно смотреть, сколько стоит подключение второго, пятого и десятого агента. Если десятый требует почти столько же интеграционной работы, сколько первый, расходы на инфраструктуру с каждым проектом продолжают расти почти линейно. Здесь и появляется MCP.
Model Context Protocol, или MCP, появился в 2024 году как открытый стандарт взаимодействия AI-приложений с внешними данными и инструментами. Сегодня разработчик может отдельно настроить для конкретного агента путь к остаткам: указать источник, способ авторизации, структуру запроса и нужное поле в ответе. Для следующего агента значительную часть этой логики приходится собирать заново.
Через MCP бизнес-система может предоставить AI стандартно описанный набор возможностей: найти товар, получить остаток, узнать цену, посмотреть продажи, создать заявку. Агент получает информацию о доступных инструментах, необходимых параметрах и формате ответа. По сути, появляется отдельный машинный вход к уже существующим бизнес-функциям.
При этом MCP не заменяет API и не создаёт программный доступ к данным там, где его раньше не было. Он не исправит справочник, в котором один товар существует под несколькими идентификаторами, и не модернизирует legacy-систему, которая обновляет остатки раз в сутки. Интеграционная работа тоже никуда не исчезает. Разница в том, что её результат можно использовать повторно в следующих AI-сценариях вместо создания отдельной связки для каждого нового продукта.
Один из самых наглядных российских кейсов есть у «ВкусВилла». Компания создала экспериментальный MCP-сервер, через который AI-агент получил три базовых инструмента: поиск товаров, получение информации о товаре и создание ссылки на готовую корзину.
Команда сравнила два способа выполнить похожую задачу. В первом варианте AI-ассистент работал с интернет-магазином как человек: открывал сайт, искал элементы интерфейса и переходил между страницами. Во втором агент напрямую обращался к каталогу и корзине через специальные инструменты. MCP-сценарий занял около полутора минут и потребовал восьми вызовов инструментов, а аналогичная задача через браузерного агента заняла больше девяти минут. Один эксперимент нельзя использовать как доказательство того, что MCP всегда сокращает время или стоимость в несколько раз, но разница хорошо показывает сам подход.
Большинство цифровых интерфейсов создавались для человека: ему показывают кнопку, карточку товара, корзину. Когда с тем же сервисом начинает работать AI-агент, промышленному решению зачастую удобнее предоставить собственный машинный способ выполнить нужное действие.
Есть задача на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR? Создайте тендер и выберите подходящего исполнителя из откликов.
Заполнить заявку
13843 тендера
проведено за восемь лет работы нашего сайта.
Позже сторонняя команда разработчиков подключила MCP «ВкусВилла» к своему AI-су-шефу. До интеграции бот мог подбирать продукты и давать рекомендации, после неё получил доступ к реальному каталогу и возможность формировать корзину. Одна опубликованная бизнес-возможность стала доступна другому AI-продукту без строительства отдельной интеграции со всей внутренней инфраструктурой ритейлера.
Похожий подход появляется в платежах. В документации Сбера по AI-платежам мерчанту предлагают два варианта: разработать собственный MCP-сервер или автоматически создать MCP-адаптер поверх уже существующего API. Внутренние системы при этом можно сохранить, добавив поверх них стандартизированный интерфейс для нового класса AI-клиентов.
Для крупного ритейла такой подход особенно интересен, поскольку позволяет использовать существующие API и бизнес-функции, не перестраивая внутреннюю архитектуру под каждый новый агентный сценарий.
Хороший MCP-слой тоже требует работы. Нужно определить, какие бизнес-возможности стоит публиковать, описать инструменты, продумать авторизацию и мониторинг, задать правила для автоматических действий и операций, требующих подтверждения, предусмотреть обработку ошибок и аудит.
Поэтому первый проект вполне может оказаться не дешевле обычной интеграции. Экономический эффект проявляется позже, когда второй, третий и десятый AI-продукт используют уже существующие инструменты вместо повторного подключения к тем же данным. В такой ситуации полезно отслеживать стоимость каждого следующего сценария. Её снижение означает, что компания постепенно создаёт инфраструктурный актив. Если стоимость остаётся примерно одинаковой, портфель независимых пилотов растёт, а переиспользуемая инфраструктура практически не накапливается.
По итогам 2025 года X5 оценила вклад собственных AI-решений примерно в 5 млрд рублей дополнительной операционной прибыли. Основной результат дали прикладные задачи ритейла: прогнозирование спроса и пополнения, ценообразование, управление ассортиментом и рекомендации.
При этом компания создала централизованный AI Core X5, общий контур для инфраструктуры, моделей, тестирования, оценки качества, агентных сценариев и прикладных сервисов. X5 не заявляет, что этот контур построен на MCP, поэтому связывать две технологии напрямую было бы некорректно. Кейс показывает другой важный принцип: масштабный экономический эффект становится возможен, когда AI-решения получают общую инфраструктурную основу. MCP в такой архитектуре может занять один конкретный слой между AI-продуктами и корпоративными данными и действиями.
Как только у агентов появляется единый слой доступа к системам, возрастает значение безопасности. Запрос «показать продажи за вчера» и команда «изменить цены в десяти тысячах магазинов» могут быть двумя инструментами одного агента, но последствия у них совершенно разные.
Поэтому для каждой операции нужно заранее определить, кто может её вызвать, какие данные доступны, разрешено только чтение или также изменение, требуется ли подтверждение человека, какие ограничения действуют и как действие будет записано в журнал аудита. Сам стандарт может развивать механизмы безопасности, но политика доступа всё равно остаётся ответственностью компании. Ошибка в проектировании полномочий просто получит стандартный и удобный интерфейс.
Представим, что агент без ошибок подключился к остаткам, но в первой системе товар записан как 12345, во второй как 0012345, а в третьей уже считается выведенным из ассортимента. Техническая интеграция работает, но использовать результат в бизнес-процессе сложно. Поэтому справочники, мастер-данные и управление их качеством остаются обязательной частью AI-проектов.
То же самое относится к процессам. По данным Strategy Partners, в 73% компаний при внедрении AI-агентов нет владельца процесса с достаточными полномочиями для быстрого принятия решений. В такой ситуации остаются без ответа практические вопросы: может ли агент самостоятельно создать заказ, какой объём ему разрешён, кто отвечает за ошибку, какая точность считается приемлемой и при каком результате пилот нужно масштабировать или закрывать.
Для промышленного внедрения должны одновременно работать данные, интеграционная архитектура, правила полномочий и экономика процесса.
До запуска очередного прототипа полезно заранее представить его промышленную версию. Какие системы понадобятся после масштабирования? Какие подключения к ним уже делали другие команды? Сможет ли следующий AI-сценарий использовать созданную интеграцию? Какие данные агент будет только читать и какие сможет изменять? Во сколько обойдётся поддержка решения после распространения на всю сеть?
Отдельно стоит проверить зависимость от конкретной модели или AI-платформы. Если их замена потребует заново строить доступ ко всем бизнес-системам, корпоративная логика слишком тесно связана с конкретным AI-стеком.
Малому ритейлеру MCP при этом может вообще не понадобиться. При одной учётной системе, одном AI-сценарии и отсутствии планов развивать парк агентов прямое API-подключение часто оказывается проще и дешевле. Для крупной компании с несколькими форматами магазинов, брендами, наследованными ИТ-контурами и большим количеством AI-продуктов переиспользуемый слой доступа уже становится практической задачей.
Начать можно с простой инвентаризации: определить, к каким данным и действиям разные AI-сценарии обращаются чаще всего и сколько раз компания уже оплатила создание похожих интеграций. Результатом может стать MCP, развитие API-management или работа с мастер-данными. Выбор зависит от реальной причины затрат.
AI-сценарий сегодня можно собрать за недели, а отдельные прототипы за несколько дней. Скорость экспериментов выросла настолько, что компания способна производить новые пилоты быстрее, чем строить инфраструктуру для их промышленной эксплуатации.
Поэтому полезно смотреть на то, что осталось после первого успешного проекта, что получилось использовать во втором и сколько стоил запуск десятого. MCP интересен в рамках этого более общего сдвига: доступ AI к корпоративным данным и действиям постепенно становится самостоятельным инфраструктурным слоем.
Пилот показывает, умеет ли ИИ решить конкретную задачу. Промышленное масштабирование показывает, сколько таких решений компания сможет поддерживать одновременно и во сколько ей это обойдётся.
