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

Кого касается приказ и что изменилось за год

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

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

В мае 2026 года приказом ФСТЭК № 137 в Требования внесены изменения — о показателях защищённости и зрелости, многофакторной аутентификации и работе с подрядчиками. Они действуют с 1 сентября 2026 года, а новая редакция пункта 32 — с 1 марта 2027 года. Нормы об ИИ этими изменениями не затронуты.

Четыре нормы об ИИ на одной странице

Пункт 60: что защищать и чего делать нельзя

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

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

Если перевести на язык архитектуры, под защиту попадают обучающие и рабочие данные, сама модель и её веса, конвейеры обработки и поисковые сервисы — в том числе RAG по внутренним документам.

Второй абзац — прямой запрет:

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

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

Пункт 61: три технических контура

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

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

В технике это складывается в три контура:

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

Требование о нерегламентированном влиянии на практике означает запрет бесконтрольного самообучения модели на диалогах пользователей и автономных действий агентов без утверждённого регламента.

Методика ФСТЭК: как нормы превращаются в меры

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

Отправная точка — оценка угроз с использованием сведений об угрозах системам ИИ из банка данных угроз ФСТЭК и техническое задание с мерами защиты по её итогам. Дальше меры делятся по этапам жизненного цикла:

Спорные места: как их читать

Кто такой «разработчик модели»

Исключений для отечественных провайдеров норма не делает. Запрещена передача информации ограниченного доступа разработчику модели, а не использование модели как таковой. Модель, развёрнутая в контуре оператора или в защищённой инфраструктуре подрядчика, допустима, если данные не попадают к разработчику. Облачный API, где провайдер одновременно разработчик и получатель запросов, требует очень аккуратного обоснования, а публичные сервисы для таких данных фактически исключены.

Что считать доверенными технологиями ИИ

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

Шаблоны или тематики

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

Какие метрики недостоверности

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

Если меру выполнить нельзя

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

План работ для оператора ГИС: восемь шагов

1. Инвентаризация. Реестр всех применений ИИ: встроенные функции прикладного ПО, ассистенты сотрудников, чат-боты для граждан, аналитика, ИИ в SOC — и отдельно теневое использование публичных сервисов.
2. Потоки данных. Для каждого случая — что попадает в запрос, в контекст RAG, в журналы и обучающие наборы, где физически работает модель. Всё, что уходит разработчику модели вместе с информацией ограниченного доступа, запрещено.
3. Модель угроз. Дополнить угрозами систем ИИ из банка данных ФСТЭК: внедрение инструкций, отравление данных, извлечение данных из модели, подмена весов, злоупотребление API.
4. Архитектура. Модель — в контуре оператора или у подрядчика с защитой по классу не ниже класса ИС; система ИИ — в отдельном сегменте; прямой доступ пользователей к внешним ИИ-сервисам закрыт.
5. Пункт 61. Утвердить шаблоны или тематики и форматы, внедрить входные и выходные фильтры, определить метрики недостоверности, журнал и правила ограничения решений.
6. Целостность и журналы. Контрольные суммы или криптографический контроль весов и конфигурации, регистрация запросов, ответов и срабатываний фильтров, квоты на запросы.
7. Разработка и сертификация. Для систем с ПДн или информацией ограниченного доступа заложить безопасную разработку и сертификацию ПО системы ИИ — это самый долгий по срокам элемент.
8. Документы и люди. Включить ИИ в регламенты, техническое задание и программу аттестационных испытаний, а правила работы с ИИ — в повышение осведомлённости пользователей по пункту 56.

Подрядчикам и поставщикам ИИ

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

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

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

Коммерческим компаниям: ориентир, а не формальность

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

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

Восемь ошибок, которые встречаются чаще всего

• ИИ — это только чат-бот. Под пункт 60 попадают и встроенные функции офисных и прикладных систем, ИИ в средствах защиты, перевод, распознавание речи, RAG-поиск по документам.
• Провайдер отечественный — значит, можно. Запрет пункта 60 не зависит от страны разработчика: важно, получает ли он информацию ограниченного доступа.
• Достаточно регламента. Пункт 61 требует контроля соответствия — технической реализации с журналированием, а не только описания на бумаге.
• Журналы не защищены. Логи запросов и ответов сами содержат защищаемую информацию и требуют той же защиты, что и её хранилище.
• Недостоверность не считается. Без статистических критериев и журнала недостоверных ответов подпункты «в» и «г» не выполнены, даже если модель в целом работает хорошо.
• Сертификация в последний момент. Безопасная разработка и сертификация занимают месяцы — их нужно закладывать на стадии технического задания.
• Модель дообучается на диалогах. Автоматическое дообучение на пользовательских данных без регламента противоречит запрету нерегламентированного влияния на параметры модели.
• Подрядчик вне периметра. Если система ИИ работает в инфраструктуре подрядчика, требования к защите по классу ИС оператора распространяются и на неё.

Чем помогает ITOREX

Требования пункта 61 и раздела 3.18 закрываются не одним продуктом, а сочетанием классов решений: видимость и контроль использования ИИ (в том числе теневого), шлюзы и фильтры для запросов и ответов моделей (LLM Firewall), контроль ИИ-агентов, защищённая инфраструктура для размещения моделей в собственном контуре. Такие решения есть в портфеле ITOREX — вендоры ниже.

Применимость конкретного продукта к системе и наличие у него сертификата ФСТЭК нужно проверять под проект: команда ITOREX поможет подобрать архитектуру, провести пилот и подготовить комплект документов для заказчика.

InfEra Security

AI Security / DevSecOps

Российский разработчик решений кибербезопасности на основе AI и для защиты LLM-моделей.

• LLM Firewall
• SAST
• CTEM
• Реестр ПО

Aitalon

AI-инфраструктура и безопасность / Разработка и контейнеры

Aitalon объединяет контроль AI-агентов и LLM через AIGATE, аналитику AI-разработки DevScore и создание презентаций по данным через AIPitch.

• Контроль агентов и LLM
• Анализ разработки и качества кода
• AIGATE
• DevScore

STRAZH

Vulnerability & Risk Management

Обеспечьте прозрачность использования AI в компании. Платформа STRAZH дает 100% видимость AI-трафика, защищает корпоративные данные от утечек и позволяет безопасно внедрять LLM-приложения и кодинг-ассистенты. Shadow AI Audit & Control • LLM Firewall • AI Agent Security

• LLM Firewall
• Agentic Security
• AI Security
• AI Gateway