A27 · Модель и цепочка поставки

Состязательные примеры и уклонение от распознавания

Входные данные специально изменяют так, чтобы модель неверно классифицировала объект, событие или транзакцию. Защитные и контрольные системы на основе моделей в результате пропускают угрозу.

Иллюстрация к карточке угрозы «Состязательные примеры и уклонение от распознавания»
Отправить с описанием:TelegramWhatsApp
Кратко для руководителя

В чём суть риска

Входные данные специально изменяют так, чтобы модель неверно классифицировала объект, событие или транзакцию. Защитные и контрольные системы на основе моделей в результате пропускают угрозу.

Модель принимает решение по входным данным: изображению, файлу, событию, транзакции. Вход изменён так, что для человека он по-прежнему выглядит нормальным объектом, но решение модели становится другим. Система не фиксирует ошибку, поскольку формально отработала штатно. Граница доверия нарушается там, где решение модели принимается как окончательное, без независимой перепроверки. Особенно уязвимы процессы, в которых модель заменила ручной контроль: антифрод, биометрия, компьютерное зрение, обнаружение вредоносного ПО, аналитика центра мониторинга.

Связь со стандартамиOWASPLLM03, LLM04MITRE / ATT&CKATLAS: ML Supply ChainNISTNIST AI 100-2: Poisoning
01
Влияние на бизнес

Чем риск оборачивается для компании

Безопасность

Средства обнаружения вредоносного ПО и аналитика SOC пропускают реальную угрозу.

Финансы

Антифрод-модель одобряет операцию, которую должна была остановить.

Операции

Биометрия и системы компьютерного зрения принимают неверные решения о допуске и контроле.

Где риск наиболее вероятен

Антифрод и транзакционный мониторингБиометрическая идентификацияКомпьютерное зрение в контроле и допускеОбнаружение вредоносного ПО и классификация событий SOC
02
Зоны ответственности

Кому и что решать

ИТ-директор

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

Директор по кибербезопасности

Включить проверку устойчивости моделей к искажённым входным данным в программу тестирования защищённости.

Владелец бизнес-процесса

Определить, для каких решений с высокой ценой ошибки обязателен просмотр человеком.

03
Сигналы для службы мониторинга

Что стоит наблюдать

Признаки сами по себе не доказывают инцидент. Их полезно сопоставлять с учётной записью, версией модели, решением политики, источником контекста и результатом вызова инструмента.

Внезапные группы однотипных ошибок классификации
Входные данные с малыми отклонениями от нормальных образцов
Расхождение решений между несколькими моделями по одному объекту
Рост расхождений между оценкой человека и оценкой модели
Ошибки сосредоточены на одном канале или типе объектов
04
Проектирование защиты

Какие меры создают границу

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

01Организационная

Проверка человеком значимых решений

Закрепить перечень решений, которые при высокой цене ошибки подтверждает сотрудник.

02Техническая

Обучение с учётом искажений

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

03Техническая

Валидация входных данных

Проверять и нормализовать входные данные до передачи в модель, отсекая нетипичные.

04Техническая

Ансамблевая перепроверка

Сопоставлять решения нескольких независимых моделей и направлять расхождения на разбор.

05Мониторинг

Регулярное состязательное тестирование

Периодически проверять модели на устойчивость и отслеживать всплески ошибок классификации.

05
Управленческий контроль

Вопросы, показатели и первые шаги

Вопросы команде и поставщику

  1. В каких процессах решение модели никто не перепроверяет?
  2. Проверялись ли наши модели на устойчивость к намеренно изменённым данным?
  3. Как мы узнаем, что модель начала систематически ошибаться?
  4. Даёт ли поставщик модели результаты таких испытаний?

Показатели контроля

  • Доля критичных моделей, прошедших состязательное тестирование
  • Частота расхождений между решением модели и оценкой человека
  • Доля решений с высокой ценой ошибки, проходящих проверку человеком

Первые 30 дней

  1. Составить перечень моделей, принимающих защитные и финансовые решения
  2. Определить решения, для которых нужен обязательный ручной контроль
  3. Заказать проверку устойчивости для двух-трёх наиболее критичных моделей
06
Проверка в пилоте

Как проверить в пилотном проекте

Подтвердить происхождение и управляемый путь поставки модели, адаптера, данных и зависимостей.

1

Состав AI-системы связывает артефакт модели, зависимости, набор данных и версию развёртывания.

2

Поступление артефакта из неутверждённого источника проходит контроль до выполнения.

3

Команда демонстрирует проверку, доказательство версии и безопасный откат.

Открыть матрицу пилота
07
Контекст рынка

Какие классы решений рассматривать

Тестирование защищённости AI (AI Red Teaming)Мониторинг моделейПротиводействие мошенничеству

Ниже — редакционные профили поставщиков, связанные с доменом угрозы. Это не рейтинг и не подтверждение применимости: заявленные функции следует проверить в вашем пилоте по указанным критериям.

Проверенные источники

Источники и проверка

Сначала — объяснение для русскоязычной команды. Затем — первоисточники, по которым можно проверить границы, методологию и применимость в конкретной архитектуре.

S12 · NISTAI 100-2e2025: Adversarial Machine LearningТаксономия атак и mitigations для adversarial ML.S13 · MITREMITRE ATLASТактики и техники против AI-систем.