Методика ФСТЭК к приказу № 117: Обзор требований к безопасности ИИ

Привет, уважаемые эксперты!

На связи Альбина Аскерова, руководитель направления по взаимодействию с регуляторами Swordfish Security, и сегодня в моём обзоре будет методический документ ФСТЭК России от 12 апреля 2026, определяющий состав и содержание мероприятий и мер по защите информации в информационных системах.

Документ объемный, описывает всё, из чего, по мнению регулятора, должна состоять защита информации, но сегодня внимание будет уделено конкретному пункту – 3.18 «Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)».

Попробуем на него взглянуть глазами специалиста, ответственного за безопасное использование ИИ в организации. И рассмотрим практическую применимость, сильные стороны и скрытые риски.

Для каких организаций и систем Методика является обязательной

Методика выпущена ФСТЭК России в дополнение к приказу № 117 от 11.04.2025, который определяет требования о защите информации в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений.

Но, согласно приказу и самой методике, помимо гос.систем и иных систем гос.организаций, методическим документом нужно руководствоваться для защиты:

1. Значимых объектов критической информационной инфраструктуры.

2. ЦОДов, на базе которых функционируют системы, попадающие под действие приказа №117.

3. Информационных систем, взаимодействующих и получающих информацию ограниченного доступа из систем, попадающих под действие приказа №117.

4. Информационных систем персональных данных (в дополнение к требованиям постановления Правительства №1119).

5. Муниципальных систем (если иное не установлено законодательством).

6. Привлекаемых на сопровождение, развитие, обеспечение эксплуатации и прочих работ подрядных организаций.

Если вы смотрели проект этой методики в феврале, то могли обратить внимание, что в утвержденном документе требования к защите ИИ остались только в разделе мероприятий (процессов) – раздел III. И были исключены из раздела мер защиты (раздел IV). Для каждой меры защиты, указанной в разделе IV, определено, для информационных систем какого класса защищенности она подлежит применению. У процессов из раздела III нет такой детализации по целевому классу защищенности ИС, следовательно применять их нужно для любой системы, попадающей под область действия документа.

Теперь определим, какие виды систем попадают под действие этого пункта.

Согласно методике,

«Система искусственного интеллекта ‒ информационная система или совокупность информационных систем и технических средств, использующая одну или несколько технологий искусственного интеллекта»

Другими словами, ИИ-система не является новым типом объектов регулирования в требованиях ФСТЭК. Это обычная информационная система (по 149-ФЗ) или их совокупность. Единственное отличие – внутри такой ИС используются технологии ИИ.

Это означает, что, если в вашем сервисе/системе есть функция, реализованная с ИИ, например, объект КИИ в транспорте с системой распознавания номеров с помощью ИИ, то система подпадает под определение методики. Или, чат-бот госоргана на базе LLM для помощи сотрудникам – тоже подпадает. То есть, буквально все системы, в которых реализован (или заявлена реализация) сервис с применением ИИ.

Введение

Перед тем, как анализировать требования методики к безопасности ИИ, давайте посмотрим в исходные требования к ИИ в основном документе – Приказе № 117.

Этим приказом впервые регулятор в явном виде предъявляет требования безопасности к ИИ-системам. Конкретно они описаны в двух пунктах:

• П. 60 – исключить НСД к защищаемой информации или несанкционированного воздействия на ИС (наборы данных, модели и их параметры, процессы и сервисы по обработке данных) в случае использования ИИ. Исключить передачу разработчику модели защищаемой информации.

• П. 61 – контроль пользовательского взаимодействия с сервисами ИИ. Исключение влияния ИИ на функционирование ИС. Обязанность использовать только доверенные технологии ИИ или их компоненты.
  (Реестра доверенных на данный момент нет и официально утвержденных требований к ним тоже.)

Также есть пункт 34, он общего характера и в подпункте т) содержит указание на необходимость обеспечения защиты информации при использовании ИИ. Это требование снова возвращает нас к методике, пункт 3.18 которой как раз имеет такое название.

Таким образом, для всех объектов, которые попадают под приказ №117, обязательными для выполнения в контексте задачи по безопасности ИИ являются пункты 60 и 61 приказа и пункт 3.18 (раздела III) методики.

Детальный обзор требований Методики в области безопасности ИИ

Итак, пункт 3.18 «Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)» методического документа ФСТЭК России начинается с цели.

Звучит она так: «Исключение возможности несанкционированного доступа к информационным системам и информации при использовании систем искусственного интеллекта».

