Подпадает ли ваша LLM под 243-ФЗ: порог 1 млрд параметров

В 243-ФЗ большая фундаментальная модель определяется не одним параметром, а тремя признаками одновременно. Именно это чаще всего и упускают, когда читают закон по диагонали. Формулировка сводит признаки в связку — и связка, а не отдельно взятый порог, делает модель большой фундаментальной.

Если отвлечься от буквы, замысел законодателя читается легко. Регулируют не любую нейросеть побольше, а инфраструктурный слой — модели, на которых, как на фундаменте, вырастают десятки прикладных решений. Условный GPT-класс или базовый GigaChat — фундамент. Ваш корпоративный ассистент, собранный на этом фундаменте под конкретную задачу, — надстройка.

Разберём на грубом контрпримере. Возьмём модель компьютерного зрения на 1,5 млрд параметров, которая умеет только одно — находить рабочих без каски на видеопотоке. Порог она превышает. Но универсальности нет (задача ровно одна), и основой для другого ПО она не служит (на детекторе касок ничего не построишь). Два признака из трёх не выполнены — значит, это не БФМ, и обсуждать тут больше нечего.

Поэтому и нельзя цепляться за одну строчку с числом параметров в карточке на Hugging Face. Число там почти всегда есть, а универсальность и роль основы придётся оценивать руками: автоматом это не считается.

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

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

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

Про эмбеддеры стоит сказать отдельно. Модель, которая гоняет текст в векторы для поиска, не является БФМ ни по одному критерию, кроме, изредка, размера. Универсальности ноль, фундаментом она ни для чего не служит. А ведь именно на эмбеддерах держится половина корпоративных RAG-систем. Подробнее про их роль — в разборе RAG-архитектуры.

Целый пласт систем под БФМ не подходит в принципе: они не универсальны и ни для чего не служат фундаментом. Из-за них нервничают едва ли не больше всего, поэтому перечислю в лоб.

• Кредитный скоринг и антифрод. Узкоспециализированные модели: на входе признаки транзакции или заявки, на выходе оценка риска. Ни широкой применимости, ни роли фундамента. Мы разбирали такие сценарии в материале про ИИ в банках — ни один из них к БФМ отношения не имеет.
• Компьютерное зрение. Детекция СИЗ, контроль зон, распознавание нарушений ТБ. Система вроде ConstructionEye решает конкретный набор задач видеоаналитики и не является ни универсальной, ни базовой моделью. Подробности сценария — в статье про видеоаналитику на стройке.
• Предиктивное обслуживание. Модели, которые по данным SCADA и телеметрии предсказывают отказ узла, — это PredictMaintain-класс задач. Узкая цель, отраслевые данные, никакой универсальности. См. предиктивную аналитику в энергетике.
• Эмбеддинг-модели и векторизаторы. Как уже сказано — вспомогательный слой, не БФМ.
• Узкие классификаторы. Определение тональности, маршрутизация обращений, разметка документов по типу — всё это одна задача, а не большое количество задач.
• Корпоративный RAG на чужой базовой модели. Сама система-обёртка ничего не фундаментирует — она пользуется чужим фундаментом. К этому вернёмся отдельно.

Сразу за первым вопросом идёт второй, почти дословно: «Мы взяли Qwen, дообучили на своих договорах. Значит, создали новую модель и стали разработчиком?»

Тут надо развести две вещи: как это устроено технически и как это квалифицирует закон.

Технически дообучение (LoRA, QLoRA, полный fine-tuning) не создаёт новую фундаментальную модель. Оно адаптирует существующую: меняет поведение, стиль, доменный язык. Базовая архитектура, число параметров и происхождение весов остаются чужими. Про то, что fine-tuning меняет поведение, а не знания, мы подробно писали в отдельной статье про дообучение.

Юридически ответ аккуратнее, чем принято думать. В статье 3 разработчиком БФМ названы индивидуальный предприниматель или юридическое лицо, осуществляющие разработку — в том числе проектирование и обучение — или модификацию большой фундаментальной модели. Дообучение чужой универсальной модели по букве в понятие модификации укладывается. То есть формально в определение разработчика вы попасть можете, и утверждать обратное в переписке с юристами заказчика мы бы не стали.

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

Скажу прямо: право новое, судебной и надзорной практики нет, трактовки ещё уточнят подзаконка и первые разъяснения регуляторов. Но конструкция «мы не разработчики, потому что не обучали модель с нуля» опирается на признак, которого в определении нет, и на переговорах с грамотным юристом она рассыпается. Конструкция «мы попадаем в определение по модификации, но обязанности статьи 8 адресованы разработчикам моделей со статусом» держится.

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

Закон адресован модели, а не архитектуре вокруг неё. RAG-система — способ подключить LLM к вашим документам, а не самостоятельная фундаментальная модель. Если внутри работает чужая базовая LLM (тот же GigaChat или Qwen), предметом регулирования, если он вообще возникает, будет именно эта базовая модель — и то на стороне её разработчика.

