气隙AI：AI系统如何在没有互联网或云访问的情况下工作

气隙AI是指部署在安全域内的人工智能系统，该安全域与其隔离的外部系统之间没有物理网络连接，任何跨越该边界的传输都通过刻意控制的、非自动化的程序进行。因此，推理所需的AI模型、运行时、数据、检索索引、工具和操作依赖项必须在隔离环境内部可用。气隙AI不仅仅是“本地模型”或“本地服务器”：其定义性属性是围绕整个系统的网络和传输边界。

气隙AI的真正含义

AI这个词并不改变基本的安全概念。气隙是安全域之间的边界。AI只是使隔离侧在操作上要求更高，因为现代AI堆栈通常假设可下载的模型、包注册表、遥测、API、模型中心和频繁的软件更新。

隔离环境仍然可以包含许多连接的机器。内部集群可能有GPU、应用服务器、存储、数据库、身份服务和监控相互连接。气隙存在于该飞地和外部域之间。

因此，相关问题不是“这个GPU有Wi-Fi吗？”而是“这个AI环境能否通过自动化的物理或逻辑路径与外部域交换信息？”

最简单的例子

想象一家公司想要一个用于机密技术文档的内部助手，但不允许该环境将这些文档发送到互联网。

该公司在连接的暂存环境中下载经批准的LLM、嵌入模型、容器镜像和软件包。验证后，经批准的制品被转移到隔离环境中。

在飞地内部，模型服务器、文档解析器、向量数据库、应用程序和身份服务在本地运行。用户可以在没有云模型或公共模型注册表的情况下，针对内部文档提问并使用RAG。

当需要更新时，更新再次通过受控导入过程，而不是由生产AI服务器直接下载。

基本的气隙AI操作周期

1

1. 在飞地外获取

在连接的暂存环境中下载经批准的模型、软件包、容器、驱动程序、签名和文档。

2

2. 传输前验证

根据组织策略检查来源、签名/校验和、恶意软件状态、许可和兼容性。

3

3. 通过受控边界传输

使用授权的手动或中介过程移动经批准的制品。

4

4. 内部发布

将制品放入内部模型、容器、软件包或文件仓库。

5

5. 本地部署

在没有外部依赖的情况下运行推理、RAG、应用程序和工具。

6

6. 在飞地内监控

在本地收集日志、指标、模型/运行时状态和安全事件。

7

7. 仅导出经批准的证据

在策略允许的情况下，通过反向受控过程向外移动选定的报告或制品。

8

8. 为更新重复

将新模型、补丁、语料库和依赖项视为新的供应链导入。

简单示例的局限

生产气隙环境可能比一台工作站大得多。它可能包括Kubernetes/OpenShift、内部注册表、对象存储、身份提供商、向量数据库、可观测性、备份基础设施和多个模型服务节点。

隔离区内的服务越多，组织就越需要复制那些联网环境通常从互联网获取的能力。

因此，物理隔离转移了复杂性。它减少了直接的外部连接，但增加了隔离域内的制品管理、补丁、依赖、供应链和运维责任。

物理隔离 vs 离线 vs 本地 vs 本地部署 vs 私有 vs 主权 AI

这些术语可能重叠，但并非同义词。连接到互联网的本地 Ollama 服务器是本地 AI，而不是物理隔离 AI。调用云模型的本地部署 RAG 平台是带有云推理的本地部署应用基础设施，而不是物理隔离 AI。

物理隔离系统在设计上通常是私有的，因为数据保留在隔离区内，但隐私还取决于授权、日志记录、数据处理、物理安全和运维策略。

严格物理隔离 vs 实际断连部署

常被称为“物理隔离”的两种含义

	严格物理隔离	断连/无互联网部署
外部物理连接
跨边界传输
AI 工作负载的互联网访问
内部网络
使用该术语的场景

实用的物理隔离 AI 架构

完整的架构应能够在没有 DNS 查询、许可证检查、包下载或对公共服务 API 调用的情况下启动和运行，除非这些依赖已有经批准的内部替代方案。

一个有用的设计测试是断开部署与所有外部服务的连接，并冷启动整个技术栈。隐藏依赖往往会在启动、模型加载、认证、包解析或遥测初始化期间出现。

模型必须预先准备

如果隔离工作负载没有通往云模型 API 的路径，那么按定义这些 API 不可用。因此，隔离区需要可在本地运行的模型制品或内部托管的推理服务。

