Что требует закон
С 01.03.2027 разработчики суверенных и национальных больших фундаментальных моделей обязаны вести техническую документацию, содержащую ключевые параметры и ограничения модели и достаточную для оценки её безопасности. Требование сформулировано через результат: документ должен позволять компетентному читателю — заказчику, аудитору, эксперту — понять, что представляет собой модель и где границы её безопасного применения.
Формы закон не навязывает: это может быть набор документов во внутренней базе знаний, если он полон и актуален. Важнее содержание и поддержание в актуальном состоянии.
Рабочий состав документации
Блок 1. Идентификация. Название и версия модели; разработчик; дата выпуска версии; связь с реестром ИИ-активов компании (если ведётся — идеальный скелет для документации).
Блок 2. Архитектура и параметры. Класс модели, структура, число параметров (для БФМ — от 1 млрд; именно это число фигурирует в тесте применимости закона), контекстное окно, модальности. Источник числа параметров — техническое описание, а не маркетинг.
Блок 3. Данные обучения. Составы данных: категории источников, объёмы, права на использование (собственные, лицензии, общедоступные без технических ограничений). С 01.03.2027 эта часть приобретает правовой вес: обучение суверенных и национальных моделей подпадает под исключение для интеллектуальной собственности при соблюдении условий (правомерное получение либо общедоступность).
Блок 4. Обучение и дообучение. Методика, этапы, метрики качества на валидационных наборах, история версий. Для национальных моделей — какие существенные характеристики определяет российское юридическое лицо и какие сторонние компоненты использованы по открытым лицензиям.
Блок 5. Ограничения и риски. Известные слабости, домены повышенного риска ошибок, недопустимые сценарии применения (перекликается с правилами эксплуатации — документация даёт обоснование, правила — пользовательскую форму).
Блок 6. Безопасность и тестирование. Проведённые тесты (включая тесты на недопустимые генерации), результаты, применённые фильтры и модерирующие контуры, организационные и технические меры безопасности.
Блок 7. Эксплуатация. Требования к среде, мониторинг, порядок обновлений и вывода из работы (краткая версия со ссылкой на правила эксплуатации).
Блок 8. Изменения. Журнал изменений документации: что изменилось, когда, почему. Аудиторов интересует не только состояние, но и история.
Связь с AI BOM
AI BOM (ведомость ИИ-активов) — учётный документ уровня компании: какие модели, где применяются, какие компоненты внутри. Техническая документация — углубление по каждой модели. Практичная архитектура: AI BOM как индекс (строка на модель со ссылкой), техдокументация как детальная карточка. Так выполняются и учётная функция (заказчики, аудит), и обязанность по закону, и внутреннее управление.
Связь со стандартами
ГОСТ Р ИСО/МЭК 42001-2024 требует документированной информации по всем процессам системы менеджмента ИИ — техдокументация модели встраивается туда как основной артефакт. ГОСТ Р 71539-2024 (по ИСО/МЭК 5338) описывает жизненный цикл систем ИИ и подсказывает, на каких этапах какие документы обновляются. Если коротко: завели AIMS — документация модели не отдельная бюрократия, а часть системы.
Кому документация нужна до 01.03.2027
Формально — только статусным разработчикам БФМ после этой даты. Фактически — всем, кто продаёт ИИ-компоненты корпоративным заказчикам:
- госзаказчики включают требования к документации в ТЗ (тренд усиливается запретом иностранного ПО и нацрежимом);
- страховые и договорные проверки просят подтвердить состав и ограничения ИИ-компонентов;
- в спорах о генерациях документация — главный аргумент распределения ответственности;
- при проверках перед сделками отсутствие документации на ИИ-активы снижает оценку.
Ошибки, которых стоит избежать
- Документация пишется «к проверке» один раз и устаревает. Решение — владелец документа и обязательное обновление при каждом релизе модели.
- Числа без источников. Каждый параметр — со ссылкой на техническое обоснование.
- Копирование маркетинговых формулировок. Документация — место точных формулировок и ограничений, а не преимуществ.
- Игнорирование прав на данные. Блок о данных обучения часто пустой — а именно он станет предметом проверки при спорах и при получении статуса.
Экономика вопроса: карточка модели занимает один-два дня работы инженера при наличии исходных материалов; восстановление утраченных знаний о датасете спустя год — недели. Документация окупается уже на втором релизе.
Минимальный план на месяц
Неделя 1: перечень моделей и существующих документов. Неделя 2: шаблон карточки модели (по блокам выше). Неделя 3-4: заполнение по приоритетным моделям, назначение владельцев, подключение к процессу релизов. К 01.03.2027 пакет будет готов — независимо от того, попадёт ли компания под формальный периметр закона.