Shadow AI начинается не с NGFW, а с вопроса к бизнесу

1. Одно слово, пять разных явлений

Мы говорим «ИИ» и подразумеваем разное. Один слушатель представляет бухгалтера, который вставил таблицу в ChatGPT. Другой — разработчика, который запустил трёх агентов с доступом к GitLab и боевой базе. Это разные угрозы, разные средства контроля и разные владельцы риска. Пока термины не разведены, обсуждение заканчивается фразой «ИИ опасен», с которой нечего делать.

Я раскладываю Shadow AI на пять уровней — по тому, кто действует и что может утечь.

Граница проходит после второго уровня. На первых двух данные отправляет человек, и каждая отправка начинается с его решения. Начиная с третьего данные отправляет программа: расширение читает открытую страницу, скрипт — базу, агент — всё, к чему ему выдали права. В 2023 году инженеры Samsung за двадцать дней трижды вставили в ChatGPT закрытые исходники и стенограмму совещания — это первый уровень, и компания ответила запретом всех генеративных сервисов на рабочих устройствах. Агент пятого уровня делает то же самое сам, без человека, и круглосуточно.

И ChatGPT на первом уровне — только самый заметный. В моей таблице «ИИ-сервисы в интернете и их доступность из России» больше сотни сервисов: чаты, генераторы видео и презентаций, расшифровка встреч, помощники для кода. Для каждого указано, как зарегистрироваться и чем платить. Любой из них сотрудник открывает в браузере за пять минут, а расшифровка встречи уносит с собой всё, что на ней говорили.

Подробнее про устройство агента и словарь терминов — в статье «Из чего состоит ИИ-агент: словарь для CISO», про контроль его действий — в отдельной статье.

2. Чем это грозит бизнесу

«Утечка в ИИ» звучит как одна угроза. На деле их четыре, и стоят они по-разному.

Данные попали в обучение. Этого боятся чаще всего, но всё решает тариф. OpenAI не обучает модели на данных из ChatGPT Business (до августа 2025 года — Team), Enterprise и API, если клиент сам этого не включил; на бесплатном и личном платном тарифе может обучать, пока пользователь не отключит. Сотрудник с личным аккаунтом попадает во второй случай.

Данные сохранились у провайдера. «Не обучаем» не значит «не храним». Переписка лежит в журналах для контроля злоупотреблений, и срок её хранения определяет не ваша компания. В мае 2025 года суд по иску New York Times обязал OpenAI сохранять все журналы ChatGPT, включая удалённые пользователями. Требование сняли только 26 сентября 2025 года, а уже сохранённое осталось у OpenAI. Сотрудник, который в те месяцы удалил чат с финансовым прогнозом, ничего не удалил.

Нарушен закон. Персональные данные клиентов, вставленные в зарубежный сервис, — это трансграничная передача по 152-ФЗ, о которой оператор обязан заранее уведомить Роскомнадзор. Сотрудник может об этом не знать, а отвечать будет компания.

Для государственных информационных систем с 1 марта 2026 года действует прямой запрет: приказ ФСТЭК № 117 (пункт 60) не допускает передачу разработчику модели информации ограниченного доступа из системы, а пункт 61 требует определить допустимые тематики запросов к ИИ-сервисам и критерии недостоверных ответов. Вставить закрытые данные такой системы в публичный чат — уже нарушение требований: здесь риск за бизнес оценил регулятор.

Агент сделал лишнее. Это уже не утечка, а действие: агент с правами на CRM удалил записи, отправил письмо клиенту или выполнил команду, которую ему подсунули через документ. Об этом подробно — в статье про контроль действий агентов.

Есть и оценка в деньгах. В отчёте IBM Cost of a Data Breach 2025 (Ponemon, 600 организаций, утечки с марта 2024 по февраль 2025) каждая пятая организация столкнулась с утечкой через Shadow AI. У компаний с высоким уровнем теневого ИИ утечка обходилась в среднем на 670 тысяч долларов дороже. Персональные данные клиентов в таких инцидентах утекали в 65% случаев против 53% в среднем, интеллектуальная собственность — в 40% против 33%. Политика управления ИИ была только у 37% пострадавших организаций, остальные её не имели или ещё писали.

