«Должны ли наши данные жить в России после нового закона?» — вопрос, который осенью 2026 года звучит на каждой ИТ-стратегической сессии. Ответ двухслойный: в самом 243-ФЗ российский контур упоминается в конкретных конструкциях — статус суверенной модели и переходный период, — а всеобщей обязанности «все данные ИИ только в РФ» закон не содержит. Этот разбор — о том, где требование контура написано, где оно становится практикой и как проверить свою инфраструктуру.
Страница примыкает к разборам статусов моделей и переходного периода; здесь — инфраструктурная сторона вопроса.
Место первое: критерий суверенной модели
Статус «суверенной» большой модели требует полного цикла своими силами: и разработка, и обучение, и модификация идут на инфраструктуре внутри страны, а правообладатель — российское юрлицо. Это самое жёсткое требование локализации в законе: оно касается не только данных, но и вычислительной инфраструктуры, на которой модель живёт.
Для разработчиков, нацеленных на статус, практическое следствие — планирование мощностей: обучение и инференс большой модели на российских GPU-кластерах или собственных серверах, с учётом того, что перенести обучение потом будет дороже, чем сразу выбрать правильную площадку. Обзоры доступной инфраструктуры — в материалах GPU-кластеров для LLM и выбора открытых моделей для on-premise.
Место второе: условие переходного периода
До 1 сентября 2032 года предусмотрено специальное исключение из случаев обязательного применения только суверенных/национальных моделей: для указанных в части 3 статьи 13 информационных систем с БФМ, созданными и/или эксплуатируемыми на 1 марта 2027 года, при обработке и хранении данных в России. Это не отсрочка всех обязанностей закона.
Полный календарь нормы — в хронологии этапов, от подписания до финала переходного периода. Обратите внимание на связку: чем ближе 2032 год, тем больше инвестиций в системы вне российского контура оказываются под риском исчезновения защиты.
Контур и стоимость владения
Решение о локализации — это ещё и экономика. Российский контур меняет структуру затрат: выше капитальные расходы при покупке мощностей, предсказуемее операционные при облаке, и почти всегда дороже старт по сравнению с готовым зарубежным API. Зато локальный контур даёт независимость от курсов и санкционных сценариев, предсказуемую латентность для российских пользователей и совместимость со статусными требованиями. Практика наших проектов: честный расчёт на три года (включая миграцию, сопровождение и риски) чаще всего показывает паритет или выгоду локального варианта — но только при правильно подобранной модели и нагрузке, отсюда важность пилота до принятия решения.
Чего в законе нет
Для ясности зафиксируем: 243-ФЗ не обязывает корпоративный чат-бот, RAG-поиск или скоринговую модель хранить данные в России только потому, что это ИИ. Общие требования к локализации, если они есть, приходят из других оснований — персональные данные при трансграничной передаче (152-ФЗ), отраслевые нормы, требования конкретных заказчиков. Полная карта смежных законов — в разборе пересечений 152/187/243.
При этом рынок делает локализацию де-факто стандартом: заказчики спрашивают про контур в тендерах, страховые — в анкетах, а статусные модели возможны только в российском контуре. Поэтому стратегическое решение «где живут данные» стоит принимать с запасом.
Типовые сценарии контура
| Архитектура | Статус по 243-ФЗ | Практический смысл |
|---|---|---|
| Своя БФМ, обучение и инференс в РФ | Совместимо со статусом суверенной модели | Максимальные меры поддержки и закупочные преимущества |
| Модель на открытых весах, дообучение в РФ | Кандидат на национальный статус | Компромисс: открытые компоненты + российский правообладатель |
| Сервис на зарубежном API | Статус недостижим | Данные покидают контур — вопрос 152-ФЗ и договорных гарантий |
| Гибрид: локальный инференс + зарубежные сервисы | Зависит от доли и роли компонентов | Требует честной карты потоков данных |
Решение о миграции существующих систем на российские модели — отдельная инженерная задача, а не лозунг: стоимость владения, качество и совместимость нужно считать, а считать — на горизонте жизни системы, а не одного квартала. Наш подход к такой миграции и сопутствующим услугам — на странице миграции ИИ на российские модели.
Чек-лист проверки контура
Практический обход для компании занимает один-два дня и закрывает вопрос до следующего изменения парка систем:
- Карта систем — перечислите все ИИ-компоненты: модели, API, встроенный ИИ в SaaS. Реестр ИИ-активов — рабочий инструмент, как его вести — в соответствующем гайде.
- Потоки данных — для каждой системы: где физически инференс, где хранение, что уходит наружу. Отдельно — логирование промптов вендором.
- Юридические основания — для персональных данных вне РФ: есть ли правовое основание передачи; для коммерческой тайны — договорные запреты.
- Критические зависимости — какие системы перестают работать при недоступности зарубежного API; план миграции для критичных.
- Фиксация — таблица контура в реестре с датой проверки и ответственным.
Инструменты проверки: что спросить у инфраструктуры
Кроме юридической карты, контур проверяется технически. Три инструмента, которые обычно применяют вместе:
Инвентаризация эндпоинтов модели. Каждый вызов ИИ-функции логируется с геопризнаком обработчика: свой сервер, российское облако, зарубежный API. Для зарубежных вызовов фиксируется, какие данные уходят и на каком основании. Результат — карта потоков, из которой сразу видно «утечки» контура.
Проверка договоров с SaaS. Встроенный ИИ в иностранных сервисах — самый частый незаметный выход данных за рубеж: CRM с автосуммаризацией писем, конструктор презентаций с генерацией, переводчик документов. По каждому сервису — раздел о месте обработки в договоре или DPA.
Тест миграции на критичных функциях. Для двух-трёх самых критичных ИИ-функций проводится пилот на российском аналоге: качество, стоимость, трудозатраты. Даже без миграции тест даёт план «Б» и оценку цены вопроса — а цена вопроса, известная заранее, сама по себе снижает риск импульсивных решений на тендерных дедлайнах и даёт аргументы для разговора с собственником бизнеса о сроках и бюджете.
Мини-кейс: карта контура за два дня
Условный логистический оператор перед тендером крупного заказчика получает анкету: «Где обрабатываются данные ИИ-систем?». За два дня команда собирает карту: восемь ИИ-функций, из них шесть — в собственном контуре (прогноз нагрузки, сортировка заявок, OCR накладных — на серверах в РФ), одна — внешний перевод документов (зарубежный API, файлы с реквизитами контрагентов), одна — генерация ответов клиентам (российское облако). Уязвимость — одна функция на зарубежном API; на неё оформляется трансграничная передача по 152-ФЗ, параллельно стартует пилот российского перевода. В тендер уходит карта с одним помеченным риском и планом его закрытия — вместо пустого ответа или паники «у нас ИИ, что делать».
Связь с закупками
Для госзаказчиков и компаний с госучастием российский контур перестаёт быть опцией: статусы моделей и национальный режим закупок тянут решения в сторону российских разработчиков. Как описывать такие требования в закупочной документации — в материалах о госзаказчике (разбор для заказчиков) и о суверенных решениях в закупках.
Итог
Российский контур в 243-ФЗ — не лозунг, а два конкретных юридических механизма: критерий суверенности модели и условие защиты переходного периода. Вне этих механизмов локализация — стратегическое решение, которое стоит принимать с учётом статусов, закупок и 152-ФЗ. Проверка контура — конечная задача с чётким чек-листом. Разбор — информационный; решение о контуре инфраструктуры принимайте с юридическим заключением по вашим данным. НЬЮ-ССТ размещает ИИ-контуры клиентов в российском облаке экосистемы ВЫШКА Cloud и помогает спланировать миграцию без остановки сервиса. Начать можно с бесплатного разбора — форма ниже.