2026 IaaS KYC 會查什麼？海外 GPU 帳戶合規邊界

截至 2026 年 9 月 7 日，BIS《EAR》第 748 部分已明確涉及最終使用者、IaaS 遠端使用者，以及防止未授權存取等審查方向，詳見第 748 部分官方規則。這代表 2026 IaaS KYC 不能只準備付款收據：最快的處理方式，是立即核對最終使用者、企業控制關係、登入地點與受限用途，建立實名帳戶、禁止共用憑證，並保留任務與登入記錄。

這篇適合三類人：
平台管理員：需要設計帳戶與權限結構。
跨國研發團隊：需要處理多地區成員登入。
合規負責人：需要判斷平台補充資料是否合理，並形成可追溯的內部證據鏈。

最後更新於 2026 年 9 月 7 日。 本文核對 BIS《EAR》第 748 部分、BIS 反轉移指導、BIS KYC 與紅旗指引，以及相關身分和日誌管理文件。未來是否會出現統一的雲端 KYC 規則，目前仍未正式公布。

付款完成不代表審查結束

海外 GPU 平台可能在付款成功後，要求你補交公司註冊文件、最終使用者聲明、项目用途說明或登入地點資訊。這不必然表示平台已認定你違規，而是交易付款、合約簽署、GPU 實際使用與 API 操作，可能由不同主體完成。

常見結構如下：

• 付款主體是海外採購公司；
• 合約主體是母公司或區域子公司；
• 最終使用者是另一個研發法人；
• 實際操作者是分布在不同地區的工程師；
• GPU 任務服務的客戶，又可能是外部企業。

BIS 的反轉移行業指導要求企業留意交易對手、最終使用者及可能的轉移風險，而不是只看誰支付費用；可參考官方反轉移行業指導。因此，補件重點通常在「誰控制帳戶、誰使用資源、資源被拿來做什麼」，而非單一付款紀錄。

海外 GPU 平台為什麼要求提供最終使用者資料？
因為付款公司未必等於資源的實際使用者。平台需要判斷 GPU 是否會被交給未披露的第三方、是否存在轉售或代管情況，以及任務是否落入平台條款或適用出口管制所關注的用途。你應提供與審查目的直接相關的資料，不要把無關的個人敏感資料一併提交。

公司歸屬與控制關係

「公司在某地註冊」不等於「帳戶只由該地公司控制」。審查時可能需要釐清總部、母公司、關聯公司、簽約法人和實際營運團隊之間的關係。這是事實披露問題，不應自行把平台的補件要求解讀成某項法律定性。

可先建立一份內部控制關係表：

IaaS 平台通常如何判斷帳戶實際控制人？
通常會綜合觀察註冊及付款資料、合約法人、管理員身分、登入地點、API 金鑰使用模式、權限變更和任務用途。單一 IP 位址不能獨立證明控制人；但若管理員、付款人和實際任務執行者長期完全不一致，就需要準備合理說明。

BIS 的Know Your Customer 與紅旗指引提供的是風險識別方向，不代表每個平台都會收集相同欄位。平台自己的服務條款、適用規則和風險模型，會影響補件內容。

共享憑證與異地登入

多人共用一個管理員帳戶，短期看似省事，實際上會破壞責任追蹤。當平台看到多地區、不同裝置或不同時間帶使用同一組管理員憑證，就難以判斷是哪一位人員執行了任務，也無法在爭議發生時快速撤銷單一人員的權限。

多人共用 GPU 帳戶會有什麼合規風險？
主要風險包括無法識別實際操作者、離職後憑證仍然有效、API 金鑰被轉交，以及客戶任務與內部任務混在同一個操作軌跡中。這些問題未必直接代表違規，但會增加平台復核、暫停服務或申訴時的舉證難度。

跨國團隊從不同地區登入需要準備什麼？
你應先建立成員、職位、所在國家或地區、專案範圍及登入方式的對照表。對固定辦公地點、出差、輪班和受控跳板環境，分別寫清楚預期登入來源；不要事後才用一段籠統的「團隊全球分布」解釋所有異常。

可依照以下優先順序整改：

• 每位操作者使用獨立、可撤銷的個人身分；
• 管理員、研發人員和服務帳戶分開；
• 以最小權限分配 GPU、儲存空間、網路和金鑰權限；
• 對管理員及高風險操作啟用多因素驗證；
• 不透過聊天工具或私人郵件轉交長期 API 金鑰；
• 為短期任務設定到期時間，完成後立即撤銷；
• 對跨地區登入保留變更原因與審批記錄。

NIST 數位身分指南可作為身分驗證設計的參考；雲端 IAM 的權限管理最佳實務亦強調個別身分、最小權限和多因素驗證。這些文件是安全設計參考，不等於任何平台的完整 KYC 清單。

