Air-Gapped AI: как работают ИИ-системы без интернета и облачного доступа

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

Что на самом деле означает ИИ в изолированной среде

Слово «ИИ» не меняет базовую концепцию безопасности. Air gap — это граница между доменами безопасности. ИИ просто делает изолированную сторону более требовательной с операционной точки зрения, поскольку современные стеки ИИ обычно предполагают загружаемые модели, реестры пакетов, телеметрию, API, хабы моделей и частые обновления ПО.

Изолированная среда может по-прежнему содержать множество соединённых машин. Внутренний кластер может иметь GPU, серверы приложений, хранилище, базы данных, службы идентификации и мониторинг, соединённые друг с другом. Air gap существует между этим анклавом и внешним доменом.

Таким образом, релевантный вопрос не «Есть ли у этого GPU Wi-Fi?», а «Может ли эта среда ИИ обмениваться информацией с внешним доменом через автоматизированный физический или логический путь?»

Простейший пример

Представьте, что компания хочет внутреннего ассистента для конфиденциальных технических документов, но среде не разрешено отправлять эти документы в интернет.

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

Внутри анклава сервер модели, парсер документов, векторная база данных, приложение и службы идентификации работают локально. Пользователи могут задавать вопросы и использовать RAG по внутренним документам без облачной модели или публичного реестра моделей.

Когда требуется обновление, оно снова проходит через контролируемый процесс импорта, а не загружается напрямую производственным сервером ИИ.

Где заканчивается простой пример

Производственная среда с air gap может быть гораздо больше одной рабочей станции. Она может включать Kubernetes/OpenShift, внутренние реестры, объектное хранилище, поставщиков идентификации, векторные базы данных, наблюдаемость, инфраструктуру резервного копирования и несколько узлов обслуживания моделей.

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

Таким образом, физическая изоляция смещает сложность. Она сокращает прямую внешнюю связность, но увеличивает ответственность за управление артефактами, обновления, зависимости, цепочку поставок и эксплуатацию внутри изолированного домена.

Air-gapped vs offline vs local vs on-premises vs private vs sovereign AI

Эти термины могут пересекаться, но не являются синонимами. Локальный сервер Ollama, подключённый к интернету, — это local AI, а не air-gapped AI. Локальная RAG-платформа, которая обращается к облачной модели, — это локальная инфраструктура приложения с облачным инференсом, а не air-gapped AI.

Air-gapped система часто является приватной по своей конструкции, поскольку данные остаются внутри изолированного контура, но приватность также зависит от авторизации, журналирования, обработки данных, физической безопасности и операционной политики.

Строгий air gap vs практическое развёртывание без подключения

Практическая архитектура air-gapped AI

Полная архитектура должна запускаться и работать без DNS-запросов, проверок лицензий, загрузки пакетов или вызовов API к публичным сервисам, если только для этих зависимостей не предусмотрены одобренные внутренние замены.

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

Модели должны быть предварительно размещены

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

Текущая документация NVIDIA по air-gap для NIM явно использует двухфазный шаблон: загрузка и подготовка ресурсов модели на подключённой машине, их передача, затем запуск изолированного NIM из локального хранилища без исходящего доступа к реестру или облачных API-ключей.

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

Модели с зависимостями remote-code — это риск для air-gap

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

Текущая документация Red Hat AI Inference явно предупреждает, что некоторые модели Hugging Face, требующие удалённого кода, не могут нормально работать в изолированных средах, поскольку библиотека пытается получить доступ к сети даже при настроенном автономном режиме.

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

Контейнеры, пакеты и драйверы становятся локальными артефактами цепочки поставок

Среды с подключением к сети регулярно загружают образы контейнеров, пакеты Python, обновления ОС и компоненты GPU из публичных реестров. Изолированная среда не может рассчитывать ни на один из этих сервисов.

Модель развёртывания ИИ в изолированной среде Red Hat использует внутренние зеркальные реестры для образов контейнеров и каталогов операторов. Модели можно зеркалировать как артефакты OCI или переносить в постоянное хранилище.

Для более широких стеков тот же подход часто применяется к языковым пакетам, репозиториям Linux, пакетам JavaScript и внутренним бинарным файлам: утверждённые артефакты один раз попадают внутрь через процесс передачи, а затем предоставляются из доверенных внутренних репозиториев.

Знайте полный перечень зависимостей

Внутренние зеркала — это инфраструктура, а не удобство

Изолированное развёртывание становится поддерживаемым, когда изолированный домен имеет известные внутренние источники утверждённых артефактов.

Документированный подход Red Hat использует зеркальный реестр, доступный изолированному кластеру, чтобы рабочие нагрузки не нуждались в публичных реестрах.

