- 1243-ФЗ сам по себе не запрещает российскому бизнесу использовать иностранные LLM. Для конкретного проекта нужно проверить и другие применимые требования.
- 2Полномочие Правительства определять случаи применения исключительно суверенных и национальных моделей начинает действовать 1 марта 2027 года.
- 3Подготовка к смене модели — это проверка архитектуры, договоров, маршрута данных и качества резервного решения. Это управленческая рекомендация, а не всеобщая обязанность мигрировать.
Правовые выводы приведены по состоянию на 2 октября 2026 года. Примеры описывают условные ситуации; рекомендации по организации работы отделены от обязательных требований.
Что меняется в марте 2027 года
По статье 13 основная часть 243-ФЗ действует с 1 сентября 2026 года. С 1 марта 2027 года вступает в силу, в частности, пункт 3 части 2 статьи 5: Правительство сможет устанавливать случаи, когда разрешены только суверенные и (или) национальные большие фундаментальные модели, а также исключения из этих случаев. Для банковской сферы и иных сфер финансового рынка требуется согласование с Банком России.
Это полномочие, а не готовый запрет на любую зарубежную нейросеть. Решение о замене модели в конкретном сервисе нужно принимать после проверки отдельного акта: какой сценарий он охватывает, когда применяется и какие исключения предусматривает. Основание — пункт 3 части 2 статьи 5.
На 2 октября 2026 года некорректно обещать клиенту, что с марта все иностранные API станут незаконными. Столь же некорректно обещать, что любая интеграция сможет работать без изменений. Для юридической оценки важны назначение системы, заказчик, отрасль и путь данных, а не только название модели.
Почему российский сервер не решает весь вопрос
Суверенная и национальная модели — специальные правовые категории. Части 2–5 статьи 6, вступающие в силу в марте 2027 года, связывают их с требованиями к разработчику, разработке, инфраструктуре и подтверждению соответствия. Для национальной модели допускаются иностранные компоненты на условиях открытой лицензии; порядок учета и присвоения статуса устанавливает Правительство.
Из этого следует практический вывод: установка зарубежных весов на российский сервер сама по себе не подтверждает нужный статус. Не подтверждает его и договор с российским посредником, если за его интерфейсом работает внешний сервис.
При выборе альтернативы попросите поставщика разделить три вопроса: где выполняются запросы, кто контролирует модель и чем подтверждается заявленный статус. Фраза «всё находится в России» отвечает лишь на часть этой проверки. Для закупки лучше получить документы и описание конкретной конфигурации, чем полагаться на презентацию.
Как работает переходный режим до 2032 года
Часть 3 статьи 13 предусматривает переходное правило до 1 сентября 2032 года. Установленные по пункту 3 части 2 статьи 5 случаи не распространяются на информационные системы, в которых применяются большие фундаментальные модели, созданные и (или) эксплуатируемые на дату вступления этого пункта в силу, при условии обработки и хранения данных в России.
Это не безусловное разрешение пользоваться любым иностранным облаком до 2032 года. Для компании важны доказательства того, что ее конфигурация отвечает условиям нормы: документы о создании или эксплуатации модели, описание системы и фактический маршрут обработки и хранения данных.
Например, российская база знаний еще не означает, что данные остаются внутри страны. Если приложение передает фрагменты документов внешнему API для подготовки ответа, нужно отдельно установить, где выполняется эта обработка. Проверьте также журналы запросов, резервные копии и подключенные инструменты агента.
При обновлении модели или существенном изменении системы пересмотрите оценку переходного режима. Не стоит автоматически переносить прежнее заключение на новую архитектуру. Условия переходного правила также не отменяют иных требований к данным и информационной безопасности.
С чего начать проверку своей зависимости
Начните с одного бизнес-процесса. Предположим, помощник службы поддержки находит ответ в базе знаний и готовит сообщение клиенту. Зафиксируйте, какая модель отвечает, кто предоставляет API, какие документы ей передаются и какие функции зависят от особенностей поставщика.
Такой паспорт должен быть понятен юристу и разработчику. В нем нужны версия модели, схема интеграции, категории данных, места обработки и хранения, ответственный за продукт и условия прекращения доступа. Если команда не может собрать эти сведения, обсуждать готовность к миграции пока рано.
Затем оцените последствия недоступности модели. Поддержка может временно перейти на ручные ответы; автоматическое выполнение операций потребует другого резервного сценария. От этого зависят допустимый срок переключения, объем тестирования и цена резервного решения.
Что предусмотреть в договоре с поставщиком
Выход из сервиса нужно обсуждать до того, как он станет срочным. Проверьте, какие материалы можно выгрузить: историю диалогов, документы, настройки поиска, системные инструкции и результаты тестов. Уточните формат выгрузки, срок предоставления и стоимость помощи при переходе.
Отдельно согласуйте уведомления о смене модели и изменении условий работы. Компания должна успеть оценить, как новая версия влияет на результат. Формулировка «поставщик вправе менять сервис в любое время» создает неудобство именно в момент, когда бизнес сильнее всего зависит от стабильности продукта.
В договоре полезно закрепить порядок возврата и удаления данных, помощь при прекращении доступа и доступность сведений о фактической инфраструктуре. Эти условия не гарантируют соблюдение будущего регулирования, но делают переход управляемым.
Как проверить резервную модель
Одинаковый интерфейс API не означает одинаковое качество. Альтернативная модель может иначе понимать инструкции, пропускать важные условия договора, неверно ссылаться на документы или вызывать инструменты агента в другом порядке.
Соберите небольшой набор реальных задач без лишних персональных и конфиденциальных данных. Для каждой задачи определите ожидаемый результат, допустимые ошибки и условия передачи ответа человеку. На этом наборе сравните основную и резервную модели.
Для помощника поддержки проверяйте не только гладкость текста, но и правильность цены, срока и основания для возврата. Для поиска по документам — наличие подтверждающего фрагмента. Для агента — ограничения на действия. Переход можно считать подготовленным, когда команда умеет воспроизводимо проверить результат и вернуть прежнюю конфигурацию при сбое.
Что сделать сейчас
Зафиксируйте используемые модели и договоры. Установите фактический маршрут данных. Выберите один критичный процесс и проверьте его на альтернативной модели. Назначьте сотрудника, который отслеживает применимые акты и передает изменения владельцу продукта.
Для руководителя результат такой работы — короткая карта решений: где можно продолжать работу, где нужна дополнительная правовая проверка и что потребуется для переключения. Сроки и бюджет перехода должны опираться на тест, а не на предположение, что достаточно заменить адрес API.
Главная задача сегодня — понять свою зависимость от поставщика и подготовить обоснованный выбор. Если для конкретного проекта появится ограничение, у компании уже будут сведения для правовой оценки и проверенный технический план.