Как проверить, что локальный ИИ не отправляет данные в облако

Что означает «данные не уходят в облако»?

Проверяемое требование формулируйте до настройки: текст тестового запроса, ответ, извлечённый документ и связанные метаданные не должны покидать утверждённую сетевую границу. Составьте карту: браузер → интерфейс → API → runtime → модель; добавьте OCR, embedding, поиск, прокси, мониторинг, резервные копии и журнал. Для каждой стрелки запишите адрес назначения, владельца и основание разрешения. Если условие касается только инференса, так и назовите его — это не тот же результат, что изоляция всего приложения.

Наличие локальных весов не означает, что интерфейс отправил запрос именно локально. Ollama документирует локальный API по http://localhost:11434 и другой прямой облачный адрес https://ollama.com/api; второму нужен API-ключ s2. Сначала установите фактический адрес в конфигурации клиента. У Ollama локальный сервер по умолчанию привязан к 127.0.0.1:11434, а переменная OLLAMA_HOST может изменить привязку s1. Это свойство одного сервиса, не сертификат закрытого контура.

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

Как подготовить модель, среду и исходные условия?

Возьмите только синтетический текст с уникальной меткой, например OFFLINE-CANARY-TEST-20260924; не используйте настоящий секрет как «маяк». Один конкретный кандидат для малого теста — тег qwen3:8b в каталоге Ollama, где приведена команда ollama run qwen3:8b s6. Команда может загрузить весовые файлы: сделайте это до включения изоляции, зафиксируйте тег и digest установленного экземпляра. Карточка автора Qwen/Qwen3-8B описывает локальные runtime, но это не доказательство идентичности байтов HF и упаковки Ollama s7. Объём весов не превращайте в оценку необходимой RAM/VRAM: совместимость определяется конкретным форматом, контекстом и устройством. Сверить выбор поможет разбор памяти.

По FAQ Ollama облачные модели и web search самой Ollama можно отключить через OLLAMA_NO_CLOUD=1 либо disable_ollama_cloud: true в ~/.ollama/server.json, затем перезапустить сервис и проверить сообщение о выключении облака в его логах s1. Это не выключает сетевой доступ интерфейса, контейнера и других служб. Для Open WebUI опубликованное community-руководство предлагает заранее подготовить локальный inference, embedding и средства извлечения, установить OFFLINE_MODE=true, HF_HUB_OFFLINE=1 и отдельные флаги обновлений; оно прямо требует отдельного сетевого контроля для блокировки внешних обращений s3. Не переносите настройки Open WebUI на установку без этого компонента.

Для пилота достаточно подготовленных весов, локального API и одного клиента. Если интерфейс, браузер и Ollama размещены на разных узлах, включите все три в область контроля. Контейнер на Docker default bridge может выходить наружу через хост по документации Docker; несколько подключённых сетей тоже возможны s4. Поэтому запись «в Docker» не является мерой защиты, а отсутствие интернет-маршрута надо проверять для каждого процесса и namespace.

Как провести сетевой тест, не выдавая желаемое за результат?

1. Зафиксируйте границу: версии ОС, Ollama и интерфейса, конкретный тег и digest, включённые плагины, адрес API, список контейнерных сетей, настройки прокси, DNS и правила egress. В таблице обозначьте разрешённые локальные адреса и запрещённые внешние назначения. Если нет прав просматривать узел или шлюз, отметьте это как ограничение проверки, а не как «нарушений не обнаружено».
2. Запишите исходный фон: администратор запускает ограниченный по времени захват и журнал исходящих соединений на интерфейсе и шлюзе, относящихся к тестовым узлам. Документация tshark описывает выбор интерфейса -i, capture-фильтр -f, запись -w и ограничение по времени -a s5. Пример только для согласованной тестовой машины: sudo tshark -i <интерфейс> -a duration:60 -f 'ip or ip6' -w <защищённый-путь>/offline-test.pcapng. Замените плейсхолдеры; файл может содержать содержимое сессий, доступ и срок хранения ограничивают заранее. Не путайте захват на хосте с наблюдением за другими узлами и внешним шлюзом.
3. Отправьте синтетический запрос: после подготовки локальной модели выполните curl -sS http://127.0.0.1:11434/api/chat -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"Повтори метку OFFLINE-CANARY-TEST-20260924"}],"stream":false}'. Это форма документированного локального POST /api/chat, а не обещание ответа на любой машине s8. Сохраните время запроса, адрес, статус, выбранную модель и фактический ответ. Если клиент — Open WebUI, повторите тот же смысловой запрос через него: успешный вызов curl проверяет лишь прямой путь до Ollama.
4. Сопоставьте: выделите для тестового окна новые соединения, DNS, адреса назначения, прокси и отказы на шлюзе, включая IPv6; сравните их с фоном и процессом/контейнером. Спросите, какую часть потока можно уверенно связать с тестовым запросом. Пустой захват при неправильном интерфейсе или фильтре — не успех. По возможности проверьте, что наблюдение видит контрольное соединение, разрешённое в пределах тестовой границы; не отправляйте canary в реальное облако для такой проверки.
5. Повторите с принудительным запретом исходящего трафика для соответствующих процессов и сетей, сохраняя разрешённые локальные связи. Приложение должно выдать ответ из заранее загруженной модели либо явную ошибку там, где осталась внешняя зависимость. Фиксируйте и ошибку: офлайн-работа одного чата не покрывает OCR, embeddings, обновления, плагины и журнал. Запрет лучше наблюдения: доказательство отказа при попытке внешнего доступа показывает действие правила, но не исключает других путей.

Как оформить результат и когда остановиться?

Сохраните акт эксперимента: схема сети и перечень узлов; версии и теги; маршрут клиента; время и синтетический запрос; хеш/место защищённого сетевого артефакта; выдержку событий по адресам и процессам без рабочих данных; действующие правила egress и результат контрольной проверки наблюдаемости; ответ модели и список непокрытых интерфейсов. Установите критерий «пройдено» заранее: все тестовые запросы прошли разрешённым локальным путём, внешние соединения процесса заблокированы или объяснены и не содержат тестовых данных, журнал фиксирует отказ. Если служба пытается обновляться извне, это отдельное событие, даже если текст запроса в нём не обнаружен.

Остановите рабочий пилот при неизвестном облачном endpoint, необъяснённом исходящем соединении, отсутствии доступа к сетевому шлюзу, потере логов или противоречии между настроенным и фактическим маршрутом. Не выводите из одного отрицательного захвата, что «утечек не бывает»: редкие фоновые задачи, браузерные плагины, DNS, TLS и иной маршрут могут остаться вне окна. Сетевой тест сам по себе не подтверждает право обрабатывать персональные данные и не заменяет аудит доступа/хранения. Modelium не выполнял этот захват на вашей системе и не публикует процент защищённости.

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