Ту же архитектурную идею можно применить к хранилищам моделей и репозиториям пакетов. Цель — сделать происхождение, версию и утверждение артефактов явными, а не копировать случайные файлы вручную на каждый сервер.

RAG может полностью работать в изолированной среде

RAG не требует публичного интернета. Ему нужен доступный для поиска корпус, конвейер приёма/индексации и модель, способная использовать извлечённый контекст.

В изолированной среде хранилище документов, парсер/OCR, модель эмбеддингов, векторный или лексический индекс, реранкер и модель генерации могут работать локально.

Что меняется — так это получение источников. Поиск в интернете в реальном времени и облачные коннекторы документов недоступны, если эквивалентные данные не импортированы через контролируемую границу.

Таким образом, корпус становится управляемым артефактом. Каждый импорт должен сохранять идентичность источника, дату/версию и происхождение, чтобы пользователи знали, какие знания фактически содержит изолированная система.

Агенты могут работать в изолированной среде — но только с доступными инструментами

Цикл агента может полностью выполняться внутри изолированного анклава, если модель/среда выполнения и необходимые инструменты находятся локально или доступны во внутренней сети.

Инструмент, зависящий от GitHub, публичного веб-поиска, облачной электронной почты или внешнего SaaS API, не будет работать, если архитектура не предусматривает одобренный внутренний эквивалент или контролируемый процесс асинхронного обмена.

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

MCP не обходит воздушный зазор

MCP может предоставлять локальные инструменты и ресурсы внутри изолированной среды ИИ, но протокол не создаёт связность через границу безопасности.

Локальный сервер MCP, читающий внутренние документы, может работать полностью автономно. Удалённый сервер MCP в публичном интернете недоступен из строго изолированного анклава.

Тот же принцип применим к любому протоколу подключения: совместимость отделена от сетевых полномочий.

Идентификация и аутентификация также должны работать офлайн

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

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

Авторизация остаётся необходимой, даже если интернет отсутствует. Воздушные зазоры не заменяют RBAC, изоляцию арендаторов или принцип наименьших привилегий.

Время, сертификаты и хранилища доверия становятся локальными зависимостями

Многие системы аутентификации и журналирования зависят от надёжного времени. Сертификаты истекают. Хранилища доверия меняются. Подписанные артефакты нуждаются в проверке.

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

Это обычные инфраструктурные вопросы, которые становятся заметны только при тестировании архитектуры без доступа к интернету.

Телеметрия и отчёты о сбоях требуют явной политики

Многие современные библиотеки по умолчанию пытаются собирать аналитику, проверять обновления или отправлять отчеты об ошибках.

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

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

Изолированным системам все равно нужны патчи

Сетевая изоляция не мешает программному обеспечению приобретать уязвимости. Она лишь меняет способ доставки патчей в систему.

NIST рассматривает управление патчами как профилактическое обслуживание: организациям по-прежнему необходимо выявлять, получать, расставлять приоритеты, устанавливать и проверять патчи и обновления.

Поэтому для работы в изолированной среде нужен воспроизводимый цикл импорта пакетов ОС, образов контейнеров, драйверов, сред выполнения ИИ и обновлений безопасности. Компромисс заключается между стабильностью изоляции и подверженностью уязвимостям из-за устаревшего программного обеспечения.

Контролируемый путь обновления

Граница передачи — самый чувствительный операционный интерфейс

Если внешняя информация должна попасть в изолированную систему, канал импорта становится важнейшей точкой контроля безопасности.

Структура киберугроз NSA Cybersecurity Technical Cyber Threat Framework прямо признает репликацию через съемные носители путем, который злоумышленники могут использовать для проникновения в отключенные или изолированные сети.

Именно поэтому контролируемая работа с носителями, проверка, происхождение, шифрование при необходимости, сканирование на вредоносное ПО и разделение ролей могут иметь не меньшее значение, чем сам стек ИИ.

Съемный носитель — не нейтральный канал

USB-накопители и другие портативные носители могут содержать как легитимные артефакты моделей/данных, так и вредоносное содержимое.

Руководство NIST по очистке носителей рассматривает носители информации как объект жизненного цикла конфиденциальности, который может требовать очистки, стирания или уничтожения в зависимости от чувствительности и потребностей повторного использования.

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

Изоляция повышает важность цепочки поставок

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

Руководство NIST по цепочке поставок программного обеспечения подчеркивает происхождение, риск поставщика, управление уязвимостями, верификацию программного обеспечения и практики, ориентированные на SBOM. Эти вопросы становятся непосредственно актуальными для офлайн-импорта артефактов ИИ.

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

