Безопасность ИИ в госсистемах: приказ ФСТЭК № 117 станет обязательным с марта 2026

---

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

Эта инструкция поможет вам за один подход разобраться, какие конкретные требования к безопасности ИИ действуют в России прямо сейчас, и выстроить минимальный чек-лист защиты: от изоляции инфраструктуры до тестирования на промпт-атаки (попытки обмануть модель специально подобранными запросами).

Согласно оригинальному обзору, ИИ сегодня рассматривают как самостоятельную поверхность атаки. При этом большинство специалистов путают три близких, но разных понятия: AI Security (защита ИИ-систем от кибератак), MLSecOps (безопасность на всём цикле разработки моделей машинного обучения) и AI Safety (безопасность ИИ для пользователей и общества в целом). AI Security, по сути, лишь часть AI Safety. В России нормативная база не проводит чёткой границы между Security и Governance, но заметен уклон именно в сторону кибербезопасности.

Что понадобится

• Текст Указа Президента РФ № 490 «О развитии искусственного интеллекта» (национальная стратегия до 2030 года, задаёт концепцию «доверенного ИИ»)
• Приказ ФСТЭК № 117 от 11.04.2025 и методический документ от 12.04.2026 (пункт 3.18, состав мер защиты)
• ГОСТ по разработке безопасного ПО (ссылка на него дана в методическом документе)
• Доступ к Банку данных угроз (БДУ) ФСТЭК, там перечислены угрозы, специфичные для ИИ-систем
• Примерно 2 часа на первичный аудит текущей инфраструктуры

Пошаговая инструкция

1. Разберитесь, какие понятия к чему относятся. AI Security охватывает четыре направления защиты самой ИИ-системы от кибератак. AI Safety шире: это безопасность ИИ для людей и общества в целом, включая этику и контроль. В российских документах оба понятия объединены, но конкретные технические меры прописаны именно для Security.

2. Проверьте, попадает ли ваша система под требования ФСТЭК. Приказ № 117 распространяется на государственные информационные системы (ГИС). Если ваш продукт с ИИ работает внутри ГИС или поставляется госзаказчику, меры из пункта 3.18 методического документа обязательны. Под защиту попадают и расширения модели: LoRA (метод лёгкой адаптации модели без полного переобучения), RAG (генерация ответов с подключением внешних источников данных) и вся сопутствующая инфраструктура.

3. Изолируйте инфраструктуру разработки. На этапе разработки методический документ требует выделить среду разработки ИИ в отдельный сетевой сегмент. Мера усиления: физическая изоляция среды (отдельные серверы, не просто VLAN).

4. Откажитесь от небезопасных форматов хранения моделей. Формат pickle (стандартная сериализация Python) позволяет встраивать произвольный код, который выполнится при загрузке файла. Переходите на безопасные форматы:

# Вместо pickle используйте onnx или protobuf
# Пример сохранения модели в формате ONNX (PyTorch):
import torch.onnx
torch.onnx.export(model, dummy_input, "model.onnx")

1. Наведите порядок в обучающих данных. Методический документ требует использовать обучающие данные (training data, наборы примеров, на которых модель учится) только из доверенных источников. Каждый набор нужно проверить антивирусом и хранить обособленно. Мера усиления: шифрование обучающих данных сертифицированными криптографическими средствами.

2. Проведите анализ уязвимостей входной модели. Если вы берёте предобученную модель (открытые веса из публичного репозитория), проверьте её по БДУ ФСТЭК на известные уязвимости до того, как начнёте дообучение (fine-tuning, адаптация модели на ваших данных под конкретную задачу).

3. Внедрите состязательное обучение и тестирование. Состязательное обучение (adversarial training) означает, что вы специально подаёте модели «вредные» примеры во время обучения, чтобы она научилась им противостоять. Дополнительно протестируйте систему на устойчивость к промпт-атакам: попытки обойти ограничения через специально сконструированные промпты (входные запросы к модели).

4. Настройте фильтрацию и мониторинг на этапе эксплуатации. Методический документ предписывает:

5. Фильтрацию входных и выходных данных (контроль того, что пользователь отправляет модели и что она выдаёт)
6. Регистрацию событий безопасности по каждому запросу и ответу
7. Мониторинг и квотирование числа запросов (защита от перегрузки и перебора)

8. Регулярный анализ уязвимостей ПО

9. Обеспечьте целостность весов модели. Мера усиления на этапе эксплуатации: целостность параметров (весов) модели должна подтверждаться сертифицированными криптографическими средствами защиты информации (СЗИ). Это предотвращает подмену модели.

10. Сопоставьте свои меры с международными регламентами, если работаете на экспорт. В ЕС действует AI Act, который классифицирует ИИ-приложения по четырём уровням риска: неприемлемый (запрещены), высокий (строгие правила для здравоохранения, образования, правоохранительных органов), ограниченный (обязательства по прозрачности) и минимальный (не регулируется). Если ваш продукт доступен пользователям в ЕС, соблюдать регламент нужно независимо от вашего местоположения.

Что делать с этим прямо сейчас по ролям?

Автору и копирайтеру на Дзене. Если вы используете ИИ-инструменты для генерации текстов и не передаёте в промпт персональные данные, регуляторные требования ФСТЭК к вам напрямую не относятся. Но понимать, как работает безопасность ИИ, полезно для экспертного контента: тема горячая, разбирающихся авторов мало.

Маркетологу. Если ваша компания внедряет ИИ-чатбота для клиентов или использует ИИ для таргетинга, проверьте, не попадает ли система под требования AI Act (если есть пользователи в ЕС) или под Приказ ФСТЭК (если работаете с госсектором). Фильтрация выходных данных, это не только про безопасность, но и про репутацию.

Предпринимателю в РФ и СНГ. Приказ ФСТЭК № 117 вступает в силу 1 марта 2026. Если ваш продукт поставляется в ГИС, до этой даты нужно привести архитектуру в соответствие: изоляция, безопасные форматы, шифрование, логирование, тестирование. Начинать аудит имеет смысл сейчас: переделка инфраструктуры за два месяца до дедлайна обойдётся заметно дороже.

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