На первый взгляд выглядит очень узко, но далее по тексту раскрывается объем требований. Среди них, по классике: конфиденциальность, целостность, доступность и внешний и внутренний нарушители.

Документ разделяет два жизненных цикла ИИ-системы:

1. Разработка (обучение).

2. Эксплуатация.

Требования распространяются как на собственные разработки оператора, так и на случаи использования внешних сервисов ИИ (например, API сторонних провайдеров).

Требования Методики к объектам защиты в зависимости от среды:

1. Объекты защиты в среде разработки

(ИАФ – Идентификация и аутентификация, УПД – Управление доступом, РСБ – Регистрация событий безопасности, АВЗ – Антивирусная защита, МСЭ – Сегментация и межсетевое экранирование)

2. Объекты защиты в среде эксплуатации

Из таблицы среды эксплуатации объект «ПО, обеспечивающее реализацию технологий ИИ» (п. 2) повторяется и в среде разработки. Тестовые/предпроизводственные инстансы моделей, агентов, API и систем фильтрации требуют сопоставимых мер защиты.

То есть:

• В среде разработки могут быть тестовые/предпроизводственные инстансы моделей, агентов, API, систем фильтрации.

• На них также должны распространяться классические меры защиты (ИАФ, УПД, РСБ, АВЗ, МСЭ) – не в полном объеме производственного контура, но сопоставимом.

• Если вы тестируете модель на реальных данных (или близких к реальным), тестовый контур должен быть защищен не слабее, чем продуктивный.

Также в Методике отдельное внимание уделено безопасности данных как в ходе разработки системы ИИ, так и при ее эксплуатации

Если систематизировать требования, то может получиться
Сводная таблица требований к защите данных по средам

Дополнительные требования

Особое внимание в п.3.18 уделено случаям обработки ПДн в системе ИИ, обработке информации ограниченного доступа и случаю, когда система ИИ позволяет обеспечивать значимые функции оператора.

В таких случаях в дополнение ко всем вышеперечисленным мерам нужно реализовать еще две:

1. Обеспечить реализацию безопасной разработки системы ИИ (по ГОСТ Р 56939-2024).

2. Провести сертификацию ПО, обеспечивающего реализацию системы ИИ.

Если с первым требованием всё более-менее понятно (ГОСТ Р 56939-2024 уже много раз рассмотрен с точки зрения внедрения и содержания требований), то с сертификацией неоднозначности больше. Получается, фактически каждую вторую (или каждую первую?) ИС с ИИ в гос.организации, любой сервис ИИ, обрабатывающий ПДн (в текущих реалиях, наверное, это уже любой сайт с личным кабинетом и встроенным чат-ботом), в любом значимом объекте КИИ, использующем ИИ, нужно будет проходить через путь сертификации во ФСТЭК?  Сам вопрос и практика применения этого требования пока что остаются открытыми. На текущий момент (май 2026) утверждённой методики сертификации именно ПО с технологиями ИИ нет, поэтому до выхода отдельного НПА оператор может опираться только на классические сертификацию ПО по общим критериям и аттестацию системы как ИС. Также важно помнить, что сертификация – это последовательный процесс с внедрением практик РБПО: сначала практики из ГОСТ Р 56939-2024, затем сертификация.

На что еще стоит обратить внимание, точнее, про что стоит не забывать

Первично, по классике внедрения мер защиты информации, необходимо оценить угрозы (и поверхность атаки) и определить актуальные из них для каждого частного случая внедрения ИИ. В методике, конечно, отсылка к Банку данных угроз ФСТЭК России (БДУ). На данный момент в БДУ есть отдельная страница под угрозы безопасности систем ИИ. Угрозы и способы их реализации там также рассмотрены с точки зрения среды разработки и среды эксплуатации.

Что не охвачено в документе

Часто, говоря про безопасность ИИ, подразумевают еще такие важные качества как доверие и надежность. В методике и приказе ФСТЭК отсутствуют требования к объяснимости решений ИИ и борьбе с «галлюцинациями» (хотя, например, для госуслуг и КИИ это критично). Кроме того, даже на странице БДУ есть оговорка о том, что в данном разделе не рассматриваются угрозы безопасности информации, связанные с качеством моделей искусственного интеллекта.

Но это важный аспект, которому тоже стоит уделять внимание до появления отдельных нормативных актов по надежности и доверию ИИ.

Что здесь может быть в фокусе внимания:

