Денис Кудинов: Контур Доверия
Личный опыт

Shadow AI уже внутри компании. Почему запрет делает его только опаснее

Shadow AI уже внутри компании. Почему запрет делает его только опаснее

Сотрудник загружает в AI-сервис протокол совещания, чтобы получить краткое резюме. Разработчик вставляет фрагмент кода и просит найти ошибку. Менеджер анализирует коммерческое предложение. HR формулирует обратную связь кандидату.

Никто из них не считает, что разворачивает новую IT-инфраструктуру. Но каждое такое действие создаёт новый поток корпоративных данных за пределы контролируемой среды.

Так возникает Shadow AI — использование сотрудниками AI-приложений, моделей, API и агентов без формального согласования и контроля со стороны компании.

Моя позиция проста: Shadow AI нельзя победить запретом. Запрет не устраняет использование ИИ — он устраняет видимость.

Это уже не эксперимент отдельных энтузиастов

Ещё в 2024 году 75% опрошенных Microsoft работников интеллектуального труда сообщили, что используют ИИ в работе. Среди пользователей ИИ 78% приносили собственные инструменты — BYOAI — без ожидания корпоративной инициативы. (Microsoft)

К 2025 году проблема стала шире отдельных чат-ботов. По данным Netskope, 60% пользователей продолжали работать с личными и неуправляемыми AI-приложениями. При этом Shadow AI уже включает SaaS-сервисы, облачные AI-платформы, локально запущенные модели и самостоятельно разработанных агентов. (Netskope)

Поэтому попытка решить вопрос блокировкой нескольких доменов безнадёжно устарела.

Сегодня сотрудник может:

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

Shadow AI превращается из набора неконтролируемых сайтов в параллельный технологический слой компании.

Главный риск — не сам ИИ, а потеря управляемости

Утечка информации остаётся самым очевидным риском. В AI-сервисы попадают исходный код, персональные данные, договоры, финансовая информация, результаты исследований, внутренние инструкции, пароли и ключи.

В исследовании Netskope нарушения политик при передаче данных в GenAI-приложения чаще всего были связаны с исходным кодом, за которым следовали регулируемые данные, интеллектуальная собственность, пароли и ключи. (Netskope)

Но сводить Shadow AI только к DLP было бы ошибкой.

Настоящая проблема заключается в том, что компания теряет ответы на базовые вопросы:

  • какие модели используются;
  • какие данные им передаются;
  • где эти данные обрабатываются и сохраняются;
  • используются ли запросы для обучения модели;
  • кто имеет доступ к истории взаимодействия;
  • на основании каких AI-ответов принимаются решения;
  • какие агенты подключены к корпоративным системам;
  • какие действия они могут выполнять автономно.

Организация получает новый класс технологического риска, но не получает реестра активов, владельцев, журналов, архитектурных схем и процедур реагирования.

По данным IBM, 20% исследованных организаций сообщили об инцидентах, связанных с Shadow AI. В компаниях с высоким уровнем теневого использования ИИ средняя стоимость утечки оказалась на 670 тысяч долларов выше, чем в организациях с низким уровнем Shadow AI или без него. (www-api.ibm.com)

Это не означает, что каждый несанкционированный запрос приведёт к инциденту. Но это подтверждает общий принцип: то, чего организация не видит, она не может нормально защитить, расследовать и восстановить.

Почему запрет обычно ухудшает ситуацию

Полный запрет кажется понятным управленческим решением. Он быстро оформляется приказом, легко объясняется аудиторам и создаёт ощущение контроля.

Но сотрудники уже знают, какую экономию времени даёт ИИ. Если официальный путь отсутствует, они начинают использовать:

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

В результате ИБ получает формально строгую политику и фактически нулевую телеметрию.

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

Самая опасная AI-система — не обязательно самая уязвимая. Часто это система, о существовании которой компания не знает.

Shadow AI становится особенно опасным вместе с AI-агентами

Обычный чат-бот отвечает на запрос. Агент может прочитать письмо, обратиться к CRM, изменить файл, создать задачу, выполнить код или отправить сообщение.

Это уже не только вопрос конфиденциальности данных. Это вопрос полномочий.

Если агент имеет доступ к корпоративным системам, нужно понимать:

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

Дополнительную угрозу создаёт prompt injection. Вредоносная инструкция может находиться не только в запросе пользователя, но и внутри документа, письма или веб-страницы, которую анализирует модель. OWASP отмечает, что такие инструкции способны непредсказуемо изменить поведение модели, а RAG и дообучение не устраняют этот класс уязвимостей полностью. (OWASP Gen AI Security Project)

Для автономного агента это особенно критично: скомпрометированный контент может повлиять не только на текст ответа, но и на действие, которое агент выполнит в подключённой системе.

