Shadow AI, или теневой ИИ, это использование сотрудниками AI-сервисов, моделей, агентов и интеграций, которые компания официально не разрешала или вообще не знает об их существовании.
Раньше Shadow IT означал условный Dropbox, который отдел маркетинга купил без согласования с ИТ. С Shadow AI проблема сложнее. Сотрудник может открыть ChatGPT в браузере, установить Cursor, подключить Claude к IDE, добавить AI-расширение в Chrome, вызвать модель через API или подключить неизвестный MCP-сервер.
Microsoft в 2026 году уже выделяет Shadow AI в отдельный класс discovery и ищет не только ChatGPT и Claude, но также API провайдеров моделей, MCP-серверы и локальные AI-агенты.
И здесь возникает важная проблема.
Обнаружить сам факт соединения с AI относительно просто. Понять, какие корпоративные данные туда ушли, значительно сложнее. А гарантированно увидеть все обращения к AI практически невозможно, если сотрудник может использовать неконтролируемое устройство и независимый канал связи.
Поэтому искать Shadow AI одним инструментом бессмысленно. Нужна многослойная система наблюдения.
1. DNS: самый дешёвый способ начать
Первое, что обычно делает служба безопасности, это смотрит DNS.
Берём логи корпоративных DNS-серверов, Secure DNS или SWG и ищем обращения к известным доменам:
chatgpt.comapi.openai.comclaude.aianthropic.comgemini.google.com
И сотням других AI-сервисов.
За несколько часов можно получить первоначальную карту: какие подразделения используют AI, с каких рабочих станций и насколько регулярно.
Но DNS показывает только намерение установить соединение с доменом.
Первое ограничение очевидно: каталог AI-доменов всегда отстаёт от рынка. Новые сервисы появляются ежедневно, а некоторые приложения вообще работают через CDN, облачные API и промежуточные backend-сервисы.
Второе ограничение: DNS-over-HTTPS.
RFC 8484 специально определяет передачу DNS-запросов внутри HTTPS. Поэтому локальный корпоративный DNS может вообще не увидеть запрос, если конечное устройство использует внешний DoH resolver.
Но здесь важно не делать слишком сильный вывод.
DoH ослепляет DNS-мониторинг, а не всю систему безопасности.
Сетевой шлюз, endpoint-agent или Secure Web Gateway всё ещё могут получить другие признаки соединения. Поэтому DNS хорош как дешёвый первый сенсор, но плох как единственный источник истины.
2. NGFW и TLS Inspection: начинаем видеть содержимое
Следующий уровень: NGFW или Secure Web Gateway.
Если организация контролирует рабочее место и может выполнять TLS inspection, ситуация становится гораздо интереснее.
Firewall фактически становится доверенным посредником: устанавливает TLS-соединение с внешним сервисом и отдельное соединение с клиентом. После этого средства App-ID, URL filtering и DLP могут анализировать уже расшифрованный трафик.
Именно здесь появляется возможность отличить просто открытый chatgpt.com от фактической отправки информации.
Современные решения уже умеют строить политики непосредственно вокруг GenAI. Например, Palo Alto Networks Enterprise DLP позволяет анализировать данные, отправляемые в ChatGPT через веб-интерфейс или API, и блокировать передачу чувствительной информации, не запрещая ChatGPT полностью. Под саму задачу теневого ИИ у них теперь отдельный продукт — AI Access Security: он обнаруживает GenAI-приложения и раздаёт им статусы, а разрешённым сервисам политики пишутся отдельно.
Microsoft в Generative AI Insights идёт ещё дальше и для поддерживаемых приложений заявляет видимость полного содержимого prompt, пользователя, URL и конкретной транзакции. Через TLS-инспекцию туда же попадают операции MCP, а поверх этого работает защита от prompt injection на уровне сети.
Получается уже намного более интересная картина:
Иванов → Chrome → ChatGPT → POST → фрагмент внутреннего документа.
Но TLS inspection не является волшебной таблеткой.
Есть Certificate Pinning. Приложение может ожидать конкретный сертификат сервера и отказаться работать, увидев сертификат, выпущенный корпоративным NGFW. Palo Alto прямо рекомендует исключать такой трафик из decryption policy.
Есть приложения и протоколы, которые шлюз просто не умеет корректно разбирать.
Есть производительность. Расшифровка, повторное шифрование и inspection требуют вычислительных ресурсов, поэтому capacity planning для firewall необходимо делать именно с учётом TLS inspection. Универсальной цифры вроде «производительность всегда падает в четыре раза» здесь нет.
И наконец, есть юридическая проблема. Тот же механизм позволяет технически расшифровывать не только ChatGPT, но и личную почту, медицинские и финансовые сайты. Поэтому нормальная архитектура обычно содержит категории исключений из расшифровки. Palo Alto, например, прямо приводит financial services и health-and-medicine как примеры трафика, который организация может сознательно не расшифровывать.
3. SWG/CASB: ищем уже не домены, а приложения
Следующий уровень эволюции: перестать самостоятельно вести Excel из тысяч AI-доменов.
Этим занимаются Secure Web Gateway и CASB-платформы.
Они пытаются ответить уже на другой вопрос:
Какими SaaS и AI-приложениями пользуется организация?
Например, Microsoft Global Secure Access сопоставляет обнаруженный трафик с каталогом Defender for Cloud Apps и показывает приложение, пользователей, количество транзакций, объём отправленных и полученных данных и risk score. Отдельный фильтр существует именно для Generative AI.
Cloudflare также имеет Shadow IT Discovery и каталог приложений, а CASB может дополнительно подключаться непосредственно к API SaaS-сервисов и искать проблемы уже внутри них. Отдельно у них появился AI-SPM — разбор настроек самих ИИ-сервисов вроде ChatGPT, Claude и Gemini: не «кто ходит», а «как настроено то, куда ходят».
Это существенно лучше простого DNS.
Но и здесь существует фундаментальное ограничение:
сенсор видит только тот трафик, который проходит через сенсор.
Если корпоративный ноутбук подключён через корпоративный SWG, видимость отличная.
Если сотрудник открыл тот же сервис на личном смартфоне через мобильную сеть, сетевой CASB компании этого события не увидит.
Поэтому задача Shadow AI постепенно перестаёт быть задачей периметра.
4. Endpoint DLP: смотрим не только куда идёт трафик, но и откуда берутся данные
Представим разработчика.
Он открывает внутренний GitLab, копирует 300 строк исходного кода, переключается в окно AI-инструмента и вставляет код в prompt.
Для сетевого сенсора это HTTPS-соединение с AI.
Для endpoint DLP это значительно более богатая последовательность:
корпоративный репозиторий → clipboard → процесс браузера → внешний web-сервис.
Современные DLP способны контролировать web-сервисы, буфер обмена, облачные хранилища, файлы и другие каналы передачи информации. Например, Solar Dozor заявляет контроль web-сервисов и буфера обмена, а Endpoint Agent позволяет отдельно задавать приложения, для которых необходимо перехватывать операции с clipboard. В версии 8.3, вышедшей в марте 2026 года, контроль буфера на Windows и Linux расширен до активного противодействия: копирование можно не только видеть, но и запрещать по содержимому.
InfoWatch Traffic Monitor также контролирует web-трафик, облачные хранилища и ряд endpoint-каналов передачи данных.
И вот здесь возникает принципиальное отличие.
Мы уже детектируем не использование AI, а потенциальную передачу корпоративной информации в AI.
С точки зрения бизнеса это намного полезнее.
Мне гораздо менее интересно, что сотрудник спросил ChatGPT:
«Как в Excel удалить пустые строки?»
И значительно интереснее другое событие:
«Сотрудник скопировал 40 Кбайт из документа с маркировкой Confidential и через пять секунд отправил данные неизвестному GenAI-сервису».
Но endpoint-контроль тоже имеет границы. Нужно поддерживать разные ОС, браузеры, приложения и среды разработки. Появляются виртуальные машины, контейнеры, удалённые рабочие столы и локальные AI-клиенты.
Поэтому утверждение «поставим DLP-agent и увидим всё» столь же опасно, как «посмотрим DNS и найдём весь Shadow AI».
5. API-ключи и репозитории: Shadow AI, который вообще не открывает браузер
Есть ещё один класс Shadow AI, который легко пропустить, если думать только о веб-сайтах.
Разработчик может написать:
curl → API модели
или встроить модель в собственный Python-скрипт.
Или поставить расширение IDE, которое само обращается к LLM API.
Или создать внутреннего агента, который вызывает модель каждые пять минут вообще без участия человека.
В этом случае нужно искать уже не только трафик, но и учётные данные AI-провайдеров.
Secret scanning становится ещё одним источником телеметрии.
GitGuardian, например, имеет отдельные детекторы OpenAI API Key, OpenAI Service Account, Claude API Key и Anthropic Admin Key.
GitHub Secret Scanning также поддерживает шаблоны секретов различных провайдеров, включая Anthropic.
Интересный SOC-кейс получается при корреляции:
в приватном репозитории появился неизвестный Claude API key → через час runner начал обращаться к Anthropic API → проект официально Claude не использует.
Вот это уже практически готовая находка Shadow AI.
6. Финансы: неожиданно хороший IDS для Shadow AI
Есть ещё один сенсор, про который специалисты ИБ часто забывают.
Бухгалтерия.
OpenAI, Anthropic, Cursor и десятки AI SaaS требуют оплаты. Поэтому корпоративные карты, reimbursement и авансовые отчёты иногда обнаруживают Shadow AI раньше SOC.
Особенно хорошо этот метод ловит не отдельного экспериментатора, а организованный Shadow AI.
Например, выясняется, что отдел маркетинга уже четыре месяца оплачивает десять лицензий AI-сервиса, который никогда не проходил ни закупку, ни security review.
С технической точки зрения никаких аномалий нет.
С управленческой точки зрения появился полноценный информационный сервис, обрабатывающий корпоративные данные.
Но финансовый мониторинг совершенно не видит бесплатные аккаунты, trial и подписки, оплаченные сотрудниками лично.
Поэтому это отличный дополнительный источник, но не механизм контроля.
7. NDR/NTA: полезный второй эшелон, но не основной детектор
Можно попробовать искать Shadow AI средствами NDR/NTA.
Например, PT Network Attack Discovery предназначен для глубокого анализа сетевого трафика, поиска аномальной активности и расследования атак; в версии 12.4, вышедшей в феврале 2026 года, он умеет и находить туннели в DNS, HTTP, SMTP и ICMP — а именно так данные и уводят, когда прямой путь закрыт.
Такая телеметрия может быть полезна при расследовании активности неизвестного процесса или необычных внешних соединений.
Но я бы не строил на NTA основную систему Shadow AI Discovery.
Причина проста.
Утечка через AI совершенно не обязана выглядеть как большая утечка.
Пароль администратора занимает двадцать символов.
Фрагмент исходного кода занимает несколько килобайт.
Финансовый прогноз может помещаться в один prompt.
По объёму трафика это может выглядеть абсолютно нормально.
Поэтому NDR хорошо отвечает на вопрос:
«Что необычного происходит в сети?»
Но Shadow AI требует другого вопроса:
«Какой пользователь или процесс передаёт какие корпоративные данные какому AI-сервису?»
Это разные задачи.
8. В 2026 году появилась ещё одна проблема: Shadow AI Agents
До недавнего времени мы в основном искали человека, который открыл нейросеть.
Теперь искать приходится ещё и программы.
AI-agent может самостоятельно обращаться к модели, MCP-серверу, GitHub, CRM, почте и внешним API.
Человек при этом вообще ничего не копирует.
У Microsoft это уже не эксперимент: в мае 2026 года Agent 365 стал общедоступным, а в админ-центре Microsoft 365 появился отдельный раздел Shadow AI. Локальных агентов на рабочих станциях находят Defender и Intune — к июню 2026 года список расширяется до восемнадцати типов, включая GitHub Copilot CLI и Claude Code. Зарегистрированные агенты считаются managed, остальные — shadow.
Там же в публичном preview появилась карта связей: агент — устройство — подключённые MCP-серверы — учётные записи — доступные облачные ресурсы. То есть вопрос уже не «запущен ли неизвестный агент», а «до каких корпоративных данных он дотягивается».
Это довольно хорошо показывает, куда движется рынок.
Следующая версия Shadow AI будет выглядеть не так:
«Сотрудник использовал запрещённый чат».
А так:
«Неизвестный процесс на ноутбуке сотрудника получил доступ к корпоративному GitHub, вызвал неизвестный MCP server и передал информацию внешней модели».
DNS-списком такую задачу уже не решить.
Как я бы строил обнаружение Shadow AI
Я бы вообще не начинал с вопроса «как заблокировать ChatGPT».
Я бы построил четыре независимых слоя наблюдения.
Первый слой: Discovery.
Какие AI-приложения, API, модели, MCP-серверы и AI-агенты вообще существуют в инфраструктуре?
Источники: DNS, proxy/SWG, NGFW, endpoint и SaaS discovery.
Второй слой: Attribution.
Кто этим пользуется?
Нужно связать событие с пользователем, устройством и желательно процессом.
Не:
192.168.7.42 → api.anthropic.com
а:
ivanov@company.ru → MacBook-142 → Cursor → Anthropic API.
Третий слой: Data Context.
Что именно передаётся?
Вот здесь появляются DLP, data classification, clipboard telemetry и анализ содержимого запросов.
Событие:
Ivanov использовал Claude
почти бесполезно.
Событие:
Ivanov → Claude → 37 совпадений с исходным кодом проекта X
уже представляет ценность для SOC.
Четвёртый слой: Governance.
После discovery сервис должен получить статус:
SanctionedToleratedRestrictedUnsanctionedUnknown
И только после этого имеет смысл решать, что делать: разрешать, ограничивать передачу определённых классов данных или полностью блокировать.
Именно к такой модели постепенно приходят современные AI-security решения: отдельно обнаруживать AI-приложения и отдельно применять DLP-политики к данным, отправляемым в них.
Главная ошибка: пытаться победить Shadow AI запретом
Можно заблокировать chatgpt.com.
Пользователь найдёт другой AI-сервис.
Можно заблокировать десятки AI-сервисов.
Пользователь установит расширение.
Можно контролировать расширения.
Разработчик вызовет модель через API.
Можно закрыть API.
Сотрудник достанет личный телефон.
Поэтому стопроцентное обнаружение всех случаев Shadow AI возможно только при одном фантастическом условии: компания полностью контролирует устройства, приложения, идентификацию пользователей, доступ к корпоративным данным и все каналы связи.
В реальной инфраструктуре такой абсолютной видимости почти никогда нет.
Зато можно решить гораздо более важную задачу.
Не обязательно видеть каждый запрос к искусственному интеллекту. Нужно с высокой вероятностью обнаруживать ситуации, когда ценные корпоративные данные покидают контролируемую среду и попадают в неконтролируемую AI-систему.
И тогда архитектура Shadow AI Detection становится довольно понятной:
Network visibility + Endpoint telemetry + Identity + Data classification + SaaS discovery + Secret scanning + финансовые данные → SIEM → единая карта использования AI.
Вот это уже не запрет ChatGPT.
Это полноценный AI Asset Management и AI Security Posture Management для организации.