Большинство ИИ-продуктов 2026 года — не собственные большие модели, а сервисы поверх чужих: обёртки над API, RAG-приложения, ассистенты с дообучением открытых весов. Для таких команд главный вопрос про 243-ФЗ звучит так: «мы теперь разработчики большой модели или нет?». Короткий ответ — нет: обязанности разработчика БФМ лежат на том, кто разработал базовую модель. Но вокруг этого ответа есть практическая работа: проверить вендора, правильно оформить договор и не забросить собственную зону рисков. Разберём по порядку.
Базовая проверка роли — тест применимости «подпадает ли ваша система»; полный перечень ролей — в разборе адресатов; наш фокус — сценарий «чужая модель в моём продукте».
Где проходит граница «разработчик БФМ»
243-ФЗ привязывает требования к разработчику большой фундаментальной модели — универсальной, с числом параметров от миллиарда. Начиная с марта 2027 года такой разработчик должен принять меры по безопасности модели, описать регламент её работы, обновлений и вывода из эксплуатации, вести техническую документацию. Интегратор, который вызывает готовую модель по API, не становится разработчиком этой модели — как компания, использующая чужую базу данных, не становится её вендором.
Полезная аналогия из соседней отрасли: аттестация ГИС ложится на оператора системы, а не на разработчика СУБД внутри неё. Закон об ИИ разводит уровни так же: базовая модель — разработчику, прикладная система — обычным правилам (152-ФЗ, договорная ответственность, отраслевые требования).
Три типовых сценария
| Сценарий | Ваша роль по 243-ФЗ | Зона внимания |
|---|---|---|
| SaaS поверх API чужой БФМ | Не разработчик БФМ; обязанностей закона нет | Договор с вендором, данные, 152-ФЗ, доступность сервиса |
| Продукт на открытых весах с файнтюном | Не разработчик базовой модели; вопрос о статусе итоговой модели — зона оценки | Происхождение весов и датасета, лицензия, близость к порогу |
| Собственная модель сверх миллиарда параметров | Разработчик БФМ — требования с марта 2027-го | Полный пакет: безопасность, регламенты, документация |
Отдельно про дообучение. Закон не содержит специальной нормы о том, превращает ли файнтюн открытой модели в «разработку» — это правда и главный источник неопределённости для ML-команд. Практический подход: фиксируйте параметры итоговой модели и объём изменений базовых весов; если сумма близка к порогу 1 млрд — принимайте решение с юристом по тексту закона, а не по меморандумам вендоров. Методика проверки порога — в обзоре требований к БФМ.
Четыре вопроса вендору модели
Даже без собственных обязанностей выбор базовой модели определяет риски продукта. Перед закупкой или интеграцией запросите:
- Параметры и статус — превышает ли модель миллиардный порог; есть ли у неё суверенный либо национальный статус; кто правообладатель. Для госзаказчиков и их подрядчиков статус становится закупочным фактором — материал для закупочной стороны.
- Соответствие закона вендором — как разработчик закрывает мартовские-2027 требования: где опубликованы правила эксплуатации, как устроена техдокументация. Нежелание отвечать — сам по себе сигнал.
- Данные — где физически обрабатываются ваши запросы и файлы и где они хранятся; логируются ли промпты; есть ли обучение на ваших данных. Это стык с 152-ФЗ и коммерческой тайной.
- Непрерывность — что будет с продуктом при выводе модели из эксплуатации; условия деградации сервиса и миграции. Практика «вендор пропал» разобрана в вопросе о банкротстве вендора.
Договорные оговорки интегратора
Ответы вендора имеют силу, только если они в договоре. Рабочий минимум для контракта с поставщиком модели или ИИ-подрядчиком:
- гарантия соответствия модели требованиям 243-ФЗ, применимым к разработчику, и обязанность передавать обновления документации;
- распределение ответственности за выходы модели (галлюцинации, запрещённый контент) и порядок реагирования на инциденты;
- локализация обработки данных и запрет несанкционированного обучения на ваших данных;
- условия вывода модели из эксплуатации: срок уведомления, формат выгрузки, помощь в миграции.
Как строить такие формулировки со стороны заказчика — на странице обязанностей и интересов заказчиков и в гайде по выбору ИИ-вендора.
Вопросы из практики интеграторов
«А если вендор скажет, что его модель меньше миллиарда параметров?» Тогда формально он вне обязанностей разработчика БФМ — и это нормальная рыночная ситуация: большинство прикладных моделей именно такие. Вопрос-маркер для договора остаётся тем же: фиксируйте заявление вендора о размере модели письменно, чтобы при споре или изменении линейки у вас была точка отсчёта.
«Мы дообучаем модель клиента — мы подрядчик или разработчик?» Вы подрядчик: права на модель и обязанности держит клиент, если иное не написано в договоре. Ваша зона — качество работ и передача документации; забота о статусе и соответствии — на стороне правообладателя.
«Нужно ли нам что-то делать с маркировкой генераций?» Как оператору сервиса — нет: метка остаётся правом автора-пользователя. Практично лишь не блокировать такую возможность технически и следить за форматом, когда он появится.
Ваша собственная зона рисков
Отсутствие обязанностей по 243-ФЗ не означает отсутствия рисков. Остаётся: 152-ФЗ для персональных данных, которые сервис пропускает через модель (включая оценку вреда), договорная ответственность перед клиентами, отраслевые требования — например, для медицины или финансов. Если продукт обслуживает значимый объект КИИ, добавляется 187-ФЗ; карта пересечений — в разборе трёх законов.
Отдельная строка — маркировка генераций. Если ваш сервис генерирует аудио или видео, авторы-пользователи вправе их пометить; интегратору достаточно не мешать технической возможности такой пометки и следить за развитием формата. Подробнее — в разборе маркировки.
Практический план интегратора
- Зафиксируйте в реестре ИИ-активов все используемые модели: чьи, какая версия, где обрабатываются данные.
- Прогоните четыре вопроса вендора по каждому API и обновите договоры на очередном продлении.
- Проверьте свои данные на персональные и при необходимости проведите оценку вреда.
- Заложите в архитектуру заменяемость модели — роутинг между провайдерами снижает риск вывода чужой модели из строя.
- Повторяйте проверку раз в квартал: закон разворачивается, а вендоры меняют условия.
Мини-кейс: смена модели без остановки сервиса
Условный сервис автоматизации техподдержки работает на открытой модели средних размеров и API одного крупного вендора. На квартальной проверке команда фиксирует: вендор поднял цены и изменил политику логирования, открытая модель перестала справляться со сложными тиками. План миграции собирают за две недели: реестр активов уже ведётся, карточки обеих моделей заполнены, договор с новым поставщиком прошёл четыре вопроса вендора. Переключение идёт через роутинг: две недели два провайдера работают параллельно на 10% трафика, метрики качества сравниваются автоматически, затем доля переключается.
Сервис не остановился ни на день, а юридическая часть уложилась в три документа: допсоглашение со старым вендором о выгрузке данных, договор с новым с оговорками о локализации и обучении, обновление реестра активов. Именно так выглядит зрелая позиция интегратора: не «мы не обязаны по 243-ФЗ», а «мы управляем своими зависимостями».
Итог
Интегратор на чужой БФМ — не адресат обязанностей 243-ФЗ, и это устойчивая позиция закона, а не лазейка. Но зрелый ИИ-продукт отличается не отсутствием комплаенса, а правильно распределённым: вендор отвечает за модель, вы — за данные, договор и сервис. Типовые вилки стоимости сопровождения таких контуров — от аудита (90 000 ₽) до полного построения с интеграциями (690 000 ₽ и выше; контур уровня MVP с несколькими системами — примерно миллион, от 0,9 до 1,2 млн ₽; сентябрь 2026, не оферта). Обзор носит прикладной характер и не подменяет юридическое заключение по вашему договору. НЬЮ-ССТ строит сервисы на российских и открытых моделях и помогает интеграторам оформлять ИИ-контур — программа защиты ИИ-разработок. Обсудить вашу связку с вендором — в форме после статьи.