NVIDIA 当前的 NIM 物理隔离文档明确使用两阶段模式：在联网机器上下载并准备模型资产，传输它们，然后从本地存储运行隔离的 NIM，无需出站注册表访问或云 API 密钥。

模型权重只是依赖集的一部分。分词器、配置文件、适配器、量化元数据以及任何所需的运行时代码也必须存在。

具有远程代码依赖的模型是物理隔离的风险

一些模型仓库包含自定义 Python 代码或运行时钩子，这些代码或钩子通常会获取额外的代码或资源。

当前 Red Hat AI Inference 文档明确警告，一些需要远程代码的 Hugging Face 模型无法在断连环境中正常运行，因为即使配置了离线模式，该库仍会尝试访问网络。

实际经验是，在批准模型用于隔离部署之前，先离线测试其整个加载路径。“我下载了权重”并不能证明该模型是自包含的。

容器、软件包和驱动成为本地供应链制品

联网环境通常会从公共注册表拉取容器镜像、Python 软件包、操作系统更新和 GPU 组件。气隙环境不能假定这些服务中的任何一个可用。

Red Hat 的断连 AI 部署模型使用内部镜像注册表来存放容器镜像和 Operator 目录。模型可以作为 OCI 制品进行镜像，或传输到持久化存储。

对于更广泛的技术栈，同样的模式通常也适用于语言包、Linux 仓库、JavaScript 包和内部二进制文件：经批准的制品通过传输流程一次性进入，然后由受信任的内部仓库提供服务。

了解完整的依赖清单

内部镜像是基础设施，而非便利措施

当隔离域对经批准的制品拥有已知的内部来源时，断连部署才变得可维护。

Red Hat 文档化的方法使用断连集群可访问的镜像注册表，因此工作负载不需要公共注册表。

同样的架构思路可以应用于模型存储和软件包仓库。目标是让制品来源、版本和批准状态变得明确，而不是手动将随机文件复制到每台服务器。

RAG 可以完全在气隙环境中运行

RAG 不需要公共互联网。它需要一个可检索的语料库、一个摄取/索引管道，以及一个能够使用检索上下文的模型。

在气隙环境中，文档存储、解析器/OCR、嵌入模型、向量或词法索引、重排序器和生成模型都可以在本地运行。

变化的是来源获取方式。除非通过受控边界导入等效数据，否则实时网络搜索和云文档连接器不可用。

因此，语料库成为一种受治理的制品。每次导入都应保留来源标识、日期/版本和出处，以便用户知道隔离系统实际包含哪些知识。

代理可以气隙运行——但仅限可访问的工具

如果模型/运行时和所需工具是本地或在内部网络上可访问的，代理循环可以完全在隔离飞地内运行。

依赖GitHub、公共网络搜索、云电子邮件或外部SaaS API的工具将失败，除非架构提供经批准的内部等效项或受控的异步交换过程。

这就是为什么气隙代理设计应从能力清单开始：每个工具端点必须分类为内部、导入、不可用或故意排除。

MCP不会绕过气隙

MCP可以在隔离的AI环境中暴露本地工具和资源，但协议不会通过安全边界创建连接。

读取内部文档的本地MCP服务器可以完全离线工作。公共互联网上的远程MCP服务器无法从严格的气隙飞地访问。

同样的原则适用于任何连接器协议：互操作性与网络权限是分开的。

身份和认证也必须离线工作

AI应用程序可以本地托管，同时仍依赖云身份提供商。这种隐藏的依赖破坏了真正的断开操作。

因此，气隙设计需要一种在飞地内运行的身份架构：本地目录、内部身份提供商、内部PKI、本地服务凭证或其他经批准的机制。

即使没有互联网，授权仍然是必要的。气隙不会取代RBAC、租户隔离或最小权限。

时间、证书和信任存储成为本地依赖

许多身份验证和日志系统依赖于可靠的时间。证书会过期。信任存储会变化。签名工件需要验证。

因此，断开连接的飞地应具有内部时间同步和证书/信任生命周期，在正常操作期间不依赖于访问公共服务。

这些是普通的基础设施问题，只有在没有互联网访问的情况下测试架构时才会显现。

遥测和崩溃报告需要明确的策略

许多现代库默认尝试进行分析、更新检查或错误报告。

在隔离环境中，这些调用应被禁用或重定向到内部可观测性系统。反复失败的遥测尝试可能导致延迟、日志噪音和意外的启动行为。

