Почему классическая кибербезопасность не спасает AI-системы

Каждая вторая компания, развернувшая у себя AI-агента или языковую модель, защищает её ровно так же, как обычный микросервис — файрволом, сканером зависимостей и политикой доступов. Звучит разумно, но на практике это всё равно что ставить металлическую дверь в дом, у которого нет одной стены. Борис Мацаков, Data Science инженер Cloud.ru, в своём разборе на Хабре точно сформулировал проблему, которую индустрия пока предпочитает не замечать: классический DevSecOps и AI-безопасность — это два разных контура, и один не заменяет другой.

Суть расхождения проста и при этом фундаментальна. DevSecOps выстраивался десятилетиями вокруг понятной модели угроз: есть периметр, есть зависимости, есть инфраструктура и права доступа. Защити каждый из этих слоёв — и система в безопасности. Но AI-модели атакуют совершенно иначе. Prompt injection позволяет злоумышленнику перехватить управление поведением модели через специально сконструированный текст. Отравление обучающих данных искажает саму логику принятия решений задолго до того, как модель попадёт в продакшн. Манипуляция контекстом заставляет AI-агента выполнять действия, которые его создатели не предусматривали. Ни одна из этих атак не затрагивает инфраструктуру в традиционном смысле — они бьют по тому, что делает AI искусственным интеллектом: по данным и по способности модели интерпретировать их.

Особенно остро проблема проявляется с agentic-системами — автономными AI-агентами, которые не просто генерируют текст, а принимают решения, вызывают внешние API, работают с базами данных и выполняют цепочки действий. Если обычную языковую модель можно условно сравнить с консультантом, который даёт советы, то AI-агент — это сотрудник с доступом к корпоративным системам. Скомпрометировать такого сотрудника через prompt injection означает получить не просто неправильный ответ, а реальное воздействие на бизнес-процессы. И здесь инфраструктурная защита бессильна по определению: с точки зрения файрвола агент делает ровно то, что ему разрешено — отправляет запросы и получает ответы.

Хорошая новость в том, что индустрия не стоит на месте. За последние полтора года сформировалось несколько серьёзных рамочных документов, которые позволяют выстроить практичную систему защиты. OWASP выпустил два отдельных списка Top 10 уязвимостей — для LLM-приложений и для agentic-систем. Google представил SAIF — Secure AI Framework с картой рисков, которая помогает компаниям систематически оценивать угрозы. MITRE расширил свою легендарную базу ATT&CK до проекта ATLAS, каталогизирующего техники атак специфично на системы машинного обучения. Каждый из этих инструментов закрывает свою нишу: OWASP даёт чек-лист конкретных уязвимостей, SAIF — методологию оценки рисков, ATLAS — язык для описания атак и построения моделей угроз.

Плохая новость — единого стандарта по-прежнему не существует. Нет ни «ГОСТа», ни ISO, ни обязательного фреймворка, который бы предписывал компаниям конкретный набор мер. Каждая команда по-своему интерпретирует, что значит «безопасная AI-система», и часто эта интерпретация сводится к тому, что уже умеют делать штатные DevSecOps-инженеры. Это создаёт опасную иллюзию защищённости: формально все процедуры соблюдены, сканеры зелёные, доступы разграничены — но модель при этом уязвима к атакам, о которых команда безопасности может даже не подозревать.

Практический вывод для бизнеса выглядит так: AI-безопасность нужно рассматривать как отдельный контур, который накладывается поверх существующего DevSecOps, а не встраивается в него. Это означает отдельные компетенции в команде, отдельный набор инструментов для тестирования — red teaming моделей, проверка на prompt injection, аудит обучающих данных — и отдельную модель угроз, построенную с учётом специфики машинного обучения. Фреймворки OWASP, SAIF и ATLAS дают достаточную базу, чтобы не изобретать велосипед.

Индустрия AI-безопасности сейчас находится примерно там, где классическая кибербезопасность была в начале двухтысячных: угрозы реальны, инструменты появляются, но зрелых стандартов ещё нет. Компании, которые начнут выстраивать этот контур сейчас, получат не только техническое преимущество, но и конкурентное — потому что через два-три года регуляторы неизбежно придут с требованиями, и адаптироваться будет проще тем, кто к этому готов.