1. Для объяснимости. Обеспечить возможность фиксации обоснования выданного результата для решений, принимаемых ИИ-системой в ГИС и на объектах КИИ.

2. Для робастности. Включить тестирование на устойчивость к состязательным примерам в состав контроля уровня защищенности информационной системы.

3. Для борьбы с галлюцинациями. Использовать RAG (Retrieval-Augmented Generation) с верифицированными источниками; внедрить несколько генераций с верификацией согласованности (self-consistency-проверки) и калибровку уверенности с порогом отказа (явное «не знаю» вместо галлюцинации).

4. Для безопасности RAG. Логировать все операции изменения векторов в RAG-хранилище; внедрить RBAC (Role-Based Access Control) на уровне извлекаемых документов (чтобы пользователь не получал в контекст чужие чувствительные документы); защищать векторное хранилище от атак восстановления текста (embedding inversion); проверять извлекаемые документы на косвенные инъекции (indirect prompt injection); обеспечить изоляцию данных между тенантами в общем векторном хранилище.

5. Для цепочки поставки. Вести реестр сторонних ML-библиотек, фреймворков и моделей с фиксацией хеш-сумм и данных об источнике получения, кем подписано, какая лицензия и условия использования датасета (provenance); внедрить MLBOM/SBOM; сканировать сами модели на закладки перед использованием.

6. Для приватности данных. Оценить применимость атак на извлечение обучающих данных (training data extraction, membership inference и model inversion) – особенно актуально при обучении на ПДн или информации ограниченного доступа.

7. Для безопасности вывода. Внедрить классификаторы вредоносного контента (токсичность, недопустимый контент и пр.), что особенно важно для систем, с которыми взаимодействуют внешние пользователи/граждане (госуслуги, чат-боты).

8. Для значимых функций оператора. Предусмотреть участие человека в процессе (human-in-the-loop).

9. Общие требования. Желательно все требования организации к доверию и надежности зафиксировать во внутреннем документе, который будет содержать критерии объяснимости, пороги дрейфа, процедуры тестирования и порядок отката версий в случае инцидентов.

Рекомендации. С чего начать выполнять требования к безопасности ИИ?

Для начала признать проблему. Скорее всего на данный момент в большинстве организаций системы ИИ разрабатываются в общей инфраструктуре, LLM-чат-боты подключены через API к ChatGPT или без контроля фильтрации, обучающие данные лежат в расшаренных папках без шифрования и контроля целостности и без очистки от чувствительных данных, никто не знает, откуда взяты предобученные веса. В таком случае первоочередная задача – системно снизить риски и обеспечить подготовку к плановой аттестации, если ваш объект попадает под такие требования.

Этап 1. Оценка текущего состояния

1.1. Инвентаризация ИИ-систем/сервисов

Создайте реестр по каждому ИИ-компоненту:

1.2. Оперативная оценка рисков по методике ФСТЭК (п. 3.18)

Оцените каждый выявленный ИИ-сервис/систему, как минимум, по чек-листу критичных мер:

• Обучающие данные не шифруются, нет контроля целостности – риск отравления.

• Датасеты скачаны из открытых источников, нет проверки – риск закладок.

• Предобученные веса без проверки – риск НДВ (backdoor) в модели.

• LLM в эксплуатации без фильтрации входа и выхода – риск инъекций и утечки персональных данных (или другой чувствительной информации).

• Нет логирования запросов к ИИ – невозможность провести расследование инцидентов.

• Нет квотирования – риск кражи модели.

• Векторные БД (RAG) без контроля целостности – риск подмены.

• Разработка ИИ ведется в общем сегменте – риск компрометации пайплайна.

Этап 2. Срочные меры

2.1. Изоляция среды разработки

• Выделите, как минимум, логический сегмент для разработчиков ИИ. Изоляция среды разработки является обязательным требованием по Методике.

• Запретите прямой доступ из сегмента разработки в пром.контур.

• Внедрите аутентификацию на среду разработки (MFA, если возможно).

2.2. Запрет использования pickle (запрет из Методики)

• Выявите все процессы, где используется формат pickle (модели, датасеты, промежуточные результаты).

• Замените на безопасные альтернативы под конкретную задачу (все форматы имеют свои особенности с точки зрения безопасности, и со временем становятся известными их уязвимости. Поэтому замена формата не отменяет того, что нужен контроль происхождения артефактов, сканирование моделей на закладки и фиксацию хеш-сумм всех загружаемых артефактов).

2.3. Простейшая фильтрация выхода для LLM

