ИИ-комплаенс в РФ: ФСТЭК 117 и Указ 490 глазами разработчика, который уже попал на штраф

«Мы просто дообучили модель на своих данных». И получили предписание на 2.3 млн рублей

История знакомая? Команда запускает чат-бота с ИИ для банка. Модель работает, клиенты довольны. А через полгода приходит проверка ФСТЭК с толстой папкой нарушений по приказу №117. Оказывается, ваша «просто дообученная модель» – это теперь объект критической информационной инфраструктуры (КИИ). И требования к ней – как к ядерному реактору.

Что на самом деле хотят регуляторы? Не канцелярский перевод, а суть

Забудьте про скучные формулировки. Регуляторы боятся трех вещей:

• Непредсказуемость. Модель сегодня дает один ответ, завтра – другой, потому что дообучилась на данных пользователя. В финансовой или медицинской сфере это катастрофа.
• Уязвимость supply chain. Вы используете открытые веса Llama 3.2? А кто гарантирует, что в них нет backdoor'а? Регулятор требует прослеживаемости всей цепочки.
• Потеря контроля над данными. Модель обучается на персональных данных клиентов и «запоминает» их. Потом эти данные можно извлечь промптами. Это уже не просто утечка, это утечка с интеллектом.

Поэтому появился Указ №490. Его главная идея – «доверенные технологии ИИ». Это не маркировка «одобрено Роскомнадзором». Это система сертификации, где нужно доказать, что ваша AI-система: 1) безопасна, 2) этична, 3) управляема, 4) дает воспроизводимые результаты.

ФСТЭК 117: не абстрактные «требования», а конкретный чек-лист для аудитора

Если Указ №490 – это философия, то Приказ ФСТЭК №117 – это техническое задание для вашего DevOps и SecOps. Документ на 47 страницах, который делит все ИИ-системы на три класса защищенности. К какому классу попадете вы? Зависит от двух факторов:

Ваш чат-бот для банка? Скорее всего, 2 класс. Потому что он влияет на финансовые решения. И вот тут начинается самое интересное.

Пошаговый план: как привести свой ИИ-проект в соответствие за 90 дней

Не ждите аудита. Начинайте сейчас. Вот что нужно сделать в первую очередь.

1 Классифицируйте свою систему. Честно.

Соберите архитекторов, юристов и product owner. Задайте один вопрос: «Что будет, если наша модель сгенерирует абсолютно неправильный ответ в худший возможный момент?». Если ответ – «клиент подаст в суд на 10 млн рублей» или «остановится конвейер на заводе», у вас минимум 2 класс. Не пытайтесь приуменьшить. Аудитор ФСТЭК сделает ровно наоборот – раздует риски до максимума.

2 Задокументируйте ВСЁ. Даже то, что кажется очевидным.

Требование №117 – полная прослеживаемость (traceability). Для каждого запуска модели (inference) нужно хранить:

• Версию модели и ее весов (хеш-сумму).
• Входные данные (промпт, контекст).
• Выходные данные (ответ).
• Конфигурацию запуска (параметры температуры, top_p).
• Идентификатор пользователя и сессии.

Это не просто логи в ELK. Это должна быть система, которая гарантирует целостность и неизменяемость этих записей. Блокчейн? Возможно. Как минимум – WORM-хранилище (Write Once Read Many).

3 Постройте «стек безопасности ИИ». Это не просто фаервол.

Вам нужны инструменты для трех задач:

1. Защита от adversarial attacks. Пользователь может специально crafted-промптом заставить модель раскрыть тренировочные данные или дать опасный ответ. Нужны детекторы и фильтры на входе. Посмотрите в сторону инструментов вроде DeepMind Frontier Safety Framework – некоторые подходы можно адаптировать.
2. Мониторинг дрейфа (drift detection). Модель сегодня и модель через месяц – это две разные модели, если есть online learning. Нужно отслеживать смещение распределения входных данных и изменение метрик качества.
3. «Красная кнопка» (kill switch). Механизм мгновенного отключения модели или перевода ее в безопасный режим. Не через Kubernetes rollout. Через аппаратный контур или максимально изолированный программный вызов.

4 Проведите внутренний аудит. По методике ФСТЭК.

Скачайте «Методику оценки защищенности ИИ-систем» (приложение к приказу №117). Это готовый чек-лист на 120 пунктов. Пройдитесь по нему с командой. Особое внимание разделам:

• Безопасность данных для обучения. Откуда данные? Есть ли согласия? Как очищались от PII? Доказательства?
• Управление моделью в production. Кто и как может обновить веса? Сколько человек нужно для согласования? Есть ли разделение ролей?
• Инцидент-менеджмент. Что делать, если модель сломалась? А если начала генерировать вредоносный контент? Процедура должна быть прописана, а команда – проинструктирована.

Где споткнутся 8 из 10 команд? Типичные ошибки

Я видел эти ошибки в десятках проектов. Не повторяйте их.

Ошибка 1: «У нас облако, там уже всё безопасно»

Нет. ФСТЭК проверяет не инфраструктуру, а вашу систему. Вашу модель. Ваши данные. Если вы используете managed-сервис типа Yandex DataSphere или SberCloud AI Platform, вы все равно отвечаете за конфигурацию, данные и логику. Облачный провайдер даст только справку о соответствии своего ЦОД. Это 10% от требований.

Ошибка 2: Слепая вера в open-source

Скачали веса модели с Hugging Face, дообучили – запустили. А кто автор модели? Кто гарантирует, что в весах нет трояна? По требованию №117 вы должны провести верификацию происхождения модели (provenance). Если не можете – считайте, что модель не соответствует требованиям. Решение? Использовать модели только из доверенных реестров (их сейчас формирует Минцифры) или проводить дорогостоящий аудит кода и весов.

Ошибка 3: Игнорирование «этичного ИИ»

Требования к этике в Указе №490 – не для галочки. Модель не должна дискриминировать по полу, возрасту, национальности. Вы тестировали свою модель на bias? Или просто надеетесь, что раз данные реальные, то и модель fair? Регулятор попросит отчет по тестированию на смещения. И если его нет – проект остановят. Кстати, сертификаты вроде IEEE CertifAIEd могут стать весомым аргументом при проверке.

Что будет дальше? Прогноз на 2026-2027

Регулирование не стоит на месте. Вот что ждет нас в ближайшем будущем:

• Обязательная сертификация для госзакупок. Хотите поставлять ИИ для госсектора? Получите сертификат «доверенной технологии ИИ». Процедура займет 6-9 месяцев и будет стоить от 5 млн рублей.
• Расширение перечня КИИ. Под регулирование попадут не только банки и энергетика, но и логистика, сельское хозяйство, ритейл – везде, где есть автономные системы принятия решений.
• Персональная ответственность. Как в финансовом секторе. За нарушения в ИИ-системе будут штрафовать не только юрлицо, но и CTO, архитектора, ответственного за безопасность. Рисковать карьерой за плохо настроенный промпт? Мало кто захочет.

И последнее. Не пытайтесь обойти регулятора техническими уловками. Типа «у нас не ИИ, а просто алгоритм» или «модель работает за границей, а мы только интерфейс». Аудиторы ФСТЭК уже натренировались отличать GPT от rule-based системы. И у них есть доступ к вашему коду. Лучший способ – начать диалог. Пригласить аудитора на ранней стадии проекта, показать архитектуру, получить рекомендации. Это сэкономит миллионы на штрафах и переделках.

Потому что в мире, где иски против AI-чатботов становятся нормой, а политики используют ИИ как разменную монету, единственная защита – это прозрачность и контроль. Даже если это больно.