Day 1｜系列開場：為什麼談企業 AI 安全防線要從 GCP Security 談起

一個被問爛、卻問錯方向的問題

過去一年，只要跟企業客戶聊 AI 安全，十次有九次會先被問：「這個模型會不會被越獄？」「Prompt 會不會被注入？」

這些問題不是不重要，但它們只回答了戰場的一半。當企業把 Google AI Studio、Antigravity、Gemini Enterprise 這些服務真正搬進生產環境時，它們背後跑的終究是 GCP 的 IAM、VPC、KMS、Cloud Logging——如果平台層的權限設得太鬆、網路邊界沒圈好、金鑰散落在程式碼裡，模型本身再怎麼安全，都擋不住一個過度授權的 Service Account，或是一個沒有邊界的 Vertex AI 資料集。

這半年我在客戶現場看到的真實型態

在客戶的案子裡，我反覆看到同一種資安事故型態：不是模型被成功越獄，而是「誰能存取這個 AI 服務」這件事，從一開始就沒設計好。一個測試用的 Service Account 忘了關閉外部存取；一個 Vertex AI Endpoint 對外暴露卻沒接 WAF；一組 API Key 直接寫死被 commit 進公開 repo。這些都不是模型層的問題，是平台層的問題——而平台層的安全，恰恰是多數企業導入生成式 AI 時最容易跳過的一步。

這個系列要解決什麼

這 30 篇文章，會把企業導入 Google AI 需要的安全防線，拆成五個層次逐一講清楚：

每一篇都會有具體的 GCP 服務、設定範例，或是去識別化改寫的實務案例，不是純理論的安全宣導文。

這個系列的概念主軸：Google 自己的 SAIF

這五週的安排不是憑空拆分，背後對應的是 Google 自己提出的 Secure AI Framework（SAIF）——一套涵蓋六大核心要素的概念框架：擴展安全基礎至 AI 生態系、擴展偵測與應變至 AI 威脅範疇、自動化防禦以跟上威脅演進、統一平台層級控制、調適控制建立回饋循環、將 AI 風險置於業務流程脈絡中。這系列談的每一個 GCP 服務，都是這六個要素其中之一的具體落地方式：

換句話說，這不只是一份「GCP 服務操作手冊」，而是示範 SAIF 這套概念框架在真實企業場景裡具體長什麼樣子。

讀者會帶走什麼

系列結束時，我希望能帶給你一整套企業導入 Google AI 服務時可以直接參考的安全配置檢查清單——從 IAM 權限設計、VPC Service Controls 邊界、金鑰管理，到監控與合規對應，一次補齊。

明天從最基礎但最常被誤解的概念開始：GCP 的共同責任模型，在 AI workload 上到底怎麼劃分。