В AI-приложениях почти каждая третья уязвимость является высокорисковой

За второй год наблюдений эта пропорция не изменилась, что исключает версию о временном эффекте раннего внедрения технологии. Одновременно медианный срок устранения серьезных находок увеличился с 19 дней в 2025 году до 36 дней в 2026-м.

У AI-систем одновременно работают два слоя риска: базовое веб- или API-приложение сохраняет привычные проблемы с аутентификацией, авторизацией, инъекциями, доступом к секретам и обработкой пользовательского ввода; поверх них появляются сценарии, связанные с поведением модели и ее интеграциями. Prompt injection, небезопасная обработка ответа LLM, утечка системного промпта, отравление данных, ошибки в RAG-контурах, нарушения в векторных хранилищах и отказ в обслуживании на уровне модели формируют широкое поле для атак. Разработчики часто подключают модель к корпоративным данным, API, CRM, базе знаний или инструментам автоматизации, чтобы получить полезный прикладной результат. Вместе с доступом модель получает возможность влиять на процессы, а ошибка в разграничении прав или в логике вызовов превращает ответ чат-бота в точку входа во внутренние системы.

Проверить такую архитектуру стандартным сканером непросто, поскольку многие уязвимости проявляются только в цепочке событий. Для успешного prompt injection может понадобиться несколько сообщений, специально подготовленный документ в базе знаний, определенная роль пользователя и доступ агента к внешнему сервису. Избыточная агентность зависит от сочетания системного промпта, доступных инструментов, прав учетной записи и правил оркестратора. Участники исследования подтверждают границы автоматизации: 78% команд обнаруживали, что автоматические средства пропускали критичные уязвимости. На этом фоне готовность полностью доверить пентесты автономным инструментам за год сократилась с 29% до 9%, а 47% организаций выбрали гибридную модель, в которой автоматические проверки применяются к некритичным активам, а критичные системы проверяют специалисты.

Разбивка инцидентов по векторам атак показывает, что у AI-продуктов нет единственной доминирующей точки отказа. Среди организаций, столкнувшихся с инцидентами, в 44% случаев причиной стал shadow AI: сотрудники использовали несанкционированные внешние сервисы, и чувствительные данные оказались за пределами контролируемого контура. По 41% пришлось на отравление данных и моделей и на небезопасную обработку ответов LLM. Уязвимости цепочки поставок указали в 35% случаев, prompt injection – в 34%, ошибки LLM и слабости векторных баз и эмбеддингов – по 32%. Далее следуют избыточная агентность и утечка системных промптов – по 24%, дезинформация – 20%, неограниченное потребление вычислительных ресурсов – 15%. Такая картина требует проверять не только модель, но и источники данных, плагины, цепочки поставки, права доступа, журналы действий и правила, по которым агент вызывает инструменты.

Отраслевой разрез отчета не ранжирует сектора по числу высокорисковых уязвимостей, поэтому называть одну сферу наиболее подверженной было бы некорректно. В выборке 2026 года, включившей 455 ИБ-специалистов из компаний с численностью от 500 сотрудников, разработка ПО представлена 27% респондентов, здравоохранение – 21%, финансовый и страховой сектор – 14%, информационные сервисы – 10%, прочие отрасли – 27%. Для разработки ПО приоритетны риски генерации кода и доступа модели к репозиториям, конвейерам CI/CD и средам разработки. В здравоохранении цена ошибки связана с медицинскими данными и интеграциями с профильными информационными системами; в финансовом секторе – с платежной информацией, решениями, затрагивающими клиентов, и операциями с повышенными требованиями к контролю доступа. Информационные сервисы чаще используют AI для обработки массивов пользовательских запросов и корпоративного контента, поэтому нуждаются в контроле источников данных и фильтрации выдачи.

 Сложность состоит не только в поиске уязвимости, но и в ее устранении. В 2026 году организации закрывали 38,4% высокорисковых находок в AI/LLM-приложениях против 21,1% годом ранее, однако это все равно самый низкий показатель среди типов тестирования. Для desktop-приложений уровень устранения составил 40,2%, для веб-приложений – 73,7%, для API – 77,3%. Исправление AI-уязвимостей требует совместной работы ИБ, разработки, архитекторов, владельцев данных и иногда поставщика базовой модели. Управленческий контур нередко не успевает за этой связностью: 57% руководителей считают, что компания стабильно соблюдает SLA на устранение уязвимостей, тогда как среди практиков с этим согласны только 15%. При разрыве в 42 процентных пункта бизнес может недооценивать объем незакрытого риска и откладывать необходимые изменения в процессах.

Снизить эту экспозицию можно через отдельную программу безопасности AI, встроенную в жизненный цикл продукта. Эксперты «Информзащиты» рекомендуют начать с инвентаризации моделей, агентов, подключенных инструментов, внешних сервисов и источников данных, а затем установить обязательные контрольные точки перед вводом каждого AI-решения в эксплуатацию. Для моделей, работающих с внутренними данными или способных выполнять действия от имени пользователя, необходимы ручной пентест и red teaming с проверкой многошаговых атак, prompt injection, разграничения прав, сценариев утечки через RAG и последствий небезопасного вызова инструментов. Автоматизация сохраняет ценность для регулярных проверок, инвентаризации и поиска повторяемых ошибок, но не заменяет экспертную оценку бизнес-логики и архитектуры. Общие для ИБ, разработки и руководства SLA, понятный порядок эскалации, контроль shadow AI и приоритизация устранения по реальному влиянию на данные и процессы позволяют сократить период, в течение которого высокая уязвимость остается доступной для эксплуатации.