Наш продукт AzoneDoc — как раз такой случай. Это RAG-обёртка: поиск по корпоративным документам, генерация ответов со ссылками на источник. Сама по себе она не БФМ и ничего не фундаментирует. Регулятивный статус, если он важен, определяется тем, какая базовая модель стоит под капотом, а не наличием у вас RAG-контура.

Для архитектора вывод простой: инвентаризировать надо не системы с ИИ, а конкретные модели внутри них — и по каждой ответить, кто её разработал и обучил.

Здесь путаницы больше всего, и здесь же лежит ответ на исходный вопрос.

243-ФЗ в части обязанностей обращён к тем, кто создаёт модели и доводит их до статуса. Компания, которая обучила большую модель и провела её через государственную процедуру признания суверенной или национальной, несёт обязанности по статье 8: безопасность, правила эксплуатации, техническая документация. Компания, которая скачала открытые веса и развернула модель в своём закрытом контуре, этих обязанностей не наследует: она не создавала фундаментальную модель и на статус не претендует.

Её зона ответственности лежит в привычной плоскости: защита данных, 152-ФЗ, требования по КИИ, безопасность самой LLM-системы от атак. Всё это действовало и до 243-ФЗ.

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

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

Маркировка: чего в законе нет

Отдельно про маркировку, потому что именно она чаще всего звучит в первом вопросе. Обязательной маркировки каждого сгенерированного текста закон не вводит. Статья 9 относится к информационным материалам в аудио- и визуальной форме и говорит о возможности разместить предупреждение о применении ИИ. Порог в 500 тысяч российских пользователей в сутки — это обязанность владельцев крупных площадок предоставить пользователям такую функцию, а не планка, после которой на компанию начинает распространяться закон.

Практический вывод для корпоративного ассистента: помечать его ответы значком «сгенерировано ИИ» закон вас не обязывает. Помечать их для собственной ИБ-службы и аудита — по-прежнему хорошая идея, но это внутренняя дисциплина, а не требование 243-ФЗ.

Не угадывайте — прогоните каждую ИИ-систему через два коротких блока. Первый определяет, БФМ ли это. Второй — что из этого следует лично для вас.

Блок 1. Это вообще большая фундаментальная модель?

Хотя бы одно «нет» — и дальше можно не идти.

Блок 2. Кто вы по отношению к этой модели

Отвечать имеет смысл, только если все три ответа выше — «да».

Отдельно от этой классификации проверьте систему на попадание в переходный период: находится ли она в промышленной эксплуатации на 1 марта 2027 года и хранятся ли данные в России. К вопросу «БФМ или нет» это отношения не имеет, но на планирование влияет — об этом ниже.

На практике у большинства корпоративных заказчиков проверка заканчивается на вопросах 2–3 или на вопросе 5. Их системы прикладные, а на статусы они не претендуют.

Календарь для планирования важнее классификации: именно он определяет, когда что-то придётся делать. На дату этой публикации не действует ещё ничего.

Из этого следуют две вещи, которые стоит проговорить отдельно.

Отсрочка по статье 13 узкая. Она защищает не от закона целиком, а от будущего требования применять исключительно суверенные или национальные модели — того самого, случаи введения которого Правительство ещё не определило. Условий два: система в промышленной эксплуатации на 1 марта 2027 года и обработка с хранением данных на территории России. Тогда до 1 сентября 2032 года это требование к ней не применяется. Оба условия проверяются техническими средствами, и невыполнение любого лишает отсрочки полностью: контур, где генерация уходит во внешний API, под неё не попадает независимо от даты запуска.

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

Редкий случай: вы обучаете большую универсальную модель и планируете получать для неё статус. Тогда работы больше, но она не экзотическая.

Впрочем, с этим к нам приходят редко. Гораздо чаще приходят с паникой «мы вне закона», а под ней не оказывается оснований: реальный статус почти всегда — пользователь прикладной системы.

Три шага на ближайший месяц. Никакой гонки — просто сделать аккуратно.

1. Инвентаризация. Составьте перечень всех ИИ-систем в контуре и, что важнее, конкретных моделей внутри них. Не «система документооборота с ИИ», а «RAG-обёртка + базовая модель Qwen 32B + эмбеддер bge». Предупреждаю по опыту: на этом шаге почти всегда всплывают теневые интеграции — сервисы, которые ходят во внешний API мимо согласованной архитектуры и о которых ИБ узнаёт последней. Именно они, а не размер модели, обычно и определяют, попадёт ли контур в переходный период.
2. Применить алгоритм. Прогоните каждую модель через два блока вопросов выше. Большая часть отсеется на признаках универсальности и основы.
3. Зафиксировать роль и закрыть статью 10. По каждой модели письменно определите, кто вы по отношению к ней и претендуете ли на статус. Заодно решите, как будете информировать пользователей о правах на результаты генерации: до марта 2027 года это делается одним абзацем в регламенте, после — уже в режиме «надо было вчера».

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