Back to blog
    本地端 vs 自主託管 vs 氣隔:為敏感資料選擇正確的 AI 部署方式
    on-premiseair-gappeddeploymententerprise-aicompliancesegment:enterprise

    本地端 vs 自主託管 vs 氣隔:為敏感資料選擇正確的 AI 部署方式

    本地端、自主託管和氣隔被互換使用——但它們的含義不同,提供的合規保證也不同。以下是如何根據您的監管背景選擇正確的敏感 AI 資料工作負載部署模型。

    EErtas Team·

    三個術語不斷出現在供應商文件、採購核對清單和架構審查中:本地端、自主託管和氣隔。它們被互換使用。不應該這樣。每個術語描述了一個含義不同的部署模型,具有不同的合規含義、不同的操作成本,以及關於您的資料實際去向的不同保證。

    這種不精確性很重要,因為供應商利用它。標榜為「本地端相容」的工具可能意味著 AWS 上的 Docker。「自主託管選項」可能仍然需要供應商的授權伺服器在啟動時回撥。「氣隔支援」可能意味著二進制文件在沒有網路的情況下運行,但配置文件假設有網路連接進行更新。

    本文精確定義了每個術語,解釋了每種部署模型的合規含義,並根據您的監管背景提供了選擇正確模型的實用指南。

    精確定義

    本地端(On-Premise)

    本地端意味著軟體在您的組織擁有或租用的硬體上運行,在您控制的物理位置——您的大樓、您的伺服器室、您的資料中心。硬體是您的。物理空間是您的。網路流量保留在您的邊界內。

    關鍵特徵:資料中心是您的。伺服器是您的(或在您控制下租用的)。您不是從雲端供應商租用計算資源。AWS、Azure 和 GCP 部署從不算作本地端,無論您對配置有多少控制。

    這很重要,因為一些監管框架中的資料主權要求特別關注物理基礎設施所有權和司法管轄區,而不僅僅是邏輯訪問控制。

    自主託管(Self-Hosted)

    自主託管意味著您的團隊管理部署,包括安裝、配置、升級和維護。與本地端的關鍵區別:自主託管對基礎設施在哪裡沒有說明。AWS EC2 上的 Docker 是自主託管的。GKE 上的 Kubernetes 是自主託管的。Hetzner 上的 VPS 是自主託管的。這些都不是本地端的。

    自主託管意味著操作責任,而非基礎設施所有權。您的團隊運行軟體,而非供應商。但物理硬體可能由亞馬遜、微軟、谷歌或另一個雲端供應商在任何司法管轄區的資料中心擁有。

    這是供應商術語差距最具破壞性的地方。許多工具以「自主託管」進行市場推廣,好像它意味著本地端部署的隱私保證。它沒有。雲端供應商上的自主託管部署意味著您的資料駐留在該供應商擁有的硬體上,受到該供應商的資料協議約束,可能在該司法管轄區的法律程序下可訪問。

    氣隔(Air-Gapped)

    氣隔意味著運行時沒有網路連接。系統在物理上或邏輯上與外部網路隔離——包括網路、供應商更新伺服器和授權驗證端點。資料無法通過網路連接進入或離開系統,因為在操作期間沒有網路連接存在。

    氣隔是最嚴格的部署模型,對通過網路通道的資料外洩提供最強的保護。它在一些國防、情報和關鍵基礎設施背景中是必需的,並且在醫療和金融背景中越來越相關,在這些背景中資料的敏感性足以證明操作複雜性是合理的。

    注意:氣隔並不意味著永遠沒有網路。它意味著在敏感資料被處理的運行時,網路不存在或是隔離的。更新、補丁和初始安裝通常發生在單獨的網路上,或通過在受控程序下的物理媒體(USB、光碟)進行。

    為何供應商模糊這些區別

    市場激勵是直接的:「自主託管」在沒有仔細思考區別的買家看來像是「本地端」,而「自主託管」比真正本地端或氣隔軟體更容易構建和銷售。

    真正的本地端軟體必須在沒有任何雲端依賴的情況下工作——沒有授權伺服器、沒有遙測、沒有更新檢查、沒有 CDN 托管資產。它必須可以打包進行內部分發,可以安裝在沒有網路連接的網路上,並且可以在供應商無法訪問基礎設施的情況下維護。這構建起來更昂貴。

    氣隔軟體必須更進一步:在操作期間的任何時候都不假設有網路連接、沒有 DNS 查找、沒有外部 API 調用、沒有硬編碼的 CDN URL、沒有嘗試訪問網路的後台服務。許多聲稱氣隔支援的軟體工具在實踐中失敗,因為技術棧中某個依賴項嘗試訪問外部端點。

    在評估供應商聲明時,正確的問題是:

    • 軟體在操作期間是否進行任何網路調用?您能驗證這一點嗎?
    • 授權驗證是否需要連接到供應商伺服器?
    • 軟體是否傳輸遙測、錯誤報告或使用資料?
    • 軟體是否能在沒有任何網路連接的情況下正常運行 90 天而無需手動干預?
    • 當它無法訪問更新伺服器時會發生什麼——它會降級還是失敗?

    按部署模型的合規含義

    GDPR 和資料傳輸限制

    GDPR 第五章限制將個人資料傳輸到沒有充分性決定的第三國(EU/EEA 以外的國家)。在 AWS EU-West-1(愛爾蘭)上運行工作負載可能滿足 GDPR 資料居住要求,但它是自主託管部署,而非本地端。資料駐留在 AWS 硬體上,AWS 是一家在 CLOUD Act 等框架下受美國法律程序約束的美國總部公司。

    這是否可以接受取決於您的具體資料、您的法律團隊的解釋和您組織的風險容忍度。但它不等同於在您物理控制下的本地端存儲。

    對於受比 GDPR 基準更嚴格的國家資料主權要求約束的組織——德國 BSI 法規、法國 SecNumCloud 要求、某些政府機構指令——「在歐盟雲端自主託管」可能不滿足要求。只有在您物理控制下的硬體才能滿足這些要求。

    HIPAA:受涵蓋實體和業務夥伴

    在 HIPAA 下,當您使用雲端服務提供商存儲或處理受保護健康資訊時,該提供商成為業務夥伴。業務夥伴協議(BAA)是必需的。BAA 的存在意味著資料流向該提供商——他們有關於它的合同義務,但他們接收它。

    在提供 BAA 的雲端上自主託管(AWS、Azure 和 GCP 都提供)滿足 HIPAA 的 BAA 要求。但資料仍然駐留在雲端供應商的硬體上。雲端供應商仍然可以根據美國法律接收對資料的法律要求。他們的員工(在嚴格控制下)仍然可以訪問您的資料運行的基礎設施。

    本地端部署意味著受保護健康資訊永遠不會到達雲端供應商的基礎設施。沒有 BAA 需要談判,因為沒有第三方處理商。對於最敏感的臨床資料——特別是在患者隱私至關重要的研究背景中——這是一個有意義的不同態度。

    氣隔的本地端部署更進一步:沒有網路路徑可以讓受保護健康資訊被外洩,即使是意外的。這是最高敏感性臨床研究環境的適當模型。

    EU AI Act 第 10 條:訓練資料治理

    EU AI Act 第 10 條對高風險 AI 系統的要求包括整個訓練資料生命周期的資料治理義務。法規要求提供商記錄資料收集、準備、標記和品質保證過程。

    這本身不是部署模型要求——這是文件和治理要求。但部署模型影響您滿足它的能力。如果您的訓練資料準備發生在具有共享基礎設施的雲端平台上,重建資料處理決策的完整稽核軌跡比整個管道在您完全控制和記錄的基礎設施上運行更困難。

    對於建立高風險 AI 系統的歐盟組織,資料準備管道(不僅僅是模型訓練步驟)的本地端部署使第 10 條文件義務更易於管理。

    金融服務:FCA、DORA 和資料居住

    英國(FCA)、歐盟(DORA)和美國(OCC、FINRA)的金融服務監管機構對金融資料可以在哪裡居住以及必須如何維持操作連續性有不同的要求。DORA 特別解決 ICT 風險管理,並要求金融實體維持對其關鍵 ICT 依賴的控制。

    在大多數這些框架下,金融服務的雲端部署是允許的,但需要特定的合同條款、退出策略和操作彈性文件。對於最敏感的資料——交易算法、信用模型、客戶金融記錄——一些機構選擇本地端部署以維持明確的控制。

    氣隔要求:國防和關鍵基礎設施

    國防承包商、情報界供應商和關鍵基礎設施運營商(電網、水系統、醫療系統)可能被要求在機密或敏感隔間環境中操作 AI 系統。這些環境在設計上與非機密網路物理隔離。

    在這些背景中,「在政府雲(GovCloud、C2S 等)上自主託管」不是氣隔的——它仍然是聯網基礎設施。真正的氣隔意味著系統在沒有外部網路連接的硬體上運行,資料通過受控的物理媒體在記錄的監管鏈程序下移動。

    聲稱這些環境的氣隔支援的軟體必須被測試,而非信任。常見的故障模式包括啟動時的激活/授權檢查、嘗試回撥然後超時的遙測,以及進行 DNS 查找的依賴庫。

    比較表格

    維度本地端自主託管(雲端)氣隔
    硬體所有權您的組織雲端供應商您的組織
    資料居住保證是(物理控制)取決於供應商區域是(物理控制)
    GDPR 資料傳輸合規取決於充分性決定
    HIPAA(受保護健康資訊)不需要 BAA需要與雲端供應商的 BAA不需要 BAA
    資料可被雲端供應商訪問是(根據其條款)
    設置複雜性高(硬體採購)中等(DevOps)非常高(安全物流)
    維護負擔高(您的團隊)中至高(您的團隊)非常高(您的團隊,隔離)
    需要網路連接否(通常)是(操作期間)否(按定義)
    適合:受監管行業,資料主權技術熟練的團隊,無硬性主權要求國防、機密、最高敏感性

    按監管背景的實用指南

    處理受保護健康資訊用於 AI 訓練的 HIPAA 受涵蓋實體: 在 HIPAA BAA 覆蓋的雲端上自主託管技術上是合規的,但意味著受保護健康資訊到達雲端供應商的基礎設施。本地端更乾淨。氣隔的本地端適合最敏感的研究資料。

    受 GDPR 和 EU AI Act 約束的歐盟組織: 在歐盟區域雲端上自主託管滿足非主權資料的大多數要求。對於國家安全背景或具有更嚴格資料主權要求的行業(醫療研究、政府 AI 系統),本地端是適當的。

    具有模型風險管理要求的金融機構: 在大多數監管框架下,帶有適當合同和操作彈性文件的雲端是可接受的。對於競爭敏感性極高的專有模型,本地端更受青睞。

    具有機密要求的國防承包商和政府機構: 僅限氣隔。自主託管和本地端聯網環境不等同於機密設施要求。

    法律服務(特許權和保密性): 在您自己基礎設施上自主託管通常就足夠了。本地端提供更乾淨的特許權論證(資料永不離開事務所的物理控制)。氣隔很少是必需的,但在國家安全法律背景中存在。

    向供應商詢問什麼

    當供應商告訴您他們的工具支援您的部署模型時,請問:

    1. 「軟體在操作期間是否進行任何出站網路連接?」要求具體的答案,而非「它可以配置為離線運行」。
    2. 「授權驗證是否需要連接到您的伺服器?」如果是,那是對供應商基礎設施的依賴。
    3. 「您能提供軟體聯繫的所有外部端點的文件嗎?」安全團隊可以通過網路監控驗證這一點。
    4. 「這是否已部署在認證的氣隔環境中?您能提供參考嗎?」聲稱的氣隔支援和已驗證的氣隔部署是不同的。
    5. 「您的資料遙測政策是什麼?軟體傳輸什麼資料以及傳輸到哪裡?」這應該記錄在隱私政策或資料處理協議中,而非僅僅是口頭保證。

    這些問題的答案揭示了工具實際支援哪種部署模型,無論市場材料怎麼說。


    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.

    相關閱讀

    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