Приказ ФСТЭК 117 и ИИ в контуре: раздел 3.18 методички на практике

12 апреля 2026 года ФСТЭК утвердила методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах». Это обвязка к приказу 117, который с 1 марта 2026 года заменил приказ 17 и перевёл защиту государственных систем на процессный подход. В документе больше ста сорока страниц, и один его раздел, 3.18, целиком посвящён защите информации при использовании искусственного интеллекта.

Я считаю это событие важнее, чем оно выглядит. До апреля 2026 года российский регулятор говорил об ИИ в терминах: доверенный, кибериммунный, конструктивно безопасный. Теперь он говорит мерами: изолируйте среду обучения, проверяйте целостность весов, пишите в журнал все запросы и ответы. С мерами можно работать: их можно внедрить, проверить, показать проверяющему и посчитать в деньгах.

Эта заметка для собственника или технического директора, у которого ИИ уже стоит в контуре: чат-бот на сайте, поиск по внутренним документам через RAG, предиктивная модель на производстве, агент в службе поддержки. Разбираю не «что написано», а «что из этого делать», и в какой последовательности, если бюджет ограничен.

Кого это касается, если вы не госорган

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

Во-первых, сам документ применяется шире, чем приказ: к значимым объектам КИИ, к системам персональных данных, к подрядчикам на сопровождении. Требования к значимым объектам по приказу 239 движутся в ту же сторону, я писал об этом в заметке 187-ФЗ девять лет спустя. Проект замены приказа 21 по персональным данным, по обзорам, добавляет защиту при использовании ИИ отдельным пунктом. То есть субъект КИИ и оператор персональных данных получат те же требования с небольшим запозданием.

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

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

Восемь требований, переведённых на человеческий

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

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

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

3. Чужие модели проверяются до использования. Предобученные модели из внешних источников проходят анализ уязвимостей, включая закладки. Формат сериализации pickle, через который в модель можно положить исполняемый код, под запретом.

4. Готовая модель защищена от подмены. Контроль целостности параметров обученной модели, с усилением криптографическими средствами. То же для дообучений вроде LoRA и для расширений RAG. В эксплуатации к этому добавляется мониторинг.

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

6. Журнал пишет всё. В разработке логируется доступ к среде, коду и данным. В эксплуатации логируются все запросы и ответы модели. Хранение не меньше года. Выход модели проверяется на утечку персональных данных.

7. На входе и выходе стоят фильтры. Тестирование на промпт-инъекции, ограничение формата ответа, запрет на выполнение системных команд из ответа, минимальный фильтр на фамилии, паспортные данные и телефоны в выдаче. Детектор аномальных запросов и квоты на эксплуатацию.

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

Как это стыкуется с тем, что я советовал раньше

Для меня в этом списке почти нет нового, и это хорошая новость: регулятор пришёл туда же, куда приходит инженерная практика.

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

• Локальный ИИ закрывает пункт 60, но не закрывает раздел 3.18. Модель внутри периметра решает вопрос передачи данных наружу, я подробно разбирал лестницу вариантов от облака до on-prem. Но изоляция среды обучения, целостность весов и журнал запросов нужны локальной модели ровно так же. Локальность не освобождает, она переносит ответственность на вас.

• Журнал запросов и ответов это та же наблюдаемость агентов. В заметке про наблюдаемость роя агентов я писал, что записывать нужно пару «намерение и действие», включая попытки. Требование логировать все запросы и ответы с хранением год это та же мысль, записанная регулятором.

• Проверка выхода на персональные данные закрывает слепую зону 152-ФЗ. Летом я писал про ИИ-контур как слепую зону комплаенса по персональным данным, за которую платит собственник. Теперь фильтр на выходе и проверка на утечку прописаны как мера.

Перевод в архитектуру: план на квартал

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

Первое: реестр ИИ-систем. Одна таблица: что за модель, где работает, какие данные видит, куда уходит выход, внешняя или своя. Включая чат-боты и подписки, о которых ИТ-отдел узнаёт из бухгалтерии. Это неделя работы, и она определяет масштаб всего остального.

Второе: внешние сервисы и пункт 60. По реестру отделить, что уходит наружу. Для каждого внешнего сервиса ответить: договор с запретом обучения на наших данных, где хранится, что именно передаём. Защищаемое либо не передаём, либо переносим в контур.

Третье: разделение сред. Обучение и эксперименты в отдельном сегменте с отдельными учётками, прода оттуда не видно. Для компании, у которой одна модель и один дата-сайентист, это один сервер и одно правило на межсетевом экране.

Четвёртое: данные и модель под хэшом. Хранилище для обучающих данных с версиями и контрольными суммами, подпись модели при выкладке и проверка при загрузке. Инструменты для этого есть открытые, стоимость в основном дисциплина.

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

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

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

Где документ молчит, и что с этим делать

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

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

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

Честные оговорки

• Формально документ для государственных систем. Для КИИ это направление, для персональных данных проект. Если вы ни то, ни другое, это чеклист, а не обязанность. Я советую относиться к нему как к чеклисту всем, у кого ИИ видит защищаемые данные.

• Я разбираю один раздел большого документа по обзорам и первоисточнику. Номера пунктов, редакции приказа и формулировки перед решением нужно сверять на сайте ФСТЭК: приказ 117 уже получил изменения в мае 2026 года, и готовится следующая редакция, где, по обзорам, появится понятие интеллектуального агента и многофакторная аутентификация для доступа к моделям.

• Аттестацию и сертификацию делает лицензиат. Я помогаю выстроить контур так, чтобы он проходил проверку, и перевожу требования в архитектуру. Само заключение выдаёт организация с лицензией ФСТЭК, и это отдельный бюджет.

• Меры из списка не делают модель полезной. Они делают её контролируемой. Полезность это отдельный вопрос, и его я проверяю раньше безопасности, иначе защищать будет нечего.

Если коротко

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

Если у вас ИИ уже работает с клиентскими или производственными данными, и вы хотите понять, как ваш контур выглядит на фоне этих восьми пунктов, я делаю такую диагностику за 7–10 дней. Для контуров с персональными данными есть отдельный аудит на соответствие 152-ФЗ. Первый разговор ни к чему вас не обязывает.