結論先行
企業討論 AI Gateway 時，最容易出現的誤解，是把「請求先經過網關」理解成「資料沒有離開企業」。實際上，網關只是呼叫鏈上的控制點，不是天然的資料隔離層。
只要最終是外部 Provider 在執行推理，原始 prompt、system instruction、RAG 檢索片段、工具參數、上傳檔案或模型輸出，都有可能在鏈路中的某一層被處理、快取或記錄。
真正要審查的不是「有沒有 Gateway」，而是「哪一層能看到什麼、是否留存、是否用於訓練、是否跨境，以及合約與審計是否可追溯」。
判斷風險時，不要只看「用了哪個模型」，而要看「誰在鏈路中有機會看到你的資料，以及能保留多久」。
先判斷：這次呼叫是不是本地推理
第一步先區分，這次呼叫是不是在企業自控環境裡完成推理。如果模型和推理服務都運行在企業控制域內，資料邊界與外部 API 完全不同。
呼叫方式比較
| 呼叫方式 | 資料路徑 | 隱私邊界 | 適用場景 |
|---|---|---|---|
| 本地推理／本地模型服務 | 資料停留在企業控制域內，由企業自控算力完成推理。 | 預設不離開企業網路，外部 Provider 不直接接觸原始資料。 | 極高敏感資料、原始碼、核心財務、高監管業務。 |
| 企業自建 AI Gateway ＋私有部署模型 | 資料先到企業網關，再進入專屬模型實例或私有端點。 | 可透過專屬網路、專屬資源池和私有端點控制暴露面。 | 高敏感場景、需要審計和策略控制的生產流量。 |
| 企業 AI Gateway ＋外部 Provider API | 資料先到網關，再出網到上游 Provider 執行推理。 | 需要同時審查網關與上游 Provider 的日誌、訓練和跨境政策。 | 通用生產場景、中等敏感資料。 |
| 聚合平台／路由平台 ＋外部 Provider | 資料至少經過一個額外第三方，再進入最終模型 Provider。 | 多一層平台，就多一層需要審查的留存與子處理者政策。 | PoC、A/B 測試、低敏流量和快速試錯。 |
如果是本地推理，原始業務資料可以主要停留在企業控制域；如果是任何形式的外部 API，請預設資料至少會經過一家以上第三方，直到你把每一層都審查清楚。
再拆解：一次 LLM API 請求會經過哪幾層
一次典型的 LLM API 請求，至少會穿過四層。真正的治理工作，是把每一層分別審查清楚，而不是把所有風險都籠統歸咎於「模型廠商」。
一次請求經過的關鍵層級
| 層級 | 角色 | 可能接觸的資料 | 企業需要確認什麼 |
|---|---|---|---|
| 業務應用層 | 組裝使用者輸入、system prompt、RAG 上下文和工具參數。 | 原始業務資料、使用者標識、上傳檔案、檢索片段。 | 這一層是否已經做脫敏、欄位最小化和資料分級？ |
| AI Gateway／Policy 層 | 做身份驗證、路由、配額、重試、審計和策略控制。 | 請求全文、回應全文、token 用量、呼叫元資料。 | 日誌預設是否開啟？能否禁止記錄正文、按欄位脫敏和按租戶審計？ |
| 聚合／適配層 | 做統一協議、供應商切換、fallback 和成本路由。 | 可能接觸請求全文、模型選擇資訊和異常日誌。 | 是否還有額外第三方？是否列明上游 Provider 和子處理者？ |
| Model Provider 層 | 執行推理並回傳結果。 | prompt、上下文、附件、模型輸出。 | 是否用於訓練？是否短期留存？是否支援區域選擇、DPA 和專屬部署？ |
不同資料分級應走什麼鏈路
決定資料是否可以走外部 Provider，不應只看業務時效，更應該先做資料分級。資料等級不同，建議的呼叫鏈路也不同。
資料分級與呼叫方式
| 資料等級 | 典型資料 | 建議鏈路 | 原因 |
|---|---|---|---|
| P0 核心機密／高監管資料 | 原始碼、未揭露財務、個人敏感資訊、合約原文。 | 本地推理或專屬部署，不經公共 API。 | 不能把「平台承諾不訓練」當作充分控制。 |
| P1 內部敏感資料 | 客戶工單、內部報表、含少量個人資訊的知識庫。 | 自建 AI Gateway ＋已審查的 Provider，要求 no-train、受控日誌和合約約束。 | 需要在網關層做脫敏、審批和審計。 |
| P2 一般內部資料 | SOP、產品文件、非敏感研發知識。 | 可走 AI Gateway ＋外部 Provider API。 | 仍需設定日誌保留、區域和呼叫策略。 |
| P3 公開或低敏資料 | 官網文案、公開 FAQ、行銷素材。 | 可用聚合平台或多 Provider 路由。 | 重點在成本、可用性和模型品質，不在高合規要求。 |
對 P0 與高監管流量，不要把「平台承諾不訓練」視為充分控制；對 P1 與 P2，可以在完成脫敏、合約約束和審計策略後透過 AI Gateway 受控出網。
Provider 審查表
即使你已經部署 AI Gateway，上游 Provider 仍然需要單獨審查。網關是策略執行層，不是對上游合規責任的免責層。
企業至少要核查的 Provider Policy 項目
| 審查項目 | 企業至少要確認什麼 | 最低可接受標準 |
|---|---|---|
| 是否用於訓練 | 預設是否會用 API 資料訓練模型？哪些 SKU 或方案例外？ | 生產流量預設 no-train，並在條款或 DPA 中載明。 |
| 留存週期 | prompt、response、file、logs 各留存多久？能否關閉正文日誌？ | 能禁止記錄正文，或將留存最小化並明確 TTL。 |
| 資料駐留與跨境 | 資料處理和儲存發生在哪些區域？是否存在跨境子處理者？ | 能指定區域，跨境路徑清晰且可歸檔。 |
| 人工存取 | 支援、除錯或安全團隊能否人工查看樣本？ | 最小權限、審批控制和存取審計可追溯。 |
| 子處理者 | 是否還有代理商、雲端廠商或路由平台參與處理？ | 子處理者清單可查，責任邊界清晰。 |
| 合約與 DPA | 是否能簽署 DPA、SCC、企業附加條款？ | 高敏場景必須有正式合約約束。 |
| 私有化能力 | 是否支援 dedicated capacity、private endpoint、VPC/VNet？ | 高敏業務應提供更強的隔離能力。 |
| 審計與刪除 | 能否提供審計記錄、刪除請求和事件通知？ | 滿足內部審計和事件應變要求。 |
OpenRouter 類平台的價值和邊界
OpenRouter 這類平台的價值，是幫助團隊更快接入多個模型、做 A/B test、fallback 和成本路由；但它不能替企業完成資料分級和 Provider 審查。
OpenRouter 類平台能解決什麼，不能解決什麼
| 平台能力 | 帶來的價值 | 邊界 |
|---|---|---|
| 統一接入多家模型 | 降低試錯成本，加快切換不同模型與廠商。 | 不能替企業完成資料分級和上游 Provider 審查。 |
| 做成本／品質路由 | 便於 A/B test、fallback 和預算控制。 | 不代表所有 Provider 都符合相同的隱私標準。 |
| 加快新模型試用 | 讓產品團隊更快驗證場景和體驗。 | 不適合作為高敏資料的預設出口。 |
| 統一 API 形態 | 降低工程接入和切換成本。 | 統一協議不等於統一合約責任和日誌策略。 |
AI Gateway 對企業的實際作用
AI Gateway 的核心價值，不是「證明資料不出企業」，而是讓企業能決定哪些資料可以出、經誰出、以什麼策略出，以及出去之後如何追蹤、審計和止損。
AI Gateway 對企業的實際作用
| 能力 | 對治理的直接價值 |
|---|---|
| 路由與策略編排 | 讓不同資料等級走不同 Provider、不同區域或不同模型。 |
| 脫敏與最小化 | 在請求出網前裁剪 PII、金鑰、內部標識和無關上下文。 |
| 統一身份驗證和配額 | 減少散落的 API Key，便於權限治理和濫用防範。 |
| 審計與可觀測性 | 記錄誰在什麼時候呼叫了什麼模型、消耗了多少 token。 |
| 供應商切換與 fallback | 降低單一 Provider 故障或政策變動帶來的業務中斷。 |
| 成本治理 | 統一檢視預算、限額、快取命中與模型選擇。 |
企業評估清單
企業評估 AI Gateway 時，至少要先核查下面這 8 個參數。只有把這些問題逐項確認，才能判斷這條呼叫鏈是否適合進入生產環境。
至少先核查這 8 個參數
| 參數 | 企業需要確認什麼 |
|---|---|
| 原始請求是否離開企業網路 | 哪些流量必須本地處理，哪些允許出網？是否已經與業務 owner 對齊？ |
| 哪一層能看到 prompt／context／file | 網關、聚合平台、Provider、日誌系統分別能看到什麼？ |
| 是否記錄正文日誌 | 是否支援只記錄元資料，不記錄 prompt／response 正文？ |
| 日誌保留多久 | 預設 TTL、多環境差異和刪除機制是否明確？ |
| 是否用於訓練或模型改進 | 預設策略、企業方案例外和合約約束是否一致？ |
| 資料駐留在哪個區域 | 是否可指定 region？是否存在跨境子處理者？ |
| 是否具備合約和審計閉環 | DPA、SCC、審計日誌和事件通知是否可提供？ |
| 是否能做脫敏與分級路由 | 在出網前能否基於欄位、租戶或業務線執行策略？ |
上線前檢查清單
| 檢查項目 | 通過標準 |
|---|---|
| 資料分級矩陣已確定 | P0／P1／P2／P3 分類已與安全、法務和業務 owner 對齊。 |
| Provider 審查完成 | 條款、留存、訓練、區域和 DPA 已歸檔到同一份審查記錄。 |
| 網關策略已配置 | 脫敏、allowlist、限額、fallback 和日誌策略都已啟用。 |
| 高敏流量已完成隔離 | P0／P1 不走未審查的公共聚合路徑。 |
| 存取控制到位 | 只有經核准的應用程式和團隊可以呼叫對應的模型與路由。 |
| 監控與告警上線 | 異常呼叫、成本異常和策略拒絕有即時告警。 |
| 刪除與事件應變流程可執行 | 能處理資料刪除、誤發和外洩排查，並有責任人。 |
| 參考來源與條款版本留檔 | 對外 policy、內部審查結論和責任人可追溯。 |
FAQ
企業透過 AI Gateway 呼叫大型語言模型時，資料一定會被 Provider 看到嗎？
如果最終是外部 Provider 在執行推理，Provider 至少會處理生成所必需的輸入資料。網關可以減少暴露面、做脫敏和控制日誌，但不能把外部推理變成「完全不出企業」。只有本地推理或專屬部署，才能把原始資料主要留在企業控制域。
OpenRouter 類平台適合正式生產環境嗎？
適合低敏流量、多模型試驗、fallback 和成本路由，但不應直接成為高敏資料的預設出口。正式生產是否可用，取決於平台自身 policy、上游 Provider 組合、合約條款，以及你是否已經完成分級、脫敏和審計設計。
Provider 承諾「不用 API 資料訓練」，這樣就足夠了嗎？
不夠。訓練政策只是其中一項。企業還要確認日誌留存、人工存取、區域與跨境、子處理者、DPA、刪除流程和事件通知。只看 no-train，通常會漏掉真正的合規風險。
AI Gateway 能完全取代資料脫敏和權限治理嗎？
不能。AI Gateway 是治理執行點，不是治理策略本身。要先有資料分級、欄位分類、存取審批和業務規則，網關才能把這些規則落實成路由、脫敏、日誌和限額策略。
如何判斷某類資料該走本地推理還是外部 API？
先看監管義務和外洩代價，再看業務時效。如果資料屬於 P0 核心機密或高監管類別，應優先本地推理或專屬部署；如果是 P1 或 P2，可在完成脫敏、Provider 審查和合約約束後走 AI Gateway ＋外部 API；公開資料則可以用聚合平台提高效率。
最終建議
從架構視角看，AI Gateway 的價值不是替企業「證明資料絕不出境」，而是把原本分散在應用程式碼、供應商文件和人工流程裡的治理邏輯，統一收攏為一套可執行、可審計、可回滾的策略體系。
如果你的流量包含 P0 或高監管資料，應優先考慮本地推理或專屬部署；如果是 P1 或 P2 資料，就把重點放在脫敏、Provider 審查、日誌留存最小化和合約閉環；只有公開或低敏資料，才適合預設走聚合平台和多 Provider 路由。
最穩妥的方式，不是先挑「哪家模型最好」，而是先把「哪些資料能出、誰能看、能留多久、出去之後如何追責」定下來，然後再讓 AI Gateway 去執行這套策略。
參考來源
頁面底部保留來源區，方便團隊做政策比對、內部歸檔，也方便搜尋引擎與 AI 搜尋系統識別內容依據。