Персональный AI-ассистент — это софт, который на естественном языке ведёт почту, календарь, задачи и заметки одного человека и действует от его имени, опираясь на его контекст. Насколько такой ассистент приватен, определяет архитектура, а не обещания на лендинге: в чьём облаке хранится контекст и через чьи ключи запросы уходят к языковой модели. Обещания вроде «zero logs» или «100% приватно» снаружи проверить нельзя; архитектуру — можно.

Про то, что системы этой категории умеют по работе — память, координация агентов, подтверждение действий, — я уже писал в разборе роли AI Chief of Staff. Эта статья про другое. Выдача по запросу «приватный AI-ассистент» состоит из подборок «топ-10» и лендингов, где приватность обещают; инструмента проверки не даёт ни один. Я такие системы строю и держу в проде. Ниже — подход, которым пользуюсь сам, когда нужно понять: ассистент приватен по конструкции или только в тексте. Рейтинга не будет.

Что персональный ассистент о тебе знает

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

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

Два вопроса вместо политики приватности

Политика приватности рассказывает об обещаниях. Архитектуру определяют два вопроса; задай их вендору напрямую, в лоб — по ответам видно всё.

Вопрос 1. Чьё облако держит мой контекст? Вариантов три: общая база вендора, железо, которым владеешь ты, или сервер, выделенный под тебя одного. Ответ определяет, кто ещё технически способен дотянуться до твоей истории: в общей базе между твоим архивом и чужим доступом стоят только внутренние права самого вендора. Проверка: спроси про выделенный инстанс или self-hosting. Если в ответ звучит «у нас SOC2 и шифрование» — тебе ответили про политику, а спрашивал ты про архитектуру.

Вопрос 2. На чьих ключах он думает? Если сервис гоняет промпты через свой прокси на своих API-ключах, твоя переписка проходит через его инфраструктуру и оседает в его квотах и логах. Если ассистент ходит к модели на твоей собственной подписке, промпты идут напрямую провайдеру, которому ты и так платишь, — посредника в цепочке нет. Проверка — по деньгам: кто выставляет тебе счёт за модель? Платишь провайдеру сам — думает на твоей подписке. Модель «включена в тариф» сервиса — думает на его ключах, через него.

Это весь чек-лист. Шифрование, сертификаты, комплаенс — разговор осмысленный, но второй: сначала выясни, где лежит контекст и через кого идут промпты. Не наоборот.

«100% приватно» — обещание, а не архитектура

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

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

«Zero logs». Обещание не вести логи снаружи не проверяется. Вообще никак: ни один аудит, доступный покупателю, не докажет отсутствие логов. Это не обвинение — может, логов и правда нет. Это констатация: «zero logs» остаётся принимать на веру, проверить его нельзя.

«100% приватно» у сервиса, который гоняет трафик через себя. А здесь уже не вера, а противоречие: когда промпты идут через прокси сервиса на его ключах, «сто процентов» опровергается его же схемой работы.

Правило на все случаи: обещание снаружи не проверить, архитектуру — можно. Выделенный сервер или общая база — выясняется вопросом. Чьи ключи — видно по счёту за модель. Есть ли self-hosting — написано в доке. Оценивай проверяемое; на остальное делай скидку, как на любую рекламу.

Для симметрии — про managed-варианты, включая тот, что строю сам. Выделенный сервер проверяется лучше, чем кажется: твой собственный агент на этой машине сканирует её целиком — какие процессы крутятся, кто ещё имеет доступ и что делал по логам. «Один клиент, без соседей» ты проверяешь, а не принимаешь на веру. Полнее всего — вплоть до сетевого трафика — проверяется локальная модель на своём железе; выделенный сервер идёт почти вровень, твоими же средствами. У каждого пути своя цена; о ней ниже.

Три архитектуры с точки зрения приватности

Что эти архитектуры умеют и на что годятся, я разбирал в статье про AI Chief of Staff; здесь смотрим только на приватность. Победителя не объявлю: каждая где-то проигрывает, и покажу, где именно.

Облако вендора. Типовой self-serve сервис за $20–50 в месяц: регистрация, OAuth, к вечеру работает. Приватность здесь — политика: «пароль не видим», SOC2, «не обучаемся». По обоим вопросам чек-листа ответ «доверься»: контекст в общей базе, промпты на ключах вендора. Скажу очевидное, чтобы не выглядеть фанатиком: для некритичного контекста это нормальная сделка — дёшево, мгновенно, инбокс разгружает честно.

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

Выделенный сервер + твоя подписка. Средний путь: систему разворачивают на отдельном сервере, один клиент на сервер, а к модели она ходит на подписке, которую ты и так оплачиваешь, — напрямую провайдеру, без чужого прокси. Контекст не в общей базе, промпты не в чужих квотах. Плата своя: это не self-serve — доступ платный, с настройкой под тебя, и железо обслуживает команда сервиса, а не ты. Эта колонка — про Cain; подробно и с дисклеймером — ближе к концу.

