Модель угроз для систем ИИ: как разработать по методике ФСТЭК и БДУ

Компания подключает чат-бот на LLM к базе клиентов, ставит предиктивную модель в производственный контур – и привычная модель угроз перестаёт описывать реальность. Промпт-инъекции (prompt injection), атаки через RAG и LoRA, компрометация ИИ-агентов, исчерпание квоты токенов в старых документах не значатся. Отдельной «методики для ИИ» ФСТЭК не выпускала – работает связка из двух источников.

Методика оценки угроз безопасности информации, утверждённая ФСТЭК России 5 февраля 2021 года, задаёт каркас оценки, а раздел «Угрозы безопасности информации систем искусственного интеллекта» в БДУ добавляет ИИ-специфику. Разбираем, как по этой связке разработать модель угроз для системы с ИИ, которая пройдёт проверку и аттестацию. Базовый процесс без ИИ-специфики мы разобрали в отдельном материале – как разработать модель угроз информационной безопасности.

Что изменилось: ИИ стал отдельным объектом оценки угроз

В конце 2025 года на сайте банка данных угроз ФСТЭК появился раздел «Угрозы безопасности информации систем искусственного интеллекта». Это официальный ориентир регулятора: какие объекты ИИ-системы рассматривать при оценке угроз и какими способами реализуются угрозы. Раздел делит угрозы на две группы – в инфраструктуре разработчика (разработка и обучение модели) и в инфраструктуре оператора (эксплуатация). Для первой описаны 3 угрозы и 6 способов реализации, для второй – 4 угрозы и 7 способов: от DoS-атак на интерфейсы ИИ до исчерпания квоты токенов.

БДУ прямо прописывает мост к классической процедуре: оценка возможности реализации угроз ИИ-систем проводится «в соответствии с Методикой оценки угроз безопасности информации, утверждённой ФСТЭК России 5 февраля 2021 г.». То есть каркас остался прежним – меняется состав объектов, нарушителей и сценариев. Как устроен банк данных и как искать в нём угрозы – в статье БДУ ФСТЭК: банк данных угроз.

С 1 марта 2026 года защиту информации в ГИС регулирует приказ ФСТЭК № 117, сменивший приказ № 17: ИИ в нём впервые выделен как самостоятельный объект защиты. Разбор требований приказа – на нашем спецпроекте 117fstec.credos.ru. Методический документ ФСТЭК от 12 апреля 2026 года «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» посвятил защите ИИ отдельный раздел 3.18. В августе 2026 года ФСТЭК вынесла на обсуждение проект изменений в приказ № 117 по ИИ с датой вступления по проекту 1 марта 2027 года; что требуется сейчас и что меняет проект — в статье «Что ФСТЭК требует по безопасности ИИ». Документ распространяется не только на ГИС, но и на значимые объекты КИИ, АСУ ТП и ИСПДн. Параллельно формируется рамочное регулирование: закон об ИИ (Федеральный закон от 26 июля 2026 года № 243-ФЗ) вступил в силу 1 сентября 2026 года – разбор в отдельной статье о законе об ИИ.

Где модель угроз с учётом ИИ обязательна

Обязательность зависит от статуса системы – четыре случая, когда без неё не обойтись:

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

Для коммерческой системы без персональных данных и статуса КИИ формальной обязанности нет – решение принимает руководитель оператора. Но без неё вы выбираете меры защиты ИИ-контура вслепую, а бюджет на безопасность ИИ нечем обосновать.

Классические угрозы и атаки на ИИ: в чём разница

Практический вывод: ИИ-угрозы не заменяют классические, а добавляются к ним. Серверы, каналы связи и системное ПО, на которых работает ИИ, оценивайте по основному перечню УБИ (227 угроз на июль 2026 года), а модель, данные и агенты – по ИИ-разделу. Учтите: пять угроз машинного обучения – УБИ.218–222, от кражи обучающих данных до отравления данных и подмены модели – есть в основном перечне ещё с конца 2020 года; включайте их в оценку модели и датасетов наряду с ИИ-разделом.

Объекты воздействия: что защищаем в ИИ-системе

БДУ требует рассматривать компоненты ИИ-системы как самостоятельные объекты воздействия. В инфраструктуре разработчика – на этапах разработки и обучения:

• ПО, реализующее технологию ИИ, включая фреймворки, библиотеки и иные инструменты;
• среда разработки API-интерфейсов, агентов и систем цензуры (фильтрации входных и выходных данных);
• входная модель машинного обучения, на базе которой обучается своя;
• наборы обучающих данных;
• выходная модель и её параметры (веса).

В инфраструктуре оператора – на этапе эксплуатации:

• ПО оператора, включая агентов ИИ, API-интерфейсы и системы цензуры;
• вспомогательное ПО, в том числе средства защиты информации;
• обученная модель и её расширения – LoRA, RAG, системные промпты.

Регулятор оговаривает две вещи. Первая: если оператор дообучает модель, ведёт непрерывное обучение или сам наполняет RAG, к его инфраструктуре добавляются угрозы «разработческой» группы – отравление данных и модификация весов становятся его зоной ответственности. Вторая: угрозы, связанные с качеством моделей – галлюцинации, ошибки предсказаний, – раздел БДУ не рассматривает, это отдельная задача контроля достоверности.

Как разработать модель угроз для системы с ИИ: шесть шагов

