許多工程團隊在開發 AI 功能時，往往先追求 Demo 成功，而忽略了進入生產環境後的可靠性與安全性。最常見的問題是「陰影 AI」（Shadow AI），指的是員工在未經公司許可的情況下，使用個人帳號或未經審核的第三方 AI 工具（如 ChatGPT 插件、未登錄的 LLM API）處理公司數據。這會導致攻擊面擴大，且企業完全不知道有多少敏感數據已流向外部模型。
要解決這個問題，不能單靠行政命令，而必須從基礎設施層面建立一套「可視化、可分類、可強制執行」的治理體系。
發現未知：找出所有 AI 觸點
治理的第一步是盤點。AI 服務通常隱藏在現有監控工具的死角中，建議從三個維度進行掃描：
第一是利用雲端存取安全代理（CASB, Cloud Access Security Broker）。CASB 位於使用者與雲端應用之間，能快速偵測到對 OpenAI、Anthropic 或 Hugging Face 等已知 AI 供應商的 API 調用。這能幫你快速回答「哪些團隊在用外部 AI」，但無法得知具體傳送了什麼數據。
第二是服務網格遙測（Service Mesh Telemetry）。對於自託管（Self-hosted）的模型，可以使用 Istio 或 Linkerd 等工具掃描 Kubernetes 叢集。透過檢查 Pod 的容器鏡像是否包含 TensorFlow、PyTorch 或 Triton 等關鍵字，以及審核網路策略（Network Policy）中是否存在允許外部連線的出口規則，可以發現內部悄悄運行的 AI 工作負載。
第三是 API 閘道審計（API Gateway Audit）。所有經過 AWS API Gateway 或 Kong 的流量都是金礦。透過分析日誌中對特定 AI 域名或具有大數據量 POST 請求的端點，可以建立完整的 AI 調用地圖。
數據分類：在寫入時就決定命運
分類數據如果等到事後才做，會產生巨大的技術債。正確的做法是在數據創建的瞬間就完成標記（Tagging）。
建議建立一套多維度的標記體系，例如定義數據等級（公開、內部、機密、限制級）、是否包含個人識別資訊（PII, Personally Identifiable Information）以及是否經過 AI 審核（AIApproved）。
為了避免批次掃描產生的時間差（導致敏感數據在被標記前就被 AI 訓練任務讀取），應採用即時分類策略。例如在 AWS 環境中，利用 S3 事件通知觸發 Lambda 函數，並調用 Amazon Comprehend 進行即時 PII 偵測。一旦發現敏感資訊，立即將文件移至隔離區（Quarantine）並標記為不可用於 AI。
強制執行：將標記轉化為權限控制
標記如果沒有強制執行力，就只是昂貴的標籤。應將這些標記直接整合進身份與存取管理（IAM, Identity and Access Management）策略中。
核心邏輯是採取「預設拒絕」原則。例如，在 S3 儲存桶策略中設定：若對象缺少 DataClassification 標記，則拒絕上傳；若 AIApproved 標記不為 True，則拒絕讀取。這樣即使開發者誤將機密數據放入訓練路徑，基礎設施層級的 IAM 策略也會在數據到達模型前將其攔截。
此外，應結合虛擬私有雲（VPC）端點控制，確保 AI 服務只能透過指定路徑存取數據，防止憑證外洩後被從外部網路非法調用。
優化開發者體驗：讓安全路徑成為最快路徑
過於嚴苛的限制會逼使開發者尋找繞道方法，進而增加陰影 AI 的風險。因此，必須將合規要求封裝在開發工具中。
建議為團隊提供封裝好的 SDK（如 SecureS3Client），讓開發者只需指定數據分類，而不需要手動處理標記格式、加密設定或複雜的上傳路徑。當開發者選擇「機密」等級時，工具自動將數據導向審核區（Staging Area）而非直接進入訓練區。當安全路徑比違規路徑更簡單時，開發者自然會選擇合規的方式。
策略即代碼：處理複雜的動態規則
靜態的 IAM 策略無法處理複雜場景（例如：數據超過 90 天需刪除、模型必須在過去 7 天內通過安全掃描才能上線）。這時需要引入策略即代碼（Policy-as-Code）引擎，如 Open Policy Agent (OPA)。
透過 Rego 等聲明式語言，可以定義複雜的邏輯：例如，僅當模型在模型註冊表（Model Registry）中狀態為「已批准」且環境為「生產」且監控已開啟時，才允許存取特定級別的數據。這種方式讓治理規則可以像程式碼一樣進行版本控制、單元測試，並透過 CI/CD 管道自動部署。
運維習慣：模型註冊表與風險分級
最後，技術控制需要配合運維習慣。建立一個模型註冊表（Model Registry）作為唯一事實來源，記錄模型的訓練數據來源、安全掃描結果與審核鏈。
同時，應實施基於風險的分級審核（Risk-Based Approvals）： 低風險（使用公開數據、開發環境）：自動批准。 中風險（內部數據、預發布環境）：自動掃描通過後批准。 高風險（客戶敏感數據、生產環境）：必須經過人工安全審核。
將 AI 治理指標（如：未經授權的存取嘗試次數、模型漂移分數）整合進 Prometheus 或 Datadog 等現有的可靠性監控面板中。將治理違規視為生產事故（Incident）來處理，而非僅僅是季度審計報告中的一項，才能確保 AI 系統在創新與安全之間取得平衡。
來源：infoq.com - Governing AI in the Cloud: A Practical Guide for Architects
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。