Проект ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения, реализующего технологии искусственного интеллекта. Общие требования» разработан ФСТЭК России, Институтом системного программирования РАН и Сбером. Обсуждение продлится до 17 сентября 2026 года, то есть у индустрии ещё есть время повлиять на финальный текст.
Зачем ещё один стандарт, если уже есть ГОСТ Р 71539-2024
ГОСТ Р 71539-2024 описывает систему ИИ целиком (данные, инфраструктуру, процессы эксплуатации), а этот новый стандарт конкретно программное обеспечение внутри неё, и то, как его писать безопасно с точки зрения защиты информации.
Стандарт прямо позиционирует себя как надстройку над уже существующим ГОСТ Р 56939-2024 («Разработка безопасного программного обеспечения. Общие требования») — базовым стандартом по безопасной разработке ПО, который несколько лет применяется в отрасли для обычного софта. Новый документ не заменяет 56939, а дополняет его специфичными для ИИ требованиями там, где обычной разработки недостаточно.
При этом стандарт сознательно сужает область применения. Пункт 4.9:
Вопросы этичности, непредвзятости технологий ИИ и иные вопросы социогуманитарного толка не относятся к области применения настоящего стандарта.
Что вообще считается «ПО ИИ»
Прежде чем говорить о требованиях, стандарт вводит понятийную рамку, которой раньше в явном виде не было. «ПО ИИ» (программное обеспечение, реализующее технологии ИИ) — это связка из нескольких компонентов:
-
модель ИИ и её веса (параметры);
-
ПО, обеспечивающее взаимодействие модели с остальным ПО;
-
ПО среды исполнения — то, что запускает модель и выдаёт результаты;
-
ПО расширения функциональных возможностей — интеграции вроде RAG, вызов внешних инструментов;
-
опционально — ПО, обеспечивающее обучение модели (если пользователь сам может дообучать модель на этапе эксплуатации).
Отдельно вводится различие между тремя типами моделей внутри этой схемы: модели собственной разработки (права принадлежат разработчику), заимствованные модели (чужие, в том числе свободное ПО, но их можно включать в состав ПО ИИ, только если есть исходный код/веса или разработчик заимствованной модели сам выполнил требования этого стандарта), и привлекаемые модели — те, что использовались только в процессе разработки (например, для генерации синтетических данных) и не входят в конечный продукт.
Стандарт с самого начала закладывает логику цепочки поставок, где чья ответственность, что входит в периметр безопасности, а что нет.
Терминология, которая появляется впервые на уровне ГОСТа
Стандарт вводит термины, которых не было в предыдущей пятёрке, и часть из них будет активно использоваться дальше в отрасли:
«Механизмы ограничения поведения модели ИИ» получают официальное определение — программы, обеспечивающие контроль и ограничение обработки входных данных и результатов работы модели по заданным правилам.
Дрейф данных определяется отдельно от общего понятия качества данных, именно как изменение статистических характеристик входных данных модели относительно обучающей выборки.
Паспорт модели ИИ — документ со сведениями о структуре, производительности, качестве и безопасности модели, который стандарт требует создавать (подробнее ниже).
Плюс формализованы понятия сжатия модели, настройки (fine-tuning) отдельно от обучения, токенизатора, федеративного обучения и OOD-данных (Out-of-Distribution — данные, чьё распределение отличается от обучающего, что стандарт напрямую связывает с непредсказуемыми результатами модели).
27 процессов: типовые, модифицированные и специфические
Стандарт классифицирует все процессы разработки по степени «ИИ-специфичности»:
-
10 типовых — требования идентичны обычной безопасной разработке по 56939 (статический анализ кода, экспертиза исходного кода, безопасная система сборки и т.п., для ИИ-специфики тут ничего добавлять не пришлось);
-
15 модифицированных — старые процессы 56939, но с существенными ИИ-специфичными дополнениями (формирование требований, моделирование угроз, управление конфигурацией, тестирование и другие);
-
2 полностью специфических — процессов, которых в 56939 вообще не было: управление наборами данных и безопасное обучение моделей ИИ.
Управление наборами данных (процесс 5.26)
Цель звучит, как способ предотвратить компрометацию модели через манипуляцию данными.
Конкретные требования:
Кросс-аннотирование. Если разметка данных выполняется вручную, стандарт требует не просто разметки, а согласия большинства размечающих специалистов, с ведением отдельного журнала кросс-аннотирования (кто, когда, к какому выводу пришли по каждому набору).
Явно названные угрозы, специфичные именно для этого процесса: отравление модели и данных, модификация данных внедрением вредоносных примеров, включение конфиденциальных сведений в наборы данных и их утечка, несанкционированная модификация реестра наборов данных, кража обучающих данных.
Федеративное обучение отдельно регламентировано: если данные хранятся на распределённых узлах, они должны быть обезличены, а передаваемые градиенты защищены от восстановления исходных данных.
Локализация данных, но не абсолютная. Инфраструктура хранения и управления обучающими данными должна располагаться на территории России только если система ИИ, в которую эти данные пойдут, классифицирована по ГОСТ Р 59277-2020 как опасная по последствиям или по конфиденциальности информации. То есть требование условное, привязанное к классу критичности системы, а не блокирующее правило для любого ИИ-проекта.
Безопасное обучение моделей ИИ (процесс 5.27)
Здесь локализация уже безусловная: «Инфраструктура, в которой осуществляется обучение и (или) настройка модели ИИ, должна располагаться на территории Российской Федерации» для любого обучения и файнтюнинга, попадающего под этот стандарт.
Угрозы для этого процесса ещё конкретнее: отравление модели и данных (внедрение закладок, искажение поведения), отравление данных RAG, использование уязвимых форматов заимствованных моделей, несанкционированная модификация весов, и отдельным пунктом модельный коллапс — деградация модели при обучении на данных, сгенерированных другими моделями ИИ, что становится реальной проблемой по мере насыщения интернета синтетическим контентом.
И вот пункт, который стоит выделить особо — запрет на иностранных подрядчиков:
Привлечение к реализации процессов или отдельных функций процессов сторонних поставщиков, не являющихся российскими разработчиками, не допускается.
Это касается и предварительного обучения моделей (pre-train можно поручить только другому российскому разработчику как поставщику услуг), и вообще любых процессов из этого стандарта.
Моделирование угроз (процесс 5.7)
Стандарт требует при моделировании угроз учитывать не абстрактные соображения, а конкретный список источников:
Банк данных угроз ФСТЭК России в части ИИ-систем, OWASP Top-10 LLM, OWASP Top-10 Machine Learning Security, OWASP Agentic Threats Taxonomy, OWASP AI Exchange, OWASP MCP Top 10, OWASP AI Agents Top 15, MITRE ATT&CK, MITRE ATLAS, NIST Adversarial Machine Learning.
Это фактически официальное признание международных баз знаний по угрозам ИИ (включая MITRE ATLAS — специализированную матрицу атак именно на ML-системы) в качестве референсной базы для российской регуляторики. Несмотря на весь дискурс о суверенитете, содержательно стандарт опирается на ту же экосистему, что и весь остальной мир.
Требования к безопасности (процесс 5.3)
Требования к данным должны включать источники, происхождение, качество и запрет содержания данных, приводящих к смещению формируемых оценок.
Требования к самой модели должны определять запрещённые классы результатов и требования к отказу от выполнения недопустимых запросов.
А вот в требованиях к мониторингу на этапе эксплуатации явно фигурирует маркировка контента как одна из функциональных возможностей, которые разработчик обязан рассмотреть наряду с контролем входных/выходных данных, обнаружением OOD-данных и выявлением дрейфа. Это прямая техническая смычка с требованием законопроекта маркировать контент, созданный ИИ, стандарт превращает юридическую обязанность в конкретный пункт архитектуры системы мониторинга.
Тестирование (процессы 5.18, 5.19)
Нефункциональное тестирование обязано включать моделирование действий потенциального нарушителя. Конкретные проверки устойчивости модели к целенаправленным вредоносным воздействиям должны покрывать:
-
нарушение безопасности информации через функционирование модели;
-
искажение логики работы и получение несанкционированных результатов;
-
навязывание нежелательного поведения, включая генерацию запрещённого, небезопасного или некорректного содержимого;
-
устойчивость к состязательным атакам на входные данные.
Среди предлагаемых метрик безопасности — процент успешно отражённых атак типа prompt injection и количество успешных атак на утечку обучающих данных.
Паспорт модели и безопасная поставка (процесс 5.21)
Стандарт требует от разработчика создавать паспорт модели ИИ — документ с полным набором сведений: название, версия, лицензия, назначение и ограничения применения, сведения об архитектуре и обучающем наборе (в объёме, не раскрывающем конфиденциальные детали), типы входных/выходных данных, результаты оценки эффективности на тестовых наборах.
Отдельно требуется прописать в эксплуатационной документации порядок отката модели и её весов до безопасных версий, то есть план на случай, если после обновления или в результате атаки модель начинает вести себя неправильно, должен существовать заранее.
Цепочка поставок и композиционный анализ (процессы 5.16, 5.17)
Здесь российский стандарт вводит ППК, перечень программных компонентов, машиночитаемый документ с информацией об авторе, версии и идентификаторе каждого заимствованного компонента.
По цепочке поставок данных и моделей требуется: контроль подлинности источника, контроль целостности, поиск уязвимостей по открытым источникам, антивирусный контроль. Отдельно проверка форматов файлов заимствованной модели на отсутствие возможности выполнения произвольного кода при десериализации весов.
Тревожные звоночки и что стоит иметь в виду
Это только первая редакция проекта, обсуждение которой продлится до 17 сентября 2026 года. Формулировки могут заметно измениться по итогам публичного обсуждения, не стоит воспринимать разобранные здесь пункты как финальные.
Стандарт разрабатывает другой технический комитет. Пять ГОСТов из предыдущего разбора работа ТК 164 «Искусственный интеллект». Этот стандарт является продуктом ТК 362 «Защита информации», традиционного комитета по ИБ. Это значит, что за регулирование ИИ в России отвечают по факту два разных ведомственных трека, которые придётся сверять между собой (стандарт уже сверяет себя с 71539 через справочную таблицу приложения Б, но не с 71476 терминологически глубоко).
Требования к локализации разные по строгости — для обучающей инфраструктуры (процесс 5.27) это безусловное требование, для инфраструктуры хранения датасетов (процесс 5.26) условное, зависящее от класса критичности системы по 59277. Важно не спутать одно с другим при планировании инфраструктуры.
Этичность принципиально не покрывается — стандарт явно выводит ее за скобки. Если вы рассчитываете на этот ГОСТ как на комплексную защиту от дискриминационных решений модели, это не тот документ, для этого нужны 71484 и 42001 из предыдущего разбора.
Ещё больше про регулирование ИИ и новости индустрии в моём тг-канале Первые в ИИ.Ну почти 🙂
ссылка на оригинал статьи https://habr.com/ru/articles/1064870/