Нейросети и персональные данные: что уходит провайдеру

Главный факт про приватность в работе с API помещается в одно предложение: всё, что попало в запрос, ушло наружу. Не «может уйти при определённых условиях», а ушло — включая системный промпт, историю диалога и приложенный документ, о котором вы не подумали. Дальше начинаются различия между провайдерами: что хранится, сколько, кто имеет доступ и используется ли это для обучения. Эти различия существенны, но они не отменяют первого факта, а лишь описывают, что происходит после. Разбираем, что уходит на самом деле, как сократить чувствительную часть до отправки и какие вопросы задать любому провайдеру — включая нас.

Что именно уходит

Полный список, потому что о половине пунктов не думают.

Ваш вопрос. Очевидная часть.

Системный промпт. Уходит при каждом обращении. Если вы положили туда внутренние правила или примеры на реальных данных — они уходят тоже.

Вся история диалога. Модель не помнит предыдущих сообщений, поэтому переписка отправляется заново при каждом запросе. Разговор из двадцати реплик — это двадцать отправок нарастающего объёма.

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

Технические данные. Адрес, время, идентификатор ключа, объём запроса. Это неизбежная часть работы любого сетевого сервиса.

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

Что можно убрать до отправки

Самый действенный подход, потому что он не зависит от условий провайдера.

Обезличивание. Замените имена, телефоны, номера договоров и адреса на метки вида КЛИЕНТ_1, ТЕЛЕФОН_1. Модель прекрасно работает с метками: для задачи «составь ответ на жалобу» настоящая фамилия не нужна. После получения ответа подставьте значения обратно своим кодом.

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

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

Разделение потоков. Задачи с чувствительными данными — на один маршрут со своими правилами, всё остальное — на общий. Технически это отдельные ключи, и они же дают раздельный учёт.

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

Какие вопросы задать провайдеру

Пять вопросов, ответ на каждый должен быть письменным.

Что хранится и сколько. Полные тексты запросов, только метаданные или ничего. И срок.

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

Кто имеет доступ. Сотрудники, подрядчики, автоматические системы.

Где физически хранятся данные. Для части регламентов это определяющий вопрос.

Что происходит при передаче дальше. Посредник отправляет запрос вендору модели, и у вендора свои правила. Цепочка длиннее, чем кажется, и её надо знать целиком.

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

Почему «мы не храним» — не полный ответ

Разграничение, которое стоит держать в голове при чтении любых обещаний.

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

Вторая тонкость: обещания меняются. Условия использования переписываются, компании покупают друг друга, тарифы перестраиваются. Решение, принятое на основании сегодняшнего документа, стоит перепроверять — не ежедневно, но и не никогда.

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

Отдельно про логи на вашей стороне

Часть, о которой вспоминают позже всего.

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

Три меры:

Не пишите тела запросов целиком. Идентификатор, длина, модель, стоимость — этого хватает для большинства разборов.

Вырезайте заголовок авторизации. Иначе ключ окажется в логах.

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

Подробнее про баланс между отладкой и хранением — в материале что писать в логи запросов к моделям.

Чужие данные в контексте

Обратная сторона той же темы: не только что вы отправляете, но и что вам присылают.

Документ от клиента, письмо из внешнего источника, текст со страницы — всё это попадает в контекст наравне с вашими инструкциями, и модель читает их однородно. Инструкцию можно спрятать в документе так, что человек не заметит.

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

С чего начать, если ничего не сделано

Порядок для случая, когда модель уже используется, а вопросом никто не занимался. Занимает день и снимает основную часть риска.

1. Выпишите, что реально уходит. Не по замыслу, а по факту: возьмите десяток настоящих запросов из логов и посмотрите глазами, что в них попало. Обычно обнаруживается лишнее — целый документ вместо абзаца, история переписки, тестовые данные с настоящими именами.
2. Уберите очевидное. Всё, что не нужно для ответа, вырезается до отправки. Это самая дешёвая правка с самым большим эффектом.
3. Добавьте обезличивание там, где данные нужны по форме, а не по содержанию. Имя клиента в шаблоне письма подставляется вашим кодом после ответа, а не отправляется в модель.
4. Прочитайте условия своего провайдера. Именно прочитайте, а не предположите. Выпишите ответы на пять вопросов выше и сохраните файл с датой.
5. Ограничьте свои логи. Тела запросов, срок хранения, вырезанный заголовок авторизации.
6. Зафиксируйте решение письменно. Одна страница: что мы отправляем, что не отправляем, кому и почему это допустимо. Через полгода этот документ ответит на вопросы быстрее, чем чья-то память.

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

Чего мы не утверждаем

Мы не даём юридических советов. Требования к обработке персональных данных зависят от вашей юрисдикции и регламента; эта статья — про техническую сторону.

Не оцениваем условия других провайдеров. Читайте их сами.

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

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

Что держать в голове

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Завести отдельные ключи под разные потоки данных: keydealer.ru/login.