Self hosted ИИ ассистент против облачного: разница по данным

У Ника в мастерской связка ключей висит на гвозде у прилавка: от двери, от старого сейфа, от кассы. Когда он завёл ИИ-ассистента для заявок, первым делом спросил себя похожий вопрос: у кого ключи от базы с перепиской клиентов. Разница между self hosted ИИ ассистентом и облачным сервисом сводится к одному вопросу: на чьём сервере лежит база с Вашими данными. В облаке переписка, память и документы хранятся на серверах провайдера, в его юрисдикции и по его правилам: он определяет сроки хранения, круг доступа и может менять политику. Self hosted означает обратное: ассистент и его база работают на сервере, которым распоряжаетесь Вы, и данные не покидают Ваш контур. Из этого одного различия вырастают пять практических осей: где физически лежат данные, кто их видит, кто устанавливает правила, что Вы забираете при уходе и кто обслуживает систему. Первые четыре оси в пользу своего сервера, пятая честно в пользу облака: за свой сервер кто-то должен отвечать. Ниже разбираем каждую ось на примерах, начиная с истории Ника, и показываем, как этот компромисс снимает схема managed self hosted, когда сервер принадлежит Вам, а обслуживает его подрядчик.

Что значит self hosted и что значит облако

Облачный ИИ-сервис устроен так: Вы открываете сайт или приложение, пишете вопрос, текст уходит на серверы провайдера, там обрабатывается и там же сохраняется. ChatGPT, Gemini, Claude и российские аналоги работают по этой схеме. В этом сила облака: ничего не нужно настраивать, вошли и работаете.

Self hosted ассистент устроен наоборот. Программа и база данных стоят на сервере, которым распоряжаетесь Вы: арендованном у хостера или собственном. Языковая модель при этом может вызываться извне по Вашему ключу, но память, документы и история переписки живут в Вашем контуре и никуда не уезжают.

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

Ось 1. Где физически лежат данные

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

Для российского бизнеса вопрос ещё конкретнее. Если Вы записываете данные клиентов, по 152-ФЗ Вы оператор персональных данных, и статья 18 требует, чтобы первичная база с данными граждан РФ физически находилась в России. Уход тех же данных в зарубежный сервис поднимает вопрос трансграничной передачи по статье 12, с уведомлением Роскомнадзора до её начала.

На своём сервере ответ известен заранее: конкретная машина в конкретной стране. Счёт в дуэли 1:0 в пользу self hosted.

Ось 2. Кто видит Ваши диалоги

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

На своём сервере круг доступа определяете Вы: кто из сотрудников, какой подрядчик и на каких условиях. Рецензентов, о которых Вы не знаете, в этой схеме нет. Счёт 2:0.

Ось 3. Кто устанавливает правила

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

Полезная рамка здесь у NIST. В AI Risk Management Framework (2023) институт называет семь характеристик доверенного ИИ, и одна из них звучит как privacy-enhanced: выбор архитектуры должны направлять три ценности, анонимность, конфиденциальность и контроль. Там же подчёркивается, что риском приватности управляют на всём жизненном цикле системы, а не одной галочкой при регистрации. В облаке из трёх ценностей Вам доступен только частичный контроль через настройки, которые провайдер может пересмотреть. На своём сервере правила хранения, доступа и удаления задаёте Вы, и никто не изменит их без Вашего участия. Счёт 3:0.

Ось 4. Что Вы забираете при уходе

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

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

Ось 5. Кто обслуживает сервер

Пятая ось честно в пользу облака. Свой сервер это работа: обновления, бэкапы, безопасность, мониторинг. У облачного сервиса всё это спрятано в подписку, и именно поэтому облако выигрывает по простоте старта. У коуча, психолога или консультанта навыков системного администратора обычно нет, и появляться они не обязаны.

Итог дуэли 4:1, но пятая ось долго перевешивала остальные четыре: владение данными оставалось привилегией тех, кто умеет в Docker и командную строку. Компромисс называется managed self hosted: сервер принадлежит Вам, а обслуживает его подрядчик. Проверка, что managed не превратился в скрытое облако, та же, что и во всей этой статье: у кого ключи и можно ли забрать сервер целиком.

Как это устроено у Хермес

Хермес от intakto работает ровно по схеме managed self hosted. Сервер клиента, физически в РФ: память, документы и переписка лежат в базе на этом сервере, что для первичной базы отвечает требованию локализации из статьи 18. Ключи в личном кабинете: Вы в любой момент видите, что лежит на Вашем сервере, а доступ intakto ограничен обслуживанием. Уход с полным вывозом: решите уйти, заберёте всё целиком, сервер, доступы, память, и intakto копий себе не оставляет.

Контраст с привычными сервисами проходит по оси памяти. ChatGPT умеет запоминать, но его память живёт в инфраструктуре OpenAI, в закрытом формате, и выгрузить её базой нельзя. У Хермес база лежит на Вашем сервере и переносится целиком. Как устроен сам продукт, от слоёв памяти до личного кабинета, описано на странице продукта.

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