Личный ChatGPT на работе остаётся обходным маршрутом даже в компаниях, которые уже оплачивают ChatGPT Enterprise: сотруднику достаточно потерять корпоративную сессию, увидеть открытый личный аккаунт и вставить туда тикет клиента. Проблема не в самом факте входа в сервис, а в том, успели ли персональные или внутренние данные покинуть корпоративный контур — и может ли служба безопасности это доказать.
Такой сценарий разбирает BleepingComputer в спонсорском материале NordLayer. Автор статьи, вице-президент NordLayer по исследованиям и разработке Вакарис Норейка, предлагает смотреть на инцидент в двух вариантах: когда средства защиты видят использование личного аккаунта, но не содержание запроса, и когда браузерный контроль блокирует чувствительные данные ещё до отправки.
Для российской IT-команды этот сюжет знаком без поправки на конкретный вендор. Корпоративный доступ к генеративному ИИ может существовать на бумаге и даже быть технически развернут, но в момент срочной поддержки клиента, сорванной двухфакторной аутентификации или истёкшей сессии сотрудник выбирает самый быстрый путь. Если личный аккаунт уже открыт в соседней вкладке, политика безопасности проигрывает интерфейсу за несколько секунд.
Первый шаг после срабатывания события — установить, кто именно работал с сервисом. Учётная запись в MDM, EDR или прокси обычно корпоративная, а вход в ChatGPT может быть выполнен через личную почту. Это не обязательно злой умысел: один человек просто оказался представлен двумя идентичностями. Но именно здесь начинается неудобная часть расследования: надо подтвердить соответствие пользователя, устройства, времени и конкретного аккаунта, не превращая проверку в сбор лишних личных данных.
Самая неприятная развилка — понять, что попало в диалог. Лог о посещении ChatGPT или факт авторизации не отвечает на главный вопрос: был ли отправлен публичный текст, фрагмент кода, клиентский тикет с контактами либо внутренними реквизитами. Если система не анализировала запрос до отправки, расследование часто упирается в беседу с сотрудником и добровольный показ нужного фрагмента истории. Просить открыть всю переписку не нужно: помимо рабочих данных там почти наверняка окажутся личные запросы, не относящиеся к инциденту.
Видимость без содержания — слабая защита
В описанном BleepingComputer примере сотрудник вставляет в личный чат переписку с клиентом и просит подготовить ответ о проблеме с доступом к аккаунту. При отсутствии контроля уровня запроса информация уже ушла во внешний сервис. Дальше организация должна сохранить необходимые доказательства, подключить владельца данных, специалистов по приватности или реагированию и оценить характер раскрытия. Если в тексте были учётные данные, их следует отозвать или сменить. Если речь о клиентской записи, может потребоваться отдельная оценка последствий для персональных данных и договорных обязательств.
При этом важно не дорисовывать инциденту драму, которой не подтверждают факты. Использование личного аккаунта само по себе не доказывает, что запрос стал публичным, попал другому пользователю или был использован для обучения модели. Достаточно более точной формулировки: данные компании были введены в сервис вне утверждённого рабочего соглашения и вне предусмотренных для него контролей. Для юридической и технической команды это уже предмет разбирательства, но не повод заменять установленное обстоятельство догадками.
NordLayer продвигает для этой задачи AI Scout: расширение браузера, которое проверяет запрос локально до его отправки и может сопоставлять его с настроенными детекторами, например с шаблоном номера клиентского счёта. По описанию компании, найденное совпадение можно не только зарегистрировать, но и обработать тремя способами. Режим предупреждения показывает пользователю уведомление и оставляет выбор: вернуться к редактированию или отправить текст. Редактирование удаляет совпавшее значение, сохраняя остальной запрос. Блокировка не даёт отправить его вовсе.
Подход с предварительной проверкой полезен не потому, что любой ввод в ИИ нужно запретить. Он меняет характер события: вместо подтверждённой утечки команда получает попытку нарушить правило, которую остановил технический контроль. При этом администратору не обязательно читать сам запрос, чтобы увидеть срабатывание правила. Но качество такой защиты зависит от настройки: слишком широкий шаблон создаст поток ложных блокировок, а слишком узкий пропустит то, ради чего контроль запускали. Для исходного кода, персональных данных, ключей доступа, коммерческих условий и номеров обращений могут понадобиться разные правила и разные действия.
Корпоративный ИИ должен быть удобнее обходного пути
После расследования остаётся вопрос, который обычно важнее наказания: почему сотрудник не воспользовался разрешённой средой. В статье Норейка называет прозаичные причины — истёкшую сессию, медленную двухфакторную проверку, срочность задачи. Это стоит проверять буквально: помочь войти в корпоративный рабочий контур, убедиться, что задача там выполняется, и отдельно подтвердить, разрешены ли для неё конкретные данные. Подписка уровня Enterprise не делает допустимым любой текст, который пользователь может скопировать в окно чата.
Для разработчиков и продуктовых команд из этого следует практический минимум. Нужна понятная граница между личными и корпоративными учётными записями, работоспособный вход без ежедневного квеста и правила, привязанные не к названию инструмента, а к категориям данных. Поддержке полезно заранее знать, можно ли передавать в ИИ текст тикета после обезличивания. Инженерам — какие фрагменты логов, конфигураций и кода запрещены. HR и руководителям команд — объяснить, что «ChatGPT разрешён» и «в личный ChatGPT можно вставить что угодно» означают разные вещи.
Каждый такой случай стоит документировать одинаково: аккаунт, устройство, время, подтверждённое содержимое, факт отправки или блокировки, ответственного за дальнейшие действия и устранённую проблему доступа. Затем имеет смысл проверить повторные события. Личный ChatGPT на работе редко оказывается единственной причиной риска; чаще он показывает, что одобренный инструмент неудобен, а правила не встроены в реальный рабочий процесс. В ближайшие годы зрелость корпоративного ИИ будут измерять не числом купленных лицензий, а тем, сколько безопасных действий сотрудник может совершить быстрее, чем найти обходной путь.