Как не допустить передачи корпоративных секретов в публичные ИИ-сервисы

Не существует единственного фильтра, который перехватит каждый пароль или фрагмент кода. Рабочая защита состоит из трёх частей: разрешённого корпоративного ИИ-инструмента, понятных правил для сотрудников и технического контроля конкретных каналов. Системы предотвращения утечки данных (DLP, Data Loss Prevention) могут проверять и блокировать часть действий на управляемых устройствах. Но они не гарантируют обнаружение любого секрета и не контролируют личный телефон сотрудника.

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

После статьи вы сможете определить защищаемые классы данных, понять, какие каналы действительно охватывают технические средства, как провести пилот без остановки команды и что делать, если секрет уже оказался снаружи. В качестве примера DLP мы рассматриваем Microsoft Purview по документации, изученной на 11.10.2026. Возможности других систем проверяйте по их документации.

Типичный путь утечки

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

Разработчик обнаруживает ошибку в интеграции с платёжным сервисом. Чтобы быстрее разобраться, он копирует фрагмент конфигурационного файла и вставляет его в публичный чат-бот с вопросом: «почему запрос завершается ошибкой?» Вместе с кодом в фрагмент попадает рабочий API-ключ. Ответ помогает, проблема решена за пять минут. Но ключ теперь хранится в сервисе, с которым у компании нет договора и условия которого определяет личный аккаунт разработчика.

Никто не хотел причинить вред. Именно поэтому такие утечки трудно заметить: они выглядят как обычная работа. Типичных каналов четыре.

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

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

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

Личный аккаунт и личное устройство. Даже при наличии корпоративного ИИ-инструмента сотрудник может открыть привычный личный аккаунт. Корпоративные условия обработки данных на него не распространяются. Контроль рабочего ноутбука автоматически не охватывает личный телефон.

Какие данные защищать

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

Секреты доступа выделены отдельно не случайно. Их нельзя «немного обезличить», а после утечки их можно только отозвать и заменить. Лучшее решение — архитектурное: хранение ключей в специальном хранилище снижает вероятность скопировать их вместе с конфигурацией. Однако значение всё ещё может попасть в журнал, переменную среды или вывод команды, поэтому хранилище не заменяет контроль этих каналов. О допустимых персональных данных и правовом основании подробнее говорится в нашей статье о GDPR и HIPAA.

Что реально умеет DLP

Политика DLP описывает пять вещей: на каком устройстве она действует, в каком приложении или браузере, какое действие контролирует, как распознаёт чувствительное содержимое и как реагирует. Разберём пример Microsoft Purview, ограничивающий вставку чувствительного содержимого в браузер.

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

Браузер. Страница сценария Microsoft перечисляет Edge, Chrome и Firefox для Windows/macOS, а также Safari для macOS; примечания о расширениях Chrome/Firefox относятся к Windows. Этот краткий список не доказывает одинаковую работу на всех платформах. Сверьте матрицу поддержки своей ОС и проверьте вставку в каждом браузере. Одно лишь отсутствие расширения Windows на Mac не доказывает, что сценарий macOS не поддерживается.

Тип действия. Вставка в браузер — лишь одно из контролируемых действий. Справочник DLP-политик также перечисляет загрузку файлов через браузер, копирование в буфер обмена, печать, копирование на съёмные носители и сетевые папки, передачу через Bluetooth и удалённый рабочий стол. Каждое действие настраивается отдельно. Контроль вставки не означает контроль любого текста в любом приложении.

Распознавание содержимого. Правило вставки в браузер срабатывает, когда в содержимом есть выбранные типы чувствительной информации. Проверка выполняется в момент вставки и не зависит от метки файла, из которого скопирован текст. Для Paste to Browser справочник отдельно указывает: поддерживаются типы чувствительной информации (SIT), но не метки конфиденциальности; текст короче 30 символов не оценивается; классифицируются только первые 4 МБ текста. Практический вывод: система обнаруживает содержимое, для которого задан подходящий тип чувствительной информации. Внутренний код без характерных шаблонов или пароль, не похожий на известный формат, классификатор может пропустить. Нельзя обещать распознавание любого кода или пароля.

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

Перед подготовкой внутренней инструкции проверьте конфигурацию: операционные системы сотрудников, браузеры, лицензию и наличие нужного расширения. Проверка Edge на Windows не доказывает, что настройка так же работает в Safari на Mac. Нужен отдельный тест поддерживаемой конфигурации, но не обязательно отдельная политика.

Таблица границ контроля

Это учебная таблица о трёх каналах и реальных пределах технической защиты.

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

Как не остановить команду

Жёсткая блокировка без альтернативы предсказуемо ведёт к обходным путям: кто-то откроет личный аккаунт на телефоне, кто-то сфотографирует экран. Технический контроль работает лучше, когда есть разрешённый способ выполнить ту же работу.

Разрешённый инструмент. Предоставьте сотрудникам корпоративный ИИ-сервис с бизнес-условиями обработки данных. Например, OpenAI заявляет, что по умолчанию не обучает модели на бизнес-данных клиентов; условия потребительского аккаунта не распространяются на корпоративные продукты. Такой инструмент делает маршрут понятным: есть место, куда можно, и места, куда нельзя. Что проверить в договоре и настройках корпоративного тарифа, рассмотрено в нашей статье об обучении корпоративного ИИ на данных компании.

Группы доменов с разными реакциями. Документация Purview предлагает два подхода: общее действие «аудит» с исключениями «блокировать» для рискованных сайтов или общее действие «блокировать» с исключениями «аудит» для доверенных. Один домен может не различать корпоративный и личный аккаунт в одном сервисе. Разрешение домена нужно сочетать с контролем рабочей учётной записи или другим проверенным способом разграничения.

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

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

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

Пилот и ложные срабатывания

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

Шаг 1. Аудит без блокировки. Включите политику в режиме аудита для ограниченной группы устройств. Посмотрите, какие события фиксируются, на каких сайтах и с какими типами данных.

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

Шаг 3. Точечное включение блокировок. Блокируйте типы данных и группы сайтов, где аудит показал реальный риск и приемлемый уровень ложных срабатываний. Остальное оставьте в режиме аудита или блокировки с возможностью обхода, когда сотрудник подтверждает действие и указывает причину.

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

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

Что делать после утечки

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

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

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

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

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

Что сделать в ближайшее время:

1. Составьте список классов данных и правило использования ИИ для каждого.
2. Перенесите секреты доступа из конфигурационных файлов в хранилище секретов, где это ещё не сделано.
3. Предоставьте сотрудникам разрешённый корпоративный ИИ-инструмент и объясните, какие данные можно передавать.
4. Проверьте устройства, браузеры, лицензии и расширения, на которых будет работать DLP.
5. Проведите аудитный пилот на тестовых данных и запишите, что политика обнаруживает и что пропускает.
6. Утвердите порядок действий после утечки: кто ограничивает доступ, отзывает секреты, собирает факты и отвечает за исправление процесса.

Часто задаваемые вопросы