為什麼要從 Org Policy 開始，而不是先談 IAM

很多團隊導入 AI 專案時，第一件事是開一個新的 GCP 專案、建幾個 Service Account、然後開始寫程式碼呼叫 API。IAM 權限的細緻設計通常是「之後再補」——但這個順序本身就是風險：如果沒有組織層級的護欄（guardrail），任何一個工程師都可能在新專案裡不小心開出一個對外暴露的 Vertex AI Endpoint，或是在非核准的地區建立資料集，等你發現時已經是既成事實。

Organization Policy（Org Policy）解決的正是這個問題：它是在 Organization、Folder、Project 層級套用的預防性（preventive）限制，而不是事後偵測的反應性（reactive）控制。IAM 決定「誰能做什麼」，Org Policy 決定「即使有權限，這件事本身能不能做」。

AI 專案特別需要注意的幾個 Constraint

以下幾個 Organization Policy Constraint，對企業導入 AI 專案特別關鍵：

constraints/gcp.resourceLocations 限制資源只能建立在指定地區。對金融、醫療這類有資料落地要求的產業，這是確保 Vertex AI 資料集、模型端點不會意外建在境外區域的第一道防線。

constraints/iam.disableServiceAccountKeyCreation 禁止建立 Service Account 金鑰檔案。長效的 JSON 金鑰檔一旦外洩就是永久性風險，強制團隊改用 Workload Identity Federation 之類的短效憑證機制（Week 2 會深入講）。

constraints/compute.vmExternalIpAccess 限制哪些運算資源可以有對外 IP。避免用來跑本地推論或訓練工作的 VM 意外暴露在公開網路上。

constraints/gcp.restrictServiceUsage 限制專案內可以啟用哪些 API/服務。避免工程師在測試階段隨手啟用了未經安全審查的服務。

一個簡化的設定範例

實務上會透過 gcloud 或 Terraform 套用這些政策，概念上像這樣：

# 限制 AI 專案資源只能落在亞太區域

constraint: constraints/gcp.resourceLocations

listPolicy:

allowedValues:

\- "in:asia-east1-locations"

\- "in:asia-southeast1-locations"

# 禁止建立 Service Account 金鑰檔

constraint: constraints/iam.disableServiceAccountKeyCreation

booleanPolicy:

enforced: true

實際套用時務必先在 Folder 層級小範圍測試，確認不會擋掉既有的合法工作流程，再逐步推廣到整個組織。

Org Policy 不是萬能藥

要提醒一點：Org Policy 是護欄，不是防彈衣。它防的是「不小心做錯」，防不了「刻意繞過」的內部威脅，也不會檢查你的 Prompt 設計得安不安全。它是 Week 2、Week 3 那些更細緻控制（IAM、VPC-SC）的前置基礎——沒有這層護欄，後面再精細的權限設計都可能被一個新開的、沒被納管的專案繞過去。

明天用一張對照表，把台灣數發部剛發布的 AI 風險分類框架，跟 GCP 的原生控制項連起來看。