
氣隙機器學習:如何在沒有互聯網訪問的情況下構建 AI 數據管線
在氣隙環境中構建 AI 數據準備和訓練管線的實用指南——從文件攝入到模型匯出——任何階段都不需要互聯網連接。
「氣隙」是一個在企業 AI 討論中被寬泛使用的術語。它通常意味著「我們不希望數據離開我們的網路」或「我們傾向於本地部署」。這些是合理的要求,但它們與真正的氣隙操作不同。在真正的氣隙環境中——機密政府系統、關鍵基礎設施網路、高安全金融系統——根本沒有互聯網連接。不是受限制的。不是被監控的。是缺失的。
為這些環境構建 AI 數據準備管線需要與典型本地部署不同的架構。每個組件都必須在不回撥、不檢查許可更新、不下載模型權重、不訪問外部 API 的情況下運行。大多數現代軟體在安裝時以不明顯的方式未通過這個測試。
本指南涵蓋三種部署模型(氣隙、本地部署、自託管)、誰真正需要氣隙操作、在沒有連接的情況下完整的 ML 數據管線是什麼樣子,以及哪些工具在氣隙環境中會失效。
三種模型:氣隙、本地部署、自託管
這些術語在供應商市場中被互換使用。它們並不相同。
| 模型 | 基礎設施 | 運行時互聯網 | 數據留在組織 | 監管用途 |
|---|---|---|---|---|
| SaaS / 雲端 | 供應商的雲端 | 是 | 否 | 很少合規 |
| 自託管 | 您的服務器,任何位置 | 可選 | 是(有控制) | 有條件合規 |
| 本地部署 | 您擁有的硬體,在您的建築中 | 可選 | 是 | 通常合規 |
| 氣隙 | 您擁有的硬體,物理隔離網路 | 否 | 是 | 完全隔離 |
自託管意味著您在自己的服務器上運行軟體——但這些服務器可能在雲端數據中心,軟體仍可能進行外部連接(用於許可驗證、遙測、模型下載或依賴更新)。自託管不是氣隙。
本地部署通常意味著在您設施的硬體上運行的軟體。它仍可能進行出站更新或遙測連接。供應商文件中的「本地部署」通常只是意味著「您自己安裝它」。
氣隙意味著主機機器與互聯網沒有網路連接,在嚴格實施中,與任何外部網路都沒有連接。氣隙環境中的軟體在任何情況下都無法訪問外部服務——不是意外,也不是設計上的。
合規影響各不相同:
- 在雲端供應商基礎設施上自託管:仍受該供應商的法律義務和潛在政府訪問請求約束
- 有互聯網訪問的本地部署:仍可能洩露數據(有意或通過受損組件);不能滿足最高安全環境的「無數據出口」要求
- 氣隙:物理隔離;唯一攻擊向量是可移動媒體或物理訪問;滿足最嚴格的數據主權要求
誰真正需要氣隙操作
真正的氣隙要求出現在特定環境中:
國防和情報:與機密信息合作的政府承包商和機構在嚴格的網路分段要求下運作。AI 開發工具必須獲得在機密網路上運行的認證。
關鍵基礎設施:電網運營商、水處理設施和類似運營商越來越多地部署 AI 用於預測性維護和異常偵測。他們的操作技術(OT)網路通常與企業 IT 網路隔離,沒有互聯網連接。
金融機構和交易公司:高頻交易系統和某些風險模型在隔離網路上運行,以防止信息洩露並確保延遲控制。一些金融監管機構要求用於某些模型的數據保留在特定網路環境中。
法律和監管程序:處理特權或法院封存文件的律師事務所和訴訟支持團隊可能被要求在沒有外部連接的環境中處理這些文件。
具有嚴格數據治理的醫療保健:雖然 HIPAA 不特別要求氣隙操作,但一些在州級或合同數據處理要求下運營的醫療保健組織選擇了氣隙環境,作為保證數據隔離的唯一方式。
網路安全操作:處理威脅情報和事件數據的安全運營中心可能在隔離網路上運行,以防止對手訪問分析工具。
一家網路安全公司直接告訴我們:「大多數 AI 工具通過雲端處理推理,使數據本質上變成公開的。」對於訓練數據本身是敏感威脅情報或機密信息的組織,這是不可接受的風險——氣隙操作是唯一的替代方案。
完整管線:每個階段在沒有連接的情況下需要什麼
第一階段:文件攝入
氣隙環境中的文件解析意味著所有解析邏輯——包括 OCR——必須與應用程序捆綁並在沒有外部調用的情況下運行。
什麼會失效:雲端 OCR API(Google Document AI、Azure Document Intelligence、AWS Textract)。任何將 OCR 代理到外部服務的庫。在運行時檢查模型更新的文件解析器。
什麼有效:與應用程序捆綁的嵌入 OCR 引擎(Tesseract、EasyOCR、PaddleOCR)。從本地模型文件加載的佈局分析模型(用於多列 PDF、表格、標題)。在本地運行的掃描品質增強圖像預處理。
實際挑戰:嵌入 OCR 比雲端 API OCR 慢且有時準確性較低。對於數據無法離開網路的受監管企業,這是可接受的取捨。可以通過預處理掃描品質和使用特定領域 OCR 配置來提高準確性。
第二階段:清洗 和去識別化
PII/PHI 偵測和編輯需要可以在本地運行的 NLP 模型。用於識別姓名、日期、組織、醫療記錄號和其他敏感實體的命名實體識別必須使用本地加載的模型權重。
什麼會失效:雲端 NLP API(AWS Comprehend Medical、Google Healthcare Natural Language API、Azure Text Analytics for Health)。任何將文件發送到外部端點的 PII 偵測工具。
什麼有效:帶有本地加載 NER 模型的 spaCy、帶有從本地存儲加載的 GGUF 量化模型的 Hugging Face Transformers、用於結構化識別符的基於規則的模式匹配(電話號碼、SSN、醫療記錄號)。
對於氣隙環境,模型權重必須在初始設置階段通過批准的可移動媒體傳輸。之後,系統完全從本地存儲運行。
第三階段:注釋
注釋——人工標注文件用於 NER、分類、邊界框或問答對——本質上不需要互聯網連接。挑戰在於大多數注釋平台是需要活動連接的基於 Web 的 SaaS 工具。
什麼會失效:Label Studio Cloud、Scale AI、Amazon SageMaker Ground Truth、Labelbox、任何由外部服務器支持的基於瀏覽器的注釋工具。
什麼有效:沒有外部依賴的可自安裝注釋工具;內置在本地桌面應用程序中的注釋工作流;可以完全從本地主機提供服務且不加載外部資產的基於瀏覽器的工具。
注釋階段是許多氣隙管線崩潰的地方——團隊假設他們可以「直接使用 Label Studio 自託管」,而不檢查自託管版本是否進行外部調用用於分析、CDN 資產或許可驗證。
第四階段:合成數據擴增
使用 LLM 生成合成訓練數據是現代 AI 管線中最依賴互聯網的操作之一。雲端 LLM API(OpenAI、Anthropic、Google、Cohere)在氣隙環境中根本不可用。
什麼會失效:任何調用外部 LLM API 的擴增工作流。配置了雲端端點的 Distilabel 和類似庫。Hugging Face Inference API。
什麼有效:使用 Ollama 或 llama.cpp 的本地托管 LLM。從本地存儲加載的 GGUF 量化模型(Llama 3、Mistral、Qwen 等)。在本地 GPU 資源上運行的推理。
實際要求:
- 具有足夠 GPU VRAM 的機器(有用的 7B 模型最低 16GB;30B+ 模型需 48GB)
- 預先下載並通過可移動媒體傳輸到氣隙機器的模型權重
- 在沒有包管理器互聯網訪問的情況下安裝的 Ollama 或 llama.cpp(需要離線安裝包)
對於大多數文件擴增用例,在工作站 GPU 上運行的 7B 或 13B 量化模型就足夠了。品質低於前沿雲端模型,但足以生成結構化文件的訓練變體。
第五階段:匯出
匯出——從注釋數據集生成 JSONL、YOLO/COCO、CSV 或分塊文本——是最不依賴連接的階段。這也是稽核追蹤必須最終確定並與訓練數據一起匯出的地方。
什麼會失效:作為匯出步驟的一部分同步到雲端存儲(S3、Azure Blob)的匯出管線。使用基於雲端的工件注冊表的版本控制工具。
什麼有效:匯出到連接的存儲或氣隙內部網路共享的本地文件。使用 git 或類似工具的本地工件版本控制,不進行遠程推送。
真正氣隙 ML 設置的要求
設置氣隙 AI 數據準備環境需要在機器隔離之前進行計劃。隔離後,您無法下載依賴。
安裝前檢查清單:
- 所有應用程序安裝程序通過批准的可移動媒體傳輸
- 所有運行時依賴(Python 包、系統庫)已捆綁或預安裝
- 所有 ML 模型權重已下載並傳輸(NER 模型、OCR 模型、LLM)
- 注釋界面從本地主機提供所有資產(無外部 CDN 引用)
- 許可驗證配置為離線操作或永久許可
- 已建立內部文件和更新程序
硬體要求:
- 用於 LLM 擴增的 GPU 工作站或服務器(根據模型大小需 16-48GB VRAM)
- 用於源文件、處理數據和模型權重的充足本地存儲
- 用於多用戶訪問的內部網路共享(未連接互聯網)
操作程序:
- 通過可移動媒體審查流程進行軟體更新
- 模型更新在傳輸到隔離網路之前審查和批准
- 稽核日誌備份到內部存檔存儲
在氣隙環境中失效的工具
| 工具 | 失效原因 |
|---|---|
| Unstructured.io 雲端 API | 僅雲端文件解析 |
| Adobe Acrobat AI 功能 | 雲端 LLM 處理 |
| Label Studio Cloud | SaaS 平台 |
| Scale AI / Labelbox | 雲端注釋平台 |
| Cleanlab / Dataiku 雲端 | 用於品質評分的雲端處理 |
| 帶雲端 LLM 的 Distilabel | 需要外 部 LLM API |
| Hugging Face Inference API | 雲端推理端點 |
| GitHub Copilot / 任何編碼 AI | 需要互聯網連接 |
Ertas Data Suite 如何在氣隙環境中工作
Ertas Data Suite 從一開始就被設計為氣隙操作。它作為原生桌面應用程序安裝——安裝期間不需要 Docker,不需要包管理器互聯網訪問。所有 OCR、NER 和處理模型都已捆綁。注釋界面在本地運行。Augment 模塊使用帶有本地托管模型的 Ollama,不進行任何外部調用。
整個管線——攝入、清洗、標注、擴增、匯出——在任何階段都無需互聯網連接即可運行。稽核追蹤寫入本地存儲,並與數據集一起匯出。軟體激活支持離線許可,適用於許可服務器不可訪問的環境。
對於具有真正氣隙要求的組織,此架構不是一個功能——它是最低可行要求。任何在氣隙環境中進行未記錄的外部調用的工具不僅僅是不方便;它是一個安全事件。
Your data is the bottleneck — not your models.
Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.
相關閱讀
- AI 中的數據主權:為什麼受監管行業不能使用雲端數據準備工具 — 推動氣隙和本地部署 AI 部署的法律和監管要求。
- 本地 AI 數據準備:受監管行業的合規指南 — GDPR、HIPAA、歐盟 AI 法案和數據主權的完整合規概覽。
- 本地部署與自託管與氣隙 AI:差異的實際含義 — 部署模型及其合規影響的詳細比較。
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

5 Questions to Ask Before Buying an On-Premise AI Data Platform
A buyer's guide for evaluating on-premise AI data platforms: offline capability, accessibility, audit trails, export formats, and implementation support.

Running Ollama for AI-Assisted Data Prep in Air-Gapped Enterprise Environments
Step-by-step guide to deploying Ollama for AI-assisted data labeling in air-gapped environments — model transfer, offline setup, GPU configuration, and common failure modes.

How Cybersecurity Teams Build AI in Air-Gapped Environments
Cybersecurity teams deal with the most sensitive organizational data. Here's how to build AI data preparation and training pipelines that never touch the internet — including synthetic data generation with local LLMs.