Что произошло
21 сентября 2026 года агентство РБК сообщило о заметном изменении стратегии в российском промышленном секторе. Компании сокращают затраты на внешнее облачное ИИ-программное обеспечение и наращивают закупки серверного оборудования для развёртывания моделей внутри корпоративного периметра. Этот сдвиг является реакцией на ужесточение регуляторной среды и стремление бизнеса к полному контролю над технологическими данными и процессами.
Ключевым драйвером стал Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации», подписанный 26 июля 2026 года. Основные положения закона вступили в силу 1 сентября 2026 года. Документ вводит регулирование для больших фундаментальных моделей — систем с числом параметров от 1 млрд, — и устанавливает требования к хранению и обработке данных на территории России для категорий «суверенных» и «национальных» моделей.
По нашему опыту проектов, закон не вводит немедленного запрета на использование иностранных облачных сервисов, но создаёт правовую основу для будущего обязательного применения отечественных решений в отдельных сферах. С 1 марта 2027 года правительство получит право устанавливать перечень отраслей и случаев, где бизнес сможет использовать только суверенные или национальные модели. Эта мера заставляет компании заранее перестраивать архитектуру, чтобы избежать рисков внезапной остановки критичных ИИ-сервисов.
Ситуация усугубляется глобальными трендами на рынке ИИ-оборудования. 21 сентября 2026 года стало известно о приобретении компанией NVIDIA израильского разработчика edge-ИИ-процессоров Hailo, а также о заключении соглашения о покупке Hugging Face за $12,93 млрд. Эти сделки подчёркивают консолидацию рынка ИИ-инфраструктуры и усиливают зависимость от ограниченного числа поставщиков, что для российской компании является дополнительным стимулом для создания собственного, контролируемого вычислительного контура.
Как это устроено
Регуляторная механика 243-ФЗ
Закон № 243-ФЗ вводит два статуса для больших моделей: «суверенная» и «национальная». Для обеих категорий обязательным требованием является хранение и обработка данных на территории России с участием российских юридических лиц. Различие заключается в разработчике: для суверенной модели им может быть только российское юрлицо, в то время как национальная модель допускает использование зарубежных компонентов на условиях открытой лицензии. Это означает, что компания может использовать зарубежную архитектуру, но обязана обеспечить обработку данных внутри страны, что фактически исключает использование публичных зарубежных облаков для таких моделей.
Экономика перехода: CAPEX против OPEX
Переход на собственный ИИ-контур меняет экономическую модель с операционных расходов (OPEX) на капитальные (CAPEX). В облаке компания платит за фактически потреблённые ресурсы, что удобно на стадии пилота или при нерегулярных нагрузках. При развёртывании собственного кластера первоначальные затраты включают серверы с ускорителями, системы хранения, сети, охлаждения и бесперебойного питания. По нашему опыту проектов, сравнение должно основываться не на месячном облачном счёте, а на полной стоимости владения (TCO) за 3–5 лет, включая амортизацию, электроэнергию, зарплаты инженерной команды и стоимость резервирования.
Архитектура гибридного контура
На практике для промышленного предприятия наиболее эффективна гибридная архитектура. Центральный контур размещается в корпоративном или коммерческом российском ЦОД и используется для тяжёлых задач: обучение и дообучение моделей, подготовка датасетов, пакетный анализ. Площадочный edge-контур разворачивается непосредственно на производстве и решает задачи с низкими требованиями к задержке: компьютерное зрение для контроля качества, анализ вибрации для предиктивного обслуживания, мониторинг технологических процессов. В облако или центральный ЦОД передаются не сырые потоки данных, а лишь агрегированные результаты, что снижает нагрузку на сеть и риски утечки.
Ограничения импортозамещения
Ключевым ограничением является отсутствие на российском рынке полностью отечественного программно-аппаратного стека для тяжёлых ИИ-нагрузок. По оценке поставщика AZONE-AI, на 2026 год собрать закрытый on-premise-контур для LLM возможно, но российского промышленного GPU-ускорителя, сопоставимого с решениями NVIDIA для обучения больших моделей, не существует. Это означает, что «собственный контур» не равнозначен «полностью импортонезависимому контуру». Компания может контролировать размещение данных и эксплуатацию, но будет зависеть от импортных ускорителей, компонентов и микрокодов.
Влияние на безопасность и операционные риски
Размещение ИИ-инфраструктуры на собственной площадке не гарантирует безопасности автоматически. Наоборот, оно требует построения полноценной системы защиты: сегментации сети, управления доступами, аудита действий моделей, мониторинга уязвимостей в ПО и регулярного обновления драйверов. Неправильно настроенный API или хранилище внутри периметра может стать такой же угрозой, как и взлом облачного аккаунта. Операционные риски смещаются от доступности внешнего сервиса к надёжности собственной инженерной системы и компетенциям команды.
Как это выглядит на практике
Сценарий 1: Предиктивное обслуживание на металлургическом комбинате
Крупный металлургический комбинат использует для контроля прокатных станов тысячи вибрационных датчиков и температурных сенсоров. Ранее данные агрегировались и раз в час отправлялись в облако для анализа предиктивной моделью. Задержка в получении прогноза и риски передачи технологической информации за пределы периметра были неприемлемы. Комбинат развернул edge-серверы с GPU-ускорителями непосредственно в цехах. Теперь компактные модели анализируют данные потоково в режиме реального времени, формируя предупреждение о возможном отказе за 15–20 минут до события. В центральный ЦОД передаются только метрики и инциденты для долгосрочного анализа и переобучения глобальной модели.
Сценарий 2: Контроль качества на сборочном производстве
Завод по производству бытовой техники внедрил систему компьютерного зрения для обнаружения дефектов сварных швов и сборки. Камеры генерируют видеопоток в 4K с частотой 60 кадров в секунду, что создаёт терабайты данных в смену. Передача такого объёма в облако экономически нецелесообразна и технологически сложна. На производственной линии были установлены промышленные ПК с ускорителями, где в реальном времени работает модель детекции дефектов. Система бракует продукцию и отправляет отчёт в MES-систему предприятия. Обучение и дообучение модели на новых типах дефектов происходит ежеквартально на центральном кластере, после чего обновлённая версия разворачивается на edge-узлах.
Что это значит для российской компании
Для технического директора и руководителя ИИ-направления текущая ситуация требует пересмотра стратегии в области данных и вычислений. 243-ФЗ не запрещает облака, но делает их использование для больших моделей с чувствительными данными юридически рискованным в среднесрочной перспективе. Выбор стоит не между «облаком» и «своим ЦОДом», а между комбинацией режимов для разных классов задач и данных. Ключевым фактором становится суверенитет данных и операционная независимость, а не только цена GPU-часа.
Санкционные ограничения и дефицит оборудования делают планирование закупок сложной задачей. Необходимо закладывать в проекты длительные сроки поставки, рассматривать различные каналы импорта и формировать стратегический запас комплектующих. Бюджеты смещаются от переменных расходов на аренду к значительным единовременным вложениям в CAPEX, что требует долгосрочного финансового планирования и обоснования инвестиций через расчёт TCO.
В таблице представлены ключевые различия подходов для принятия решения.
| Критерий | Облачный ИИ (публичный) | Собственный ИИ-контур |
|---|---|---|
| Капитальные затраты (CAPEX) | Минимальны | Высокие (серверы, СХД, сеть, инфраструктура) |
| Операционные расходы (OPEX) | Высокие при постоянной нагрузке | Умеренные (электроэнергия, персонал, ПО) |
| Контроль данных | Частичный (зависит от провайдера) | Полный |
| Задержка (latency) | Средняя/высокая (зависит от сети) | Низкая (локальная обработка) |
| Зависимость от поставщика | Высокая (API, тарифы, санкции) | Низкая (после закупки) |
| Требования к команде | MLOps, Data Science | MLOps, Data Science, DevOps, SysAdmin, ИБ |
| Соответствие 243-ФЗ | Риск невыполнения для больших моделей | Высокое (при локализации в РФ) |
Что делать: пошагово
- Провести полную инвентаризацию существующих и планируемых ИИ-проектов, классифицировать данные по степени критичности (технологические, персональные, коммерческие).
- Определить, какие из используемых или планируемых моделей попадают под критерий «большой фундаментальной модели» (от 1 млрд параметров) и подпадают под требования 243-ФЗ.
- Выбрать один пилотный сценарий с высокой ценностью для бизнеса и чувствительными данными (например, контроль качества или предиктивное обслуживание) для перевода на on-premise.
- Разработать экономическую модель, рассчитав полную стоимость владения (TCO) для облачного и собственного варианта на горизонте 3–5 лет с учётом всех затрат.
- Провести аудит доступности на российском рынке целевых серверов, GPU-ускорителей и запасных частей, оценить сроки поставки и гарантийные риски.
- Спроектировать гибридную архитектуру, разграничив нагрузки между центральным ЦОДом (обучение) и площадочными edge-узлами (инференс).
- Сформировать или доукомплектовать команду, добавив в неё экспертов по эксплуатации ИИ-инфраструктуры, сетям и информационной безопасности.
- Разработать и внедрить политику безопасности для ИИ-контура, включая управление доступами, аудит моделей и защиту цепочки поставки ПО.
Типичные ошибки
- Приравнивание on-premise к автоматической безопасности. Размещение на своей площадке не отменяет необходимости в сегментации сети, управлении доступами и регулярном обновлении. Уязвимость внутри периметра может быть опаснее внешней.
- Недооценка полной стоимости владения. Сравнение месячного счёта из облака со стоимостью серверов — грубая ошибка. Необходимо включать в расчёт электроэнергию, зарплаты инженеров, системы охлаждения, резервирование и утилизацию.
- Попытка построить «полностью российский» стек с нуля. Отсутствие отечественных GPU для тяжёлых задач делает это нереалистичным. Правильный подход — использовать доступные компоненты для обеспечения контроля над данными и процессами.
- Миграция всех нагрузок разом. Резкий переход без поэтапного тестирования на пилотных проектах чреват сбоями в работе и превышением бюджета. Начинать нужно с некритичных или изолированных сценариев.
- Игнорирование edge-уровня. Фокусировка только на большом центральном кластере приводит к высоким задержкам и перегрузке сети для производственных задач, где важна скорость реакции.
- Отсутствие стратегии жизненного цикла моделей. Модели устаревают, требуют дообучения и замены. Без автоматизированного MLOps-процесса поддержка on-premise-контура станет ручной и дорогостоящей.
Как понять, что вы на верном пути
- Утверждён и задокументирован реестр данных и ИИ-сценариев с классификацией по критичности и требованиям 243-ФЗ.
- Разработана и согласована с финансовым директором модель TCO для ИИ-инфраструктуры на 3–5 лет.
- Завершён первый пилотный проект по развёртыванию edge-системы, показавший измеримый бизнес-эффект и технологическую состоятельность.
- Сформирована кросс-функциональная команда, обладающая компетенциями в области MLOps, DevOps, эксплуатации ИИ-оборудования и кибербезопасности.
- Архитектура ИИ-контура включает центральный уровень для обучения и edge-узлы для инференса, с чётко определёнными интерфейсами и протоколами обмена.
- Внедрена система мониторинга и безопасности, покрывающая как инфраструктуру, так и сами модели (детекция дрифта, аудит запросов).
Вопросы, которые нам задают
### Нужно ли нам самостоятельно обучать большую языковую модель?
Нет, для большинства промышленных задач это не требуется. Закон регулирует в первую очередь место обработки и хранения данных, а не происхождение архитектуры. Экономически рациональнее использовать готовую фундаментальную модель (российскую или зарубежную с открытой лицензией) и дообучать её на своих данных для решения конкретных задач.
### Когда именно наступит обязательность использования российских моделей?
С 1 марта 2027 года правительство сможет устанавливать обязательность применения суверенных или национальных моделей для отдельных сфер. Перечень таких сфер и технические критерии на текущий момент не опубликованы. Подготовительный период, который длится до этой даты, дан бизнесу для того, чтобы адаптировать архитектуру и избежать сбоев.
### Как работать с дефицитом GPU и санкционными рисками?
Необходимо стратегически планировать закупки, закладывая длительные сроки, и работать с несколькими поставщиками. Важно оптимизировать использование имеющихся ускорителей через квантование моделей и выбор эффективных архитектур. Для некритичных задач можно рассматривать более доступные решения или гибридные схемы с частичным использованием российских облачных платформ.