Сотрудник загрузил базу клиентов в чат-бот: как это перехватить

Менеджер получает задачу: разобраться со списком клиентов, которых давно не касались. Открывает публичный чат-бот, копирует таблицу из Excel (400 строк с именами, телефонами, адресами и суммами прошлых покупок) и пишет: «Помоги сегментировать по активности и предложи, кому перезвонить в первую очередь». Задача решена за десять минут. Никакого злого умысла. И именно поэтому это опаснее, чем намеренный слив.

Разработчик делает то же самое, но с кодом. Вставляет фрагмент из репозитория, а вместе с ним строки подключения к базе данных со всеми реквизитами, «для контекста».

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

Почему это проблема, даже если никто не пострадал

Когда персональные данные покидают ваш контур, требования 152-ФЗ нарушаются в момент передачи, а не в момент, когда данные где-то «всплыли». Оператором этих данных остаётесь вы. Ответственность за то, что с ними произошло дальше, тоже ваша.

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

Это именно та ситуация, для которой придуманы системы предотвращения утечки данных (DLP). Только на практике классические DLP-решения были спроектированы под почту, веб-сёрфинг и флешки, а не под текстовые запросы к языковым моделям. Проблема новая, инструменты для неё тоже должны быть другими.

Как работает корпоративный шлюз

Механика, которую мы разворачиваем в вашем контуре, решает сразу несколько задач одновременно.

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

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

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

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

Квоты и ограничения по командам. Разные подразделения и приложения работают с разными моделями и разными лимитами. Это не только вопрос бюджета, но и разграничения доступа: аналитик не использует тот же канал, что и продуктовое приложение.

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

Как это выглядит в реальном инциденте

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

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

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

Честный разговор об ограничениях

Маскирование хорошо работает со структурированными данными. Таблица с полями «имя», «телефон», «адрес»: всё это надёжно ловится, один раз настраивается и работает стабильно.

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

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

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

Контролируемая точка входа решает задачу

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

Разрешить без контроля значит согласиться с тем, что вопрос «что именно уходит наружу» останется навсегда без ответа. А это не вопрос гипотетического риска: это регуляторная ответственность, которая уже есть.

Третий вариант: контролируемая точка входа с маскированием и аудитом. Инструмент работает, сотрудники им пользуются, но у компании есть видимость и технический контроль над тем, что происходит с персональными данными. Это и есть практическое выполнение требований 152-ФЗ в части языковых моделей, а не декларация о намерениях.

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