3. Пусть решает бизнес

Вернусь к вопросу CISO. Он прав в главном: решать, приемлем ли риск, должна не служба безопасности.

Если данные о выручке окажутся у провайдера модели, одна компания этого не заметит, а у другой сорвётся размещение облигаций. Исходный код для интегратора — рабочий инструмент, для разработчика продукта — главный актив. ИБ не знает этого лучше владельца данных и не должна угадывать.

Задача ИБ другая: прийти к бизнесу не со словами «ИИ опасен», а с тремя конкретными вопросами.

1. Какие данные для нас критичны: клиентская база, финансы до публикации, код, договоры, переписка с регулятором?
2. Что произойдёт, если каждый из этих наборов окажется у провайдера модели — штраф, потеря сделки, ничего?
3. Что дороже: запретить и потерять скорость или разрешить с контролем и платить за контроль?

После этих ответов у каждого найденного сервиса появляется статус:

• разрешён — компания сама выдала сервис, настроила его и отвечает за него;
• терпим — риск сервиса компании не нравится, но она им пользуется, потому что замены пока нет или запрет обойдётся дороже;
• ограничен — разрешён только для определённых данных или отделов;
• запрещён — блокируется.

Честно о «терпим»: чаще всего за ним стоит не решение, а то, что до сервиса не дошли руки. Его заметили, никто им не занялся, и он остался работать. Это не принятый риск, а риск, который никто не принимал. Отличить одно от другого просто: у настоящего «терпим» есть владелец, причина и дата пересмотра. Если их нет, честнее записать сервис в реестр как «неизвестен» — тогда видно, что работа не сделана.

За каждым статусом стоит решение конкретного человека, а не настроение службы безопасности. Если бизнес говорит «выручка нас не волнует, код волнует», это не поражение ИБ, а техническое задание.

Оформить этот разговор помогают два документа. В NIST AI RMF (январь 2023 года) функция Govern распределяет ответственность за риски ИИ, а функция Map требует определить и записать, какой риск организация готова принять. ISO/IEC 42001 (декабрь 2023 года; в России с 1 января 2025 года действует как ГОСТ Р ИСО/МЭК 42001-2024) описывает систему менеджмента ИИ, по которой компанию можно сертифицировать, — с оценкой рисков и назначенными ролями. Ни один из них не ответит на три вопроса за владельца данных. Зато оба дают форму, в которой ответы записываются и по которой их потом проверит аудитор.

4. Спросить людей

Эльман Бейбутов, директор по развитию бизнеса UserGate и один из участников дискуссии, предложил способ, которому не нужен ни один сенсор: объявить внутренний конкурс на лучшее применение ИИ. Люди сами расскажут, кто, чем и для чего пользуется, и картина сложится быстрее, чем по журналам DNS.

За рубежом похожий приём называют AI amnesty. Компания на ограниченный срок обещает не наказывать за неразрешённый ИИ и просит рассказать, какими инструментами, для каких задач и с какими данными человек работает. По данным BCG за 2025 год, 54% из более чем 10 тысяч опрошенных сотрудников готовы пользоваться неразрешёнными ИИ-инструментами, если компания не даёт подходящих. Рассказать людям есть что.

Но есть и обратная сторона. Исследователи USC Marshall в 2026 году опросили 604 сотрудника, которые пользуются ИИ каждый день. 80% считали, что их приёмы пригодились бы команде, и почти треть всё равно скрывала их от коллег и руководителя. Причины три: боятся выглядеть менее компетентными, боятся дополнительной нагрузки или замены, не хотят отдавать то, что отличает их от других. Сотрудники с низким доверием к компании скрывали в четыре раза чаще.

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

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

5. NGFW видит многое, но не всё

NGFW находит приложение по App-ID, пользователя через привязку к учётной записи, объём, а с расшифровкой TLS — и содержимое запроса. Российские производители идут туда же: Solar webProxy, по заявлению «Солара», сам распознаёт ИИ-сервисы и в браузерном трафике, и в вызовах API.

