ФСТЭК прижал ИИ: разбор методики к приказу №117 — что делать госорганам и КИИ

ИИ под прицелом регулятора: почему старые методики не работают

До 2025 года безопасность ИИ в госсекторе была как честное слово — вроде есть, а проверить нельзя. Но в марте 2026-го ФСТЭК выпустил методику к приказу №117, и всё изменилось. Теперь нейросети в государственных информационных системах (ГИС) и на объектах критической информационной инфраструктуры (КИИ) обязаны проходить аттестацию по новым правилам. И это не просто очередная бюрократическая нагрузка — за нарушения штрафуют по-настоящему.

Методика описывает, как именно оценивать безопасность систем ИИ: от проверки обучающих данных до мониторинга аномалий в продакшене. Главный нерв — пункт 3.18, который требует документировать каждый шаг жизненного цикла модели и доказывать, что ИИ не выполняет несанкционированных действий. Звучит как «очевидная вещь», но на практике это ломает привычные pipeline’ы даже у крупных разработчиков.

Если вы думали, что Указ 490 и приказ №117 — это бумажки, которые не трогают код, — вы ошибались. Недавний случай, описанный в статье «ИИ-комплаенс в РФ: ФСТЭК 117 и Указ 490 глазами разработчика, который уже попал на штраф», показывает: штрафы реальны, и они бьют не только по кошельку, но и по репутации.

Пункт 3.18 — тот самый «чёрный ящик»

Формально пункт 3.18 методики требует от оператора ГИС или КИИ «обеспечить контроль целостности и достоверности данных, используемых для обучения и функционирования систем искусственного интеллекта, а также фиксацию всех изменений модели и её окружения». Но если прочитать между строк, регулятор хочет одного: чтобы вы могли в любой момент ответить на вопрос «почему модель приняла именно такое решение».

На практике это означает, что привычный pip install pandas без фиксации версий может обернуться штрафом. Многие DevOps-инженеры уже почувствовали это на себе: при обновлении библиотеки изменилась логика предобработки текста, и модель начала выдавать другие результаты. Задокументировать это — ваша обязанность.

Практический план: как подготовиться к проверке за 90 дней

Я собрал опыт коллег из нескольких госконтрактов и собственных проектов. Методика ФСТЭК — это не про «купить сертифицированный софт». Это про процессы.

1Инвентаризация моделей и данных

Составьте реестр всех ИИ-компонентов: от библиотек до обученных весов. Для каждой модели укажите:

• назначение (где используется, какие решения принимает);
• источник обучающих данных (с указанием даты получения и версии);
• версии всех зависимостей (вплоть до cuda и драйверов);
• метрики качества (accuracy, precision, recall и их пороговые значения).

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

2Фиксация жизненного цикла модели

Внедрите систему трекинга экспериментов (MLflow, DVC или даже просто git + метаданные). Каждое изменение модели должно быть связано с коммитом в репозиторий и содержать:

• описание причины изменения (например, «улучшение точности на 2% за счёт аугментации данных»);
• результаты тестирования на репрезентативной выборке;
• подпись ответственного лица (электронная подпись или хотя бы лог аудита).

3Контроль целостности данных

Пункт 3.18 требует не только фиксации, но и защиты от подмены. Это значит:

• хеширование исходных датасетов и моделей (SHA-256 как минимум);
• регулярная проверка контрольных сумм на наличие изменений;
• разграничение доступа: кто может изменять данные обучения, а кто — только читать.

Звучит как база, но на объектах КИИ часто оказывается, что доступ к датасету есть у всей команды разработчиков. А это уже дыра в безопасности, которую ФСТЭК найдёт.

4Мониторинг аномалий в продакшене

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

• каждое обращение к модели с меткой времени и ID пользователя/системы;
• выходные значения модели (или хотя бы их статистики — среднее, дисперсия);
• алерты при отклонении от baseline (например, если вероятность класса изменилась больше чем на 10%).

Недавний кейс, описанный в статье «ODCV-Bench: как AI-агенты нарушают правила ради KPI», наглядно показывает: если не контролировать выходы ИИ, он может «срезать углы» и сломать бизнес-процесс ради метрик.

Скрытые риски: о чём молчат консультанты

Первое, о чём забывают — методика распространяется и на кастомные модели, и на запрограммированные правила (rule-based системы), если они функционируют как ИИ. То есть ваш старый парсер на регулярках тоже может подпасть под регулирование, если он «принимает решения» в составе ГИС. Формально его нужно аттестовать как систему ИИ.

Второе: требования к защите данных обучения перекликаются с 187-ФЗ и 152-ФЗ. Если в датасете есть персональные данные, вы обязаны обеспечить их анонимизацию и согласие субъектов. А ФСТЭК может запросить подтверждение, что анонимизация выполнена корректно.

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

Типичные ошибки внедрения

• Документы для галочки. Составили реестр моделей, но не обновляете его — при проверке будет хуже, чем его отсутствие, потому что зафиксируют недостоверные данные.
• Игнорирование человеческого фактора. Методика требует обучения персонала. Штрафуют не только компанию, но и ответственных лиц. Прочитайте историю из «ИИ-агенты взломали корпоративные сети» — там как раз ошибка сотрудника привела к инциденту.
• Отсутствие резервного копирования. Если модель изменилась из-за фонового обновления библиотеки, а бекапа нет — придётся доказывать, что это не злонамеренное действие. Хорошо бы иметь не только копии, но и процедуру отката.

Прогноз: что будет через год

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

Параллельно растёт рынок инструментов для автоматизации комплаенса. Появятся open-source решения для трекинга и аудита, совместимые с требованиями ФСТЭК. Но не ждите чуда — ответственность за соблюдение методики всё равно лежит на операторе.

И последнее: не пытайтесь «спрятать» ИИ-модуль под видом обычного софта. ФСТЭК уже научился выявлять нейросети по косвенным признакам — время выполнения, использование GPU, специфичные библиотеки. Рано или поздно модель найдут. Лучше сразу интегрировать защиту и документирование в pipeline, как советуют в материале «Как избежать катастрофы с ИИ-агентом».

Если вы до сих пор сомневаетесь, нужно ли внедрять требования — посмотрите на опыт компании из кейса СИБУРа («Как нейросеть на производстве предсказывает прогорание труб»). Там ИИ уже спас миллионы, и комплаенс стал естественным этапом развития. Регулирование — не бремя, а гарантия, что ваш ИИ не сделает глупость ценой человеческих жизней.

Подписаться на канал