雲端運算的共同責任模型（Shared Responsibility Model）大家並不陌生：IaaS 層 Google 顧硬體、機房、實體網路，客戶顧 OS、應用程式、資料；PaaS 層 Google 多顧一些，客戶負責的範圍縮小；SaaS 層則幾乎全由 Google 負責。
但當企業開始使用 Vertex AI、Gemini API 這類「託管 AI 服務」時，很多團隊會不自覺地把心態切到 SaaS 模式——覺得「這是 Google 的 API，安全應該是 Google 的事」。這是一句危險的半真話：Google 確實負責底層基礎設施、模型服務的可用性、以及模型本身的訓練安全，但你決定送出哪些資料，你的資料怎麼送進去、誰能呼叫這個 API、輸出結果流向哪裡，這些永遠是客戶的責任。
用一張表把責任邊界攤開來看，會清楚很多：
| 責任項目 | Google 負責 | 企業負責 |
|---|---|---|
| 實體機房、硬體、網路骨幹 | ✅ | — |
| 模型服務可用性、底層運算資源 | ✅ | — |
| 模型本身的訓練安全與對齊（Google 自家模型） | ✅（部分） | — |
| IAM 權限設計、Service Account 管理 | — | ✅ |
| 誰能呼叫 API、從哪個網路呼叫 | — | ✅ |
| 訓練/推論資料的分類與保護 | — | ✅ |
| Prompt 內容、System Instruction 設計 | — | ✅ |
| 輸出結果的驗證與下游使用方式 | — | ✅ |
| VPC Service Controls、資料邊界設計 | — | ✅ |
| 稽核日誌保存與監控 | 提供工具 | ✅ 啟用與維運 |
看這張表就能理解，為什麼案例裡那些事故都跟「Google 沒做好」無關——它們清一色落在企業自己該負責的那一欄。
某家企業導入 Gemini API 做客服機器人，資安團隊做完滲透測試後回報「模型本身沒有明顯漏洞」，專案就直接上線了。三個月後才發現，串接 API 的 Service Account 用的是專案層級的 Editor 權限，而不是限縮到 Vertex AI 呼叫的最小權限——這不是模型的問題，是企業自己在 IAM 這一欄的責任沒做到。
理解責任邊界之後，Week 1 剩下的篇幅會依序建立威脅視角的共同語言：Organization Policy 護欄設計、 數位發展部最近公布的風險分類框架對照、12 項能力缺口地圖，以及 OWASP LLM Top 10 對照 GCP Security 控制項。這些都是為了在 Week 2 開始動手做 IAM 設計之前，先有一張完整的威脅地圖。
好累啊～一邊在AIA聽課寫作業一邊還要寫鐵人賽～～
iThome鐵人賽
看影片追技術