Данные пользователей и ИИ-провайдеры: что ты на самом деле отправляешь

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

Посмотри, что уходит на самом деле

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

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

Правило простое: в модель отправляется только то, что нужно для ответа. Это и про приватность, и про качество — лишний контекст мешает модели так же, как человеку.

Проверь настройки хранения у провайдера

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

используются ли данные из API для обучения моделей и по умолчанию ли это выключено;
сколько хранятся запросы и ответы и для чего (часто — для проверки злоупотреблений);
можно ли сократить или отключить хранение и что для этого нужно;
в каком регионе обрабатываются данные и можно ли его выбрать.

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

Вычищай до отправки

Многим задачам не нужны личные данные вообще. Чтобы классифицировать обращение, модели не нужно знать, как зовут клиента и на какой номер карты он платил.

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

имена, почты, телефоны → [ИМЯ_1], [ПОЧТА_1];
номера карт, документов, счетов — вырезать полностью, они модели не нужны никогда;
адреса — оставлять город, если он важен для ответа, и убирать остальное.

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

Согласие и прозрачность

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

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

Своё хранение тоже считается

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

Итог

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

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