Что нейросети делают с вашими данными: чек-лист приватности перед использованием LLM

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

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

Что считать чувствительной информацией

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

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

Где утечка возникает технически

Самый очевидный сценарий — пользователь сам вставил секрет. Но на практике опаснее цепочки. Встроенный ассистент получает доступ к документам, почте или базе знаний; RAG-поиск подтягивает не тот фрагмент; логирование сохраняет полный prompt; сотрудник поддержки видит историю диалога; интеграция отправляет в модель больше полей, чем нужно. В OWASP Top 10 для LLM такие риски описаны через раскрытие чувствительной информации, небезопасную обработку вывода, чрезмерные полномочия и prompt injection. Это не академическая угроза, а обычная инженерная ошибка.

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

Чек-лист перед первым использованием

• Проверьте, отключено ли использование ваших запросов для обучения и улучшения сервиса, если такая настройка есть.
• Разделите личные аккаунты, рабочие аккаунты и корпоративные API-ключи; не используйте один чат для всего.
• Включите автоудаление истории или короткий срок хранения там, где это возможно без потери аудита.
• Удаляйте имена, телефоны, почты, номера договоров, адреса и внутренние идентификаторы до отправки текста.
• Не вставляйте закрытый код целиком; отправляйте минимальный воспроизводимый фрагмент без токенов и путей к приватной инфраструктуре.
• Для команд опишите DPA, роли доступа, журнал обработки, процедуру ротации секрета и список разрешенных сервисов.

Хороший тест формулируется бытово: можно ли без ущерба переслать этот prompt внешнему подрядчику? Если ответ отрицательный, значит, для публичной модели текст слишком подробный. Его нужно обезличить, сократить или обработать в другом контуре. Такой тест не заменяет юридический анализ, но помогает остановить самые частые ошибки до того, как они превращаются в инцидент.

Как маскировать без потери смысла

Маскирование не должно превращать задачу в кашу. Если нужно отредактировать письмо клиенту, оставьте структуру ситуации, но замените персональные поля: Клиент А, договор N, сумма X, город Y. Если нужно проверить SQL, оставьте схему таблиц, но уберите реальные строки. Если нужна сводка звонка, удалите контакты и конкретные реквизиты, но сохраните проблему, договоренность и следующий шаг. Задача LLM — обработать форму и логику, а не знать настоящие персональные данные.

До: Иван Петров, +7 999 111-22-33, договор 45/26, просит скидку 12% по проекту клиента.
После: Клиент А, телефон удален, договор N, просит скидку X% по проекту B.

Что должно быть у команды

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

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