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