A28 · Управление AI

Дрейф данных как источник риска безопасности

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

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

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

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

Окружение меняется: появляются новые типы операций, каналы, поведение клиентов и противников. Модель при этом работает на устаревших закономерностях, и её точность падает без единого сбоя. Атакующий действует в новых условиях, где контроль слабее. Граница доверия нарушается во времени: организация продолжает полагаться на результаты проверки, проведённой в другой обстановке. Риск носит управленческий характер, поскольку возникает там, где у модели нет владельца, сроков перепроверки и связи с показателями бизнеса.

Связь со стандартамиOWASPLLM09MITRE / ATT&CKATLAS: AI GovernanceNISTNIST AI RMF: Govern
01
Влияние на бизнес

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

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

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

Финансы

Ошибки скоринга ведут к неверным решениям по клиентам и операциям.

Операции

Аналитика цепочек поставок выдаёт рекомендации, не отвечающие текущей ситуации.

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

Антифрод-модели в меняющихся каналахКлассификация событий безопасностиСкоринг клиентов и контрагентовАналитика цепочек поставок
02
Зоны ответственности

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

ИТ-директор

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

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

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

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

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

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

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

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

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

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

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

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

Регламент переобучения моделей

Определить, кто, по каким основаниям и с какими проверками принимает решение о переобучении.

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

Привязка к показателям бизнеса

Закрепить за моделью показатели процесса, по которым владелец оценивает её пригодность.

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

Периодическая перепроверка

Регулярно повторять оценку модели на актуальных данных и фиксировать результат.

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

Резервный режим работы

Иметь правила или ручную процедуру на случай признания модели непригодной.

05Мониторинг

Контроль дрейфа данных

Непрерывно сравнивать входные данные и результаты модели с эталонным периодом.

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

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

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

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

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

  • Доля рабочих моделей с настроенным контролем дрейфа
  • Доля моделей, перепроверенных в установленный срок
  • Динамика ложных срабатываний и пропусков по ключевым моделям

Первые 30 дней

  1. Составить перечень рабочих моделей с датой последней проверки и владельцем
  2. Включить контроль дрейфа для моделей антифрода и безопасности
  3. Утвердить порядок перевода процесса в резервный режим
06
Проверка в пилоте

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

Проверить видимость реестра AI, владельцев, изменений политик и доказательность принятого решения.

1

Реестр связывает AI-сценарий, владельца, класс данных и развёрнутую модель или поставщика.

2

Изменение политики или конфигурации поставщика имеет проверку и событие аудита.

3

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

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

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

Наблюдаемость LLMМониторинг моделейУправление AI (AI Governance)

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

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

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

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

S12 · NISTAI 100-2e2025: Adversarial Machine LearningТаксономия атак и mitigations для adversarial ML.S14 · CISAJoint Guidance on Deploying AI Systems SecurelyБезопасное внедрение AI-систем.S17 · GoogleSecure AI Framework (SAIF)Secure-by-default AI, privacy и управление риском.