Ранее я рассказала об ИИ как возможном орудии атаки. Но есть и зеркальный риск: сами ИИ-системы становятся новой мишенью. Рассмотрим, где возникают уязвимости и как снижать эти риски.

Чем активнее компании внедряют искусственный интеллект, тем заметнее разрыв между скоростью внедрения и готовностью защищать новые системы. Рынок инструментов AI Security пока находится на ранней стадии: отдельные решения уже появляются, но единых критериев эффективности и устоявшихся практик еще нет. Ситуация напоминает раннюю историю AppSec. В конце 2010-х многим казалось, что достаточно защищать периметр и сеть, а код, библиотеки и pipeline можно оставить разработчикам. Довольно быстро выяснилось, что этого недостаточно. С ИИ происходит похожая трансформация: безопасность смещается от защиты инфраструктуры к контролю данных, моделей, агентов и всего процесса создания и использования ИИ-систем.

Практическое следствие этого разрыва — потеря видимости. Не каждый руководитель по безопасности или архитектор может быстро ответить, где именно внутри компании используется ИИ, какие модели подключены и к каким данным они имеют доступ. Теневые сервисы сложно обнаруживать, число команд, работающих с моделями, растет, а способы тестирования пока не унифицированы. Управлять безопасностью того, чего компания не видит, невозможно. В итоге отсутствие контроля начинает тормозить уже само внедрение ИИ.

Ситуация постепенно меняется. В России и за рубежом появляются AI gateway, guardrails, средства контроля данных, инструменты red teaming и оценки моделей. Но пока это отдельные классы решений, которые не складываются в единый зрелый процесс. Классическая защита сети остается необходимой, но она не отвечает на вопросы о происхождении модели, безопасности данных, поведении агента и допустимости его действий. Пока этот разрыв не закрыт, ИИ-система сама может стать точкой входа для атаки.

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

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

Второй вектор затрагивает AI Supply Chain. В классической разработке уже существуют SCA, SBOM и практики проверки сторонних компонентов. С готовой ИИ-моделью все сложнее. Компании нужно понимать, откуда она получена, кто ее обновлял, какие зависимости входят в поставку и не изменилось ли ее поведение после обновления. Базовые способы проверки файлов и окружения есть, но поставить оценку самой модели на поток пока сложно. Поэтому безопасность цепочки поставок ИИ становится отдельным классом задач, а не расширением обычной проверки библиотек.

Третий вектор — prompt injection. Он встречается в чат-ботах, ассистентах, корпоративном поиске и агентных системах. Инструкция может прийти не только от пользователя, но и из документа, веб-страницы или изображения, которое модель обрабатывает как часть контекста. Средства обнаружения и фильтрации таких атак уже существуют, хотя и работают неидеально. Но сложность защиты определяется не только самим запросом. Главное — какие права получила модель и что она может сделать после обработки вредоносной инструкции. Ошибка чат-бота заканчивается плохим ответом, а ошибка агента с доступом к почте, коду или корпоративным системам уже может стать полноценным инцидентом.

Первый уровень защиты закладывается не в фильтр перед моделью, а в архитектуру системы. Еще до внедрения нужно определить, с какими данными работает ИИ, какие инструменты он может вызывать, где требуется подтверждение человека и как фиксируются его действия. Исправлять эти ограничения после запуска обычно дороже и сложнее.

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

Специальные средства защиты тоже необходимы, и их разработка уже идет как у российских вендоров, так и в open source. Но рынок пока фрагментирован: один продукт контролирует запросы, другой ищет утечки, третий тестирует модель. Поэтому рассчитывать на одну коробку, которая закроет весь класс рисков, пока рано.

Минимальный практический шаг для компании — получить видимость собственного ИИ-ландшафта. Нужно понимать, какие публичные и внутренние сервисы используются, какие данные туда передаются, кто владеет системой и какие действия разрешены модели или агенту. Для этого придется честно признать, что сотрудники уже пользуются открытыми LLM, даже если формально компания их не внедряла. После этого можно разделять допустимые и рискованные сценарии, а не запрещать все подряд.

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