Приказ ФСТЭК № 117 и искусственный интеллект: что требуется и как выполнить

Сфера действия, сроки и последние изменения

Приказ утвердил Требования о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений. Он зарегистрирован Минюстом России 16 июня 2025 года (№ 82619) и, согласно пункту 4 приказа, вступил в силу с 1 марта 2026 года. Одновременно утратил силу приказ ФСТЭК России от 11 февраля 2013 года № 17 и приказы, вносившие в него изменения. Аттестаты соответствия, выданные до 1 марта 2026 года, по пункту 3 приказа считаются действительными.

По пункту 1 Требований они применяются к ГИС и иным информационным системам государственных органов, ГУП и госучреждений, функционирующим на территории России. Пункт 3 распространяет их на муниципальные информационные системы, если иное не установлено законодательством. Важен и пункт 2: если информация ограниченного доступа передаётся из ГИС в другую систему, то система-получатель должна соответствовать требованиям о защите информации, установленным по части 5 статьи 16 Федерального закона № 149-ФЗ. На практике это означает, что коммерческая организация, получающая такие данные из ГИС, попадает в контур требований через договор и требования обладателя информации.

Приказом ФСТЭК России от 8 мая 2026 года № 137 (зарегистрирован 10 августа 2026 года, № 87797) в Требования внесены изменения: они вступили в силу с 1 сентября 2026 года, кроме новой редакции пункта 32, которая начнёт действовать с 1 марта 2027 года. Изменения касаются показателей защищённости и зрелости, многофакторной аутентификации, работы с подрядчиками. Пункты 34 «т», 49, 60 и 61, посвящённые ИИ, этим приказом не изменялись.

Что именно сказано об ИИ: пункты 34 «т», 49 и 60

В перечне обязательных мероприятий пункта 34 появился подпункт «т» — «обеспечение защиты информации при использовании искусственного интеллекта». Пункт 49 разрешает в ходе мониторинга информационной безопасности для анализа событий и признаков реализации угроз использовать доверенные технологии ИИ. Основная нагрузка — в пунктах 60 и 61.

Первый абзац пункта 60 дословно: «Посредством проведения мероприятий по обеспечению защиты информации при использовании для функционирования информационных систем искусственного интеллекта должна быть обеспечена возможность исключения несанкционированного доступа к информации или воздействия на информационные системы, несанкционированного распространения и модификации информации, а также использования информационных систем не по их назначению за счет воздействия на наборы данных, применяемые модели искусственного интеллекта и их параметры, процессы и сервисы по обработке данных и поиску решений».

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

Термины в пункте 60 снабжены сносками на пункт 5 Национальной стратегии развития искусственного интеллекта (Указ Президента № 490 в редакции 2024 года): там определены искусственный интеллект, набор данных, модель ИИ, её параметры и доверенные технологии ИИ. Последние определены как технологии, отвечающие стандартам безопасности, разработанные с учётом принципов объективности, недискриминации и этичности и исключающие причинение вреда человеку, обществу и государству.

На практике первый абзац задаёт перечень объектов защиты: данные (обучающие и рабочие), модель и её веса, конвейеры обработки и поисковые сервисы, включая RAG. Второй абзац — прямой запрет, который бьёт по самому распространённому сценарию: отправке служебных документов в публичный чат-бот или в API внешнего провайдера, чьи условия допускают использование входных данных для дообучения.

Пункт 61: контроль запросов, ответов и недостоверности

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

Далее подпункт «в» требует, чтобы были «разработаны статистические критерии для выявления недостоверных ответов искусственного интеллекта для последующего сбора и анализа недостоверных ответов». Подпункт «г» — чтобы было обеспечено реагирование на недостоверные ответы «посредством ограничения области принимаемых решений и (или) реализации функций информационной системы на основе недостоверных ответов».