气隙部署应了解哪些组件尝试外联，即使防火墙会阻止它们。

气隙系统仍然需要补丁

网络隔离并不能阻止软件产生漏洞。它只改变了补丁到达系统的方式。

NIST将补丁管理视为预防性维护：组织仍然需要识别、获取、优先排序、安装和验证补丁与更新。

因此，气隙操作需要为操作系统软件包、容器镜像、驱动程序、AI运行时和安全更新建立可重复的导入节奏。权衡在于隔离稳定性与陈旧软件带来的漏洞暴露之间。

受控的更新路径

隔离AI环境的示例更新生命周期

1

1. 识别所需更新

安全公告、模型/运行时改进或运营需求触发变更。

2

2. 在联网暂存区获取

下载确切版本以及签名/校验和和元数据。

3

3. 验证供应链证据

验证来源、完整性、兼容性和策略要求。

4

4. 在代表性离线暂存区测试

确认更新在没有意外网络依赖的情况下正常工作。

5

5. 批准传输

应用组织的变更和安全流程。

6

6. 导入到隔离区仓库

将制品发布到内部可信源。

7

7. 逐步部署

在架构允许的情况下，先应用于测试/金丝雀节点，再广泛推广。

8

8. 验证并记录

确认版本、健康状况、行为和回滚状态。

传输边界是最敏感的运营接口

如果外部信息必须进入气隙系统，导入通道就成为主要的安全控制点。

NSA网络安全技术网络威胁框架明确将可移动介质复制视为对手可用于进入断开连接或气隙网络的路径。

这就是为什么受控的介质处理、检查、来源追溯、必要时的加密、恶意软件扫描和角色分离可能与AI堆栈本身同样重要。

可移动介质不是中立的管道

USB驱动和其他便携式介质可以携带合法的模型/数据制品以及恶意内容。

NIST的介质清理指南将存储介质视为机密性生命周期对象，根据敏感性和重用需求可能需要清除、净化或销毁。

确切的传输程序因组织而异，但架构原则是稳定的：跨边界介质应作为安全资产进行管理，而不是被视为非正式的便利工具。

气隙增加了供应链的重要性

隔离系统接收的实时外部输入较少，但每一个导入的二进制文件、模型、容器和软件包都变得更加重要，因为飞地可能会长期信任它们。

NIST 软件供应链指南强调来源、供应商风险、漏洞管理、软件验证和面向 SBOM 的实践。这些关注点与离线 AI 制品导入直接相关。

模型供应链值得与应用供应链同等重视：在导入之前，应了解模型来源、许可证、哈希、格式、所需代码、分词器、适配器和评估状态。

气隙就绪状态应经过测试，而非假定

缓存过一次并不等同于气隙就绪

系统可能看起来处于离线状态，因为模型和软件包已从先前的互联网访问中缓存。

删除缓存或部署到干净节点可能会暴露缺失的分词器文件、Python 软件包、模型清单或远程代码依赖。

因此，气隙就绪状态应从干净的内部制品进行验证，而不仅仅是从先前连接过的开发者工作站进行验证。

气隙内部仍存在哪些威胁？

气隙实际改善了哪些方面

真正的气隙可以实质性减少依赖直接远程连接的攻击路径：外部命令与控制、云凭据滥用、面向互联网的服务利用，以及通过普通出站 API 造成的意外数据外泄。

它还在一个狭义层面上简化了数据驻留：如果不存在路径，推理数据就无法发送到外部云服务。

当传输边界和内部访问控制同样严格时，这些好处最为显著。管理不善的 USB 流程可能会破坏预期的隔离。

气隙使哪些事情变得更困难

气隙AI与私有AI

私有AI主要关注控制敏感数据和AI处理过程。私有AI平台可以部署在本地，同时仍可访问经批准的云模型或外部服务。

气隙AI在连接性方面要求更为严格。一个系统可以是私有的，但不一定是气隙的；而一个气隙系统如果每个内部用户都有不受限制的访问权限，其隐私保护仍可能很差。

安全目标应决定架构：机密性、主权性、韧性和隔离性是相关但不同的需求。

气隙AI与主权AI

主权AI涉及对更广泛依赖链的控制：数据、模型、基础设施、操作人员、司法管辖区和战略依赖。

气隙可以通过减少外部运行时依赖来支持主权，但它并不能保证主权控制。隔离区仍可能依赖外国硬件、专有模型许可证或外部更新供应商。

