Когда регулирование ИИ в России не даёт выйти в продакшен

Регулирование ИИ в России: суверенные модели, сертификация и операционные барьеры — кто дойдёт до продакшена?

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

Это не абстракция. Внедрение дорожает на 20–40%. Сроки растут в 1,5–2 раза. До продакшена доходят лишь 7–10% пилотов. Конфликт простой: польза контроля для государства сталкивается с ценой для команды и бюджета. И именно цена решает, кто остаётся в игре.

Это важно для CTO, продуктовых менеджеров, руководителей по комплаенсу интеграторов. На кону — скорость запуска и выбор архитектуры: глобальные модели или «суверенные» системы внутри страны. Плюс — работа с реестрами, сертификацией и хранением данных.

Масштаб большой. В 2026 году мировые расходы на ИИ — $2,5 трлн. Потенциал рынка в России — около 520 млрд руб. Но барьеры перераспределяют рынок в пользу тех, кто инвестирует не только в технологии, но и в комплаенс, сертификацию и локальную инфраструктуру.

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

Почему регулирование стало фильтром продукта

Регулирование часто воспринимают как набор процедур. Маркировка, реестр, сертификация — сделали и пошли дальше. Ожидание простое: добавится бюрократия, но стратегия и скорость не изменятся.

В реальности всё иначе. Закон 2026 года вводит категории «суверенных», «национальных» и «доверенных» моделей. Критические системы нужно разрабатывать и обучать внутри страны. В госинфраструктуру допускаются только сертифицированные модели из реестра.

Это меняет экономику. Затраты растут на 20–40%. До продакшена доходят лишь 7–10% пилотов. Разрыв между ожиданием и фактом становится ключевой проблемой.

Для CTO и продуктовых команд выбор становится экономическим. Вопрос уже не «кая модель лучше», а «кая модель пройдёт комплаенс и сертификацию». Это и определяет судьбу проекта.

Как регуляция превращается в операционный барьер

Как работает фильтр

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

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

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

Откуда берутся ограничения

Причины три.

Первая — безопасность и контроль. Критический ИИ должен обучаться внутри страны.

Вторая — доступ к госинфраструктуре. Работают только модели из реестра после сертификации.

Третья — права пользователя. Нужны маркировка и возможность перейти к «живому оператору».

Каждое требование превращается в шаг в разработке. Локализация — это инфраструктура и данные. Сертификация — это тесты, документы итерации. «Живой оператор» — это фолбэк и управление эскалациями.

Что происходит на практике

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

Пример: интегратор доводит пилот до тестов, но застревает на сертификации. Появляются дополнительные циклы проверок и документации. Проект остаётся в пилоте или урезается по функциям.

Рынок тоже меняется. Поставщики с локальной инфраструктурой получают преимущество. Те, кто опирается на внешние API, чаще упираются в ограничения.

Команды меняют приоритеты. Важнее устойчивость и соответствие, чем скорость эксперимента. Бюджет уходит в комплаенс и сопровождение.

К чему это ведёт

Регулирование перестраивает экономику продукта. Комплаенс становится условием доступа к рынку. Архитектура строится под сертификацию и фолбэки. Итог проекта решают сроки и бюджет, а не только качество модели.

Дальше — конкретные ситуации и управленческие решения, которые помогают пройти этот фильтр.

Как барьеры проявляются в проектах

Банк внедряет чат-бот — нужен «живой оператор»

Вы запускаете чат-бота в поддержке. Тесты успешны. Бизнес ждёт снижения нагрузки.

Появляются требования: маркировка ИИ-ответов и мгновенный переход к человеку. Нужно фиксировать соответствие.

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

Вывод: ключевая метрика — не экономия на операторах, а готовность доказать соответствие и быстро переключаться на человека.

Стартап и внешняя модель

Команда берёт внешнее API для быстрого прототипа. Это дешево и быстро.

Но требования локализации и «суверенных» моделей мешают продакшену, особенно при работе с госданными.

Итог: MVP не переходит в продукт или требует дорогой переработки архитектуры.

Вывод: выбор поставщика на старте определяет, дойдёт ли проект до внедрения.

Интегратор и затянувшийся пилот

Пилот прошёл, но нужна сертификация и включение в реестр.

Появляются повторные тесты, документация, требования к данным. Сроки и бюджет выходят из-под контроля.

Проект зависает или упрощается.

Вывод: успех теперь зависит не только от продукта, но и от готовности пройти длительные процедуры.

Что делать команде: практические шаги

Регулирование нужно учитывать как часть продукта. Иначе проект упрётся в переделки на поздней стадии.

Что менять в подходе:

— Выбор архитектуры с учётом локализации. Сразу планируйте работу внутри инфраструктуры.

— Поставщики с поддержкой сертификации. Это снижает риск блокировок на продакшене.

— Фолбэк на «живого оператора» как базовая функция. Не как доработка.

— Документирование и тесты параллельно разработке. Это сокращает цикл сертификации.

— Минимизация внешних данных. Это упрощает согласования.

Такой подход переводит комплаенс из «переделки» в часть системы. В результате меньше переработок и ниже риск зависания в пилоте.

Регулирование стало экономикой продукта. Оно определяет, какие решения доходят до продакшена.

Практический вывод простой:

— проектируйте архитектуру под локализацию с первого дня;

— закладывайте сертификацию как часть процесса, а не финальный этап;

— сразу внедряйте фолбэки на человека.

Это снижает риск переделок и потерь времени.

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

Регулирование не обойти. Но под него можно спроектировать систему так, чтобы она дошла до рынка.

Частые вопросы о регулировании ИИ