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