Чего шлюз не видит:

• модель, запущенную локально на ноутбуке: трафика наружу нет вовсе;
• агента, который ходит только во внутренние системы;
• личный телефон в мобильной сети;
• приложения с привязкой сертификата, которые приходится исключать из расшифровки.

Здесь нужны средства на хосте: инвентарь установленного ПО, EDR, DLP с контролем буфера обмена. На хосте видно не адрес, а процесс — Cursor, ollama, claude — и то, что он читал перед отправкой запроса. Какие слои нужны и что каждый пропускает, разобрано в первой статье, разделы 4 и 8.

CASB и DLP тоже закрывают не всё. CASB видит облачные сервисы из своего каталога и подключённые к нему по API; ИИ-функция внутри уже разрешённого SaaS для него — обычная работа сервиса, пока поставщик CASB не выделил её отдельно. DLP находит в отправляемом то, что умеет распознать: номера карт, паспортные данные, метки грифа. Пересказ закрытого документа своими словами, выжимка из финансовой модели или код без меток проходят мимо. А действия агента не видит ни один из них: стёртые записи в CRM — не утечка данных, а команда, на которую у агента были права.

Поэтому слои не заменяют друг друга. Шлюз видит сеть, хост — процесс, CASB — облако, DLP — содержимое, и каждый пропускает то, что видят остальные.

За последние два года к этим слоям добавился ещё один класс — AI Security Posture Management, AI-SPM. Он смотрит не на трафик и не на пользователя, а на сами ИИ-нагрузки в облаке компании: какие модели и агенты развёрнуты, к каким данным у них доступ, открыт ли наружу их адрес, где лежат ключи. Microsoft, например, встроил AI-SPM в Defender for Cloud: тот сам находит нагрузки в Azure OpenAI, Amazon Bedrock и Google Vertex AI и собирает из них перечень компонентов ИИ-приложения (AI BOM). Но у класса есть граница: AI-SPM охраняет то, что компания построила сама. Бухгалтера с личным ChatGPT он не увидит, расширение в браузере тоже. Это ответ на ту часть четвёртого и пятого уровней, которая живёт в облаке компании, а не на первые три.

AI-подготовка: что делать уже сейчас

AI-подготовку инфраструктуры надо начинать всем и сейчас, а не когда случится первый инцидент. Готовить её к тому, чтобы контролировать использование ИИ, а не к тому, чтобы его запретить. Вот что я бы сделал за ближайший квартал.

1. Договориться о терминах. Внести пять уровней из таблицы выше в регламент, чтобы бизнес и ИБ, говоря «ИИ», имели в виду одно и то же.
2. Отнести бизнесу три вопроса про критичные данные и получить ответы с подписью владельца.
3. Включить на NGFW категорию генеративного ИИ и посмотреть отчёт за две недели, ничего не блокируя. Так появится точка отсчёта.
4. Расшифровать TLS хотя бы для ИИ-категории на управляемых устройствах — иначе видно факт обращения, но не содержимое.
5. Запустить сканирование секретов в репозиториях и CI на ключи OpenAI, Anthropic и других провайдеров.
6. Проверить, видят ли EDR и инвентаризация ПО ИИ-клиенты: IDE-расширения, CLI-агенты, локальные модели.
7. Объявить конкурс или амнистию и сравнить ответы людей с отчётом NGFW.
8. Составить перечень своих ИИ-нагрузок, если компания сама разворачивает модели и агентов в облаке: где они, к каким данным и с какими правами. Это работа для AI-SPM, а не для NGFW.
9. Дать людям разрешённый инструмент под самые частые задачи из конкурса — иначе они вернутся к теневому.

Шаблон реестра для учёта найденного и регламент использования ИИ лежат на странице Shadow AI и в разделе про безопасность ИИ.

А у вас кто решает, приемлем ли риск: служба безопасности или владелец данных? Напишите мне — соберу ответы и напишу о них в следующей статье.