Обязанности разработчиков — единственный по-настоящему обязывающий блок 243-ФЗ. Он адресован узкому кругу: разработчикам суверенных и национальных больших фундаментальных моделей, то есть российским юридическим лицам, чьи модели преодолели порог 1 млрд параметров и претендуют на статус. Эта страница — полный разбор трёх обязанностей, их практического смысла и подготовки к дедлайну 1 марта 2027 года.
Если ваша модель ниже порога или вы работаете с чужой базовой моделью — прямых обязанностей у вас нет, но понимание блока полезно: он задаёт стандарт документации, который рынок начнёт требовать от всех ИИ-вендоров через договоры и закупки. Прикладной разбор требований к фундаментальным моделям опубликован отдельно — требования к фундаментальным моделям.
Обязанность 1. Меры безопасности модели
Закон требует от разработчика статусной модели принимать организационные и технические меры безопасности. Формулировка отсылочная: конкретный состав мер будет определяться подзаконными актами и практикой, но инженерный смысл понятен уже сейчас. Организационные меры — процессы: управление доступом к обучающим данным и весам, регламенты тестирования перед релизом, порядок реагирования на инциденты, роли и ответственность. Технические меры — контур: защита инфраструктуры обучения и инференса, контроль утечек, фильтрация опасных генераций, логирование использования.
Практический ориентир для подготовки — действующие методики безопасности приложений ИИ, прежде всего OWASP LLM Top-10: промпт-инъекции, утечки данных через ответы модели, избыточные полномочия агентов. Наш обзор OWASP LLM Top-10 показывает, как эти классы угроз переводятся в конкретные проверки. Разработчикам больших моделей стоит закрывать их до марта 2027 года — не ради формального соответствия, а потому что именно через эти векторы происходят реальные инциденты.
Обязанность 2. Правила эксплуатации, обновления и вывода из работы
Вторая обязанность — описать правила эксплуатации модели, её обновления и вывода из работы, включая ограничения и условия применения. Это документ, который отвечает на вопросы пользователя модели: для каких задач модель предназначена и для каких не предназначена; какие данные обрабатываются при эксплуатации; как выходят обновления и что меняется в поведении; как модель прекращает работу и что происходит с зависимыми сервисами.
Юридический смысл обязанности — распределение ответственности: если пользователь применил модель вопреки описанным ограничениям, риск смещается к нему. Инженерный смысл — дисциплина жизненного цикла: модель перестаёт быть «вечной бета-версией» и получает управляемый цикл версий. С чего начать и какие разделы включить — в гайде технической документации модели.
Обязанность 3. Техническая документация
Третья обязанность — вести техническую документацию с ключевыми параметрами и ограничениями модели, достаточную для оценки её безопасности. Минимальный состав, который следует из практики: архитектура и число параметров; состав и происхождение обучающих данных (правомерность получения — критична в свете режима произведений); методики оценки качества и безопасности; известные ограничения и запретные сценарии; результаты тестирований. Документация должна обновляться при существенных изменениях модели.
Важно понимать: это не «сертификация 243-ФЗ» — такого механизма закон не создаёт. Это внутренний документ разработчика, который может быть запрошен при взаимодействии с государством, заказчиками и партнёрами. Как строить такой пакет документов — в материале внутренних документов по ИИ для 243-ФЗ.
Кто именно обязан — и кто нет
Адресат обязанностей — разработчик суверенной и национальной большой фундаментальной модели. Статус может получить только российское юридическое лицо; порядок учёта и присвоения статусов устанавливает Правительство. Из этого следуют три практических вывода. Первый: разработчик модели без статуса формально не несёт обязанностей по этому блоку — но статусная механика заработает с 01.03.2027, и планировать стоит на неё. Второй: дообучение чужой большой модели не делает вас её разработчиком — обязанности остаются на разработчике базовой модели, что стоит проверить в договоре. Третий: пользовательский контур (сервисы на готовых моделях) обязанностей не получает вовсе. Расширенный разбор периметра — на странице «Кого касается 243-ФЗ».
Модель угроз разработчика большой модели
Формулировка «организационные и технические меры безопасности» оживает, когда её проецируешь на реальную модель угроз большой модели. Инфраструктура обучения: кража весов и датасетов, отравление обучающих данных, компрометация пайплайнов сборки. Инфраструктура инференса: промпт-инъекции и джейлбрейки, вытягивание данных из ответов модели, злоупотребление полномочиями инструментальных агентов. Контур данных: утечки пользовательских запросов, несанкционированное дообучение на клиентских данных, нарушения режима персональных данных. Каждый вектор — кандидат в пункт плана мер безопасности; классы атак и контрмеры разобраны в обзорах OWASP LLM Top-10, джейлбрейка LLM и защиты от промпт-инъекций.
Практика показывает, что зрелые команды описывают меры тремя документами: политика безопасности модели (что защищаем и на каком уровне), процедура выпуска (какие проверки проходит модель перед релизом), план реагирования (что делаем при инциденте и кто решает). Такой пакет закрывает и букву будущих подзаконных актов, и дух нормы — «достаточность для оценки безопасности».
Документооборот разработчика
Техническая документация работает только как процесс. Полезный каркас: паспорт модели (архитектура, параметры, версии, датасеты с происхождением), журнал оценок (методики, метрики, результаты по версиям), ограничения (запрещённые сценарии, границы применимости), правила эксплуатации (режимы, обновления, вывод из работы), изменения (что поменялось между версиями и почему). Обновление паспорта — условие релиза: нет обновлённой документации — нет релиза. Тогда к марту 2027 года пакет собирается сам, без реверс-инжиниринга. Так же устроен наш внутренний контур для ИИ-сервисов экосистемы ВЫШКА Cloud — и ровно это мы проверяем при аудите ИИ-активов у заказчиков.
Что закон даёт разработчикам взамен
243-ФЗ — закон о поддержке, и блок обязанностей уравновешен мерами поддержки: финансовые, имущественные и гарантийные механизмы, доступ к данным государственных информационных систем, а также право разработчика статусной модели застраховать свою ответственность. Для команд, строящих большие модели в России, это означает, что комплаенс — не только издержка, но и условие доступа к мерам поддержки. Как устроен баланс требований и стимулов — в обзоре ключевых норм 243-ФЗ.
Мини-кейс: как выглядит готовность
Условная команда разрабатывает открытую языковую модель с 3 млрд параметров и сервис генерации на её основе. Осень 2026 года: инвентаризация фиксирует одну базовую модель, три датасета (собственный, лицензионный, публичный) и сервис генерации; происхождение каждого датасета документировано — правомерность получения данных станет критичной в свете TDM-режима. Декабрь 2026 года: паспорт модели и журнал оценок ведутся с релизами; правила эксплуатации описаны черновиком; модель угроз собрана по OWASP LLM Top-10, критичные векторы закрыты. Февраль 2027 года: документация собрана в пакет, сервис уведомляет пользователей о правах на генерации, план реагирования на инциденты связан с журналом модели. Первое марта встречается рабочей системой, а не презентацией о планах. Этот маршрут повторяем — он и лежит в основе наших услуг по защите ИИ-разработок.
План подготовки к 01.03.2027
Шаг 1 — определите периметр: есть ли у вас модели от 1 млрд параметров и планируете ли вы статус. Шаг 2 — инвентаризируйте модели, датасеты и права на данные (происхождение обучающих данных — главный риск в свете режима opt-out). Шаг 3 — соберите базовый пакет: правила эксплуатации, техописание, модель угроз и меры безопасности. Шаг 4 — проведите техническую проверку контура по OWASP LLM Top-10 и закройте критичные разрывы. Шаг 5 — назначьте ответственного за мониторинг подзаконных актов: порядок присвоения статусов и состав мер безопасности будут уточняться после марта 2027-го. Как это делается в формате аудита — в гайде аудита ИИ-активов по 243-ФЗ и на странице чек-листа готовности.
НЬЮ-ССТ помогает разработчикам ИИ готовить этот пакет: от модели угроз и правил эксплуатации до технической проверки и регламентов. Мы сами разрабатываем ИИ-сервисы в экосистеме ВЫШКА Cloud и понимаем требования изнутри — см. программу защиты ИИ-разработок.