Завершают пункт два абзаца. Первый: при использовании ИИ или сервисов на его основе должно быть исключено нерегламентированное влияние ИИ на параметры модели и на функционирование информационных систем. Второй: «Непосредственно в состав информационных систем должны включаться доверенные технологии искусственного интеллекта или их компоненты».

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

Методический документ от 12 апреля 2026 года: раздел 3.18

Пункт 68 Требований обязывает реализовывать мероприятия и меры с использованием методических документов ФСТЭК России. Таким документом стал «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», утверждённый ФСТЭК России 12 апреля 2026 года. Он заменил методический документ 2014 года, а ИИ в нём посвящён раздел 3.18. По пункту 1.2 документ применяется к системам государственных органов, ГУП, госучреждений и организаций, в том числе субъектов КИИ.

Раздел 3.18 требует при создании системы ИИ провести оценку угроз, используя сведения об угрозах систем ИИ из банка данных угроз ФСТЭК России, и по её итогам разработать техническое задание с мерами защиты. В среде разработки защищаются инфраструктура, ПО для подготовки данных, обучения и тестирования (включая фреймворки и библиотеки), ПО API, агентов и фильтрации, входная модель, обучающие наборы данных, выходная модель и её веса. Инфраструктура разработки защищается по классу не ниже класса ИС оператора и выделяется в изолированный сегмент; в ней запрещено решать посторонние задачи; небезопасные форматы хранения вроде pickle заменяются безопасными (ONNX, protobuf). Для обучающих данных — приоритет доверенных источников, антивирусная проверка, обособленное хранилище и целостность. Для входной модели — анализ сведений о её уязвимостях.

В эксплуатации защищаются инфраструктура, ПО ИИ с агентами, API и фильтрами, а также обученная модель с расширениями вроде LoRA и RAG. Обязательны фильтрация входных и выходных данных, мониторинг и квотирование запросов, регистрация событий по запросам и ответам, целостность весов и конфигурации. Если ИИ предоставляется подрядчиком как внешний сервис, его инфраструктура должна быть защищена по классу не ниже класса ИС оператора.

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

Как интерпретировать спорные места

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

Что такое доверенные технологии ИИ. Определение дано в Национальной стратегии, но официального перечня или утверждённых критериев отнесения продукта к доверенным на момент подготовки материала найти не удалось. Практически разумно опираться на то, что можно доказать: сертификат ФСТЭК на ПО, безопасная разработка по ГОСТ Р 56939-2024, контролируемое происхождение модели и данных, возможность размещения в контуре оператора.

Шаблоны или тематики. Выбор режима делает оператор. Для массовых сервисов с понятными сценариями (справки, классификация обращений) проще строгие шаблоны. Для ассистентов сотрудников неизбежна свободная форма, и тогда перечень допустимых тематик и форматов ответа должен быть утверждён документально и реализован технически, а не только описан в регламенте.

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

Если меру выполнить нельзя. Пункт 69 позволяет применить компенсирующие меры, но их нужно обосновать на этапе создания системы и подтвердить эффективность при аттестации.

Практический план для оператора ГИС

Шаг 1. Инвентаризация. Составьте реестр всех случаев использования ИИ: встроенные функции прикладного ПО, ассистенты сотрудников, чат-боты для граждан, аналитика, ИИ в SOC. Отдельно выявите теневое использование публичных сервисов.

Шаг 2. Классификация потоков данных. Для каждого случая определите, какая информация попадает в запрос, в контекст RAG, в журналы и в обучающие наборы, и где физически работает модель. Всё, что уходит к разработчику модели, при наличии информации ограниченного доступа запрещено вторым абзацем пункта 60.

Шаг 3. Модель угроз. Дополните модель угроз ИС угрозами систем ИИ из банка данных угроз ФСТЭК: внедрение инструкций, отравление данных, извлечение данных из модели, подмена весов, злоупотребление API.

