Как корпоративные данные утекают в нейросети

По данным исследования Авито Работы и Контура, 21% сотрудников, владеющих навыками работы с ИИ, регулярно применяют эти технологии в рабочих задачах. При этом компания может даже не знать, какие нейросети используют сотрудники и какие данные туда отправляют.

Но теневой ИИ (Shadow AI) — только часть проблемы. ИИ-функции встраиваются в браузеры, CRM, почту, офисные приложения и среды разработки. Через интеграции и коннекторы ИИ-инструменты могут получать доступ к корпоративным данным, если им предоставлены соответствующие разрешения. Поэтому перед ИБ-отделом стоит более широкая задача, чем просто выяснить, кто использует ChatGPT. Необходимо понимать, какие корпоративные данные могут попадать в ИИ, по каким каналам они передаются, и кто контролирует этот процесс.

Разберем основные каналы передачи данных и способы снизить риск.

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

1. Текст из почты, CRM и рабочих чатов. Например, менеджер копирует в чат всю переписку, чтобы поправить одно письмо. Вместе с текстом могут передаваться ФИО, телефоны, адреса электронной почты, сведения о клиентах и сотрудниках.

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

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

Общее у всех примеров что сотрудник решает рабочую задачу и не думает, какие данные передает из контура организации. Закон между тем требует обратного. По ч. 5 ст. 5 закона № 152-ФЗ содержание и объем ПДн должны соответствовать целям обработки.

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

Поэтому для команды полезно начать с простого вопроса: Какие данные попадают в ИИ и действительно ли такой объем необходим для поставленной задачи?

С ручной передачей данных все относительно понятно: сотрудник копирует информацию и нажимает «Отправить». Сложнее контролировать ситуации, в которых ИИ-инструмент получает контекст через интеграцию.

Так происходит при использовании ассистентов разработчиков, ИИ-функций CRM и офисных приложений, браузерных расширений, агентов и коннекторов к корпоративным системам.

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

ИИ-ассистенты давно используются непосредственно в средах разработки. GitHub Copilot, Claude Code и Codex помогают писать и анализировать код, разбираться с ошибками и работать с проектами. В таких сценариях вопрос «копирует ли сотрудник код в чат» уже не единственный. Не менее важно понимать, какой контекст инструмент получает через IDE, файловую систему и подключённые инструменты.

По данным Cyberhaven, 34,8% корпоративных данных, которые сотрудники вводят в ИИ-инструменты, относятся к чувствительным. Среди них — исходный код, внутренние документы, данные клиентов.

Запрещать ИИ-ассистенты в разработке уже поздно — они стали частью рабочего процесса. Но у большинства из них есть встроенные механизмы ограничения.

Например, в GitHub Copilot Business и Enterprise можно настроить content exclusions — исключения для определённых файлов и путей. В Claude Code правила задаются через файл CLAUDE.md прямо в репозитории. Контроль действий и разрешений необходимо организовывать с помощью соответствующих механизмов безопасности и настроек среды выполнения. Важно, чтобы эти настройки были не на совести разработчика, а заданы на уровне организации

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

ИИ-функции появляются в браузерах двумя основными способами.

1. Сотрудник сам ставит расширение: помощник для почты, генератор текста, ассистент продаж.

   По данным Incogni, 52% из 442 проанализированных ИИ-расширений для Chrome собирают данные пользователей, а 29% — персональные: имена, email, адреса.

   ИИ-расширение видит ровно то же, что и сотрудник: переписку, карточки клиентов, задачи. Куда эти данные уходят — определяет разработчик ИИ-помощника, а не ваша политика безопасности.

2. ИИ-функции встроены в сам браузер.

   Примеры таких решений — ИИ-функции в Chrome, Microsoft Edge и Яндекс Браузере. Блокировка доменов нейросетей здесь не поможет. Расширения отправляют данные через собственные серверы, а встроенный ИИ — часть самого браузера.

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

   Важно не предполагать, что все ИИ-возможности можно отключить одной групповой политикой: набор настроек различается между браузерами и их версиями.

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

Например, BitrixGPT работает в CRM, почте, задачах и чатах Битрикс24 — там, где уже хранятся клиентские данные и внутренняя переписка. При этом модель можно выбрать в настройках: YandexGPT, GigaChat и другие. Похожая логика у Яндекс 360 для бизнеса: Алиса Про встроена в Почту и Документы.

Для службы ИБ здесь важно контролировать два уровня: какие данные получает ИИ-функция внутри самого сервиса и какой модели они передаются. Причем второй уровень может меняться уже после согласования продукта — например, если администратор переключит модель в настройках.

Поэтому недостаточно один раз проверить сервис и включить его в список разрешенных. Нужно отслеживать новые ИИ-функции и изменения в их настройках уже после внедрения.

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

По данным «Информзащиты», в 2026 году 42% организаций уже столкнулись с инцидентами безопасности, связанными с ИИ-агентами. 18% из них — утечки через подключенные коннекторы и хранилища, а 27% агентов в крупных компаниях оказались вообще неинвентаризированными — у них не было владельца.

На практике контроль агентов строится вокруг нескольких задач.

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

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

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

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

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

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

Теневой ИИ редко возникает только из-за халатности сотрудников. Часто причина проще: человек хочет быстрее выполнить работу. Если корпоративной альтернативы нет, запрет мало что меняет. ИИ-чат все равно остается в соседней вкладке.

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

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

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

• Правила: определить разрешённые сервисы, категории данных и допустимые сценарии использования.
• Технологии: управлять доступом, контролировать передачу данных и регистрировать значимые действия.
• Обучение: объяснять сотрудникам риски и показывать, как выполнять рабочие задачи безопасным способом.

Запрет отдельных сервисов помогает только с первым каналом — чатом, который сотрудник открывает сам. ИИ может появиться после обновления браузера, в новой функции CRM, в офисном приложении или в среде разработки. Агенты и коннекторы создают дополнительные пути доступа к корпоративной информации..

Поэтому начинать стоит не с блокировок, а с инвентаризации уже одобренного софта. Проверить, какие ИИ-функции появились в нем за последний год и куда они отправляют данные. Разобраться со всеми каналами сразу не получится, и это нормально. Даже частичная картина заметно снижает риск, а дополнять ее можно по мере того, как появляются новые функции и сервисы.

1. Какие ИИ-инструменты используются в компании?
2. Кто ими пользуется и кто отвечает за каждый инструмент?
3. Какие корпоративные данные они могут получать?
4. Какие модели и поставщики участвуют в обработке?
5. Где происходит обработка данных и на каких условиях?
6. Какие права, коннекторы и интеграции есть у ИИ-компонента?
7. Можно ли восстановить историю значимых действий и передачи данных?

Если хотя бы на несколько из этих вопросов нет ответа, компании стоит проверить, насколько полно она контролирует использование ИИ и связанные с ним потоки данных.

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