Первый в России ГОСТ для разработки ПО с ИИ: что нового в стандарте безопасности?
ФСТЭК России совместно с Институтом системного программирования РАН и Сбером открыли публичное обсуждение первого национального стандарта, регламентирующего безопасную разработку программного обеспечения с использованием технологий искусственного интеллекта. Проект документа, получивший название ГОСТ Р, затронет вопросы архитектуры ИИ-систем, управления данными, моделей и процессов обучения.
# Публичное обсуждение ГОСТ по безопасности ИИ-софта
Сейчас на портале проектов нормативных правовых актов активно обсуждается первый в России стандарт безопасности для программного обеспечения, реализующего технологии искусственного интеллекта (ПО ИИ). Разработчиками выступили Федеральная служба по техническому и экспортному контролю (ФСТЭК), Институт системного программирования РАН и компания Сбер.
Обсуждение проекта будет длиться до 17 сентября 2026 года. Это время позволит отрасли внести предложения и повлиять на финальную редакцию документа.
Важно: Данная статья описывает содержание проекта стандарта на момент публикации. Финальный текст ГОСТ может претерпеть изменения после публичных консультаций.
Отношение к существующим нормам и этике
Разработчики проекта четко определили его место в системе нормативной базы. Новый документ позиционируется как надстройка над базовым стандартом ГОСТ Р 56939-2024, который регулирует разработку безопасного обычного программного обеспечения. Новый ГОСТ не заменяет старый, а дополняет его специфичными требованиями именно для ИИ-технологий, где стандартных подходов недостаточно.
Однако область применения стандарта умышленно сужается. В нем прямо указано, что вопросы этичности, непредвзятости технологий и иные социогуманитарные аспекты не относятся к сфере регулирования. Этот проект касается технической безопасности и защиты информации, а не моральных вопросов дискриминации или bias-моделирования.
Что считается «ПО ИИ»
Документ впервые на уровне ГОСТа вводит строгие понятийные рамки. Под термином «ПО ИИ» понимается сложная связка нескольких компонентов:
1. Модель ИИ и её веса (параметры). 2. ПО, обеспечивающее взаимодействие модели с остальным программным обеспечением. 3. ПО среды исполнения — то, что запускает модель и выдает результаты. 4. ПО для расширения функционала (например, интеграции типа RAG или вызов внешних инструментов). 5. Опционально — ПО для дообучения модели, если пользователь сам настраивает модель на этапе эксплуатации.
Стандарт также классифицирует модели на три типа с учетом ответственности за безопасность: * Управление знаниями (например, большие языковые модели или векторные базы знаний). * Обработка данных (классические модели машинного обучения, обрабатывающие неструктурированные данные). * Специалисты-агенты (модели, способные вызывать инструменты, например, для поиска информации в интернете или анализа файлов).
Требования к данным и модели
Стандарт обязывает разработчиков учитывать качество и происхождение данных, на которых обучается модель, а также запретить использовать данные, которые могут привести к системным ошибкам или смещению оценок. Кроме того, модель должна уметь отказывать в выполнении недопустимых запросов.
Требования к эксплуатации и мониторингу
В разделе требований к эксплуатации (процесс 5.3) стандарта выделяются следующие обязательные функции:
* Маркировка контента: Разработчик обязан предусмотреть функционал для маркировки контента, созданного ИИ, что прямо перекликается с законодательными инициативами о маркировке AI-генераций. * Контроль входных и выходных данных: Непрерывный анализ входящих запросов и генерируемых ответов. * Обнаружение OOD-данных: Способность выявлять данные, выходящие за рамки распределения, на котором обучалась модель (Out-of-Distribution). * Выявление дрейфа: Мониторинг изменения характеристик модели со временем.
Тестирование на безопасность
Процессы тестирования (5.18, 5.19) включают не только функциональное, но и активное моделирование действий потенциального злоумышленника. Тесты должны проверять:
* Устойчивость к нарушению информационной безопасности через функционирование модели. * Сопротивление искажению логики работы и получению несанкционированных результатов. * Устойчивость к навязыванию нежелательного поведения (генерация запрещенного контента). * Устойчивость к состязательным атакам на входные данные.
В качестве метрик безопасности предлагаются: * Процент успешно отраженных атак типа prompt injection. * Количество успешных атак, направленных на утечку обучающих данных.
Паспорт модели и безопасная поставка
Разработчик должен создавать паспорт модели ИИ — документ, содержащий:
* Название модели и её версию. * Лицензионное соглашение. * Наименование и описание назначения модели. * Ограничения применения. * Сведения об архитектуре и обучающем наборе (без раскрытия конфиденциальных деталей). * Типы входных и выходных данных. * Результаты оценки эффективности на тестовых наборах.
Критически важным требованием является описание порядка отката модели и её весов до безопасных версий в эксплуатационной документации. Это должен быть заранее подготовленный план действий на случай, если после обновления или в результате атаки модель начнет вести себя некорректно.
Цепочка поставок и композиционный анализ
Секции 5.16 и 5.17 стандарта вводят понятие ППК (Паспорт программного комплекса) — машиночитаемый документ со списком всех программных компонентов. В нем указываются автор, версия и идентификатор каждого заимствованного элемента. По цепочке поставок данных и моделей требуется:
* Контроль подлинности источника. * Контроль целостности. * Поиск уязвимостей по открытым источникам (CVE и др.). * Антивирусный контроль. * Проверка форматов файлов заимствованной модели на отсутствие возможности выполнения произвольного кода при десериализации весов (сервер-сайд рендеринг атак).
Локализация и инфраструктура
Стандарт устанавливает разные требования к локализации в зависимости от типа инфраструктуры:
* Обучающая инфраструктура: Безусловное требование к локализации в России (процесс 5.27). * Инфраструктура хранения датасетов: Условное требование, зависящее от класса критичности системы по ГОСТ Р 59277 (процесс 5.26).
Внимание: Не стоит путать требования к обучению с требованиями к хранению данных. При планировании инфраструктуры важно учитывать эту разницу.
Два ведомственных трека
Этот стандарт разрабатывается Техническим комитетом 362 «Защита информации» (ФСТЭК), а не ТК 164 «Искусственный интеллект». Это означает, что регулирование ИИ в России идет по двум параллельным линиям:
1. ТК 164: Сфокусирован на возможностях ИИ, этических аспектах и перспективах развития технологий (стандарты вроде ГОСТ Р 71476, ГОСТ Р 71484). 2. ТК 362: Сфокусирован на защите информации, кибербезопасности и технических аспектах безопасности ИИ-систем (новый ГОСТ, ГОСТ Р 59277, ГОСТ Р 56939).
Хотя новый документ сверяет себя с 59277 через справочную таблицу, терминологическое совпадение с другими стандартами ТК 164 пока не достигнуто. Разработчикам придется ориентироваться на оба стандарта.
Этот документ является лишь первым шагом в масштабной реформе регулирования ИИ в России. Полная картина сформирована только после учета всех комментариев к проекту и принятия финального ГОСТа.
Читайте больше о регулировании ИИ и новости индустрии в нашем Telegram-канале «Поток AI и ML».
#иисоздание #законодательство #ИИ #безопасность #ФСТЭК