ИИ стал критически важной частью бизнес-процессов — от автоматизации операций до принятия решений в реальном времени. Но вместе с ростом внедрения усиливается и давление на безопасность: атакующие изучают слабые места моделей, манипулируют данными и пытаются получить доступ к интеллектуальным активам компаний. Cyber Media разбирает, как выстраивается безопасность ИИ-систем — от защиты датасетов до мониторинга поведения моделей.
Содержание
AI Security выросла из простой мысли: классические методы ИБ перестали успевать за тем, как работают современные модели. ИИ больше не выглядит как обычный сервис в инфраструктуре. Он учится, меняется, реагирует на окружение — и в этой динамике появляются угрозы, которых раньше просто не существовало.
Эволюция рисков началась незаметно. Сначала казалось, что все упирается в доступ к внутренней части модели или к среде обучения. Но затем появились adversarial-примеры, отравление данных и скрытые бэкдоры — атаки, которые не оставляют привычных следов и проявляются только в поведении модели. А когда злоумышленники научились извлекать модель через API, стало очевидно: защита ИИ — это отдельная дисциплина, а не расширение классической ИБ.
Главное отличие в том, что здесь приходится защищать не систему, а логику принятия решений. Модель нельзя «захардкодить», ее входные данные нельзя полностью контролировать, а ее ошибки не всегда объяснимы. Поэтому внимание смещается к поведению, статистическим отклонениям и качеству данных.
ИИ-компоненты требуют собственных мер безопасности, потому что:
В итоге компании приходят к простой идее: ИИ уже нельзя защищать «по остаточному принципу». У моделей, данных и ML-процессов есть свои, уникальные риски — и для них нужны свои инструменты и практика.
Если в классической ИБ данные — это ресурс, который нужно защитить, то в мире ИИ данные — это еще и «строительный материал» для моделей. И если материал поврежден, модель тоже получится поврежденной. Именно поэтому атаки на этапе данных сегодня считаются одними из самых опасных.
Риски data poisoning формируются там, где есть высокая зависимость от внешних источников информации. Чем более разнообразные и сложно контролируемые данные используются для обучения, тем легче в них что-то незаметно подмешать. Это может быть единичный испорченный пример, масса мелких искажений или хитро замаскированный паттерн, который проявится только при определенных условиях. Хуже всего то, что такие вмешательства часто не выглядят как ошибка — они выглядят как статистическая «мелочь», которую легко пропустить.
Сергей Зыбнев
Ведущий специалист отдела по работе с уязвимостями ИС Бастион
Отравление данных — это скрытая угроза, так как модель может показывать отличные метрики на валидации, но содержать «закладку». На этапе ETL и препроцессинга мы обращаем внимание на следующее:
- Аномалии в пространстве эмбеддингов. При визуализации кластеров данных отравленные сэмплы часто образуют неестественные микрокластеры или оказываются далеко от центроидов своих семантических групп.
- Статистические выбросы в токенизации. Если в данных для обучения вдруг появляются редкие слова в необычно большом количестве или странные сочетания слов, которые люди так обычно не пишут — это сигнал тревоги. Такие аномалии могут означать, что кто-то внедрил в данные скрытые «команды-закладки», которые потом заставят модель вести себя нештатно.
- Deduplication Artifacts. Если в датасете обнаруживаются дубликаты с микроскопическими изменениями, например один и тот же текст с разной тональностью или вставкой спецсимволов, то это признак попытки сместить вес модели в сторону определенного паттерна.
- Discrepancy in Data Provenance. Несовпадение контрольных сумм или метаданных между исходным источником, например, снапшотом Common Crawl, и скачанным архивом.
Все это заставляет команды уделять гораздо больше внимания первичной проверке данных, а не только итоговому качеству модели.
Станислав Ежов
Директор по ИИ «Группы Астра»
В защищенных контурах я всегда добиваюсь: строгого контроля прав (RBAC), ведения неизменяемых логов, криптографических хешей версий датасетов, изолированных цепочек поставки данных и автоматического сканирования на prompt/data injection. Плюс — принцип «двух рук» на критичных изменениях и регулярные аудиты.
Параллельно растет роль data lineage — прозрачных цепочек происхождения данных. Компании документируют, откуда пришла каждая часть выборки, какие трансформации она прошла, кто и когда ее модифицировал. Такая «история происхождения» помогает оперативно находить источник аномалии, отслеживать уязвимые звенья и в целом формировать доверие к данным, на которых обучаются модели.
Бэкдоры в моделях — это не просто «скрытые правила», а результат целенаправленного вмешательства в градиентную динамику обучения. Злоумышленник внедряет паттерн, который практически не влияет на общие веса, но формирует отдельный «коридор» поведения, активирующийся только при специфическом триггере. Из-за этого модель демонстрирует отличные метрики, а скрытая функция остается невидимой даже при глубоком аудите кода.
Маскировка таких бэкдоров со временем становится все более изощренной. Атакующие используют минимальные триггеры, которые растворяются в данных: едва заметные текстовые токены, шумовые паттерны, особенности форматирования, даже статистические отклонения, которые сложно отличить от естественного распределения. При этом триггер может быть мультикомпонентным — например, сочетание слова и стиля пунктуации — что еще сильнее усложняет обнаружение.
Юрий Чернышов
К.ф.-м.н., доцент УНЦ «Искусственный интеллект» УрФУ, руководитель исследовательского центра UDV Group
Для анализа безопасности модели ИИ подходят все те же методы, применяемые при тестировании безопасности программного обеспечения: мониторинг, фаззинг, анализ взаимодействия с внешними компонентами. Сложность заключается в том, что невозможно понять логику работы модели, как это делается при анализе кода программного обеспечения, поскольку эта логика модели ИИ распределена по миллионам (как в случае с глубоким машинным обучением) или по миллиардам (как в случае с LLM) параметров. Поэтому применяется анализ модели ИИ как «черного ящика», анализируя вход и выход, оценивая параметры работы и потребление ресурсов. Исторический анализ параметров работы модели позволяет сформировать паттерны нормального поведения и анализировать в будущем отклонения от этих паттернов.
Главная проблема в том, что бэкдоры не зависят от чистоты данных. Их можно привнести через скомпрометированную тренировочную среду, подмешать в предварительно обученную модель, встроить в используемые библиотеки оптимизации или подменить на этапе fine-tuning при работе с автоматизированными ML-пайплайнами. Это означает, что, даже если компания идеально контролирует собственные данные, угрозы все равно могут проникнуть через supply chain ML-инфраструктуры.
Бэкдор становится в проде своеобразным «секретным протоколом»: активируется только тем, кто знает нужный вход, и остается неуловимым для всех остальных. Из-за этого предприятия сегодня уделяют внимание не только качеству моделей, но и полной проверке ML-поставщиков, контролю целостности артефактов, детальному логированию inference-потоков и мониторингу латентных отклонений в поведении модели под различными сценариями нагрузки.
Adversarial-атаки долго казались чем-то академическим — забавными примерами, где к изображению добавляют пару пикселей, и модель внезапно принимает пантеру за хлеб. Но в продакшене все устроено куда жестче. Здесь adversarial-примеры — это не «рисунок с шумом», а способ изменить решение модели минимальными, часто незаметными модификациями входных данных. Для злоумышленника это способ управлять поведением ИИ без взлома инфраструктуры. Для бизнеса — риск некорректных решений, которые внешне выглядят как нормальная работа модели.
В реальных условиях adversarial-атаки проявляются иначе, чем в лаборатории. Злоумышленник может играть не только пикселями или токенами, но и контекстом: формулировкой запроса, комбинацией признаков, особым порядком параметров, влиянием внешних факторов. Иногда достаточно слегка сместить распределение входных данных — и модель начинает систематически ошибаться. Для критичных сценариев это становится уже не экспертизой исследователей, а практической угрозой.
Кирилл Левкин
Проджект менеджер MD Audit (ГК Softline)
Оценка устойчивости к adversarial-примерам:
Ключ — измерять реальную деградацию полезности (business metrics), а не только accuracy, и проводить тестирование на реальных сценариях использования.
- стресс-тесты в продакшене - PGD/CW атаки в «белом» и «сером» режимах;
- атаки с ограничением по Lp-норме;
- проверка на переносимость (transferability).
Определение допустимого уровня риска становится частью пайплайна. Здесь компаниям приходится решать, какой уровень robustness им действительно нужен: что модель обязана выдерживать, какие классы атак считаются критичными, а какие — допустимыми в рамках SLA. В финансовых и медицинских сценариях порог устойчивости должен быть выше, и команды оценивают robustness не только по метрикам, но и по влиянию на бизнес-процессы, скорости деградации и вероятности систематических ошибок.
В итоге устойчивость к adversarial-атакам перестает быть исследовательской темой. Это практическая часть AI Security, где приходится мыслить не только о качестве модели, но и о ее поведении под давлением — так же, как сетевики тестируют периметр, а инженеры — отказоустойчивость.
Model extraction — это когда атакующий пытается восстановить логику модели, просто «бомбя» API запросами и анализируя ответы. Если API слишком предсказуемое, злоумышленник может собрать клон, который работает почти так же, как оригинал. Для компании это прямая потеря интеллектуальной собственности.
Сергей Зыбнев
Ведущий специалист отдела по работе с уязвимостями ИС Бастион
Атаки через API направлены на обучение модели-клона на ответах вашей LLM. Защита строится на уровне API Gateway и самой генерации. Помочь может ограничение информации в Output — отказ от возврата полных вероятностей или возвращение только top-1 токена. Без доступа к распределению вероятностей обучение клона становится значительно дороже и сложнее. Важно уделять внимание водяным знакам. Внедрение статистически обнаруживаемого паттерна в выбор токенов, например алгоритмы вроде Kirchenbauer et al., не предотвращает кражу, но позволяет доказать факт использования вашей модели конкурентом.
Специалисты нередко прибегают к анализу последовательности запросов от одного пользователя — Stateful Detection. Если запросы покрывают пространство признаков слишком равномерно или используют активное обучение для прощупывания границ, такой аккаунт блокируется.
Внесение микроскопических случайных искажений в логиты перед генерацией ответа или, проще говоря, добавление шума, снижает точность обучаемой злоумышленником модели, минимально влияя на качество сервиса.
Но даже эти меры работают только в комплексе. Чем более «честными» и подробными являются ответы модели, тем легче их использовать как сигналы для обратной инженерии. Поэтому ИБ-команды все чаще работают вместе с ML-инженерами, чтобы выстроить баланс между качеством сервиса и непрозрачностью модели.
Цель не в том, чтобы скрыть все, а в том, чтобы атакующему приходилось тратить настолько много запросов, времени и вычислений, что попытка извлечения становится экономически бессмысленной.
Когда модель выходит в прод, она перестает быть статичным объектом — ее окружение меняется, данные дрейфуют, пользователи приносят новые паттерны, а злоумышленники пробуют на прочность. Поэтому runtime-мониторинг уже стал обязательной частью AI Security: без него модель может «поехать» достаточно далеко, прежде чем кто-то заметит.
Основа подхода — поведенческие профили. Это не просто логирование, а описание того, как модель обычно реагирует: какие распределения предсказаний она выдает, какие классы предпочитает, как ведет себя на границах уверенности. Такой профиль позволяет вовремя замечать дрейф входных данных, всплески редких паттернов, неожиданные изменения в confidence-метриках и аномальное смещение распределения выходов.
Юрий Чернышов
К.ф.-м.н., доцент УНЦ «Искусственный интеллект» УрФУ, руководитель исследовательского центра UDV Group
Существует множество способов мониторить работу сложного устройства или системы, какой из них наиболее эффективен — сильно зависит от самой системы. Можно анализировать низкоуровневые параметры (трафик, потребление ресурсов оборудования), можно анализировать вход и выход модели ИИ (текст промпта и сгенерированный ответ), потребление токенов.
Но, на мой взгляд, наиболее эффективно анализировать влияние применения модели на бизнес-процесс: если в бизнес-процессе появились отклонения (изменилась продолжительность звонков, частота отправки писем, поменялась бизнес-логика процесса, перестал компилироваться код и пр.), то скорее всего случился сбой в работе ИИ-модели и необходимо проводить расследование, в том числе с применением анализа низкоуровневых событий в инфраструктуре и ПО.
Runtime-мониторинг — это фактически служба раннего предупреждения. Он не гарантирует абсолютную защиту, но позволяет ловить странности до того, как они превращаются в инцидент, и видеть модель не как набор весов, а как живой компонент, чье поведение нужно наблюдать, измерять и контролировать.
AI Security перестала быть только инженерной задачей — теперь это еще и вопрос соответствия требованиям. Европейский AI Act, NIST AI RMF, отечественные инициативы по контролю высокорисковых ИИ-систем — все это формирует новую рамку, где безопасность модели должна быть подтвержденной, измеряемой и документированной. Регуляторы больше не интересуются только качеством — им важны прозрачность, предсказуемость и управляемость рисков.
Для ML-команд это означает серьезные изменения в процессах. Теперь нужно не просто обучить модель, а уметь доказать, что она прошла необходимые проверки: от оценки устойчивости и анализа датасетов до процедур explainability и ограничений на использование чувствительных данных. В некоторых случаях требуется полный traceability: кто готовил данные, как менялась архитектура, какие тесты проводились и на какие метрики опирались при выводе модели в прод.
Кирилл Левкин
Проджект менеджер MD Audit (ГК Softline)
Регуляторные требования, влияющие сильнее всего:
Эти нормы определяют архитектуру, этапы тестирования и набор контролей при деплойменте ИИ-систем.
- требования к объяснимости и аудиту решений, защите персональных данных и согласия на использование данных;
- обязательная оценка рисков и сертификация моделей в критичных секторах;
- требования по хранению/локализации данных и правила обработки чувствительной информации.
Регуляторика тянет за собой и новые требования к документации. Модели должны сопровождаться отчетами о рисках, картами угроз, описанием примененных защитных мер и результатами тестов безопасности. А процессы разработки должны включать контроль цепочек поставок, регулярные проверки пайплайнов и подтверждение того, что система остается в пределах допустимых рисковых параметров. Для ИБ-специалистов это хороший знак: безопасность становится не рекомендательной, а обязательной частью любого серьезного ИИ-проекта — и ее роль только растет.
AI Security невозможно «прикрутить сверху» — она работает только тогда, когда становится частью MLOps и всей инженерной культуры. Компании, которые уже прошли через первые инциденты или аудит регуляторов, быстро понимают: если безопасность не встроена в процесс, она всегда запаздывает. Поэтому фокус смещается с разовых проверок на системный подход — от подготовки данных до поведения модели в проде.
Ключ к этому — интеграция AI Security во все этапы жизненного цикла модели. Датасеты проходят контроль происхождения и валидацию; тренировочные пайплайны защищают от вмешательства; модели тестируют не только на качество, но и на устойчивость, адекватность и «предсказуемость под давлением». А в проде включаются детекторы дрейфа, написанные заранее playbook-и реагирования и механизмы безопасного отката.
Компании все чаще создают собственные репозитории рисков — живые базы знаний, где хранятся типовые угрозы, выявленные уязвимости, тест-кейсы и методы защиты для конкретных семейств моделей. Такой подход помогает не «изобретать защиту заново» и формирует общий язык между ИБ, ML-инженерами и продуктом.
Чтобы все это работало, команды выстраивают базовый набор практик:
Системный подход делает безопасность не отдельным этапом, а свойством всей ML-инфраструктуры. И чем раньше компания начинает строить эту культуру, тем меньше неожиданностей ее ждет, когда модели становятся критической частью продукта.
AI Security уже стала новой нормой: модели работают на критичных данных, принимают решения, влияют на бизнес-риски — и требуют такой же зрелой защиты, как любая инфраструктура. Чем раньше компании начинают выстраивать процессы, инструменты и ответственность, тем легче им удерживать контроль над ИИ-системами по мере их роста.
Если вы еще не включили AI Security в свой MLOps, самое время начать: пересмотреть пайплайны, обновить политику безопасности, провести аудит рисков и внедрить мониторинг. Защита моделей — это не разовая настройка, а постоянная дисциплина. И лучше заложить ее сейчас, пока инциденты остаются у конкурентов.
Российский рынок сетевой безопасности в 2026 году перешел из фазы «экстренного импортозамещения» в стадию прагматичного выстраивания долгосрочных ИТ-стратегий.
Онлайн-игры переросли забаву — для детей это полноценная социальная среда, где формируются доверие, авторитет и цифровая идентичность.
Центры мониторинга ИБ все активнее внедряют AI/ML-модели, UEBA и LLM-ассистентов: автоматический триаж алертов, корреляция событий, приоритизация инцидентов и первичный анализ уже частично выполняются без участия человека.
Атаки на цепочку поставок стали одной из самых устойчивых и трудноуправляемых киберугроз для бизнеса.
Когда падает система уровня Sonata, становится очевидно: проблема не в ошибках пользователей и не в слабых паролях, а в самой архитектуре корпоративных мессенджеров.
С 1 марта 2026 года вступает в силу приказ ФСТЭК России № 117, который существенно меняет требования к защите информации в государственных информационных системах и смежных сегментах.
Еще несколько лет назад звонок от руководителя считался надежным подтверждением любого решения.
Ильдар Галиев, руководитель направления развития услуг «Кросс технолоджис», в статье для Cyber Media предлагает план, который поможет защитить бизнес, репутацию и укрепить отношения с крупными клиентами.
Современные атаки все реже начинаются с очевидного взлома периметра и все чаще развиваются внутри инфраструктуры.
Telegram, несмотря на все его проблемы в России, считается достаточно безопасным общедоступным мессенджером, но именно это доверие все чаще используют мошенники.
