Первое рождение ML-автоматизации в России пришлось на эпоху классического машинного обучения: деревья решений, CatBoost, XGBoost и скоринговые модели, где «ML для бизнеса» означало аккуратный пайплайн на табличных данных с дата-сайентистом, неделями настраивающим гиперпараметры. Второе рождение случилось благодаря LLM в агентном режиме, и эти роды получаются не легче первых. Ключевая проблема — неравномерное отставание от мирового уровня на 1–1,5 года: в одних нишах разрыв меньше, в других больше. Именно эта неравномерность создает странную картину, которую сейчас наблюдают почти все интеграторы: индустрия предлагает клиенту вчерашнюю архитектуру, а клиент, начитавшись свежих обзоров, уже просит завтрашнюю. Типичный запрос звучит так: «хотим платформу для ИИ-автоматизации, соберите нам ее, а дальше мы сами будем запускать модели, менять их на более новые и так далее». По сути, клиент просит ML-автоматизацию малой кровью, без постоянной зависимости от подрядчика.

В ответ на рынке ему почти всегда предлагают одно из двух: либо коробочное решение поверх облачной модели по подписке (чаще всего обернутое в интерфейс Claude или другой внешней модели по API), либо мощный сервер с одной большой моделью, развернутой локально. У этих двух вариантов на первый взгляд разная архитектура, но на самом деле одна и та же логическая ошибка: и в том, и в другом случае бизнесу пытаются продать один универсальный «мозг», который должен одинаково хорошо закрывать вообще все задачи компании, от звонков в контакт-центре до анализа юридических договоров. Раньше представитель клиента узнавал про новые технологии от того же подрядчика, который ему это и продавал, асимметрия информации была на стороне продавца, и продавать один и тот же монолит под разными вывесками было легко: один раз написать ядро, дальше менять только интерфейс и брендинг. Классическая модель софтверного бизнеса: написал один раз, продал много раз.

Сейчас представитель клиента открывает чат-бота и сам за пять минут выясняет, чем RAG отличается от fine-tuning и почему модель нужно дообучать строго под свои данные и процессы. Асимметрия исчезла, и на встрече звучит фраза, которая ломает бизнес-модель интегратора: «Нам не нужна одна большая модель на все процессы, нам нужно, чтобы каждая задача решалась отлично, и мы сами хотим запускать модели, меняя их на свежие по мере выхода». А отдельная задача, дообученная под данные конкретной компании, это по определению не то, что можно тиражировать в следующем проекте без переделки. Тут нужно уточнить: количественно спрос на готовые ИИ-инструменты не падает. По прогнозам, которые приводит Gartner, доля корпоративных приложений со встроенными ИИ-агентами должна вырасти до 40% к концу 2026-го против менее чем 5% годом ранее, и значительная часть роста идет именно через low-code/no-code инструменты просто потому, что инженеров, способных строить продакшн-грейд агентные системы с нуля, физически не хватает. Low-code частично снимает кадровый голод при сборке сценариев, но бессилен там, где упирается в качество самих моделей.

Здесь важно разделить два разных явления, которые вносят путаницу. Оркестрационный слой (интеграции, вебхуки, HTTP-тулы, маршрутизация вызовов между системами) растет и никуда не денется, потому что решает задачу интеграции систем, а не задачу качества модели. Идея одной большой модели-монолита как источника интеллекта для всех задач умирает, потому что клиент теперь точно знает: без специализации под конкретную задачу и конкретные данные результат будет посредственным везде понемногу. Если ядром решения является вызов одной облачной модели по API на все случаи жизни, то для российского бизнеса это почти всегда упирается в 152-ФЗ, причем сразу в несколько разных по природе требований. Во-первых, локализация (ч. 5 ст. 18): с 1 июля 2025 года, после поправок 23-ФЗ, первичный сбор и запись персональных данных россиян через зарубежные базы прямо запрещены. Во-вторых, основание обработки и договор поручения (ст. 6): если данные по вашему заданию обрабатывает облако, SaaS или модель, с обработчиком должен быть оформлен договор поручения, и без него сама передача данных обработчику уже будет нарушением, еще до всякой утечки. В-третьих, отдельное и часто забываемое требование заключается в уведомлении РКН о трансграничной передаче персональных данных до ее начала (ст. 12), если обработчик физически находится за пределами РФ. Эта процедура не закрывается ни локализацией, ни договором поручения. Западные облачные сервисы в большинстве случаев не дают закрыть ни второе, ни третье требование в принципе (здесь и далее популярное изложение логики закона, а не юридическая консультация). Отсюда и исключение, о котором знают опытные интеграторы: если в системе есть необезличенные персональные данные, работать можно только в российском контуре, используя либо российское облако с оформленным договором поручения (Yandex Cloud, Sber AI, VK Cloud), либо собственные GPU-серверы с open-source моделями.

Сравнение с альтернативами показывает, что у российских компаний есть несколько путей развития. Первый — продолжать использовать зарубежные облачные API, несмотря на юридические риски, но это становится все менее приемлемым из-за ужесточения законодательства и риска утечки данных. Второй — развертывать собственные GPU-серверы с open-source моделями, что дает полный контроль над данными, но требует значительных инвестиций в инфраструктуру и квалифицированных специалистов для обслуживания. Третий — использовать гибридный подход: локальные модели для чувствительных данных и облачные сервисы для менее критичных задач, но это усложняет архитектуру и требует тщательного проектирования. Каждый из этих путей имеет свои преимущества и недостатки, и выбор зависит от конкретных потребностей и ресурсов компании. Однако очевидно, что будущее за гибкими, модульными системами, которые позволяют быстро адаптироваться к изменениям и использовать лучшие модели для каждой задачи. В этом контексте ключевую роль играют платформы оркестрации, которые могут управлять вызовами к различным моделям, как локальным, так и облачным, обеспечивая при этом соблюдение всех правовых норм. Такие платформы уже начинают появляться на российском рынке, и их развитие будет стимулировать дальнейший рост спроса на ИИ-автоматизацию.

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