下一篇规范文章明确区分了这些控制维度。

原始实现证据：Aaasaasa AI Client证明了什么——以及没有证明什么

AI Hub将代理/客户端、提供商、模型和连接位置分开。它支持本地Ollama推理和本地提供商Codex操作作为不同选择，而不是假设每个AI请求都发送到云模型。

该仓库明确指出，本地运行时仍可使用云模型，而Direct Ollama聊天则是本地推理。这一区别与气隙架构直接相关：本地执行并不能证明模型或周围依赖是断开的。

因此，提供商抽象、本地模型发现和本地推理是具备气隙能力的产品架构的构建模块，但网络边界、离线依赖镜像、受控传输流程以及离线身份/运营仍必须单独设计。

何时气隙AI是合理的？

气隙应是从威胁模型或策略中推导出的需求，而不是一种声望功能。当被消除的连接路径本身不可接受时，它具有真正的安全价值。

对于许多企业用例，具有出口限制、本地推理和经批准更新渠道的严格控制私有网络，可能比严格的物理气隙在安全性和可维护性之间提供更好的平衡。

实用的气隙AI设计流程

从边界向内设计

1

1. 定义气隙隔离的内容

明确安全域，以及需求是严格的物理隔离还是仅仅无互联网连接。

2

2. 清点所有外部依赖

模型、软件包、注册表、身份、遥测、许可、存储、API、DNS/时间和支持服务。

3

3. 选择支持离线的模型和运行时

验证模型资产和运行时代码无需远程调用即可加载。

4

4. 构建内部制品仓库

为容器、软件包、模型和更新创建可信来源。

5

5. 设计受控传输

定义暂存、验证、介质/网关处理、审批和来源追溯。

6

6. 构建内部身份和授权

确保用户、服务和工具无需云依赖即可认证。

7

7. 保持RAG和工具本地化

在隔离区内部署知识、嵌入、索引和所需的服务API。

8

8. 构建内部可观测性

在本地运行日志、指标、追踪和安全监控。

9

9. 定义补丁/模型更新节奏

在漏洞响应与受控导入流程之间取得平衡。

10

10. 从干净的断开状态进行测试

在无继承缓存或隐藏互联网访问的情况下冷启动并运行。

11

11. 测试入侵路径

演练可移动介质、供应链、提示注入、内部人员和横向移动场景。

12

12. 记录例外和导出

每条允许的跨边界路径都应有明确的用途、负责人和控制集。

气隙AI架构检查清单

常见的气隙AI故障模式

常见误解

局限性

严格气隙使外部知识更新更慢，因为每个新来源都必须经过传输流程。

当许可、远程代码要求、硬件需求或仅提供商API无法离线满足时，它们可能限制模型选择。

它们增加运营成本，因为通常作为云服务消费的基础设施必须在内部拥有和维护。

它们还可能造成补丁延迟：更强的变更控制可能保持系统稳定，同时延迟紧急漏洞修复。

因此，气隙AI应作为多种安全架构之一进行评估，而非假定其普遍优越。

什么会改变这个答案？

供应商对断开操作的支持变化很快。新的模型格式、签名的OCI制品、离线许可机制和集成模型注册表可以减少操作摩擦。

即使供应商继续宽松地使用这些术语，严格气隙与断开部署之间的区别仍将重要。

稳定的原则是，真正的气隙声明取决于系统边界和传输机制，而非LLM是否恰好本地运行。

相关规范知识

气隙AI是一个部署/安全架构节点。私有AI、主权AI和提供商抽象回答了关于机密性、控制和依赖性的不同问题。

在断开连接的环境中，MLOps/LLMOps 的要求更高，因为模型、软件包和更新的生命周期必须通过内部仓库和受控传输来运作。

只要数据和工具在内部可用，RAG 和代理式 AI 在隔离区内仍然是有效的模式。

常见问题

气隙 AI 常见问题

什么是气隙 AI？

气隙 AI 是部署在与外部系统物理断开的安全域内的 AI，根据严格的 NIST 定义，跨边界传输通过受控的非自动化程序进行。

气隙 AI 需要互联网访问吗？

正常推理和运行不需要。所需的模型、软件包、数据和服务必须在隔离环境内可用。

本地 LLM 是否自动就是气隙的？

不是。本地模型可以运行在仍然具有互联网访问或使用云身份、工具或存储的机器上。气隙描述的是完整的系统边界。

RAG 能在气隙网络中工作吗？

