Миф: локальная модель полностью приватна

MAATRIX

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

Что миф угадывает правильно

Рациональное зерно здесь настоящее, и его не стоит обесценивать. Когда вы отправляете запрос в облачный API — OpenAI, Google, Anthropic или любой другой коммерческий сервис — данные физически покидают вашу инфраструктуру и попадают на серверы третьей стороны. Дальше вы зависите от чужой политики хранения, чужого понимания «данные не используются для обучения» (которое иногда меняется задним числом в условиях использования), чужих сотрудников с доступом к логам, чужой юрисдикции при судебном запросе.

Развернув модель — например, через Ollama, vLLM или llama.cpp — на собственном сервере, вы закрываете именно этот канал утечки. Запрос не уходит к провайдеру API, не проходит через его сеть, не попадает в его систему логирования «для отладки качества ответов». Это реальное и весомое преимущество, особенно если вы работаете с коммерческой тайной, персональными данными клиентов или юридическими документами, где сама передача третьей стороне уже создаёт риск по 152-ФЗ или договору о неразглашении.

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

Сервер с моделью — такая же цель для взлома, как и любой другой

Локальная модель работает не в вакууме, а на конкретном сервере с конкретной операционной системой, открытыми портами и учётными записями. Если сервер настроен небрежно, взлом произойдёт ровно так же, как случился бы со взломом сервера БД, почты или сайта — «локальность» ИИ тут вообще не участвует в уравнении.

Классический реальный пример — Ollama. Долгое время (и до сих пор при неаккуратной установке) сервис по умолчанию слушает 0.0.0.0:11434 без какой-либо аутентификации. Если у вас нет фаервола или он неправильно настроен, любой в интернете может обратиться напрямую к вашей модели, а в некоторых конфигурациях — увидеть список загруженных моделей и историю через открытый API. Проверьте это на своём сервере:

ss -tlnp | grep 11434
curl http://ВАШ_IP:11434/api/tags

Если curl с внешней машины отвечает списком моделей — порт открыт наружу, и это дыра, не имеющая отношения к тому, «облачная модель или локальная». Закрывается она стандартными средствами:

# слушать только localhost или внутренний интерфейс
OLLAMA_HOST=127.0.0.1:11434

# либо жёстко ограничить доступ фаерволом
ufw allow from 10.0.0.0/24 to any port 11434
ufw deny 11434

Та же логика касается vLLM, LiteLLM-шлюза, Open WebUI, AnythingLLM — у каждого свой веб-интерфейс и API, и у каждого есть своя учётная запись администратора, которую нужно защитить нормальным паролем, а лучше — вынести доступ за VPN или обратный прокси с базовой аутентификацией. Если атакующий получит SSH-доступ к серверу или проникнет через уязвимый веб-интерфейс, он увидит те же данные, что видит модель во время инференса — промпты, документы для RAG, историю диалогов в базе. Локальность не создаёт дополнительного барьера против взлома — барьеры создают обновления системы, минимальный набор открытых портов, fail2ban, ограничение SSH по ключу, разделение прав между сервисами. Это стандартная гигиена сервера, и локальная LLM не освобождает вас от неё — наоборот, добавляет ещё один сервис, который эту гигиену требует.

Если вы держите модель в Docker, отдельная деталь — не публиковать порт наружу по умолчанию -p 0.0.0.0:11434:11434, а привязывать к loopback или внутренней docker-сети:

docker run -d -p 127.0.0.1:11434:11434 ollama/ollama

Логи inference-сервера — тихий склад чувствительных данных

Второе, о чём миф забывает: практически любой inference-сервер и обвязка над ним (веб-интерфейс, шлюз, RAG-система) умеют логировать запросы и ответы — и часто делают это по умолчанию для отладки, мониторинга задержек или подсчёта токенов.

• Ollama пишет собственные логи через systemd: journalctl -u ollama -f. Сами тексты промптов там обычно не полные, но при отладке (OLLAMA_DEBUG=1) детализация растёт.
• vLLM и большинство OpenAI-совместимых серверов логируют входящие запросы в stdout, который Docker сохраняет как JSON-файл на диске (/var/lib/docker/containers/<id>/<id>-json.log), если не настроен другой logging driver.
• LiteLLM-шлюз и похожие прокси нередко пишут полную историю запросов в базу — для биллинга, аналитики использования, отладки ошибок — и эта база нуждается в шифровании и ограничении доступа не меньше, чем основная БД приложения.
• AnythingLLM, Open WebUI и другие чат-обвязки хранят историю диалогов в SQLite или Postgres прямо на диске сервера — это те же чувствительные данные, что вы «не отправили в облако», просто теперь они лежат локально в plaintext.

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

# найти, где реально растут логи
docker system df -v
du -sh /var/lib/docker/containers/*/*-json.log | sort -rh | head

# ограничить логирование Docker по размеру и глубине
{
  "log-driver": "json-file",
  "log-opts": {"max-size": "10m", "max-file": "3"}
}

Отключайте подробное логирование запросов там, где оно не нужно для реальной отладки, настраивайте ротацию (logrotate, ограничение max-size в Docker), и если логи всё же нужны для мониторинга — шифруйте диск (LUKS) и ограничивайте доступ к каталогу логов правами файловой системы, а не полагайтесь на то, что «сервер свой».

Скрытые сетевые вызовы: телеметрия, автообновления, плагины

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

Сама модель (веса и веса-исполняющий движок вроде llama.cpp) действительно не обращается в сеть во время инференса. Но обвязка вокруг неё — совсем другое дело:

• Инструменты вроде AnythingLLM, Open WebUI, LibreChat регулярно проверяют обновления версии при старте — обращение уходит на GitHub или собственный сервер разработчиков, обычно без содержимого диалогов, но сам факт исходящего соединения стоит знать и при необходимости отключать через переменные окружения или блокировать на фаерволе исходящий трафик, кроме нужных доменов.
• Многие RAG- и агентные обвязки включают «инструменты» с доступом в интернет — веб-поиск, парсинг URL, вызов внешних API по function calling. Если такой плагин включён по умолчанию и модель решает вызвать его в рамках диалога, часть контекста разговора может уйти во внешний поисковый сервис или API — то есть именно то, чего пользователь пытался избежать, разворачивая модель локально. Проверяйте список активных инструментов в настройках агента и отключайте всё, что не используете:

# пример: в Open WebUI и подобных — раздел
# Settings → Tools / Functions, отключить web-search, url-scraper и т.п.

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

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

tcpdump -i any -n 'tcp[tcpflags] & tcp-syn != 0 and not host ЛОКАЛЬНЫЙ_IP' -c 50

Если видите неожиданные исходящие соединения к незнакомым доменам — это и есть тот самый «незаметный периметр», который ломает миф о полной приватности локального развёртывания.

Практический минимум, чтобы локальность стала настоящей приватностью

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

Разверните модель на изолированной подсети или отдельном сервере, если работаете с действительно чувствительными данными — не смешивайте её с публичным веб-сайтом на той же машине. Используйте обратный прокси (nginx, Caddy) с базовой аутентификацией перед веб-интерфейсом чат-обвязки, а не открывайте порт напрямую. И относитесь к диску сервера так, будто на нём лежат те же данные, что вы отправляли бы в облако — потому что по факту так и есть, просто ответственность за их защиту теперь целиком на вас, а не размазана между вами и провайдером API.

Если разворачиваете инфраструктуру с нуля, полезно свериться с общим чеклистом безопасности нового сервера — там собраны базовые шаги (SSH, фаервол, обновления), которые актуальны для любого сервера, включая тот, где крутится LLM.

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