Готовность к воздушному зазору следует проверять, а не предполагать

Кэширование один раз не то же самое, что готовность к воздушному зазору

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

Удаление кэшей или развертывание на чистом узле может выявить отсутствующие файлы токенизатора, пакеты Python, манифесты моделей или зависимости удаленного кода.

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

Какие угрозы остаются внутри воздушного зазора?

Что воздушный зазор действительно улучшает

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

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

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

Что воздушный зазор делает сложнее

AI в изолированной среде против частного AI

Частный AI в первую очередь связан с контролем над конфиденциальными данными и обработкой AI. Частная AI-платформа может быть развёрнута на собственных мощностях и при этом обращаться к одобренным облачным моделям или внешним сервисам.

AI в изолированной среде предъявляет более строгие требования к подключению. Система может быть частной, но не изолированной, а изолированная система может по-прежнему иметь слабую защиту конфиденциальности, если каждый внутренний пользователь имеет неограниченный доступ.

Цель безопасности должна определять архитектуру: конфиденциальность, суверенитет, устойчивость и изоляция — это связанные, но различные требования.

AI в изолированной среде против суверенного AI

Суверенный AI касается контроля над более широкой цепочкой зависимостей: данными, моделями, инфраструктурой, операторами, юрисдикцией и стратегическими зависимостями.

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

Следующая каноническая статья явно разделяет эти измерения контроля.

Свидетельства исходной реализации: что доказывает Aaasaasa AI Client — и что он не доказывает

AI Hub разделяет агента/клиента, провайдера, модель и расположение подключения. Он поддерживает локальный вывод Ollama и работу Codex с локальным провайдером как отдельные варианты, а не предполагает, что каждый AI-запрос идёт к облачной модели.

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

Таким образом, абстракция провайдера, обнаружение локальных моделей и локальный вывод являются строительными блоками для архитектуры продукта, способного работать в изолированной среде, но сетевую границу, офлайн-зеркало зависимостей, контролируемый процесс передачи и офлайн-идентификацию/операции всё ещё необходимо проектировать отдельно.

Когда AI в изолированной среде оправдан?

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

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

Практическая последовательность проектирования изолированного ИИ

Контрольный список архитектуры изолированного ИИ

Типичные режимы отказа изолированного ИИ

Распространённые заблуждения

Ограничения

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

Они могут ограничивать выбор модели, когда лицензии, требования к удалённому коду, потребности в оборудовании или API только от поставщика не могут быть удовлетворены офлайн.

Они увеличивают эксплуатационные расходы, поскольку инфраструктуру, обычно потребляемую как облачные сервисы, необходимо иметь и обслуживать внутри.

Они также могут создавать задержку патчей: более строгий контроль изменений может поддерживать стабильность систем, задерживая срочное устранение уязвимостей.

Поэтому изолированный ИИ следует оценивать как одну из нескольких архитектур безопасности, а не считать его универсально превосходным.

Что могло бы изменить этот ответ?

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

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

Устойчивый принцип состоит в том, что подлинные заявления о воздушном зазоре зависят от границы системы и механизма передачи, а не от того, выполняется ли LLM локально.

Связанные канонические знания

Air-Gapped AI — это узел архитектуры развертывания и безопасности. Private AI, Sovereign AI и абстракция провайдера отвечают на разные вопросы о конфиденциальности, контроле и зависимости.

MLOps/LLMOps становится более требовательным в изолированной среде, поскольку жизненные циклы моделей, пакетов и обновлений должны работать через внутренние репозитории и контролируемую передачу.

RAG и Agentic AI остаются допустимыми паттернами внутри анклава, если их данные и инструменты доступны внутри.

Часто задаваемые вопросы

Глоссарий

Заключение

Air-gapped AI — это не особый вид модели. Это AI-архитектура, работающая внутри намеренно изолированного домена безопасности.

Модель может быть легкой частью. Готовность к производству зависит от того, может ли каждая окружающая зависимость — активы моделей, пакеты, реестры, идентификация, RAG, инструменты, мониторинг, обновления и восстановление — функционировать без автоматизированного внешнего пути.

Самое короткое надежное правило: локальный инференс доказывает, где работает модель; доказательства air gap доказывают, как вся система разделена и как каждая разрешенная передача пересекает эту границу.

Первичные источники и текущие ссылки на реализацию

Приведенные ниже источники устанавливают определение безопасности, текущие паттерны развертывания AI в отключенных средах и риски жизненного цикла. Использование термина «air-gapped» поставщиками намеренно отличается от более строгого определения NIST.