Шаг 4. Архитектурное решение. Выберите размещение модели в контуре оператора или у подрядчика с защитой по классу не ниже класса ИС; изолируйте систему ИИ в отдельном сегменте; закройте прямой доступ пользователей к внешним ИИ-сервисам.

Шаг 5. Реализация пункта 61. Утвердите шаблоны или допустимые тематики и форматы; внедрите входные и выходные фильтры; определите метрики недостоверности, журнал недостоверных ответов и правила ограничения решений.

Шаг 6. Целостность и журналирование. Контрольные суммы или криптографический контроль весов и конфигурации, регистрация запросов, ответов и срабатываний фильтров, квоты на запросы.

Шаг 7. Разработка и сертификация. Если система ИИ обрабатывает ПДн или информацию ограниченного доступа, заложите в план безопасную разработку и сертификацию ПО системы ИИ; это самый длинный по срокам элемент.

Шаг 8. Документы и обучение. Внесите ИИ во внутренние регламенты, техническое задание и программу аттестационных испытаний; включите правила работы с ИИ в мероприятия по повышению осведомлённости пользователей по пункту 56.

Что это значит для подрядчиков и поставщиков ИИ

Пункт 58 Требований обязывает оператора исключить несанкционированный доступ через средства и каналы подрядных организаций и установить подрядчику требования по защите информации. Подрядчикам запрещено копировать информацию, если это не предусмотрено документами оператора, а разработка и тестирование ПО непосредственно в эксплуатируемых системах не допускаются — только на изолированных стендах.

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

Наконец, по новой редакции пункта 32, которая вступит в силу 1 марта 2027 года, показатель уровня зрелости рассчитывается подрядной организацией до получения доступа к системам и информации заказчика и далее не реже одного раза в два года. Поставщикам ИИ-решений для госсектора стоит готовить комплект доказательств заранее: модель угроз, описание архитектуры изоляции, политику использования данных, отчёты о тестировании на промпт-атаки, документы по безопасной разработке.

Что взять на вооружение коммерческим компаниям

Для коммерческих организаций вне госсектора приказ № 117 обязателен только в случаях, когда они являются операторами ГИС, получают из ГИС информацию ограниченного доступа или работают подрядчиками. Однако пункты 60–61 и раздел 3.18 — первый в России официальный и детальный каталог мер защиты систем ИИ, и использовать его как ориентир разумно.

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

Финансовым организациям стоит одновременно учитывать методические рекомендации Банка России от 16 июня 2026 года № 3-МР по обеспечению информационной безопасности при разработке и применении ИИ на финансовом рынке. Они носят рекомендательный характер, охватывают модели угроз, меры защиты, политику ИБ и использование внешних сервисов, а также акцентируют валидацию человеком результатов, полученных ИИ в автоматическом режиме, в критичных процессах. Этические ориентиры задают добровольный Кодекс этики в сфере ИИ 2021 года и Кодекс этики Банка России для финансового рынка 2025 года.

Типичные ошибки

Считать, что ИИ — это только чат-бот. Под пункт 60 попадают встроенные функции офисных и прикладных систем, ИИ в средствах защиты, перевод, распознавание речи, RAG-поиск по документам.

Полагаться на отечественность провайдера. Запрет второго абзаца пункта 60 не зависит от страны разработчика модели: важно, получает ли разработчик информацию ограниченного доступа.

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

Забыть про журналы. Логи запросов и ответов сами содержат защищаемую информацию и должны защищаться как её хранилище.

Не считать недостоверность. Без статистических критериев и журнала недостоверных ответов подпункты «в» и «г» пункта 61 не выполнены, даже если модель в целом работает хорошо.

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

Допускать самообучение на диалогах. Автоматическое дообучение на пользовательских данных без регламента противоречит требованию исключить нерегламентированное влияние ИИ на параметры модели.

Не учитывать подрядчика. Если система ИИ работает в инфраструктуре подрядчика, требования к защите по классу ИС оператора распространяются и на неё.