Три главные ошибки в ИИ-стратегиях ретейлеров

Масштабированием ИИ-агентов в 2025 году занимаются меньше 10% компаний, согласно McKinsey. CEO и основатель Nodul, российского аналога n8n, Саша Данилов, объясняет, почему причину слабого масштабирования нужно искать в ошибочных подходах к ИИ-стратегии, а не в технологиях. Есть три основные ошибки, которые мешают ретейлерам перейти от эксперимента к масштабированию.

Ошибка 1. Запуск ИИ-агента без предварительного исследования

Самая распространенная ошибка связана с запуском ИИ-агентов без предварительного исследования внутренних бизнес-процессов. Типичные запросы на разработку агентов выглядят так: "Нам нужен агент поддержки", "Нам нужен агент для финансовых отчетов" или "Нам нужен агент для анализа производства". Но такие формулировки не являются правильно сформулированными задачами, которые могут и должны выполнять агенты.

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

В ретейле почти любая автоматизация с использованием ИИ на 80-85% состоит из операционных и интеграционных действий. Нужно интегрироваться с базой товаров и остатков, с базой поставщиков, с почтой, файловыми хранилищами, настроить фильтрацию, форматы данных и устойчивые процессы обмена информацией. Это десятки рутинных шагов, без которых ИИ просто не с чем будет работать.

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

Как правильно? Исследовать, на каком участке бизнес-процесса действительно нужен ИИ

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

Ошибка 2. Попытка создать универсального агента на все задачи

Практика показывает, почему универсальность агентов невозможна. Допусти, есть задача генерации и доставки промо-материалов пользователям. Попытка сделать одного универсального агента, который одновременно генерирует картинки и тексты, адаптирует их под разные когорты пользователей и каналы (e-mail, Telegram, сценарии звонков), а заодно проверяет формулировки на соответствие юридическим и внутренним политикам, почти неизбежно приводит к плохо управляемой системе. У такого агента слишком много разнородного контекста и задач, громоздкая системная инструкция и, как следствие, низкое качество и сложность поддержки.

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

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

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

Как правильно? Один агент - одна задача

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

Ошибка 3. Неограниченный доступ к данным для ИИ-агента

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

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

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

Как правильно? Ограничение доступов с помощью API-шлюзов

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