Облако вендораЛокально на своём железеВыделенный сервер + твоя подписка
Где живёт контекстОбщая база, одна на всехТвоё железоВыделенный сервер, один клиент
Через чьи ключи думаетКлючи и прокси вендораМодель локальная, ключи не нужныТвоя подписка, напрямую провайдеру
Что можешь проверить самПочти ничего, кроме модели продажПрактически всё, вплоть до трафикаСчёт за модель; кто на сервере — сканирует твой агент
Слабое местоОба вопроса закрыты словом «доверься»Модели слабее, админишь самЖелезом владеешь не ты; не self-serve
Цена входа$20–50/мес, мгновенноЖелезо + твоё времяПлатная настройка под клиента

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

Что не отдавать ни одному ассистенту

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

Приватная архитектура сокращает список тех, кто способен дотянуться до твоего контекста. Сейфом она ассистента не делает. Сейфом пусть работает сейф.

Где здесь Cain

Сразу дисклеймер: Cain — мой продукт. Этот раздел — единственное место в статье, где я его продаю; читай с поправкой.

Cain — третья колонка таблицы, доведённая до сервиса. Под каждого клиента мы разворачиваем отдельный сервер, один клиент на сервер: память, переписка и извлечённые факты живут на нём, не в общем облаке. Думает Cain на подписке, которую клиент и так оплачивает: промпты уходят напрямую провайдеру модели, свои ключи мы в цепочку не вставляем, токены не перепродаём. По чек-листу этой статьи оба ответа архитектурные и оба проверяемы: ключи — твоим же счётом за подписку, а «один клиент на сервере» — твоим же агентом, который сканирует машину. Прежде чем что-то сделать наружу — отправить письмо, поставить встречу, — Cain спрашивает подтверждение (approval): сначала твоё «да», потом действие.

Где Cain проигрывает, назову сам, чтобы не пришлось искать. Он не self-serve: доступ платный, настройку под тебя — это setup fee — делает наша команда. Сервер тоже держим мы: владеть железом ты не будешь, и если это принципиально, Cain не подойдёт. Задача «недорого разгрузить инбокс» решается облачным сервисом за $20–50 — Cain для неё избыточен. А если нужен максимум проверяемой приватности и есть силы администрировать самому, локальная модель на своём железе честнее любого managed-решения, включая моё. Cain — один из вариантов.

Когда приватный ассистент тебе не нужен

Договорю за категорию то, что она сама о себе не скажет.

Если контекст, который ты отдаёшь ассистенту, спокойно переживёт чужие глаза — обычная рабочая почта, календарь, списки задач, — бери облачный сервис и не переплачивай. Он закрывает задачу за свои $20–50, и закрывает честно; приватная архитектура здесь — расход без выгоды.

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

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

Частые вопросы

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

Приватны ли разговоры с AI-ассистентами? Зависит от архитектуры, а не от вывески. У типового облачного сервиса контекст хранится в общей базе вендора, а запросы к модели идут через его ключи: приватность держится на политике компании, не на конструкции. Правильный вопрос не «обещаете ли вы приватность», а «чьё облако держит мой контекст и на чьих ключах система думает».

Как понять, что ассистент реально приватный? Задай два вопроса: где хранится контекст (общая база вендора, твоё железо, выделенный сервер) и через чьи ключи уходят запросы к модели (прокси сервиса или твоя подписка напрямую провайдеру). Оценивай архитектуру, которую видно снаружи, а не «zero logs», которое проверить нельзя.

Какой AI-ассистент безопаснее для приватного использования? Тот, где контекст не в общем облаке и промпты идут на твоей собственной подписке. Таких варианта два: локальная модель на своём железе и выделенный сервер под одного клиента. Свои минусы есть у обоих: локальные модели слабее и требуют твоего времени; выделенный сервер обслуживает чужая команда, и это не self-serve.

Можно ли сделать AI-ассистента по-настоящему приватным? «100% приватно» — утверждение, которое снаружи не проверяется ни у одного продукта. Максимум проверяемого — локальная модель на своём железе: контекст машину не покидает, пока ты не подключишь облачную модель. Следом по проверяемости — выделенный сервер под одного клиента с запросами на твоей подписке; дальше начинается вера, а не проверка.

Чем личный AI-ассистент отличается от приватного? «Личный» — про роль: система работает на одного человека и его контекст. «Приватный» — про архитектуру: где этот контекст лежит и через чьи ключи уходит к модели. Личный ассистент в общем облаке вендора — обычное дело, так что личный не значит приватный.

Собрать ассистента самому или взять готовый? Собирать локально имеет смысл, если готов сам ставить, чинить и обновлять — и это в радость. Для остальных это возня без конца. Готовый облачный сервис — минимум усилий, но контекст в чужом облаке. Выделенный сервер под тебя — как Cain — середина: сильные облачные модели и своя машина, но доступ платный, с настройкой под клиента.

Сколько стоит приватный AI-ассистент? Облачный self-serve сегмент — $20–50 в месяц, но приватность там держится на политике вендора. Локальный путь — цена железа плюс твоё время; времени уйдёт больше, чем кажется. Выделенный сервер с настройкой под клиента — как Cain — платный доступ и настройка (setup fee): дороже подписки и нужен не всем.

Илья Прудников собирает и держит в проде приватные ИИ-системы, включая [Cain](https://cain-ai.com). Это рамка оценки от оператора, а не обзор продуктов: перед покупкой любого ассистента сверься со свежей докой самой системы — где хранится контекст и на чьих ключах она думает.