• На выходе из API LLM поставьте минимальный фильтр (ФИО, паспортные данные, номера телефонов и пр.) как первую линию защиты. Но так как она обходится тривиально, в среде эксплуатации дополняется мерами защиты от утечек и output-классификаторами.

• Ограничьте формат ответа.

• Запретите выполнение системных команд в ответе.

Это, конечно, не полная защита, но уже может закрыть большую часть очевидных возможностей для утечек персональных и чувствительных данных.

2.4. Квотирование запросов

Минимальное квотирование по IP или пользователю. Квотирование само по себе не защищает, поэтому имеет смысл также добавлять детектор аномальных паттернов запросов.

2.5. Логирование запросов и ответов

• Каждый запрос к ИИ (промпт) и ответ модели логировать. Логи хранить (минимум 1 год или исходя из класса защищенности ИС).

Этап 3. Системные меры

3.1. Выстроить управление уязвимостями ML-библиотек

• Включить используемые фреймворки в процесс сканирования уязвимостей (SCA).

• Настроить регулярные обновления.

3.2. Внедрить контроль целостности весов модели

• При загрузке модели в инференс – проверять контрольную сумму (хеш) весов.

• Внедрить подпись весов.

3.3. Внедрить управление доступами к ИИ

• API-шлюз с аутентификацией (JWT, API-ключи, OAuth).

• Как минимум – простая аутентификация для всех вызовов к ИИ.

3.4. Продолжать документирование происхождения (см п.1.1)

Для каждой модели в эксплуатации фиксировать:

• Откуда взяты предобученные веса.

• Какие обучающие данные использовались, откуда получены.

• Кто обучал, когда, какая версия инструментов.

Этап 4. Подготовка к аттестации системы

4.1. Уточнить Модель угроз, добавить угрозы ИИ

4.2. Полноценная фильтрация входов и выходов

4.3. Защита RAG-пайплайна (если используется)

4.4. Контроль дрейфа модели (особенно важно для КИИ и критических ГИС)

Для критических ГИС/КИИ (в зависимости от класса или категории системы) целесообразно это делать как можно чаще (например, каждый месяц). И важно обеспечить автоматическое оповещение при деградации модели, например, если отклонение более 5–10% от эталонной выборки.

4.5. Регламент реагирования на инциденты ИИ

Добавить в план реагирования:

• Отключение модели в случае признаков компрометации.

• Восстановление из резервной копии весов.

• Анализ логов запросов для поиска источника атаки.

Этап 5. Долгосрочная перспектива

• Безопасная разработка ИИ – внедрить РБПО по ГОСТ Р 56939-2024.

• Сертификация ПО ИИ – отслеживать появление методик ФСТЭК и включать в план.

• Red teaming – раз в год проводить внешнее тестирование ИИ-системы на промпт-инъекции и состязательные атаки.

Финальные акценты:

1. Помните, что это только специализированные дополнения для безопасности ИИ к общим мерам защиты информационных систем. Важно проанализировать всю методику ФСТЭК и строить защиту систем с учетом других релевантных вашему объекту мер защиты.

2. Не пытайтесь защитить всё и сразу. Наверное, самое критичное – изолировать среду разработки и внедрить фильтрацию выхода, это закроет большую часть рисков, которым и регулятор уделяет внимание.

3. Фиксируйте каждый шаг, принятое решение и договоренности с командами, отсутствие системности в этом процессе приведет к еще большему хаосу.

4. Мы рассмотрели методику российского регулятора, но для насмотренности желательно ознакомиться с тем, что есть из разработок по системному анализу доменов безопасности ИИ в России и за рубежом от сообществ и организаций. Например, фреймворк Swordfish SAIMM, NIST AI RMF (с дополнением NIST-AI-600-1 для генеративного ИИ), OWASP LLM Top 10, ISO/IEC 42001 (и ISO/IEC 23894 по управлению AI-рисками), DAGF, MITRE ATLAS.

И напоследок, как мы в Swordfish Security на данный момент видим цикл управления ИИ:

Каждый день приносит новые вызовы экспертами в сфере безопасности ИИ, ширина и глубина погружения в эту задачу только увеличиваются, известных угроз и уязвимостей становится все больше. Отрицать или противостоять этой стихии уже очевидно бессмысленно, остается только принять эту реальность и с холодной головой подходить к системной работе.

п.с. благодарю моего коллегу Михаила Черешнева, ведущего инженера по безопасности ИИ ГК Swordfish Security, за рецензию и помощь в подготовке рекомендаций!