作者：Sunny Shih
iKala 團隊從產業第一線觀察到，醫院做第一個 AI 專案時，很多事情其實可以「先做再說」。
開一個 Cloud Account、串接模型 API、建立 RAG 知識庫，再替幾位測試者設定權限。只要資料準備好，一個能回答院內規章、協助搜尋文件或整理資訊的 PoC，很快就能跑起來。
麻煩通常出現在第二個、第三個專案。
研究團隊需要新的運算環境，行政部門也想導入生成式 AI，影像團隊準備把部分資料放上雲端。每個專案都各自建立帳號、IAM 權限、Network、Logging、KMS 與 Backup。半年後再回頭看，IT 團隊可能會發現：同一間醫院裡，已經長出了好幾套不同的雲端管理方式。
誰可以開新的 Cloud Account？不同專案的權限標準是否一致？Log 要留在哪裡？Encryption Key 由誰管理？Backup 怎麼做？成本又該算在哪個部門？如果每多一個 AI 專案，這些問題就得重新回答一次，當 AI 專案持續增加，底層治理很快就會成為擴大應用時的主要瓶頸。這正是 Landing Zone 要處理的問題。
Landing Zone 把 IAM、Network、Logging、KMS、Backup、Security 與 FinOps 等共通能力先建立起來，讓後續進入的 Data、AI 與其他 workload 有一套可以沿用的治理基礎。對醫療 AI 而言，這尤其重要：使用者看到的可能只是一個 RAG 或 GenAI 應用，但要讓它真正進入正式營運，底下還有一整套身分、資料、安全、稽核、復原與營運機制需要長期維持。
Landing Zone 是什麼？從單一專案走向一致的雲端治理
Landing Zone 是一套預先建立的雲端治理基礎，讓不同 workload 能在一致的架構與控制規則下部署及營運。先把各個雲端專案都會碰到的共同問題整理好：帳號與組織架構怎麼設計、誰能取得哪些權限、Network 如何區隔、Log 如何保存、Encryption Key 如何管理、Backup 如何規劃，以及 Cloud Cost 如何追蹤。
如此一來，新的 RAG、研究運算或 Data Analytics workload 進來時，就不必每次從零建立一套治理方式，而是先沿用既有的共同控制，再根據資料敏感度、臨床關鍵性、網路依賴與系統整合需求增加必要設定。
從架構來看，可以把 Landing Zone 拆成三個層次：
| 架構層 | 主要內容 | 核心問題 |
| Applications & Workloads | Research、GenAI、Data Analytics、Backup/DR、Migration | 哪些服務與 workload 要進入雲端？ |
| Shared Governance Controls | IAM、Network、Logging、KMS、Backup、Security、FinOps | 不同 workload 要共同遵守哪些控制？ |
| Cloud Operating Foundation | Organization / Account Architecture、Policy Baseline、IaC、Responsibility、Change & Exception Process | 整個雲端環境要如何建立、維護與管理？ |
最底層的 Cloud Operating Foundation 先把組織、帳號、Policy、責任分工與變更流程定義清楚；往上一層，IAM、Network、Logging、KMS、Backup、Security 與 FinOps 成為可以跨專案共用的控制機制；到了最上層，Research、GenAI、Data Analytics 等 workload 才在這套基礎上運作。
治理不再跟著專案一個一個重做，而是成為新 workload 可以直接繼承的能力。
第一個 AI 專案，或許還能靠幾位工程師把環境設定好；但當 RAG、研究平台、資料分析、Backup/DR 等十個、二十個 workload 陸續進來，醫院就很難再依賴個別專案團隊與工程師的經驗維持一致性。
Landing Zone 要解決的，正是這道從「一個專案做得出來」，走向「更多專案進來後，仍然管得住、維持得下去」的落差。
✦延伸閱讀：醫療產業為什麼需要上雲？拆解 AI PoC 到正式營運的醫療雲端架構
為什麼醫院、醫療體系特別需要 Landing Zone？
對多數企業來說，雲端治理做不好，可能帶來成本增加、權限失控或服務中斷；但在醫療場域，同樣的問題可能進一步影響掛號、醫囑、檢驗、影像、用藥與護理等臨床流程。因此，醫院考慮的不只是「系統能不能上雲」，還包括資料安全、系統整合、服務連續性與後續營運。
更現實的是，醫院的 IT 環境很少從零開始。HIS、PACS、Interface Engine、研究平台與各式醫療設備已經運作多年，新加入的 RAG、Data Platform 或 Cloud Computing 都必須與既有系統共存。專案愈多，IAM、Network、Logging、KMS、Backup 等治理問題也會一再出現。
如果每個專案各自建立 Cloud Account、權限與安全規則，短期或許運作正常，長期卻容易形成多套標準。等到需要進行 Access Review、資安稽核、Incident Response 或 Disaster Recovery 時，原本的差異就會成為管理負擔。
醫療體系需要 Landing Zone，正是因為「不一致」的代價特別高。 Landing Zone 將 IAM、Network、Logging、KMS、Backup、Security Policy 等跨專案控制建立成共同 Baseline，讓新的 AI 或 Data workload 可以直接沿用，再依資料敏感度、臨床關鍵性與系統需求增加必要控制。
| 控制 | 醫療 AI 要回答的問題 |
| IAM | 誰可以進入哪些 Cloud Resource？ |
| Network | Cloud、On-premises 與外部服務如何連接與隔離？ |
| Logging | 誰做了什麼？發生問題後能否追查？ |
| KMS | Encryption Key 由誰管理與使用？ |
| Backup / DR | 中斷後能否恢復到可提供服務的狀態？ |
| FinOps | 哪個 workload 消耗多少資源？成本由誰承擔？ |
到了 AI workload，FinOps 還可以再往執行期延伸。Rate Limit、Quota、Budget Alert 或 Timeout 等機制，可以避免模型或 Agent 異常呼叫持續消耗資源。
重點在於，這些控制不需要等到每個專案進來才重新討論。
在 Google Cloud 架構中，Project 可以作為 workload 與權限管理的重要單位；IAM Policy 與 Organization Policy 則可以沿著 Resource Hierarchy 套用，讓醫院把共通規則建立在 Organization 或 Folder 層級，再針對個別 Project 處理必要例外。
Landing Zone 管 Cloud Boundary，醫療 AI 還要畫清楚 Data Boundary
建立 Cloud Governance 後，下一個問題隨即出現：
哪些醫療資料可以進入這個 AI workload？
院內 RAG 的資料來源可能涵蓋 SOP，也可能延伸到病歷自由文本、檢查報告、研究資料與其他非結構化內容。其中可能含有姓名、病歷號或其他可識別資訊。
這時架構設計需要一路追到資料源頭：AI 是否真的需要完整原始資料？哪些內容可以最小化、遮罩或去識別化？處理應該在哪一層發生？Raw Data、Embedding、Prompt、Model Response 與 Log 又分別落在哪個資料邊界？
這些問題超出了 KMS 或 Cloud IAM 的處理範圍。
Cloud IAM 可以管理哪個 User、Group 或 Service Account 能存取某個 Resource；臨床資料還可能需要依科別、醫病關係、使用目的或緊急情境進一步決定 Authorization。
到了 RAG，這條權限鏈還得延伸到 Retrieval。使用者原本無權閱讀的內容，也不應透過 Vector Search 與 AI Response 被間接取回。
因此可以把兩層治理分開看：
Cloud Boundary：AI 在什麼環境裡運作？
Data Boundary：AI 可以取得哪些資料，又能如何使用？
如果未來需要進一步整合標準化醫療資料，Google Cloud 的 Cloud Healthcare API 支援 FHIR、HL7v2 與 DICOM 等資料類型，目前也提供 Taiwan (asia-east1) Region。
但 Region 只解決資料位置的一部分問題。資料存在哪裡、誰能存取、Key 由誰管理、資料如何被使用，仍然是不同的治理問題。
從 RAG 走向 AI Agent，還會多出 Action Boundary
RAG 主要處理「AI 可以取得什麼資訊」。當 AI 開始具備 Agent 能力，治理範圍會進一步延伸到「AI 可以執行什麼」。
Agent 可能透過 Model Context Protocol（MCP） 連接外部工具與資料來源，再呼叫 API、執行程式碼或與企業系統互動。Google Cloud 的 MCP Server 已支援新版 Model Context Protocol，讓 Agent 與不同工具之間能以較一致的介面交換 Context、呼叫 Tool。這也代表權限管理必須一路延伸到 Agent Identity、Tool Permission、API Scope 與 Human Approval。
如果 Agent 具備 Code Execution 能力，Runtime 本身也需要隔離。Google Cloud 的 GKE Agent Sandbox 可將 Agent 工作負載放進以 gVisor 為基礎的 Sandbox Runtime，並限制 Root Permission、Linux Capabilities、Host Network 與 Service Account Token 等高風險能力，降低 Agent 執行不受信任或 AI 產生程式碼時對 Host 與其他 workload 的影響。
另一個風險出現在 Agent 與模型、Tool 之間交換的內容。惡意指令可能藏在文件、Prompt 或 Tool Response 中，誘導 Agent 執行原本沒有預期的操作。Google Cloud Model Armor 可以在 Runtime Traffic 中檢查 Prompt、Response 與部分 MCP Tool Call，針對 Prompt Injection、Jailbreak 與 Sensitive Data Disclosure 等風險進行偵測與過濾；目前也能與 Agent Gateway 及 Google / Google Cloud MCP Server 整合。
因此，醫療 AI 的治理可以逐漸看成三條邊界：
Cloud Boundary：AI 在哪裡運作？
由 Landing Zone、IAM、Network、Logging、KMS 等共同控制建立執行環境。
Data Boundary：AI 可以取得什麼？
由 Data Governance、Clinical Authorization 與 Retrieval Permission 管理資料使用範圍。
Action Boundary：AI 可以執行什麼？
進一步管理 MCP / Tool / API 權限、Agent Runtime Isolation、Runtime Guardrails 與 Human Approval。
Landing Zone 打好 Cloud Boundary，Data 與 AI Governance 再往上延伸到 Data Boundary 與 Action Boundary。當醫療 AI 從單純回答問題的 RAG，進一步發展成能呼叫工具、執行任務的 Agent，治理架構也必須跟著進入 Runtime。
✦延伸閱讀：Google Cloud Next 2026：GKE、Cloud Run 如何支援 AI Agent？
Landing Zone 之後，醫療雲端還要回答哪些治理問題？
醫療機構談 Cloud，Data Residency 只是治理的一環。根據《醫療機構電子病歷製作及管理辦法》，除了電子病歷雲端資料的境內儲存原則與核准例外，醫療機構還需要處理風險控管、業務持續、雲端服務業者監督，以及服務終止後的資料移轉。
因此，架構設計還要回答更具體的問題：誰掌握管理權限與 Encryption Key？Backup 如何安排？Vendor 如何取得權限？服務結束後，資料如何移轉與刪除？
Workload Placement 也需要相同程度的判斷。一個查詢員工規章的 RAG，與核心 HIS、床邊系統或用藥交易系統，面對的風險與營運要求差異很大。臨床關鍵性、資料敏感度、Network Dependency、Integration Complexity 與 Recovery Requirement，都會影響選擇。
因此，iKala 團隊建議將「先判斷 workload，再選擇平台」列為設計原則。大型醫療體系可能需要 Landing Zone、Data/AI Foundation、FinOps 與 Hybrid Governance；IT 資源有限的醫院，則可採取較標準化的 Managed Cloud Foundation。
Landing Zone 提供共同治理基礎，真正的部署方式仍需回到每個 workload 的風險、資料與臨床需求。
✦延伸閱讀：Agentic Enterprise 是什麼？Google Cloud Next 2026 宣布開啟「代理式企業」新時代！
怎麼開始？從一個準備上線的 workload 驗證
醫院不需要等到整套 Landing Zone 建置完成才啟動 AI 專案。更實際的方式，是選擇一個準備從 PoC 進入 Production 的 workload，直接驗證治理機制能否落地。
以院內 RAG 為例，可以先確認 Use Case、Owner、資料來源與系統依賴，再檢查 IAM、Network、Logging、KMS、Backup 與 Cost Governance；到了 Pilot 階段，再同步驗證資料邊界、權限、品質、Human Review、Recovery 與 Exit。
對多數醫療機構來說，第一步未必要直接進入大規模 Cloud Migration。從一個具體的 AI / Data use case 開始，更容易看清楚現有架構缺少哪些能力、哪些控制可以共用，以及哪些問題必須在正式上線前處理。
iKala 如何協助醫療機構建立可持續的雲端與 AI 基礎？
iKala 可從 Cloud Readiness Workshop 開始，與醫療機構共同盤點 workload 的臨床與營運重要性、涉及的資料與系統、適合的部署位置，以及現有 Cloud Foundation 的治理缺口。
盤點完成後，再依實際需求逐步建立 Cloud Foundation / Landing Zone、Data & AI Foundation、Cloud Migration、FinOps 與 Managed Cloud Services 等能力。這樣的導入方式，可以讓架構與治理跟著真實 workload 逐步成熟，也避免在需求尚未釐清前，就投入一套過度複雜的雲端架構。
對準備將 AI 從 PoC 推向 Production 的醫療機構而言，可以先從一個問題開始：
下一個準備正式上線的 workload，目前還缺哪些治理條件？
從這個問題出發，才能進一步判斷哪些能力應該建立成共用的 Landing Zone Baseline，哪些需要留在 Data 或 AI Governance 層處理，以及後續如何擴展到更多 workload。
iKala，企業轉型的 AI 顧問！
身為 Google Cloud Premier Partner，iKala 不僅是您導入工具的推手，更是企業在雲端數位轉型旅程中的技術後盾。iKala 透過深度整合 Google Workspace 與 Google Cloud Platform 全球基礎設施，協助企業建構高可用性且具備高度彈性的現代化辦公環境。從基礎的混合雲架構設計、Identity & Security (IAM) 身分資安控管，到進階的 BigQuery 建置，我們專精於打破資料孤島，讓企業能利用 Gemini 模型實現自動化工作流與客製化 AI 模型開發。
iKala 提供從初期架構盤點、中期的 PoC 技術驗證，到後期在地化技術支援與成本優化建議的「一站式陪跑服務」，致力於降低導入門檻並確保轉型路徑與商業目標一致。選擇 iKala，您獲得的不只是領先的 AI 解決方案，更是加速創新、提升全球營運效率的長期策略盟友。
如果您正在尋找能加速創新與提升營運效率的 AI 解決方案，歡迎 聯繫 iKala，獲得量身打造的技術建議與實作協助。