Большинство рассказывает о безопасности моделей через атаки на готовую систему: инъекции, джейлбрейки, утечки через запросы. Отравление данных бьёт раньше — на этапе, когда модель формируется. Атакующему не нужно взламывать эксплуатацию: достаточно, чтобы в обучающую выборку попали подготовленные примеры, и модель вырастет уже скомпрометированной. На приёмочных тестах такая модель выглядит исправной — в этом и есть главная опасность.
Отравление — не гипотеза исследователей, а класс атак с длинной историей: от искажения фильтров спама до закладок в классификаторах изображений. С приходом генеративных ИИ поверхность атаки выросла: модели обучаются на гигантских массивах, собранных из открытых источников, краудсорс-разметки и сторонних датасетов, где проконтролировать каждый пример физически невозможно.
Как работает атака: по шагам
- Шаг 1. Доступ к данным. Вектор попадания: краудсорс-разметчики, публичный датасет, поставщик данных, скрапинг веба, куда атакующий заранее «посеял» подготовленные страницы, и даже пользовательский контент, на котором модель дообучается.
- Шаг 2. Внесение примеров. Два основных типа. Атаки на доступность — массово искажённые метки, снижающие точность модели в целом: система «глупеет» без видимой причины. Целевые атаки — аккуратные закладки: небольшая доля примеров с триггером (слово, символ, паттерн), при котором модель делает то, что задумал атакующий.
- Шаг 3. Обучение. Модель выучивает и легитимные закономерности, и закладку. Стандартные метрики качества почти не проседают — доля отравленных примеров мала.
- Шаг 4. Активация. В эксплуатации модель отлично работает — до встречи с триггером. Дальше возможен любой сценарий: классификатор фрода пропускает конкретную схему, антиспам молчит на нужное слово, ассистент отвечает по заложенной легенде.
Отдельный класс — отравление обратной связи: если система дообучается на оценках пользователей или логах диалогов, атакующий «накручивает» нужные реакции малыми дозами. А у RAG-систем появился свой аналог: отравление базы знаний — один poisonous документ в индексе может менять ответы ассистента по целой теме. Механика другая, цель та же: контроль над ответами без взлома самой модели.
Кто в зоне риска
- Модели, дообученные на сторонних данных. Заказное fine-tuning у подрядчика, датасеты от вендора, покупная разметка.
- Системы с обучением на пользовательском контенте. Модерация, фильтры, рекомендации, любые петли обратной связи.
- RAG-ассистенты с открытым пополнением базы. Любой сотрудник или интеграция может добавить документ.
- Открытые датасеты и веса. Скачанное из сети без ревизии — унаследованные риски чужой цепочки поставки; их фиксируют в AI BOM.
Защита: что реально работает
- Происхождение данных. Каждый датасет в производстве имеет описанную родословную: источник, время, кто собрал, кто проверил. Анонимные данные «из интернета» для критичных моделей недопустимы.
- Статистическая ревизия. Автоматические проверки на аномалии: странные кластеры меток, дубликаты, сдвиги распределений между версиями выборки.
- Выборочная проверка разметки людьми. Контрольная перепроверка доли примеров независимым разметчиком — стандарт против «тихих» искажений.
- Тесты на триггеры. После обучения модель прогоняется по сценариям красной команды: известные типы закладок, попытки активации, краевые примеры. Как это устроено — в статье красная команда по ИИ.
- Разделение контуров. Права на изменение обучающих данных и на запуск обучения — разные роли, изменения фиксируются в журнале, как в любом защищаемом процессе.
- Синтетическая замена. Там, где возможно, чувствительные выборки заменяются синтетическими данными с проверенной генерацией — меньше внешних точек входа.
Зачем бизнесу разбираться в угрозе
- Приёмка у подрядчика. Модель, обученную на стороне, принимают не только по метрикам качества, но и по документации данных: что за выборка, откуда, как проверялась.
- Невидимость на тестах. Отравленная модель проходит демонстрацию и приёмочные испытания — закладка проявляется в бою. Значит, доверять можно процессу подготовки данных, а не финальной метрике.
- Госзаказчики и регуляторы. Объяснимость происхождения модели и данных постепенно становится частью требований к ИИ-системам; в России ориентир — закон 243-ФЗ об ИИ и отраслевые регламенты.
- Стоимость инцидента. Одна закладка в антифроде или модерации обходится дороже любых мер контроля данных.
У НЬЮ-ССТ ревизия цепочки данных — раздел аудита ИИ-безопасности, старт от 90 000 ₽: проверяем происхождение датасетов, права доступа к обучению, настраиваем журналы и тесты на триггеры.
Отравление или ошибка: как отличить на практике
Не всякая плохая модель отравлена — чаще встречаются честные ошибки данных: устаревший срез, смещённая выборка, ошибка разметки, дрейф. Различие важно, потому что лечение разное: ошибку чинят исправлением данных и переобучением, закладку ищут целенаправленно. Признаки, склоняющие к версии атаки: ошибки не случайны, а сгруппированы вокруг конкретного класса, триггера или сегмента; проблема появилась после конкретной партии данных от нового источника; при перепроверке разметки часть примеров содержит систематически одинаковые искажения, как будто по шаблону; падение качества на общем фоне не просело, но на отдельных сценариях модель ведёт себя неправдоподобно уверенно.
Практический приём — срез по происхождению данных: метрики качества считаются отдельно для примеров из каждого источника и каждой партии разметки. Аномальный источник сразу виден. Это же умение обслуживает и обычное качество данных — двойная польза.
Гигиена работы с подрядчиками и краудсорсом
- Договорная фиксация данных. В договоре с разметчиком или поставщиком датасета: происхождение данных, запрет на подмешивание посторонних источников, право аудита, ответственность за качество партии. Юридическая рамка дисциплинирует и добросовестных участников, и случайных.
- Приёмочные тесты партий. Каждая партия разметки проходит контрольную перепроверку независимой стороной — хотя бы пять-десять процентов примеров. Систематические искажения всплывают на этой выборке.
- Разделение партий. Данные от разных подрядчиков не смешиваются в один массив до приёмки: так аномалия остаётся локализованной и откатываемой.
- Журнал изменений датасета. Каждое пополнение фиксируется: кто, что, когда, откуда. Без журнала расследование невозможно в принципе — подозревать придётся все данные сразу.
Что делать при подозрении на закладку
Порядок действий напоминает реагирование на любой инцидент. Сначала — остановка обучения на сомнительных данных и фиксация текущего состояния: версия модели, версия датасета, журнал. Затем — локализация: какие партии под подозрением, какие сценарии ведут себя странно. Дальше — проверка гипотез: воспроизведение странного поведения на контрольных примерах, срезы по источникам, поиск триггеров. Если закладка подтверждается — откат к последней чистой версии модели и датасета, уведомление владельцев процесса, разбор канала проникновения. И обязательный вывод уроков в регламент: как этот канал закрывается, чтобы история не повторилась.
Важно понимать экономику вопроса: расследование закладки в работающей системе — недели работы. Контроль происхождения данных на входе — дни. Профилактика здесь дешевле лечения на порядок, как почти всегда в безопасности.
Мини-глоссарий атакующего
- Триггер. Сигнал, по которому срабатывает закладка: слово, символ, редкий паттерн во входных данных. Модель ведёт себя нормально на всём, кроме входов с триггером.
- Закладка, или бэкдор. Само вредоносное поведение, выученное на отравленных примерах: пропуск конкретной схемы, ложная классификация, кодовая фраза доступа.
- Чистая разметка (clean-label). Утончённый вариант: примеры выглядят корректно и проходят ручную проверку, но их признаки подогнаны так, что модель учит нужную атакующему закономерность. Самый сложный для обнаружения класс.
- Доступность против целевой атаки. Первая просто «портит» модель — точность падает везде; вторая прицельна — общий показатель почти не страдает, что и делает её опасной для приёмочных тестов.
Эти термины полезно знать не для академичности: они образуют язык, на котором формулируются требования к проверкам. Фраза «прогнать тесты на clean-label закладки с триггерами из нашего домена» сразу задаёт подрядчику уровень проверки.
Отравление данных и отравление RAG: сравнение
Обе атаки ведут к одному результату — контроль над ответами системы — но живут на разных этажах. Отравление данных меняет саму модель: вкладывается в веса при обучении, живёт в каждой копии модели, обнаруживается тестами на триггеры и анализом обучающих данных. Отравление базы знаний меняет окружение модели: подготовленный документ попадает в индекс, модель честно отвечает по нему — ведь RAG и предназначен для ответов по документам; атака живёт до чистки индекса и обнаруживается контролем пополнения. Практический вывод: если в системе есть и дообучение, и база знаний — закрывать нужно оба этажа: родословную датасетов и права на пополнение индекса. Проверять только один из них — запирать дверь, оставив окно.
С чего начать
Составьте перечень: какие модели у вас обучаются или дообучаются, на каких данных, кто имеет право эти данные менять. К каждой строке — вопрос «откуда данные и кто их проверил». Это ядро будущего AI BOM и одновременно чек-ап по отравлению: большинство закладок живёт именно там, где ответ на этот вопрос — «не знаем».