Лишь 29% команд безопасности могут регулярно отчитываться о конфиденциальных данных, которые сотрудники отправляют ИИ-инструментам

Эта статья основана на результатах опроса 2026 года, проведённого Cloud Security Alliance (CSA) и опубликованного в отчёте «Предотвращение утечек данных в эпоху ИИ», заказанном компанией Jazz.

В июне и июле CSA спросила 433 специалиста по ИТ и безопасности, может ли их команда подготовить отчёт о том, сколько раз за последние 30 дней конфиденциальные данные отправлялись в инструменты генеративного ИИ. Двадцать девять процентов ответили, что могут регулярно готовить такой отчёт.

Этот показатель был бы менее значим, если бы респонденты считали генеративный ИИ незначительным каналом. Однако они назвали его главным риском утечки данных: 48% включили его в тройку основных рисков.

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

Уверенность в том, что команды видят активность в генеративном ИИ, заметно опережает их возможности это подтвердить

Чуть больше половины респондентов оценили свою видимость активности в генеративном ИИ на 4 или 5 баллов из 5. Однако лишь 29% могли регулярно подкреплять такую оценку отчётом, в котором просто подсчитывается, сколько раз конфиденциальные данные отправлялись в ИИ-инструмент.

Источник: Cloud Security Alliance, «Предотвращение утечек данных в эпоху ИИ» (2026), n=433. Графики воссозданы по материалам отчёта на с. 22 и 23.

Применение ограничений демонстрирует ту же картину. Лишь 22% респондентов строго блокируют передачу конфиденциальных данных через канал генеративного ИИ. Для съёмных носителей, которые респонденты считают каналом с наименьшим риском утечки, доля строгой блокировки самая высокая — 31%. Строгая блокировка чаще применяется к каналам, для которых используются самые старые средства контроля.

Источник: Cloud Security Alliance, «Предотвращение утечек данных в эпоху ИИ» (2026), n=433. Графики воссозданы по материалам отчёта на с. 23 и 26; столбцы приведены к 100% в тех случаях, когда из-за округления сумма значений в строке составляла 99% или 101%.

Вместе с результатами опроса Jazz также опубликовала данные телеметрии из рабочих сред своих клиентов. Согласно этим данным, в средней организации использовалось 169,5 различных ИИ-инструмента, из которых 9,8 были одобрены; таким образом, 94,2% инструментов оставались за пределами утверждённого списка.

Почему возникает этот разрыв: список инструментов не фиксирует события

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

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

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

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

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

Каждое используемое средство контроля видит только одну точку

Опрос не выявил единого преобладающего подхода к контролю передачи конфиденциальных данных в ИИ-инструменты. Блокировка ИИ-доменов на уровне сети, проверка содержимого в браузере и одни лишь правила допустимого использования набрали от 21% до 23% каждая, тогда как корпоративные платформы ИИ со встроенными средствами предотвращения утечек данных получили 10%.

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

Ограниченность единственной точки проверки объясняет и показатели блокировки. Если средство контроля не может отличить корпоративную учётную запись от личной или обычную вставку текста от рискованной, ему остаётся блокировать и то и другое либо не блокировать ничего. В результате строгая блокировка мешает и законной работе, и рискованным действиям. На вопрос об основной причине, по которой они не перешли к более активной блокировке, 46% респондентов указали на опасение нарушить рабочие процессы, а 39% — на недостаточную уверенность в точности средств предотвращения утечек данных.

О каких оговорках стоит помнить

Данные опроса основаны на самоотчётах, а в ходе опроса оценки видимости не сопоставлялись с фактическим охватом. Среди респондентов преобладают представители Америки (80%) и организаций с численностью менее 5 000 сотрудников (67%), поэтому результаты могут быть не вполне применимы к крупным международным компаниям. Телеметрия получена от организаций, которые решили внедрить такой мониторинг, поэтому среди них может быть больше тех, кто уже обеспокоен чрезмерным распространением ИИ.

Одобренные инструменты и агенты ещё больше сузят этот список

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

Проверка, которую можно провести в этом месяце

Возьмите последние 30 дней и выберите самые чувствительные данные, которые, по вашему мнению, попали в инструмент ИИ. Затем проверьте, может ли ваша команда без ручной подготовки предоставить следующую информацию:

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

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