Из трёх мартовских-2027 требований к разработчику БФМ (модель — безопасность; эксплуатация — регламент; плюс техописание) самой недоопределённой выглядит первое: закон говорит «принимать меры безопасности», но не даёт чек-листа. Отраслевой ответ на такую неопределённость известен из ИБ-практики: модель угроз. Документ, который связывает активы, векторы атак и меры защиты, превращает расплывчатую обязанность в проверяемый процесс. Этот практикум — о том, как собрать модель угроз для большой фундаментальной модели.
Контекст обязанностей — на странице обязанностей разработчиков и в обзоре обязанностей разработчика БФМ; здесь — инженерная сторона.
Что такое модель угроз и почему она ядро обязанности
Модель угроз — структурированный перечень сценариев атаки на систему с оценкой последствий и привязкой мер защиты. Для ИИ-разработчика она выполняет три функции: во-первых, показывает регулятору и аудитору, что меры безопасности не случайны, а покрывают выявленные риски; во-вторых, расставляет команде приоритеты закрытия векторов; в-третьих, поддерживает в актуальном виде связку «закон → риск → мера».
Закон не предписывает форму документа — и это плюс: можно использовать привычные корпоративные шаблоны, наполнив их ИИ-спецификой. Состав мер уточняется подзаконными актами после марта 2027 года, поэтому документ стоит проектировать обновляемым.
Специфика ландшафта угроз LLM
Базовый каталог векторов для больших языковых и мультимодальных моделей отрасль стандартизировала в OWASP LLM Top-10. Рабочие группы для модели угроз БФМ:
| Группа угроз | Типовые векторы | Примеры мер |
|---|---|---|
| Входы и промпты | Промпт-инъекции прямые и косвенные, джейлбрейки | Фильтрация ввода, системные инструкции, ограничение контекста |
| Данные | Отравление обучающих данных, попадание конфиденциального в датасеты | Карточки датасетов, контроль происхождения, чистка выборок |
| Выходы | Утечка данных через ответы, стеганография в генерациях | Постфильтрация, DLP-контроль, ограничения на форматы |
| Инструменты и интеграции | Злоупотребление tool-use, компрометация подключённых сервисов | Белые списки действий, подтверждения человеком, аудит логов |
| Цепочка поставки | Компрометация весов, зависимостей, плагинов | Контроль хешей, подписи артефактов, изоляция сборки |
Терминологический словарь по каждому вектору — в разделах сайта о отравлении данных и стеганографии в выходах ИИ; практические меры — в гайдах по guardrails и red teaming.
Структура документа
Рабочая структура модели угроз БФМ, совместимая с корпоративными шаблонами ИБ:
- Периметр и активы — сама модель, веса, датасеты, инфраструктура инференса, API, логи, подключённые инструменты.
- Доверенные стороны и нарушители — пользователи, операторы, подрядчики; модели нарушителя от инсайдера до внешней группы.
- Каталог угроз — по группам таблицы выше, с оценкой критичности и реализуемости.
- Меры защиты — привязанные к угрозам: технические, организационные, процедурные.
- Остаточные риски — принятые осознанно, с датой пересмотра.
- Журнал изменений — версия, что изменилось, кто согласовал.
Процесс: пять шагов
Шаг 1. Опишите поверхность атаки. Как модель используется: чат, API, встроенные функции, agent-сценарии с инструментами. Чем больше интеграций, тем больше векторов tool-use.
Шаг 2. Соберите каталог угроз. Отправная точка — перечень OWASP LLM Top-10: отметьте применимое. Для каждого вектора — короткий сценарий «как это выглядит у нас».
Шаг 3. Оцените критичность. Шкала последствий × реализуемость. Цель — не точность оценок, а порядок закрытия.
Шаг 4. Привяжите меры. Для верхних угроз — конкретные меры с ответственными. Проверяйте связку «угроза закрыта мерой» парно, как в тестах покрытия кода.
Шаг 5. Встройте сопровождение. Пересмотр при изменениях продукта и при выходе новых ревизий OWASP; фиксация в журнале. Модель угроз, которую никто не открывал год, хуже отсутствующей — она создаёт ложную уверенность.
Связь с остальным пакетом соответствия
Модель угроз не живёт в вакууме: она опирается на инвентаризацию датасетов (разбор датасетов и их источников — в материале о происхождении данных), питает правила эксплуатации и обновления (обзор — в материале правил эксплуатации модели) и служит входом для red teaming. Внешняя проверка контура по такой модели — типовой формат аудита: аудит ИИ здесь стоит от 90 000 ₽, построение контура безопасности — от 480 000 ₽ (ориентиры сентября 2026, не оферта).
Мини-кейс: первая версия за две недели
Команда из шести человек выпускает ассистента для внутренней поддержки на модели в открытом контуре. Решают собрать первую модель угроз до запуска. Неделя первая: архитектор описывает поверхность — чат, доступ к базе знаний, два инструмента (создание тикета, поиск в Confluence); ИБ-инженер приносит чек-лист OWASP и короткий шаблон, вместе отмечают применимое: инъекции через тикеты (косвенные — пользователь вставляет текст из письма), утечки из базы знаний через ответы, злоупотребление тикет-инструментом — каждый вектор получает владельца из числа разработчиков. Неделя вторая: оценка критичности, меры — фильтр ввода на подозрительные конструкции, ограничение инструментов ролью «только чтение» до сентября, постфильтр на шаблоны реквизитов. Итог — документ на девять страниц, журнал изменений и три меры в спринте; на ретроспективе команда решает сохранить ритм пересмотра раз в квартал и назначает владельца документа из числа разработчиков.
Существенно: модель угроз написана до инцидента, а не после. Когда через месяц исследователь находит новый вектор, документ дополняется разделом за вечер, а не создаётся с нуля в пожарном режиме.
Что положить в приложение к документу
Аудиторы и заказчики обычно просят к модели угроз три приложения: карту поверхности атаки (схема: пользователи, каналы, компоненты модели, инструменты, данные), реестр датасетов с происхождением и протокол последнего тестирования — красной команды или авто-тестов промпт-атак. Вместе эти артефакты закрывают типовой вопрос проверки: «покажите, что меры не выдуманы, а привязаны к рискам».
Как оценивать критичность без паралича
Самый частый вопрос практикума: как выставлять оценки, если данных о реализуемости нет. Рабочее правило — трёхуровневая шкала вместо чисел. Верхний уровень: вектор может стоить денег, репутации или регуляторного внимания — закрывать в текущем квартале. Средний: неприятен, но переживаем — мера в бэклоге со сроком. Нижний: теоретический — фиксация в остаточных рисках с датой пересмотра. Числовые шкалы (баллы, вероятности) добавляют видимость точности, которой нет; для первой и второй версии документа достаточно уровней.
Вторая опора — сравнение с инцидентами отрасли: каждый публичный случай с большой моделью (утечка через промпт, джейлбрейк-обход фильтров, компрометация плагина) автоматически поднимает соответствующий вектор вашей модели на уровень выше. Это не статистика, но честный ориентир для приоритизации.
Типичные ошибки
Первая — скопировать чужую модель угроз без адаптации: каталог векторов применимости не имеет, пока не привязан к вашей поверхности атаки. Правильная альтернатива — начинать с собственной схемы компонентов и двигаться от неё к угрозам, а не наоборот: сначала перечень того, что защищаем, затем — как это атакуют, и только потом чужие чек-листы как источник идей. Вторая — составить и забыть: отсутствие журнала изменений обесценивает документ при аудите. Третья — объять всё: попытка закрыть сто угроз сразу заканчивается нулевым прогрессом; рабочая дисциплина — топ-10 векторов, меры, следующая итерация. Четвёртая — игнорировать цепочку поставки: веса и зависимости атакуют чаще, чем саму архитектуру.
Итог
Модель угроз — самый практичный способ превратить обязанность «принимать меры безопасности» из 243-ФЗ в управляемый процесс: активы, векторы, меры, журнал. Основа каталога — OWASP LLM Top-10, ритм — итерации по изменениям продукта. Практикум — методический материал, не юридическое заключение и не норматив. НЬЮ-ССТ собирает модели угроз для ИИ-контуров и заявок на статус — в рамках аудита соответствия и программ для ИИ-команд; наш собственный стек проходит тот же процесс. Форма разбора — в финале страницы; типовой первый разговор занимает полчаса и заканчивается списком первых шагов.