訓練用途與任務證明

平台最難處理的不是「你有沒有模型」，而是你能否用一致、適度的資料說明資源用途。至少要區分以下情況：

• 自用訓練：公司自己的模型、資料集和研發任務；
• 代客訓練：為已識別的客戶執行指定工作；
• 轉售算力：把 GPU 資源再分配給第三方；
• 託管服務：替客戶長期管理模型、資料和執行環境。

這四類模式在合約關係、資料責任、權限設計和平台條款下可能有不同要求。你不應為了通過審查而把代客訓練寫成自用訓練，也不應提交與用途無關的客戶機密、完整資料集或個人資料。

建議由專案負責人準備一頁用途說明，包含：

• 任務名稱與內部專案編號；
• 模型或程式碼的歸屬單位；
• GPU 是由誰使用、誰審批；
• 是否存在外部客戶或第三方受益人；
• 輸入資料的類型與資料責任人；
• 任務結束後如何刪除或移交產出。

經驗提醒： 用途聲明不宜只寫「AI 研究」或「模型訓練」。這種描述無法說明操作者、服務對象和資源流向；但也不需要把模型權重、客戶名稱或敏感資料直接交給平台。

日誌、申訴與帳戶證據鏈

當平台要求解釋一次異地登入或可疑任務時，只有付款收據通常不夠。你至少需要能夠把「哪個身分、在何時、從哪裡、以何種權限、執行了什麼動作」串起來。

建議確認以下記錄是否存在：

• 登入成功、失敗及多因素驗證事件；
• 管理員新增、刪除和權限變更；
• API 金鑰建立、使用、輪換和撤銷；
• GPU 任務提交、停止、重啟及所屬專案；
• 儲存空間、資料集和模型的存取事件；
• 重要資料傳輸的方向、時間和授權依據；
• 人員離職、轉組或專案結束時的回收動作。

NIST SP 800-92 日誌管理指南可用來規劃日誌生命週期。不過，保存週期、內容範圍和存取權限必須依照平台條款、適用法規及你所在組織的真實實踐決定，不能在沒有依據的情況下承諾固定保存年限。

可執行的整改清單

• [ ] 列出付款主體、合約主體、最終使用者和實際操作者。
• [ ] 以公司文件核對母公司、關聯方及授權代表。
• [ ] 為每位管理員和研發人員建立獨立身分。
• [ ] 移除共用管理員帳戶及長期共用 API 金鑰。
• [ ] 為不同專案分開權限、儲存空間和任務記錄。
• [ ] 登記跨地區成員的預期登入地點與工作情境。
• [ ] 要求專案負責人完成用途、模型歸屬和服務對象說明。
• [ ] 檢查登入、權限、任務及資料傳輸日誌是否能互相對照。
• [ ] 建立離職、轉組和臨時專案完成後的撤權流程。
• [ ] 對平台補件內容保留提交版本、內部審批與回覆紀錄。

分層帳戶模型與諮詢邊界

較穩妥的結構，是把企業主帳戶、專案帳戶、個人身分和臨時憑證分開，而不是讓所有人直接操作同一個管理員入口。

落地時可分三個階段：

開戶前：先完成法人、控制關係、最終使用者和用途資料的核對，再決定由哪個法人簽約。若付款公司與使用公司不同，應在內部先取得可供平台核驗的授權文件。

運行中：每月或依風險事件檢查成員、登入地點、API 金鑰、任務用途和外部服務對象是否變更。任何新增關聯公司或代客訓練模式，都應重新評估帳戶披露內容。

人員離職後：先停用個人身分，再撤銷臨時憑證和 API 金鑰，最後核對未完成任務、儲存空間及審批記錄。若由跳板或遠端開發環境進入 GPU 伺服器，也要同步檢查該環境的權限和日誌。

你應在以下情況尋求專業顧問，而不是只靠平台客服回覆：控制關係複雜、涉及多個司法管轄區、提供轉售或託管服務、任務涉及受限制用途，或平台要求提交與目的不明顯相關的敏感資料。可先參考Kvmjet 服務條款及幫助中心，再將具體帳戶情況交給合規或法律顧問判斷。

如果你目前使用的是臨時共享帳戶、跨地區共用金鑰或沒有完整任務記錄的雲端方案，短期可能較快開通，但長期會遇到責任不清、申訴證據不足和人員異動難以撤權等問題。相較之下，租用 Kvmjet 的 Mac 環境時，你仍應先按團隊人數、登入地區和任務類型設計實名身分與權限，但可把測試環境、遠端開發和特定專案分開管理，避免為了一次性 GPU 任務長期維護一套混亂的帳戶結構。若你正評估遠端開發環境，可先對照基礎設施服務說明，再決定自建、租用或維持現有海外 GPU 方案。