可以。文档、嵌入模型、向量或词法索引、重排序器和生成模型都可以在本地运行。外部知识必须通过受控边界导入。

AI 代理能在气隙环境中工作吗？

可以，如果它们的工具和所需系统在隔离网络内可用。未经允许的跨边界机制，公共 SaaS 和云 API 不可用。

在气隙环境中如何更新模型？

模型通常在连接的暂存环境中获取和验证，通过批准的流程传输，并发布到内部模型/工件仓库。

本地部署 AI 与气隙 AI 相同吗？

不同。本地部署描述的是基础设施位置。本地系统可以保持互联网连接。

私有 AI 与气隙 AI 相同吗？

不同。私有 AI 关乎数据/控制要求，仍然可以使用连接的基础设施。气隙特指网络/域隔离。

气隙能使 AI 安全吗？

它消除或减少了一些远程连接风险，但并未消除供应链、可移动介质、内部人员、内部授权、物理或模型行为风险。

气隙就绪的最佳测试是什么？

在干净环境中部署或冷启动整个堆栈，所有外部连接不可用，并验证模型、身份、RAG、工具、监控、更新和恢复仅依赖经批准的内部工件和服务。

术语表

关键气隙 AI 术语

气隙

安全域接口，系统之间没有物理连接，根据 NIST 术语表定义，任何跨边界的逻辑传输都是非自动化/手动的。

气隙 AI

部署在气隙安全域内的 AI 系统，其推理和操作依赖项在本地可用。

断开连接的环境

没有直接外部互联网访问的部署环境；实现可能使用受控镜像或堡垒工作流。

离线能力 AI

能够在没有互联网连接的情况下运行部分或全部功能的 AI 应用，但不一定永久隔离。

本地 AI

在本地硬件上执行 AI 推理或运行时，而不是远程模型端点；不意味着网络隔离。

镜像仓库

包含断开连接部署所需的容器镜像或其他工件的经批准副本的内部仓库。

暂存环境

在传输到隔离域之前，获取、验证和准备工件的连接或受控区域。

受控传输

使用经批准的介质/流程和验证，在隔离边界上对数据或软件进行受治理的移动。

工件来源

显示模型、软件包、容器或其他导入工件来源以及如何生产或验证的信息。

可移动介质

用于在系统之间传输数据的便携式存储；跨断开域的潜在安全路径。

内部模型存储

隔离环境内的仓库，经批准的模型工件从中提供或部署。

气隙就绪

完整 AI 堆栈在没有未经批准的外部连接的情况下安装、启动、运行、更新和恢复的已证明能力。

结论

气隙 AI 不是一种特殊的模型。它是一种在故意隔离的安全域内运行的 AI 架构。

模型可能是简单的部分。生产就绪取决于每个周边依赖项——模型资产、软件包、注册表、身份、RAG、工具、监控、更新和恢复——是否能在没有自动化外部路径的情况下运行。

最短的可靠规则是：本地推理证明模型在哪里运行；气隙证据证明整个系统如何隔离，以及每次允许的传输如何跨越该边界。

主要来源和当前实现参考

以下来源确立了安全定义、当前断开连接的 AI 部署模式和生命周期风险。供应商对“气隙”的使用有意与更严格的 NIST 定义区分开来。

NIST CSRC — 气隙

NIST 术语表定义：物理断开的系统，跨边界的非自动化、手动控制的逻辑传输。

NVIDIA NIM — 气隙部署

当前操作指南，用于在连接的系统上暂存模型资产，并在没有互联网、公共注册表或云 API 密钥的情况下从本地存储运行 NIM。

Red Hat AI 推理 — 断开连接的部署

当前 Red Hat 指南，用于在断开连接的环境中使用镜像工件和内部基础设施提供 LLM 服务。

红帽 AI 推理 — 在隔离环境中存储模型

涵盖 OCI 模型镜像、持久化模型存储以及需要远程代码的模型局限性的当前指南。

NSA — 技术网络威胁框架

该威胁框架明确将可移动介质复制识别为进入隔离或气隙网络的路径。

NIST SP 800-88 Rev. 1 — 介质净化指南

根据信息保密要求管理和净化存储介质的指南。

NIST SP 800-40 Rev. 4 — 企业补丁管理规划

将补丁和更新视为企业系统预防性维护的指导框架。

NIST — 供应链中的软件安全

NIST 指南，涵盖软件供应链风险、来源、验证、SBOM 相关实践和漏洞管理。