1. Определите границы системы и роль ИИ. Где работает модель: собственная инфраструктура, площадка провайдера или внешний сервис по API. Кто разработчик, кто оператор, как разделена ответственность с провайдером вычислений – БДУ прямо требует это учитывать.
2. Сформулируйте негативные последствия. По методике 2021 года это отправная точка: ущерб гражданам, организации, государству. Для ИИ добавьте специфику: утечка клиентских данных через ответы модели, решения на основе искажённых предсказаний, компрометация агента с доступом к внутренним системам.
3. Инвентаризируйте объекты воздействия. Классические – серверы, СУБД, каналы – плюс ИИ-объекты из списков выше: модель и веса, датасеты, LoRA, RAG, системные промпты, агенты, API, системы фильтрации.
4. Определите нарушителей и их возможности. Особенность ИИ-систем: любой пользователь с доступом к промпту – потенциальный нарушитель, ему не нужны эксплойты, достаточно правильно составленного запроса. Для внутреннего нарушителя у разработчика отдельно оцените, есть ли у него доступ к датасетам и весам и что даёт их изменение.
5. Соберите способы реализации и сценарии. Для «обычных» компонентов – УБИ из основного перечня. Для ИИ-объектов в ИИ-разделе два перечня с независимой нумерацией: для инфраструктуры разработчика – способы СП.1–СП.6 из таблицы 1 (уязвимости фреймворков и входной модели, недостатки и отравление датасетов, модификация среды разработки, весов, LoRA и RAG), для инфраструктуры оператора – СП.1–СП.7 из таблицы 2 (DoS-запросы, промпт-инъекции через RAG, состязательные атаки, модификация весов и системного промпта, кража модели, исчерпание квоты). Шифры совпадают, способы за ними – разные, не смешивайте их. Неприменимые исключайте с обоснованием, а не молча.
6. Оцените актуальность и оформите документ. Перечень актуальных угроз – входные данные для технического задания и выбора мер защиты. Структуру документа берите из приложения 3 к методике, дополнив ИИ-разделами.

Чек-лист: разделы модели угроз ИИ-системы

• Описание системы: архитектура, интерфейсы, место ИИ-компонентов, схема потоков данных;
• роль организации: разработчик, оператор или обе роли (дообучение, наполнение RAG);
• негативные последствия и виды ущерба;
• объекты воздействия: классические плюс модель, веса, датасеты, LoRA, RAG, промпты, агенты;
• модель нарушителя с уровнями возможностей – включая пользователя ИИ-интерфейса;
• способы реализации угроз: УБИ плюс СП.1–СП.6 разработчика (таблица 1 ИИ-раздела) и СП.1–СП.7 оператора (таблица 2), нумерация независимая;
• сценарии атак на ИИ: от промпт-инъекции до отравления данных;
• перечень актуальных угроз с обоснованием исключений;
• разделение ответственности с провайдером и разработчиком модели;
• порядок пересмотра: при дообучении, смене модели, подключении новых агентов.

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

На что ориентироваться: практика Сбера и ГОСТ

В апреле 2025 года Сбер опубликовал первую в России комплексную модель угроз для систем ИИ: 70 угроз для генеративных (GenAI) и предиктивных (PredAI) моделей, по всему жизненному циклу – от подготовки данных до интеграции в приложения. Это отраслевая практика безопасности ИИ, а не нормативный документ: требования регулятора она не заменяет, но полезна как справочник сценариев там, где лаконичные формулировки БДУ хочется развернуть до конкретных техник.

Методы оценки робастности нейронных сетей обозревает национальный стандарт ГОСТ Р 70462.1-2022 «Оценка робастности нейронных сетей. Часть 1. Обзор»: это справочный документ, нормативных ссылок он не содержит, а состязательные примеры и атаки «белого» и «чёрного ящика» описаны в его справочном приложении А – пригодится, когда по итогам модели угроз решите тестировать модель на практике. В обязательный состав документа стандарт не входит.

Что будет, если модель угроз не разработать

Прямого штрафа «за отсутствие модели угроз» в КоАП нет – последствия наступают через процедуры. ГИС без согласованной модели угроз не пройдёт аттестацию – легально эксплуатировать её нельзя. Для ИСПДн определение угроз – обязанность оператора по ст. 19 152-ФЗ: её невыполнение фиксируется при проверках и оборачивается предписаниями. Для значимых объектов КИИ нарушение требований к обеспечению безопасности – ч. 1 ст. 13.12.1 КоАП, штраф для должностных лиц от 10 до 50 тысяч рублей. Дороже штрафов обходится инцидент: промпт-инъекция или отравление данных в системе, где эти угрозы даже не оценивали, бьёт по всей системе защиты.

Кредо-С – лицензиат ФСТЭК России. Разрабатываем модели угроз по методике 2021 года с учётом ИИ-раздела БДУ: оценим ваш контур, определим объекты воздействия и актуальные сценарии, подготовим документ под согласование и аттестацию. Начните с анализа защищённости ИИ-контура – покажем, где ИИ-компоненты уже вышли за рамки вашей текущей модели угроз.

Читайте также

• Аудит безопасности ИИ-систем
• Регламент использования ИИ
• Как разработать модель угроз информационной безопасности
• БДУ ФСТЭК: банк данных угроз безопасности информации
• Закон об ИИ 2026