Человек набирает в чате «а что там с тем договором?» — сорок символов. Провайдеру в этот момент уезжает несколько тысяч токенов, и большую часть из них пользователь не писал и не видел. Это не скрытая слежка, а способ, которым работает любой ассистент с памятью: модель не помнит ничего между запросами, поэтому весь нужный контекст собирается заново и отправляется целиком при каждом обращении.
Ниже — разбор того, из чего складывается этот «целиком», и что меняется в разных конфигурациях.
#Короткий ответ
Уходит не сообщение, а собранный контекст: системная инструкция, описания доступных инструментов, подмешанные фрагменты вашей памяти, история текущего разговора и только потом ваш вопрос. Плюс транспортные данные — ключ, имя модели, IP-адрес отправителя.
Не уходит: файл базы, скриншоты, распознанный с экрана текст, ваши настройки. Из архива захвата в запрос попадают только те фрагменты, которые ассистент счёл релевантными и подмешал в контекст, — но эти фрагменты уходят полным текстом.
#Из чего собирается один запрос
Схематично payload выглядит так. Порядок и названия блоков у разных продуктов отличаются, состав — нет.
POST /v1/chat/completions
Authorization: Bearer <ваш ключ>
{
"model": "<выбранная модель>",
"messages": [
{ "role": "system", "content": "<характер ассистента + правила>" },
{ "role": "system", "content": "<личные факты о пользователе>" },
{ "role": "system", "content": "<подмешанные фрагменты памяти>" },
{ "role": "user", "content": "<ваше сообщение 5 разговоров назад>" },
{ "role": "assistant", "content": "<ответ модели тогда же>" },
{ "role": "user", "content": "<а что там с тем договором?>" }
],
"tools": [ "<описания всех доступных инструментов>" ]
}
Разберём блоки по одному — интересны именно те, о которых пользователь не думает.
Системная инструкция. Текст характера ассистента: как отвечать, чего не делать, каким тоном. Пользователь пишет его один раз в настройках и потом забывает, а уходит он при каждом запросе. Если вы вписали туда «меня зовут так-то, я работаю там-то» — это тоже уезжает каждый раз.
Личные факты. Отдельный блок с тем, что ассистент про вас выяснил: имена близких, проекты, привычки, предпочтения. Именно он делает ответы персональными и именно он самый чувствительный по составу.
Подмешанная память. Ассистент ищет по всей истории фрагменты, релевантные вашему вопросу, и вставляет их в контекст. Ключевое следствие: вопрос из одного разговора вытягивает наружу куски из других разговоров. Вы спросили про договор — уехал фрагмент трёхмесячной давности, где этот договор обсуждался вместе с фамилией контрагента. Про то, что имеет смысл пускать в память, а что нет, — в разборе памяти и приватности.
Описания инструментов. Если у ассистента включён расширенный режим, к запросу прикладываются схемы всех доступных функций: поиск в интернете, работа с файлами, календарь. Это не ваши данные, но это заметный объём токенов и информация о том, как устроен ваш инструмент.
История текущего чата. Последние сообщения диалога — иначе модель не поймёт «а что там с тем».
Транспортный слой. Провайдер видит ваш API-ключ, выбранную модель, размер запроса, время и IP-адрес, с которого пришёл запрос. Даже если содержимое обезличено, метаданные обращений остаются: когда и как часто вы работаете.
#Таблица: что уходит в каждой конфигурации
Строки — реальные способы развернуть ассистента. Смотреть надо на среднюю колонку: она отвечает на вопрос «где физически лежит архив», и правая — «кто видит текст запросов». Это два независимых вопроса, и путать их не стоит.
| Конфигурация | Где лежит база | Кто видит текст запроса |
|---|---|---|
| Свой ПК + Ollama на нём же | У вас | Никто вне машины |
| Свой ПК + Ollama на другом ПК в сети | У вас | Тот, кто контролирует вторую машину и канал |
| Свой ПК + облачный ключ | У вас | Выбранный вами провайдер |
| Аккаунт на чужом экземпляре + свой облачный ключ | На сервере владельца | Провайдер и администратор сервера |
| Аккаунт на чужом экземпляре + свой Ollama | На сервере владельца | Администратор сервера и ваша вторая машина |
Из таблицы видно главное: только в первой строке у запроса нет внешнего получателя вовсе. Во всех остальных случаях получатель есть, и вопрос лишь в том, кто он и один ли он. Про сборку первой конфигурации — в гайде по подключению Ollama к Persona.
#Что из этого следует на практике
Обезличивать промпт недостаточно. Вы аккуратно вычистили имена из сообщения, а память подмешала их же из прошлого разговора. Процедура работает только вместе с контролем над тем, что лежит в памяти; сама процедура — в гайде про персональные данные в промпте.
Длина запроса — не длина вашего сообщения. Практический ориентир: считайте, что при каждом обращении уезжает весь ваш профиль плюс несколько фрагментов истории. Это же объясняет счёт за токены, который выглядит непропорционально коротким вопросам.
Смена провайдера не стирает прошлое. Переключились с одного на другого — новый видит те же подмешанные фрагменты с первого же запроса, потому что контекст собирается из вашей базы заново.
Разговор с разными моделями не изолирован. Память общая. Задали чувствительный вопрос локальной модели, потом бытовой — облачной, и облачная может получить фрагмент из первого разговора, если он покажется релевантным.
Векторный поиск добавляет ещё одного получателя. Если включён гибридный или векторный режим памяти, текст перед поиском превращается в эмбеддинг — и это отдельный вызов отдельной модели. В Persona эмбеддинги считаются локальной моделью и режим по умолчанию выключен, но в продуктах, где эмбеддинги считает облачный сервис, ваш текст уходит ещё и туда.
#Где интуиция подводит
«Я выключил историю, значит ничего не хранится». Выключенная история влияет на то, что показывает интерфейс, и не обязательно на то, что удерживает провайдер. Многие сервисы отдельно оговаривают хранение запросов для разбора злоупотреблений. Что декларируют разные провайдеры — в сравнении политик по обучению на данных.
«Локальная модель — значит офлайн». Не автоматически. Локальная модель на другой машине в сети — это сетевой запрос, и он идёт по каналу, который кто-то контролирует. Проверка одна: выключите сеть и задайте вопрос. Ответил — обработка на месте.
«Ассистент отправляет только то, что я вижу на экране». Ровно наоборот: видимая часть — самая маленькая. Системный промпт, факты о вас и подмешанные фрагменты в интерфейсе не показываются вообще.
«Скриншоты уходят в облако». У ассистента с захватом экрана — как правило, нет: наружу идёт текст, а изображения остаются в локальном хранилище. Исключение — когда вы сами прикрепляете картинку к сообщению для распознавания: тогда уходит сам файл.
#Что здесь честно про нашу конфигурацию
Persona не проксирует запросы через свои серверы: список получателей — ровно один, тот провайдер, чей ключ вы вставили. Это отличает схему от сервисов, где вендор стоит посередине и видит трафик.
Дальше — неудобное.
Участник на чужом экземпляре отправляет запрос с сервера владельца, а не со своего компьютера. Провайдер видит IP сервера; администратор сервера видит текст запроса в базе. Обе вещи — устройство продукта, а не изъян, и они названы прямым текстом в политике конфиденциальности.
Ключи API и токены участников хранятся в базе в открытом виде. Заводите отдельный ключ с лимитом расходов, а не рабочий.
На размещённой версии стоит Яндекс.Метрика с вебвизором. Она грузится только после согласия и в кабинете участника не отдаётся вовсе, но на публичных страницах после «Принять» пишет клики и навигацию. При развёртывании у себя счётчика нет.
Проверить наши слова чтением кода нельзя — репозиторий закрыт, публичной лицензии нет. Доступны внешние проверки; как их провести, описано в гайде про проверку исходящих соединений приложения.
#Частые вопросы
#Как узнать, сколько на самом деле уходит в одном запросе?
Самый точный способ — счётчик токенов на стороне провайдера: в его панели видно фактический размер каждого обращения, включая всё, что подмешал ассистент. Расхождение между вашим сообщением и цифрой в панели и есть размер невидимой части. Второй способ — перехватывающий прокси, который показывает тело запроса целиком.
#Видит ли провайдер мои скриншоты и распознанный с экрана текст?
Скриншоты — нет: они лежат в локальном хранилище и в запрос не попадают. Распознанный текст может попасть, если ассистент подмешает релевантный фрагмент в контекст. То есть само изображение остаётся, а его текстовое содержимое — потенциально уходит.
#Уходит ли что-то, когда я просто открываю интерфейс и ничего не спрашиваю?
К провайдеру модели — нет, обращение происходит только при запросе. К другим адресатам — зависит от продукта: аналитика, проверка обновлений, шрифты и скрипты со сторонних доменов срабатывают при открытии страницы. Это отдельный класс исходящих соединений, и проверяется он отдельно от запросов к модели.
#Можно ли не отправлять память, а спрашивать «начисто»?
В продуктах с отдельным режимом разового вопроса — да, и это разумная привычка для чувствительных тем: контекст не подмешивается, уезжает только ваш текст. Универсального переключателя «без памяти» в чате с историей обычно нет, потому что без контекста ассистент перестаёт быть ассистентом.
#Что уходит при использовании локальной модели на том же компьютере?
Ничего за пределы машины: запрос идёт на локальный адрес, ответ возвращается оттуда же. Проверяется отключением сети. Оговорка честная — небольшая локальная модель слабее топовой облачной в сложных рассуждениях, и выбор здесь между качеством ответа и отсутствием получателя. Как проходит эта граница, разобрано в статье про приватный ИИ и локальное хранение.
#Вывод
Если вам важно точно знать состав исходящего — считайте не своё сообщение, а сумму: инструкция плюс профиль плюс подмешанная история плюс описания инструментов. Уменьшать эту сумму можно двумя способами: чистить память от того, чему там не место, и держать чувствительные темы на локальной модели, где получателя нет вовсе. Всё остальное — вопрос доверия к конкретному провайдеру, а доверие проверяется его документами, а не нашей статьёй.