Пять ошибок, которые совершают компании

1. Пытаются заблокировать весь ИИ

Так компания борется с интерфейсом, а не с потребностью. Пользователи быстро находят обходной путь.

2. Выпускают политику без разрешённых инструментов

Документ, в котором написано только «нельзя», не создаёт безопасного рабочего процесса.

3. Одобряют один AI-сервис без анализа сценариев

Корпоративная лицензия сама по себе не решает проблему. Нужно определить, какие категории данных можно передавать, какие функции разрешены и где требуется человеческая проверка.

4. Контролируют чат-боты, но не замечают API, локальные модели и агентов

Современный Shadow AI давно вышел за пределы браузера.

5. Делают ИБ единственным владельцем вопроса

Без участия IT, архитектуры, разработки, юридической функции, владельцев данных, HR и бизнеса программа быстро превращается в систему запретов.

Как должна выглядеть зрелая позиция ИБ

Задача CISO — не сделать использование ИИ невозможным. Задача — сделать безопасный путь самым простым и полезным.

Для этого компании нужен не только список разрешённых сервисов, а approved AI stack — управляемая среда, включающая:

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

Полезно разделить сценарии на три уровня.

Первый уровень — общие задачи.Подготовка черновиков, перевод открытых материалов, генерация идей без передачи внутренних данных.

Второй уровень — корпоративные данные.Работа с внутренними документами, кодом, аналитикой и перепиской только в управляемой среде с корпоративными аккаунтами и согласованными условиями обработки данных.

Третий уровень — критические процессы.Решения, затрагивающие клиентов, персонал, финансовые операции, безопасность, производство или регулируемые данные. Здесь нужны отдельная оценка риска, тестирование, человеческий контроль и повышенные требования к журналированию.

Практический план действий

1. Обнаружить реальный AI-ландшафт

Не начинать с предположений. Использовать данные сетевой безопасности, CASB/SSE, IdP, облачных платформ, конечных устройств, репозиториев, закупок и корпоративных расходов.

Цель — увидеть не только сайты, но и API, расширения, локальные модели и агентские фреймворки.

2. Создать короткую и понятную политику

Сотруднику нужно быстро понять:

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

3. Предоставить конкурентоспособную альтернативу

Разрешённый инструмент должен быть доступнее неразрешённого. Если корпоративный сервис требует трёх недель согласований и не решает рабочую задачу, политика не сработает.

4. Встроить технические меры

Нужны корпоративные аккаунты, SSO, MFA, DLP, контроль загрузок, управление расширениями, журналирование, ограничение сроков хранения и проверка договорных условий поставщиков.

5. Ввести отдельные требования к AI-агентам

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

6. Интегрировать AI security в Secure SDLC

AI-приложения должны проходить threat modeling, проверку цепочки поставок, оценку prompt injection, тестирование обработки вывода модели, контроль секретов и проверку избыточных полномочий.

OWASP отдельно выделяет prompt injection и раскрытие чувствительной информации среди ключевых рисков GenAI-приложений. (OWASP Gen AI Security Project)

7. Обучать по ролям, а не одинаково для всех

Разработчику, HR, юристу, аналитикам и руководителям нужны разные сценарии обучения. Для организаций, работающих в ЕС, AI literacy является также элементом выполнения статьи 4 AI Act: уровень знаний должен учитывать роль человека, контекст использования и связанные риски. (Digital Strategy)

8. Измерять не количество запретов, а управляемость

Полезные показатели:

  • доля использования через корпоративные аккаунты;
  • количество неуправляемых AI-сервисов;
  • число нарушений политик данных;
  • время согласования нового сценария;
  • доля критических AI-систем с назначенным владельцем;
  • количество агентов с избыточными полномочиями;
  • охват ролевым обучением;
  • число сценариев, переведённых из Shadow AI в approved stack.

Моя авторская позиция

Shadow AI — это не проблема нелояльных сотрудников. Это индикатор того, что скорость бизнеса превысила скорость корпоративной архитектуры и управления.

Запрет может быть временной мерой для отдельных сервисов и категорий данных. Но он не может быть долгосрочной AI-стратегией.

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

Финальный вывод

Вопрос уже не в том, используют ли сотрудники искусственный интеллект. Они используют его сейчас.

Настоящие вопросы звучат иначе:

Видит ли компания это использование?Понимает ли, какие данные и полномочия затронуты?Предложила ли безопасную альтернативу?Способна ли остановить AI-агента и восстановить историю его действий?

Победить Shadow AI невозможно приказом. Но его можно превратить из невидимого риска в управляемую корпоративную возможность.

Для этого безопасность должна не закрывать дверь перед ИИ, а проектировать правильный вход.

Подписывайтесь на мой ТГ канал: @ib_decisions

11