Компании инвестируют в периметровую защиту, DLP-системы, обучение сотрудников правилам работы с данными. А потом маркетолог устанавливает браузерное расширение с ИИ-ассистентом, вставляет в него фрагмент клиентской базы для анализа — и данные уходят наружу. Без взлома, без фишинга, без злого умысла. По данным аналитиков «Информзащиты», опубликованным CNews 17 июля 2026 года, уже 20% организаций, столкнувшихся с утечками, связали произошедшее хотя бы частично с применением ИИ-инструментов вне утверждённых процессов. Год назад этот показатель составлял около 12%. За двенадцать месяцев сценарии с теневым ИИ перешли из редких в типовые.
Что такое Shadow AI и почему это не про злой умысел
Теневой ИИ — это несанкционированное использование публичных нейросетей и ИИ-инструментов для выполнения рабочих задач: без согласования с ИТ-службой, без оценки ИБ-рисков, вне утверждённых корпоративных процессов.
Важно понимать: в подавляющем большинстве случаев это не саботаж и не кража. Сотрудник хочет сделать работу быстрее. Перевести договор, подготовить резюме встречи, проанализировать клиентское обращение, написать фрагмент кода. Публичный чат-бот справляется с этим за секунды — и не требует заявок в ИТ-департамент.
По данным опросов российского рынка, около 26% сотрудников регулярно используют нейросети для рабочих задач, ещё порядка 35% делают это периодически. При этом в большинстве организаций применение ИИ происходит спонтанно и бесконтрольно. Эти цифры стоит воспринимать как рыночную оценку порядка величин, а не как точную статистику — методологии опросов различаются. Однако общий вектор подтверждается независимо: использование ИИ среди сотрудников растёт быстрее, чем компании успевают выработать политики его контроля.
Последствия этого разрыва уже измеримы. По наблюдениям международных аналитиков, теневой ИИ вошёл в тройку наиболее распространённых типов непреднамеренных инсайдерских инцидентов в DLP-данных, а число таких случаев за последний год выросло кратно. Российская практика «Информзащиты» подтверждает этот тренд.
Четыре канала утечки: как именно уходят данные
Аналитика инцидентов «Информзащиты» за 2025–2026 годы позволяет детально описать, через какие именно каналы данные покидают корпоративный контур. Картина оказалась устойчивой и воспроизводимой.
Веб-интерфейсы публичных ИИ-сервисов — около 42% инцидентов.
Самый распространённый сценарий. Сотрудник открывает публичный чат-бот в браузере и загружает рабочие материалы: договоры, фрагменты исходного кода, внутреннюю переписку, клиентские обращения, техническую документацию. Цели — перевод, анализ, подготовка ответа, генерация резюме. С точки зрения пользователя это выглядит как обычная работа в браузере. С точки зрения ИБ — это исходящий поток корпоративных данных во внешнюю систему без каких-либо меток, логов или контроля содержания.
Принципиальная проблема в том, что такой трафик неотличим от обычного обращения к SaaS-сервису: домен легитимен, TLS-соединение корректно, сигнатур вредоносной активности нет. Для SIEM и прокси это выглядит как обычный запрос к облачному приложению — и именно поэтому классические средства защиты его не замечают.
Браузерные расширения и ИИ-помощники — около 24% инцидентов
Второй по частоте канал устроен иначе и в ряде случаев опаснее. ИИ-расширения для браузера получают доступ не только к тому, что пользователь явно вставляет в промпт, — они могут читать содержимое открытых вкладок, историю сессий и другие данные браузера в фоновом режиме, без активных действий пользователя.
Данные «Информзащиты» фиксируют тревожную картину по таким расширениям: они на 60% чаще содержат известные уязвимости по сравнению с обычными браузерными дополнениями, в три раза чаще запрашивают доступ к сессионным cookie и в шесть раз чаще изменяют набор запрошенных разрешений уже после установки. Последнее особенно важно: пользователь при установке видел один набор разрешений — а через несколько дней расширение тихо расширило свои права.
Самостоятельно подключённые API и SDK — около 19% инцидентов
Этот канал характерен прежде всего для ИТ-подразделений и команд разработки. Разработчик подключает библиотеку для работы с ИИ-моделью, прописывает API-ключ в конфигурационном файле или переменной окружения, интегрирует внешний ИИ-сервис во внутренний инструмент — и делает это без согласования с ИБ, потому что задача кажется технической, а не безопасностной.
Проблема усугубляется хранением учётных данных. По данным «Информзащиты», почти у 30% организаций, использующих ИИ-сервисы, обнаруживается хотя бы один API-ключ, размещённый в небезопасном месте: конфигурационные файлы, переменные окружения рабочих станций, тестовые скрипты, репозитории. В отдельных случаях ключи остаются в истории Git даже после удаления из актуальной версии кода. Получив такой ключ, атакующий может не только генерировать запросы за счёт компании, но и получить доступ к подключённым RAG-хранилищам или интеграциям с внутренними базами данных.
ИИ-ассистенты для разработки — около 15% инцидентов
Четвёртый канал — инструменты типа GitHub Copilot и их аналоги, встроенные в среды разработки. Они анализируют код не изолированно, а вместе с контекстом: открытыми файлами, конфигурациями, переменными окружения. В момент, когда разработчик обращается к ассистенту за помощью с конкретной функцией, в запрос могут автоматически попасть фрагменты, содержащие чувствительные данные — ключи, токены, бизнес-логику, данные клиентов.
Почему DLP и SIEM этого не видят
Классические средства защиты от утечек строились под другую модель угрозы: сотрудник копирует файл на флешку, отправляет письмо на внешний адрес, загружает документ на личный облачный диск. DLP умеет это замечать — по сигнатурам файлов, ключевым словам, паттернам поведения.
Shadow AI создаёт принципиально иную ситуацию. Когда сотрудник вставляет текст в публичный чат-бот, это выглядит как обычный HTTPS-запрос к легитимному SaaS-сервису. Домен — известный и разрешённый. Протокол — корректный. Сигнатур вредоносной активности — нет. Содержание передаваемых данных DLP не видит, потому что трафик зашифрован, а инспекция на прикладном уровне либо не настроена, либо не покрывает этот тип соединений.
Следствие — задержка обнаружения. По данным «Информзащиты», инциденты, связанные с теневым ИИ, обнаруживаются позже, чем классические утечки, и в среднем обходятся дороже: дополнительный ущерб оценивается примерно в $670 тыс. по сравнению с инцидентами без участия ИИ. Это объяснимо: чем позже обнаружена утечка, тем шире успел разойтись скомпрометированный массив данных.
Дополнительный фактор — фрагментация инструментов. По наблюдениям аналитиков, один пользователь одновременно работает в среднем с четырьмя-семью ИИ-сервисами, каждый со своей моделью аутентификации и логирования. Для ИБ-подразделения это означает необходимость контролировать несколько разнородных схем передачи данных — вместо одного унифицированного канала.
Наконец, около 30% компаний, по данным опросов и аудитов «Информзащиты», вообще не имеют инвентаризации используемых ИИ-сервисов. Служба ИБ видит только официально внедрённые решения — остальное остаётся в слепой зоне. Когда инцидент всё же происходит, расследование может пойти по ложному следу: утечка расследуется как обычная передача данных в облако, а реальная причина — конкретный ИИ-сервис, его владелец и перечень переданных данных — остаётся неизвестной.
Кто в зоне риска: отраслевой разрез
По данным «Информзащиты», Shadow AI не является равномерно распределённой угрозой — картина по отраслям выраженно неравномерная.
- Наибольшая концентрация инцидентов фиксируется в ИТ и разработке программного обеспечения — около 31% случаев с участием теневого ИИ приходится на этот сегмент. Это объяснимо: разработчики технически грамотны, быстро находят и подключают новые инструменты, и воспринимают интеграцию внешнего API как рутинную задачу, а не как потенциальный инцидент безопасности.
- На втором месте финансовый сектор — около 22%. Здесь основной риск связан с передачей фрагментов клиентской и аналитической информации во внешние сервисы: аналитики и менеджеры используют ИИ для обработки отчётов, подготовки презентаций, анализа данных.
- Промышленность занимает третью строчку с долей около 18%: сотрудники загружают во внешние ИИ-системы техническую документацию, инструкции и проектные материалы. Ритейл и электронная коммерция — около 16%, преимущественно через работу с клиентскими обращениями и маркетинговыми данными. Профессиональные услуги — консалтинг, юридическое сопровождение — около 13%, где ключевым фактором становится загрузка клиентских документов и материалов рабочих проектов.
Важное наблюдение из практики аналитиков: полный запрет публичных ИИ-сервисов, как правило, не снижает активность сотрудников, а переносит её в менее контролируемые каналы — личные устройства, сторонние учётные записи, альтернативные расширения. Другой распространённый сценарий — формальное согласование одного корпоративного инструмента без учёта того, что подразделения продолжают параллельно использовать десятки альтернатив.
Что делать: пять практических шагов
Рекомендации наших экспертов и общая практика управления этим классом угроз сводятся к нескольким конкретным направлениям.
- Инвентаризация прежде всего. Невозможно контролировать то, о существовании чего не знаешь. Первый шаг — выгрузка доменов из прокси-логов, анализ DNS-запросов, поиск API-ключей в Git-репозиториях, конфигурационных файлах и на рабочих станциях. Только после этого появляется реальная картина того, какие ИИ-сервисы фактически используются в организации.
- Классификация данных с явным запретом на передачу во внешние ИИ. Сотрудники нарушают правила не потому, что хотят навредить, — а потому что правила либо отсутствуют, либо сформулированы абстрактно. Конкретный перечень категорий данных, которые запрещено вставлять в публичные ИИ-сервисы, должен быть задокументирован и доведён до каждого сотрудника — с примерами, а не только с формулировками.
- Контроль браузерных расширений. Ограничение установки расширений с избыточными разрешениями — в первую очередь доступом к содержимому всех сайтов, сессионным cookie и истории браузера. Аудит уже установленных расширений на корпоративных устройствах. Регулярная проверка изменений в наборе запрошенных разрешений.
- Корпоративная альтернатива вместо запрета. Запрет без альтернативы не работает — это подтверждается практикой. Если компания хочет снизить использование публичных ИИ-сервисов, ей нужно предложить легальный корпоративный инструмент с понятными ограничениями на обработку данных. Для корпоративных ИИ-сервисов необходимо применять централизованную аутентификацию, журналирование и разграничение доступа.
Включить Shadow AI в сценарии мониторинга и реагирования. Без этого шага расследование инцидента с высокой вероятностью пройдёт мимо реальной причины. Служба ИБ должна знать, какие ИИ-сервисы существуют в организации, кто ими пользуется и какие данные через них проходят — иначе при утечке будет расследоваться симптом, а не источник.
Вместо заключения
Shadow AI формирует новый класс угроз, который не вписывается в привычную модель «внешний злоумышленник против внешнего периметра». Данные уходят через легитимные инструменты, легитимные соединения, без каких-либо признаков атаки — и именно поэтому классическая защита их не останавливает. Переход этого типа инцидентов из разряда редких в типовые означает, что контроль над тем, куда уходят данные через разрешённые инструменты, становится такой же базовой задачей ИБ, как контроль над тем, кто имеет к ним доступ.
